This document describes HiPay’s cryptographic policy. It is intended for technical staff or IT service providers.
SSL/TLS protocols and cipher suites implemented by HiPay are described hereafter.
Impending changes to HiPay’s cryptographic policy are also indicated as a warning.
Please note that some of these changes are outside of HiPay’s control and may be enforced by contractual or legal obligations.
TLS 1.0 support is a prime example, as it must be dropped by the end of June 2018 at the very latest, in compliance with PCI DSS requirements.
The information contained in this document is non-binding and subject to change, as the cryptographic scene evolves.
Please refer to the information on the POODLE attack for more details on how such situations may arise.
Acronyms and glossary of terms
RFC 2119 key words
Should they appear hereafter, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 / BCP 14.
Acronyms
- AEAD: Authenticated Encryption with Associated Data
- AES: Advanced Encryption Standard (as per FIPS publication 197)
- APT: Advanced Persistent Threat, typically state-sponsored agencies with million-dollar resources
- DH: Diffie-Hellman
- DH params: Diffie-Hellman parameters used for the initial key exchange in cryptographic communications
- EC: Elliptic Curve
- GCM: Galois/Counter Mode
- KEX: Key EXchange
- MAC: Message Authentication Code
- MITM: Man In The Middle – i.e., the attacker who gets between the client and the server to intercept traffic
- SSL: Secure Sockets Layer
- TLS: Transport Layer Security
Diffie-Hellman acronyms
- DHE: Diffie-Hellman Ephemeral (same as EDH)
- ECDHE: Elliptic Curve Diffie-Hellman Ephemeral (same as EECDH)
- EDH: Ephemeral Diffie-Hellman (same as DHE)
- EECDH: Ephemeral Elliptic Curve Diffie-Hellman (same as ECDHE)
Glossary of terms
- HiPay Enterprise: Advanced single solution designed to handle all your online payment needs
- HiPay’s tokenization servers: System allowing merchants to submit credit card data and get a secure token in return
- HiPay Professional: Platform created for start-ups and growing businesses to simplify integration and provide online payments in a few clicks
- Soft-cut: Soft cut-off date for a given protocol or cipher suite (date on which we would like to implement the change)
- Hard-cut: Hard cut-off date for a given protocol or cipher suite (date on which, no matter what, the protocol or cipher suite will have to be disabled by HiPay)
Key words for changes
- Discourage: The use of a given cipher will be discouraged by moving it down the list, making it less likely that a client will use it when connecting to HiPay’s systems
- Drop: A given protocol or cipher suite will stop being supported entirely
- Implement: A given protocol or cipher suite will be added to the list of supported protocols or cipher suites
- Keep: A given protocol or cipher suite will keep on being supported, with no changes
- Monitor: A given protocol or cipher suite is considered brittle, vulnerable or soon to be deprecated and will be kept closely monitored
Deciphering cipher suites
Cipher suites handle privacy (i.e., the encryption of data) and integrity (i.e., the signature/hashing of data).
Cipher suites are typically written as follows:
[SSL|TLS]_[KEX]_[SIG]_WITH_[CIPHER]_[HASH]
The following cipher suite
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
gets translated as:
- Use Transport Layer Security.
- Initiate key exchange with Elliptic Curve Diffie-Hellman Ephemeral.
- Sign the initial KEX with Elliptic Curve Digital Signature Algorithm.
- Encrypt data with 256-bit Advanced Encryption Standard in Galois/Counter Mode.
- Authenticate data with 386-bit Secure Hash Algorithm.
HiPay tries to prefer Elliptic Curve cipher suites, which offer better performance.
HiPay tries to prefer Ephemeral cipher suites, which offer Perfect Forward Secrecy.
HiPay tries to prefer AEAD cipher suites, which are stronger and harder to implement incorrectly in cryptographic libraries.
Whenever possible, HiPay will prefer ChaCha20-Poly1305 over AES256-GCM-SHA*.
AES in Galois/Counter Mode is prone to implementation errors wherein a single nonce reuse breaks the entire cryptosystem.
Cryptographic protocols
HiPay supports the following Transport Layer Security protocols.
TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | |
HiPay’s tokenization servers | ✔ | ✔ | ||
HiPay Enterprise | ✔ | ✔ | ||
HiPay Professional | ✔ | ✔ |
Diffie-Hellman parameters
The classic Diffie-Hellman (DH1024, DH2048, etc.) are not supported. Only Ephemeral Diffie-Hellman (DHE) and Elliptic curve Diffie-Hellman Ephemeral (ECDHE) are supported in order to enable Perfect Forward Secrecy.
Cipher suites
HiPay supports the following cipher suites.
The lists below only show supported ciphers, not the order in which they are sent to clients.
Cipher suites – HiPay’s tokenization servers
CHACHA20-POLY1305-SHA256
AES128-CCM-8-SHA256
AES128-CCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
DHE-RSA-CHACHA20-POLY1305-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
AES256-GCM-SHA384
AES256-SHA256
ECDHE-RSA-CHACHA20-POLY1305-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
AES128-GCM-SHA256
AES128-SHA256
Cipher suites – HiPay Enterprise
CHACHA20-POLY1305-SHA256
AES128-CCM-8-SHA256
AES128-CCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
DHE-RSA-CHACHA20-POLY1305-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
AES256-GCM-SHA384
AES256-SHA256
ECDHE-RSA-CHACHA20-POLY1305-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
AES128-GCM-SHA256
AES128-SHA256
Cipher suites – HiPay Professional
CHACHA20-POLY1305-SHA256
AES128-CCM-8-SHA256
AES128-CCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
DHE-RSA-CHACHA20-POLY1305-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
AES256-GCM-SHA384
AES256-SHA256
ECDHE-RSA-CHACHA20-POLY1305-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
AES128-GCM-SHA256
AES128-SHA256
Impending changes
This section references the upcoming changes to HiPay’s cryptographic support.
Changes – SSL/TLS protocols
This subsection covers changes to the support of SSL/TLS protocol versions.
Item | HiPay’s tokenization servers | HiPay Enterprise | HiPay Professional | Soft-cut | Hard-cut | Rationale |
TLS 1.0 | Drop | Drop | 15 May 2018 | June 2018 | As per PCI DSS requirements, TLS 1.0 is insecure and must be removed. | |
TLS 1.0 | Drop | June 2018 | October 2018 | TLS 1.0 is vulnerable to BEAST. | ||
TLS 1.1 | Drop | Drop | Drop | December 2021 | March 2022 |
Does not support modern cryptographic algorithms. The Internet Engineering Task Force is planning to officially deprecate the protocol (cf this Internet-Draft). |
Changes – Key exchange
This subsection covers changes to the support of initial key exchange parameters during SSL/TLS negotiations.
Item | HiPay’s tokenization servers | HiPay Enterprise | HiPay Professional | Soft-cut | Hard-cut | Rationale |
Common DH 1024 primes | Drop | Keep | Keep | 15 May 2018 | June 2018 | As per PCI DSS requirements, common 1024-bit prime fields are too weak to ensure protection against APTs and MITM attacks. |
Common DH 1024 primes | Drop | Drop | 2019 | None | Common 1024-bit DH primes are exposed to APTs and MITM attacks. | |
Common DH | Drop | Drop | Drop | December 2021 | March 2022 | Does not enable PFS |
Changes – Cipher suites
This subsection covers changes to HiPay’s supported cipher suites for encryption and message integrity mechanisms over SSL/TLS connections.
Item | HiPay’s tokenization servers | HiPay Enterprise | HiPay Professional | Soft-cut | Hard-cut | Rationale |
CHACHA20 | Implement | Implement | Implement | 2019 | N/A | We need an alternative AEAD to AES-GCM, which is excessively brittle with regard to implementation failure. |
AES-GCM | Monitor | Keep | Keep | N/A | N/A | AES-GCM is one bit flip away from IV reuse and catastrophic crypto failure: be prudent when implementing. |
DES and 3DES (TDEA) |
Drop | Drop | Drop | Q3 2018 | Q1 2019 | DES and 3DES cipher suites are provably insecure and are being sunset by NIST. |
SHA, SHA1 |
Drop | Drop | Drop | Q4 2021 | End of Q1 2022 | SHA-1 used in digital signatures is not considered “Strong Cryptography” for purposes of PCI DSS. |
RC4 |
Drop | Drop | Drop | Q4 2021 | End of Q1 2022 | Due to the latest attacks on RC4, Microsoft has issued an advisory against it. The PCI DSS also prohibits the use of the RC4 bulk cipher. |
CAMELLIA |
Drop | Drop | Drop | Q4 2021 | End of Q1 2022 | Neither known nor recognized nor supported to a sufficient extent. |
SSL/TLS test links
HiPay offers merchants several links to test their SSL/TLS implementation.
Please note that these links do not work like our staging and pre-production systems, they do not offer the possibility to test transactions.
They merely allow you to ensure that your tools can negotiate a TLS protocol and associated ciphers with HiPay.
TLS 1.3
This vhost implements the final version of TLSv1.3 as per RFC8446:
DH prime fields
Please use the following links to test your ability to connect to HiPay when using 2048 and 4096 bit DH primes:
HiPay's platforms
Please use the following links to test your ability to connect to our Tokenization, Enterprise and Professional servers.
Tokenization servers: https://token-ssl.hipay.com/
HiPay Enterprise servers: https://gateway-ssl.hipay.com/
HiPay Professional servers: https://wallet-ssl.hipay.com/
Getting help and technical support
Should you have any questions or need help interpreting this document, please do not hesitate to contact HiPay by submitting a request through our Support Center.
Literature and further reading
On AEAD ciphers: https://blog.cryptographyengineering.com/2011/12/04/matt-green-smackdown-watch-are-aead/
On the brittleness of AES-GCM and AES-GCM-SIV: https://eprint.iacr.org/2017/708.pdf
On the BEAST attack: http://vnhacker.blogspot.fr/2011/09/beast.html
On the BIRTHDAY attack: https://danielmiessler.com/study/birthday_attack/
On the ChaCha20 cipher suite: https://blog.cloudflare.com/it-takes-two-to-chacha-poly/
On the deprecation of DES and 3DES: https://csrc.nist.gov/news/2017/update-to-current-use-and-deprecation-of-tdea
On the untrustworthiness of Dual_EC_DRBG: http://rump2007.cr.yp.to/15-shumow.pdf
On the LOGJAM attack: https://weakdh.org/
On the LUCKY13 attack: https://arstechnica.com/information-technology/2013/02/lucky-thirteen-attack-snarfs-cookies-protected-by-ssl-encryption/
On Perfect Forward Secrecy: https://scotthelme.co.uk/perfect-forward-secrecy/
On the POODLE attack that killed off SSLv3: https://blog.qualys.com/ssllabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack
On the sunset of TLS 1.0: https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls
On the SWEET32 attack against 3DES: https://sweet32.info/
On recommended cipher suites for TLS 1.3 : rfc8446, appendix-B.4
Comments
0 comments
Article is closed for comments.