Key management is important topic when it comes to protection of critical assets at rest, or during transfer. However, it is very often omitted and we are exposing sensitive data to potential attackers. The reason is probably lack of experience and knowledge in the field of cryptography which is tightly connected with that.
We are working with cryptographic keys in almost all applications nowadays. It does not matter if it is for the purposes of establishing secure transmission, like in SSL/TLS protocols, or for secure storage of sensitive personal data using AES cipher, we need to be aware of the following in connection with our keys during their life cycle:
- what was the procedure and algorithm to generate keys?
- where and how are keys stored?
- is someone able to get the cleartext keys?
- who is authorised to work with the keys?
- what are restrictions on how and when keys can be used?
- what is the renewal and revocation procedures?
- how are keys destroyed at the end of their life?
- what to do in case of compromise of keys?
How we are working with keys
In general, there are different ways how we are trying to work with cryptographic keys:
- We do not care, and we store clear-text key inside configuration, or database
- We feel the responsibility for the keys, so we encrypt them with master key and store only cryptogram inside configuration or database, however the master key remains obfuscated in configuration
- We are aware of software key stores, so we are using them in order to protect at least the integrity of our keys, however password for software key store is obfuscated, or is written in clear-text in configuration file
- We know that the hardware security modules (HSMs) are designed to protect clear-text keys inside secure, and commonly certified, boundary, so we use them in more critical applications, however we are storing credential to use these keys in configuration file
Integrity and Purpose
As you can feel, there are many topics we need to discuss and design when we would like to work with cryptographic keys correctly. We need to ensure that during all phases of life-cycle their integrity and confidentiality will remain, and that keys can be used only in authorised way.
But now, let’s discuss how we can be sure that someone wouldn’t use the key for different purposes as should be.
When key is used for multiple purposes, the. potential attacker can gain additional material, based on different operations, that can weaken the key and increases the likelihood of getting the clear-text key. In that case we are decreasing the strength of the security in application and of course we are decreasing security of our critical assets. Moreover, we are not able to enforce any policy associated with cryptographic keys that should be followed.
A good example what can go wrong is Triple DES data encryption (or TDEA, if you prefer). Triple DES key is a concatenation of 3 single DES keys which should be used in a specific order. In case you do not have control on how such key can be used, how you will ensure that the application is not using only first part of the key?
Assigning attributes to keys
The situation can be simpler when we are using key stores. Why?
Key stores are usually protected by some password-based encryption (PBE). If you provide a password, it will be used to derive cryptographic key that is used to encrypt secret and private keys inside key store container.
But what is more important, key stores are assigning attributes to keys so it can be used only in a way that was supposed to.
Another example can be the PKCS#11 interface. PKCS#11 defines keys as objects that can have attributes. For example if we take a general Private Key object, we can define the following attributes related to private key functions in order to achieve signing but not decryption (only small subset of all attributes, refer to PKCS#11 documentation):
- CKA_DECRYPT = false
- CKA_SIGN = true
In that case PKCS#11 will stop us if we would like to use the key for decryption purposes as this is not allowed.
Attributes can have a different purpose, and using the combination of attributes we should be able to comply with our policy and enforce correct and secure use of cryptographic key:
- and many more
What is Key Block
When it comes to protect keys that are stored as a cryptogram, we can follow the rules that are applied for key stores or defined in cryptographic standards and interfaces. In most cases, cryptogram are products, or maybe better to say exports of keys that were product by HSM and are protected by master key which will never leave the secure boundary of HSM.
Therefore, we can work with the key only in HSM, the procedure is simple:
- send cryptogram to the HSM
- HSM will use its master key to get the clear-text of the key inside secure memory
- HSM performs operation using the key
- clear-text key is destroyed from secure memory of HSM
- result is sent back
Key Block is a structure defined around the key itself that should ensure the following:
- integrity of the key, so cryptogram cannot be altered
- attributes that can be used to control boundaries how the key can be used
Header of the Key Block can be used to define policy that should be met using the key, such as attributes mentioned above. The whole structure integrity is protected by MAC, which is calculated using the key inside HSM, and it ensures that no one would be able to change the behavior of the key defined by Key Block.
It is very similar how digital X.509 certificates are protected. These are the usual certificate attributes:
- Serial Number: Used to uniquely identify the certificate.
- Subject: The person, or entity identified.
- Signature Algorithm: The algorithm used to create the signature.
- Signature: The actual signature to verify that it came from the issuer.
- Issuer: The entity that verified the information and issued the certificate.
- Valid-From: The date the certificate is first valid from.
- Valid-To: The expiration date.
- Key-Usage: Purpose of the public key (e.g. encipherment, signature, certificate signing…).
- Public Key: The public key.
- Thumbprint Algorithm: The algorithm used to hash the public key certificate.
- Thumbprint (also known as fingerprint): The hash itself, used as an abbreviated form of the public key certificate.
The certificate data is ensured by the signature on top of all attributes by private key of certification authority.
Key Block has the same goal.
There are few standards that can help us to use Key Block structure, so we do not have to invent wheel again. On the other hand, we have also regulation which can force us to change our key management policies and procedures and adopt key attributes.
TR-31 Key Block
When it comes to Key Block format, TR-31: Interoperable Secure Key Exchange Key Block Specification is the most popular. It provides a comprehensive guideline on how to define Key Block structure. It was developed by American National Standards Institute (ANSI) to support and streamline the interoperability in heterogenous environment of security modules.
PCI PIN Security Requirements
Payment Card Industry PIN Security Requirements applies to every entity working with the PIN and PIN Block in scope. The requirement 18-3 applies for the mandatory use of Key Block formats:
“Effective 1 January 2018, encrypted symmetric keys must be managed in structures called key blocks. The key usage must be cryptographically bound to the key using accepted methods.
Acceptable methods of implementing the integrity requirements include, but are not limited to:
- A MAC computed over the concatenation of the clear-text attributes and the enciphered portion of the key block, which includes the key itself,
- A digital signature computed over that same data,
- An integrity check that is an implicit part of the key-encryption process such as that which is used in the AES key-wrap process specified in ANSI X9.102.”
PCI revised the requirement and provided 3 implementation phases in order to support companies to migrate key management to Key Blocks.
- Phase 1 – Implement key blocks for internal connections and key storage within service provider environments. This would include all applications and databases connected to hardware security modules (HSM). Effective date: June 2019.
- Phase 2 – Implement key blocks for external connections to associations and networks. Estimated timeline for this phase is 24 months following Phase 1, or June 2021.
- Phase 3 – Implement key blocks to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Estimated timeline for this phase is 24 months following Phase 2, or June 2023.
Ready to Help
We believe that the proper key management would help you to secure critical assets and provide a robust framework for managing all different cryptographic keys, internal and external.
We are here to help you with it! Our broad experience and knowledge about key management can help you to better understand, be more effective, and have a better control about what is happening with your keys in every stage.
Don’t hesitate and ask us how to work with you keys.