ATM Security Through Cryptography – and the Upcoming TR-31 Deadline

The logical security in an ATM, which helps assuring that transactions are legit and cash is dispensed and funds transferred as intended, is based on cryptography – a discipline that mixes mathematics and computer science.

Cryptographic Algorithms

Different cryptographic algorithms are used for different purposes, but the basic tasks are Encryption, Decryption, Hashing, Signing and Verification.

Encryption and Decryption assures that sensitive data can be transported between Alice and Bob in encrypted form, using a non-protected communication line – without the risk that Eve can eavesdrop on the communication and obtain the clear-text content of the data being transported.

Hashing is used to calculate a fixed-length fingerprint over data, in a way that assures that any small change in the data will result in a completely different Hash value.

Signing is how Alice, the sending party, proofs to the receiver that she’s legit, and Verification is how Bob, the receiving party, verifies that the data indeed comes from Alice.

The most important characteristic for any cryptographic algorithm is that it must be a one-way function, meaning that the original message cannot be recovered from the encrypted message unless you have the right key.

Symmetric and Asymmetric Cryptography

There are two basic flavors of cryptography, Symmetric and Asymmetric.

Symmetric cryptography (3DES or AES) requires that Alice and Bob each have the same symmetric key, and use it for the cryptographic steps that each of them must do.

Asymmetric cryptography (RSA or ECC) relies on an asymmetric key pair for each party, i.e. Alice and Bob each have their key pair consisting of a Public key and a Private key. The Private key is never shared, but the Public key can be shared with anybody.

There are two major differences between Symmetric and Asymmetric cryptography. One is speed, as Symmetric cryptography performs much faster than Asymmetric cryptography – and the other is data size limitation, as symmetric encryption can be done on any amount of data, whereas asymmetric encryption is limited to data amounts less than the key size.

Basic Key Requirements

The most important characteristics for cryptographic keys are that they must be random, meaning that the likelihood of a specific key value must be the same for all possible key values, and that the total number of potential keys is so high that guessing the right key is not doable within a reasonable time frame.

The former is obtained by using a TRNG (True Random Number Generator), which is tested and approved as such by 3^rd party labs, and the latter is obtained by moving to longer keys over time.

The original DES key from the mid 1970es had 56 bit, corresponding to about 7.2*10¹⁶ different keys, the currently most commonly used TDES key has 112 bit, which gives about 5.2*10³³ different keys, and the recently introduced AES128 key has 128 bit, corresponding to appr. 3.4*10³⁸ different keys.

So, by extending the key length from 56 bit to 128 bit, the number of potential key values increases by approx. 4700 billion billions – which is a pretty large number!

By the way, when it comes to ‘logical key strength’, it’s worth mentioning that the number of bit in a symmetric key is not directly comparable with the number of bit in an asymmetric key – due to the mathematics involved!

Key Management and Key Distribution

In practical solutions, keys need to be managed and distributed – i.e., they need to stay secret over their entire lifetime, and the relevant key(s) need to be available in the relevant place(s) for the ATMs to work as intended.

PCI requires that keys are handled in a proper and compliant way, i.e. they’re stored in certified HSMs and EPPs, and must be kept secret also during key distribution.

Both parties – the HSM used in the Host system and the EPPs used in the ATMs – must have relevant key(s) in place in order for the ATM solution to work as expected. In general, transaction related keys are generated in the HSM and then distributed to the EPPs.

The distribution itself can be done in a number of ways, from Manual Key Load (where key parts are entered directly on the EPP keyboard, and the resulting key is generated inside the EPP by combining the key parts) over loading of an encrypted key (based on a Key Encryption Key (KEK) already present in the EPPs) to Remote Key Loading (RKL) based on either Certificates (TR-34, cRKL) or Signatures (sRKL).

Manual Key Load is still widely used, even though it’s quite labor intensive – two key custodians must visit every single EPP on a regular basis, for each of them to enter their part of a Master Key (MK) directly on the EPP keyboard. The Session Keys (SK) are then loaded encrypted, using the manually loaded Master Key as transport key.

Alternatively, RKL allows the MK to be loaded using asymmetric encryption, as the HSM and the EPPs are able to recognize and accept each other based on either a Certificate or a Signature. RKL is performed via the same network that handles the ATM transactions, so all it requires is a one-time initial process where the EPP vendor signs a Certificate or Signature issued by the Host (HSM).

The upcoming TR-31 deadline – and why Key Blocks are being mandated!

A Key Block is a way to assure that a given symmetric key is only used for its intended purpose – in a cryptographically secure way – and X9.TR-31 (now X9.143) is the most common way of using key blocks in the payment industry.

It has always been ‘best practice’ in Key Management circles to have dedicated keys for dedicated purposes, but PCI now enforces the use of Key Blocks via their TR-31 deadline – by January 1, 2025, all ATMs must use Key Blocks when managing encrypted symmetric keys, in order to stay PCI compliant.

PCI has communicated related deadlines for Host systems and their external connections to Associations and Networks, but these deadlines are both in the past (June 1, 2019, resp. January 1, 2023).

So, to keep your ATMs from going dark, you need to assure that your EPPs as well as your symmetric key distribution process is using TR-31 when managing encrypted symmetric keys!