Key management

Prior to any secured communication, users must set up the details of the cryptography. In some instances this may require exchanging identical keys (in the case of a symmetric key system). In others it may require possessing the other party's public key. While public keys can be openly exchanged (their corresponding private key is kept secret), symmetric keys must be exchanged over a secure communication channel. Formerly, exchange of such a key was extremely troublesome, and was greatly eased by access to secure channels such as a diplomatic bag. Clear text exchange of symmetric keys would enable any interceptor to immediately learn the key, and any encrypted data.

The advance of public key cryptography in the 1970s has made the exchange of keys less troublesome. Since the Diffie-Hellman key exchange protocol was published in 1975, it has become possible to exchange a key over an insecure communications channel, which has substantially reduced the risk of key disclosure during distribution. It is possible, using something akin to a book code, to include key indicators as clear text attached to an encrypted message. The encryption technique used by Richard Sorge's code clerk was of this type, referring to a page in a statistical manual, though it was in fact a code. The German Army Enigma symmetric encryption key was a mixed type early in its use; the key was a combination of secretly distributed key schedules and a user chosen session key component for each message.

In more modern systems, such as OpenPGP compatible systems, a session key for a symmetric key algorithm is distributed encrypted by an asymmetric key algorithm. This approach avoids even the necessity for using a key exchange protocol like Diffie-Hellman key exchange.

Another method of key exchange involves encapsulating one key within another. Typically a master key is generated and exchanged using some secure method. This method is usually cumbersome or expensive (breaking a master key into multiple parts and sending each with a trusted courier for example) and not suitable for use on a larger scale. Once the master key has been securely exchanged, it can then be used to securely exchange subsequent keys with ease. This technique is usually termed key wrap. A common technique uses block ciphers and cryptographic hash functions.[6]

A related method is to exchange a master key (sometimes termed a root key) and derive subsidiary keys as needed from that key and some other data (often referred to as diversification data). The most common use for this method is probably in smartcard-based cryptosystems, such as those found in banking cards. The bank or credit network embeds their secret key into the card's secure key storage during card production at a secured production facility. Then at the point of sale the card and card reader are both able to derive a common set of session keys based on the shared secret key and card-specific data (such as the card serial number). This method can also be used when keys must be related to each other (i.e., departmental keys are tied to divisional keys, and individual keys tied to departmental keys). However, tying keys to each other in this way increases the damage which may result from a security breach as attackers will learn something about more than one key. This reduces entropy, with regard to an attacker, for each key involved.

However distributed, keys must be stored securely to maintain communications security. Security is a big concern[7][8] and hence there are various techniques in use to do so. Likely the most common is that an encryption application manages keys for the user and depends on an access password to control use of the key. Likewise, in the case of smartphone keyless access platforms, they keep all identifying door information off mobile phones and servers and encrypt all data, where just like low-tech keys, users give codes only to those they trust.[7]

In terms of regulation, there are few that address key storage in depth. "Some contain minimal guidance like 'don’t store keys with encrypted data' or suggest that 'keys should be kept securely.'" The notable exceptions to that are PCI DSS 3.2.1, NIST 800-53 and NIST 800–57.[8]

For optimal security, keys may be stored in a Hardware Security Module (HSM) or protected using technologies such as Trusted Execution Environment (TEE, e.g. Intel SGX) or Multi-Party Computation (MPC). Additional alternatives include utilizing Trusted Platform Modules (TPM),[9] virtual HSMs, aka "Poor Man's Hardware Security Modules" (pmHSM),[10] or non-volatile Field-Programmable-Gate-Arrays (FPGA) with supporting System-on-Chip configurations.[11] In order to verify the integrity of a key stored without compromising its actual value a KCV algorithm can be used.

The major issue is length of time a key is to be used, and therefore frequency of replacement. Because it increases any attacker's required effort, keys should be frequently changed. This also limits loss of information, as the number of stored encrypted messages which will become readable when a key is found will decrease as the frequency of key change increases. Historically, symmetric keys have been used for long periods in situations in which key exchange was very difficult or only possible intermittently. Ideally, the symmetric key should change with each message or interaction, so that only that message will become readable if the key is learned (e.g., stolen, cryptanalyzed, or social engineered).

A key management system (KMS), also known as a cryptographic key management system (CKMS) or enterprise key management system (EKMS), is an integrated approach for generating, distributing and managing cryptographic keys for devices and applications. They may cover all aspects of security - from the secure generation of keys over the secure exchange of keys up to secure key handling and storage on the client. Thus, a KMS includes the backend functionality for key generation, distribution, and replacement as well as the client functionality for injecting keys, storing and managing keys on devices.

Many specific applications have developed their own key management systems with home grown protocols. However, as systems become more interconnected keys need to be shared between those different systems. To facilitate this, key management standards have evolved to define the protocols used to manage and exchange cryptographic keys and related information.

KMIP is an extensible key management protocol that has been developed by many organizations working within the OASIS standards body. The first version was released in 2010, and it has been further developed by an active technical committee.

The protocol allows for the creation of keys and their distribution among disparate software systems that need to utilize them. It covers the full key life cycle of both symmetric and asymmetric keys in a variety of formats, the wrapping of keys, provisioning schemes, and cryptographic operations as well as meta data associated with the keys.

The protocol is backed by an extensive series of test cases, and interoperability testing is performed between compliant systems each year.

• 
  Individual interoperability tests performed by each server/client vendor combination since 2012
• 
  Results of 2017 OASIS KMIP interoperability testing

A list of some 80 products that conform to the KMIP standard can be found on the OASIS website.

• Barbican, the OpenStack security API.[36]
• KeyBox - web-based SSH access and key management.[37]
• EPKS - Echo Public Key Share, system to share encryption keys online in a p2p community.[38]
• Kmc-Subset137[39] - key management system implementing UNISIG Subset-137 [40] for ERTMS/ETCS railway application.
• privacyIDEA - two factor management with support for managing SSH keys.[41]
• StrongKey - open source, last updated on SourceForge in 2016.[42] There is no more maintenance on this project according to its home page.
• Vault - secret server from HashiCorp.[43]
• NuCypher
• SecretHub - end-to-end encrypted SaaS key management
• Infisical - end-to-end open-source secret management platform.

• Amazon Web Service (AWS) Key Management Service (KMS) [44]
• Bell ID Key Manager[45]
• Bloombase KeyCastle [15]
• Cryptomathic CKMS[46]
• Doppler SecretOps Platform[47]
• Encryptionizer Key Manager (Windows only)
• Google Cloud Key Management
• IBM Cloud Key Protect [48]
• Microsoft Azure Key Vault[49]
• Porticor Virtual Private Data[50]
• SSH Communications Security Universal SSH Key Manager[51]
• Akeyless Vault[52]

The security policy of a key management system provides the rules that are to be used to protect keys and metadata that the key management system supports. As defined by the National Institute of Standards and Technology NIST, the policy shall establish and specify rules for this information that will protect its:[13]

• Confidentiality
• Integrity
• Availability
• Authentication of source[53]

This protection covers the complete key life-cycle from the time the key becomes operational to its elimination.[1]

Bring your own encryption (BYOE)—also called bring your own key (BYOK)—refers to a cloud-computing security model to allow public-cloud customers to use their own encryption software and manage their own encryption keys. This security model is usually considered a marketing stunt, as critical keys are being handed over to third parties (cloud providers) and key owners are still left with the operational burden of generating, rotating and sharing their keys. IBM offers a variant of this capability called Keep Your Own Key where customers have exclusive control of their keys.

A public-key infrastructure is a type of key management system that uses hierarchical digital certificates to provide authentication, and public keys to provide encryption. PKIs are used in World Wide Web traffic, commonly in the form of SSL and TLS.

Group key management means managing the keys in a group communication. Most of the group communications use multicast communication so that if the message is sent once by the sender, it will be received by all the users. The main problem in multicast group communication is its security. In order to improve the security, various keys are given to the users. Using the keys, the users can encrypt their messages and send them secretly. IETF.org released RFC 4046, entitled Multicast Security (MSEC) Group Key Management Architecture, which discusses the challenges of group key management.[54]