Explanation and Best Practices regarding iDEAL Certificate use

If you offer products and services for sale online, you also obviously want to offer your customers a secure and trusted means of making online payments. iDEAL is a safe means of payment. What makes it so safe? We will explain this to you in this document.

iDEAL message traffic

iDEAL consists of a collection of agreements and standards (a protocol), which banks, Payment Service Providers and online businesses implement in their systems. The iDEAL protocol checks the sender, thus providing security on a guaranteed transfer from the bank account of a customer to the bank account of an online business or Payment Service Provider. Ultimately, the transfer is guaranteed by the transmission of digital data between the parties involved, which recognise each other. This transmission of digital data is referred to as iDEAL message traffic. Certificates are used to ensure confidentiality and integrity in the iDEAL message traffic. Confidentiality because it concerns the transmission of financial and personal data, and integrity to prevent messages and data from being intentionally or unintentionally altered while in transit.

Which certificates are used?

Digital certificates are used to secure message traffic between you and the iDEAL acquirer (often your bank). Such a certificate is comparable to a passport and is characterised by the fact that it links the owner's identity to a (security) key. iDEAL message traffic uses two certificates:

• TLS certificate
  The Transport Layer Security (TLS) protocol, which is a requirement for the TLS certificate, secures the internet connection between you and your acquirer. The TLS certificate is used to ensure that you establish a connection with the right party. The certificate shows that the party to which you connect owns the private key that goes with the public key in your possession. Your acquirer uses such a TLS certificate (formerly called an SSL certificate). Once the certificate has demonstrated that your counterparty is indeed your acquirer, the TLS protocol generates a key to encrypt the confidential data exchanged between you and your acquirer. As a result, the data cannot be intercepted and read by third parties. This ensures that your data are always received by the right party and that the confidentiality of your data is guaranteed. More information on the technical operation of TLS and its predecessor SSL can be found in the appendix.
• Signing certificate
  A signing certificate protects the content of the messages that are exchanged over a secure internet connection between you and the acquirer. This gives you and your acquirer certainty that the content of the message has not been tampered with. You use the private security key from the signing certificate to sign the messages you send to your acquirer. The public key of each participant in iDEAL message traffic is recorded by the recipient beforehand. The recipient (in this case your acquirer) can therefore use the public component of your signing certificate to verify the digital signature for the message and thus confirm that the message is from the right sender and that the content has not been altered by a (malicious) third party while in transit. It is essential that the private key (the confidential part of the signing certificate) is known only to the owner of the certificate. Signatures made with the private key can only be verified using the public key.

Which certificate types are used by whom?

Online business:

• Signing certificate

Acquirer:

• TLS certificate
• Signing certificate

As an online business you only need a signing certificate for the iDEAL message traffic sent from you to your acquirer. Your acquirer provides a comparable signing certificate on his end for the message traffic sent from your acquirer to you. Your acquirer also provides a TLS certificate, for a secure internet connection between you and your acquirer.

How can I obtain a signing certificate?

There are two options:

• You can obtain a signing certificate from a certificate authority.
• You can generate a self-signed certificate.

Both certificates are permitted for protecting the content of iDEAL message traffic.

What do I need to do once I have a signing certificate?

1. You should always register the public key of your signing certificate with your acquirer. This enables the acquirer to verify and decrypt your messages.
2. You must also register the public key of your acquirer's signing certificate in your own iDEAL implementation. This enables you to verify the signature of the iDEAL messages you receive from your acquirer.

Signing certificate requirements

The signing certificate you use must satisfy the following requirements:

• It must be a SHA256 certificate. Older hashing algorithms such as SHA-1 and MD-5 are not suitable for use with iDEAL.
• The (security) key length must be 2048 bits.
• The signing certificate must have a maximum validity of five years.

Certificate best practices

• Use a strong password to protect certificates containing the key (usually .pem files like those received from the certificate authority).
• Refresh your certificates regularly. It is recommended that they are refreshed every one to two years, and in any case at least once every five years.
• When establishing a secure connection with the acquirer's server, make sure that your server does not support reversion to the older SSL version 3 during the TLS handshake. This will not be supported by your acquirer either.
• Check the validity of your certificates regularly (ensure that they have not expired or are set to expire soon). In general, it is advisable to request or create new certificates a month before your certificates expire.
• Acquaint yourself thoroughly with the security and certificates chapter in the iDEAL Merchant Integration Guide. This contains essential information for correct functioning of the secure connection and signing of messages.

iDEAL Merchant Integration Guide

For more information on the use of certificates in iDEAL message traffic and on the generation of certificates, you can consult the iDEAL Merchant Guide, which can be obtained from your iDEAL contracting party.

Appendix – How is my connection secured?

This appendix describes how Transport Layer Security (TLS) and its predecessor Secure Sockets Layer (SSL) are structured. These technical details are not essential for you to be able to use iDEAL in your business. However, the decision was made to include this index in order to explain the principles on which the security of iDEAL is based as completely as possible.
TLS and SSL are cryptographic protocols that secure online communication. In highly technical terms, TLS encrypts parts of the network connection that are controlled by the Application and Transport layer. Encryption takes place through:

• asymmetric cryptography for the exchange of keys
• symmetric encryption for confidentiality
• message authentication codes for the integrity of messages.

Asymmetric cryptography or encryption means that a message that is encrypted using a certain key can never be deciphered (decrypted) by means of the same key. This is the reason for the use of a key pair, consisting of a private key and a public key. What is encrypted with the private key can only be decrypted with the public key, and vice versa. Ensuring that the private key is known only to the owner and that the public key can be used by anyone else makes it possible to verify that messages signed with the private key come from the actual owner of the certificate.

Symmetric encryption is used for confidentiality (information may not be read by third parties). Both the server and the client use the same key to encrypt and decrypt information. This usually concerns a session key, which is only valid while the session between the client and the server exists. Thanks to the short period of validity, it can be assumed that this session key is known only to the client and the server.

A Message Authentication Code (MAC) is a small piece of information created to authenticate a message and check that the message has not been tampered with. A MAC algorithm, often called a keyed hash function, uses a secrete key and a message of a random length that must be authenticated to create the MAC. This MAC is sent along with the encrypted message. The recipient also knows this secret key and can regenerate it on the basis of the decrypted message. If this MAC matches the MAC sent, the recipient knows that the message was not tampered with while in transit.

TLS starts with authentication between the client and the server through the exchange of certificates. Then, the client and the server negotiate on the encryption algorithm and both generate a symmetric key pair, which is used for both encryption and decryption of the information send and received, respectively

The figure below shows how a TLS secured connection is established:

The dotted arrows indicate that information is sent either unsecured or secured by an asymmetric key pair (with a public key certificate). The solid arrows indicate information that is encrypted with the symmetric key pair (symmetric session key). Thus the TLS certificates are only used during this handshake procedure (dotted arrows) to establish the secure connection. Afterwards, they are no longer used and the generated symmetric session keys are used instead, with integrity guaranteed by the MACs.

iDEAL message traffic version 3.3.1 must use at least TLS version 1.1