Introduction

Cryptographic key management is administering the entire life cycle of cryptographic keys in a cryptosystem. It includes key generation, storage, exchange, use, and replacing the keys in the system as and when required and protecting them from loss or misuse. “The proper management of cryptographic keys is essential to the effective use of cryptography for security. Keys are analogous to the combination of a safe. If the combination is known by an adversary, the strongest safe provides no security against penetration” – NIST Recommendation for Key Management.

Let’s take an example of a bank and a card personalization bureau where all credit/debit cards are being personalized as per the chosen payment scheme by the bank. There are two major parts here: data or profile to be personalized on the card and the cryptographic keys to be injected into each card. For this, the bank needs to share this information with the personalization bureau which is generally PCI and payment scheme (eg: VISA, Mastercard, etc.) certified. Here in this article, let’s take a close look at how the keys are getting securely exchanged between two entities.

Secure Key Exchange Process

As a prerequisite for the whole process, both entities are equipped with a Hardware Security Module (HSM), which is a dedicated cryptographic device to generate, store and process the keys – certified by PCI or FIPS 140-2 Level 3 or higher. These devices are generally looking like a CPU cabinet of a desktop computer and shall be installed in a physically and logically High-Security Area (HSA). Some of the leading HSM manufactures are Thales and nCipher.

To start the key exchange process, we need to have a transport key (ZMK) first. Either party can create this ZMK in the HSM by logging in to the system either by username-password or by smartcard depends on the provider. The keys must be generated as two or more key components or key shares with random numbers satisfying the statistical tests of NIST PUB 800-22. Once the component is generated in HSM, it can be printed or noted down by the respective key custodian in such a way that the component cannot be tapped or observed during the process by others. A key custodian is an individual responsible for a key or a key component during the key exchange process. Now all the generated ZMK key components (generally three components) along with computed Key Check Value (KCV) will be placed in separate pre-serialized, tamper-evident envelopes and handed over to the key custodians of the other entity by an approved process, for example, sending each component by different courier services to each custodian.

Once the key custodians of the second entity receive all the components, they will go and enter these components in the HSM and HSM will combine these components by XOR operation to make the actual transport key. After completion of this process, both entities have the same ZMK in their HSMs and this is verified by cross-checking the KCVs. It is very important to keep in mind that each key must be used only for the purpose it was created for and not for any other purpose. “Transport keys used to encrypt other keys for conveyance must be unique per established key zone and, optionally, unique per issuer within that zone. These keys must only be shared between the two communicating entities and must not be shared with any third organization” – PCI Card Production and Provisioning.

During the key or key components creation, sufficient care should be taken to set the key attributes and key usages. Key attributes define characteristics about how the key can be viewed, used, and managed (eg: Exportable, Modifiable, etc.). Key usage defines how the key can be used (eg: for encrypting, signing, or deriving other keys, etc.).

We haven’t exchanged the keys to be injected into the cards yet!

Come, let’s exchange the actual keys to be injected into the card during the personalization. The number of keys may vary depends on the bank or payment scheme but the process remains unchanged. The bank needs to create all their keys or they may already have the keys in their HSM and these keys cannot be shared as it is. We have the transport key! Yes, using transport key (ZMK) bank keys should be wrapped (encrypted) one by one, and the wrapped values along with the KCVs need to be shared with the personalization bureau. In practice, this exchange of wrapped keys happens over email or FTP to the key custodians. And the next step is unwrapping the wrapped keys received. For this, key custodians of the personalization bureau need to go to HSM again and unwrap all received keys using the initially created ZMK and verify the KCVs are matching with the bank’s KCV when they wrapped the keys with ZMK.

And the final step is to securely destroy any residue from the exchange process that might disclose a component or key so that an unauthorized person can access it. For example, cross-shredding if paper or overwriting with random data multiple times if electronically stored, etc.

 Conclusion

The key exchange process needs to be performed with utmost care and professionalism as it has a lot of external parameters involved in the process. In the event of any known or suspected key compromise, emergency key replacement activities should be initiated and notified to the relevant entities. The security or strength of any cryptography directly depends on the strength of the keys, mechanisms, and protocol associated with the keys and the protection available to the keys.

 

Next: Roles and Responsibility in a Cryptographic Key Management System. Stay tuned!