Practicality of using AES in the payment industry
With the payment card industry standard PCI PTS 5.x it is now required for vendors to support AES in products being certified.
AES, the “Advanced Encryption Standard” was created in 2001 by NIST (the American “National Institute of Standards and Technology”).
Until now, the payment industry has been dominated by the Triple DES algorithm, based on the Data Encryption Standard (DES) developed in 1975 by IBM and turned into a standard by NIST in 1976. Triple DES is still considered secure for another decade, so you could say it was about time to change to something more secure.
However deploying AES in the payment industry is not that easy.
AES supports three different key strengths: 128, 192 and 256 bits. Keys needs to be loaded into devices securely, and while one could load an AES key using secure key entry, even the lowest key size would mean typing in 32 digits twice, once for each key part of a key split in two.
This is error prone and not very practical.
Ideally AES keys should be loaded by public key mechanisms such as RSA, the pre-dominant public key cryptography algorithm used in the payment card industry.
The problems arise when one compares the key strength of AES with the strength of RSA.
A key strength comparison table was developed by NIST with a little help of NSA, the National Security Agency that employs the largest number of mathematicians in the world.
* source: https://www.keylength.com/en/4/
The table shows that RSA with 2048 bits is equivalent to 3DES with 2 keys (112 bits).
This means that in order to load an AES key with 128 bits key size, an RSA key of size 3072 bits should be used. Today the PCI PTS standard requires RSA keys to be only 2048 bits.
Recently there has been several organizations requiring the use of AES keys with 256 bit key size such as the new German Banking Industry Committee (Deutsche Kreditwirtschaft (DK)) standard and the new Austrian PSA offline PIN standard.
Using RSA to load an AES key that large would require an RSA key size of 15.360 bits.
No HSM exist on the commercial market that supports RSA keys with that key size.
The most commonly supported key sizes are 2048, 3072 and 4096. Some vendors extend the support to 8192 bits but support for 15.360 bits is unheard of.
How do we support the new solutions that organizations are requesting support for?
Currently the payment card industry allows loading AES keys of any size using RSA keys with a 2048 bit size which should not be allowed according to the NIST key size table.
The payment industry should start using elliptic curve cryptography (ECC) as elliptic curves has a smaller key size but the same strength as can be seen in the table above.
However with ECC there is no encryption scheme such as exist with RSA encrypting data using the public key.
The most common encryption scheme when using ECC is to use the elliptic curve parameters to generate a symmetrical (ephemeral) key such as for AES and then encrypt the data using that key.
The X9.24 standard specifies the concept of how this should work in general without specifying the mechanism involved.
The newest standard for remote key loading is the “ANSI TR-34 part 1” standard that currently only exists for RSA where key usage is tied to the key loaded.
TR-34 with RSA is compliant with X9.24 and use the same concept of introducing an ephemeral key for the data encryption. The standard allows the loading of an AES key but only with key size of 128 bits using RSA.
Rumors say a part 2 of the TR-34 standard is underway, dealing with remote key load using ECC.
To sum up, we are currently stuck with using RSA in Remote Key Load for a while, even though there is a mismatch between the key size of RSA used and the symmetric keys it should load.