HSMs in a Payment Industry

Hardware Security Module or HSM are at the hearts of the payment industry providing cryptographic functions to support network and point-to-point data security, while the complexity of the ciphers being put in place by them seems to be discouraging for many. This article aims to demystify HSMs as being hard to understand top-secret devices and provide high-level overview for their common better understanding.

Acting as a peripheral to a Host computer, the HSM provides the cryptographic facilities required to implement key management, message authentication and Personal Identification Number (PIN) encryption in real-time online environments. The HSMs are made physically secure by locks, electronic switches and tamper-detection circuits being also called as Tamper Resistant Modules (TRMs).

Why do we need HSMs? These devices have been required by Payment Networks for many years and are now essential to achieving the PCI DSS compliance – needed for network access and certification. They also serve as Local Master Keys (LMKs) storage – parent or grant parent keys to all keys used in your payment system. This functionality allows secure storage of all child keys in a Payment Host system, where those are being securely encrypted under a keys known to HSM and key custodians only. Common HSM implementation (e.g. Thales) uses symmetric two-key triple DES encryption for LMK keys storage. This is worth unimaginable 2^108 of possible keys – making an exhausting brute force (meet-in-the-middle) attack to require lengthy 5 years long search even for today’s supercomputers (interesting articles here and here).

Common HSM supports a number of standard cryptographic functions needed for secured payment operations that include:

• Verifying and generating Personal Identification Numbers (PINs) such as those used with bank accounts and credit cards.
• PIN translation from downstream encryption key under a card acquirer’s key.
• Generating encrypted card values such as Card Verification Values (CVV, CVV2, iCVV).
• Generating and key management for use in Electronic Funds Transfer systems.
• Generating and verifying Message Authorization Codes (MACs) for messages transferred via telecommunications networks.
• Serve as a hardware cryptographic accelerator for symmetric (DES/3DES) and asymmetric encryption (RSA).

All these operations are made with keys already encrypted under LMKs stored in a HSM so their disclosure is very unlikely. LMK keys are some of highest secrets for all payment institutions where their storage undergoes secured procedures involving multiple key custodians and security officers. Today’s LMKs are being generated on the HSM itself, split into parts, stored to special smart-cards and distributed from those, so exact LMK values were never exposed in their clear value. This also means that all production HSMs have to be loaded with appropriate LMKs and an accidental reset for any of these HSMs to its default LMK values can make a day for any payment service.

Lets see how HSM works on an example. The figure “Security keys hierarchy in a payment system” shows multiple LMK pairs being used for different cryptographic tasks. Typical payments cryptographic task is to translate a PIN-block created on Point-Of-Sale side (TPK) under the upstream PIN key (ZPK). Simplified procedure would be as follows:

1. HSM receives a PIN-block encrypted under TPK together with TPK encrypted under one of LMK key pairs and ZMK under another LMK pair.
2. HSM deciphers TPK key with particular triple DES key pair to get its clear value and uses this key to decipher a clear PIN-block.
3. HSM deciphers ZMK key with particular triple DES key pair to get its clear value and uses this key to encrypt a clear PIN-block again.
4. HSM responds to Host with a PIN-block encrypted under particular ZMK which can be now send upstream for further validation.

As you may see, there were no clear keys used in a whole procedure, making it all well secured.

To make the breaking of LMK keys even more complicated each task can use a different key scheme and key variant which changes few known bits of a key as per its usage. This means that slightly different key will be used e.g. for Terminal Master Key, Terminal PIN key and PIN Verification key making even same child key being encrypted with same master key having completely different result.

It is obvious that HSMs play an important role in today’s electronic payments industry and their presence is mandated by the largest payments networks. Their unique role also makes these devices very expensive making their usage for payment service development one of major project expenses. EFTlab recognized this opportunity and offers BP-HSM emulator for Hardware Security Module emulation for development to pre-production environments with implementation of the Thales RG8000 communication protocol to be compliant with majority of payment switches worldwide.