Cryptographic keys are a vital part of any security system. They do everything from data encryption and decryption to user authentication. The compromise of any cryptographic key could lead to the collapse of an organization’s entire security infrastructure, allowing the attacker to decrypt sensitive data, authenticate themselves as privileged users, or give themselves access to other sources of classified information. Luckily, proper management of keys and their related components can ensure the safety of confidential information.
Key Management is the process of putting certain standards in place to ensure the security of cryptographic keys in an organization. Key Management deals with the creation, exchange, storage, deletion, and refreshing of keys, as well as the access members of an organization have to keys. Primarily, symmetric keys are used to encrypt and decrypt data-at-rest, while data-in-motion is encrypted and decrypted with asymmetric keys. Symmetric keys are used for data-at-rest since symmetric encryption is quick and easy to use, which is helpful for clients accessing a database, but is less secure. Since a more complicated and secure encryption is needed for data-in-motion, asymmetric keys are used.
The way symmetric key systems work is shown in the steps listed below.
- A user contacts the storage system, a database, storage, etc, and requests encrypted data.
- The storage system requests the data encryption key (DEK) from the key manager API, which then verifies the validity of the certificates of the key manager API and the key manager.
- A secure TLS connection is then created, and the key manager uses a key encryption key (KEK) to decrypt the DEK which is sent to the storage systems through the key manager API.
- The data is then decrypted and sent as plaintext to the user.
Asymmetric key systems work differently, due to their use of key pairs. The steps follow below:
- The sender and recipient validate each other’s certificates via either their private certificate authority (CA) or an outside validation authority (VA).
- The recipient then sends their public key to the sender, who encrypts the data to be sent with a one-time use symmetric key which is encrypted by the recipient’s public key and sent to the recipient along with the encrypted plaintext.
- The recipient decrypts the one-time use symmetric key with their own private key, and proceeds to decrypt the data with the unencrypted one-time use key.
While these key systems do keep data secure, that makes the cryptographic keys the biggest sources of security concerns for an organization, which is where key management comes in. To ensure strong security and uniformity across all government organizations, the National Institute of Standards and Technology (NIST) has created Federal Information Processing Standards (FIPS) and NIST Recommendations, referred to as NIST Standards, for sensitive and unclassified information in government organizations. These standards have security methods approved for all government data that is unclassified and sensitive. Since these standards are approved for all of the government’s sensitive and unclassified data, this means they are best-practice methods for cryptographic key protection for non-governmental companies.
The first security issue the NIST Standards review are cryptographic algorithms which are used for the encryption of data. Previously in this blog, symmetric and asymmetric cryptographic algorithms were discussed, but the NIST Standards only approve of a few specific types of these algorithms. For symmetric algorithms, block cipher-based algorithms, such as AES, and hash function-based algorithms, like SHA-1 or SHA-256, are approved. Block cipher based algorithms iterate through a series of bits called blocks and use different operations, such as XOR, to permutate the blocks over a series of rounds, leading to the creation of a ciphertext. Hash function-based algorithms use hashes, which are one-way functions, to generate hash data. Asymmetric algorithms are all accepted, NIST says that “the private key should be under the sole control of the entity that “owns” the key pair,” however. Cryptographic hash functions, which do not use cryptographic keys, and Random Bit Generators (RBGs), which are used for key material generation, are also approved by NIST Standards. A list of all algorithms approved by NIST Standards can be found in FIPS 180 and SP 800-90 for hash functions and RBG respectively.
Also discussed by NIST Standards is how cryptographic keys should be used. The most important recommendation is that a unique key should be created at every key creation. A key should not be used for both authentication and decryption, a user should have a separate key for each use. NIST Standards gives advice on what a cryptoperiod should be set to. A cryptoperiod is the time span that a key can be used for its given purpose before it must be renewed or, preferably, replaced with a new key. For asymmetric-key pairs, each key has its own cryptoperiod. The cryptoperiod of the key used to create a digital signature is called the originator-usage period, while the other cryptoperiod is called the recipient-usage period. NIST Standards suggests that the two cryptoperiods begin at the same time, but the recipient-usage period can extend beyond the originator-usage period, not vice versa.
Key Management is one of the essential portions of cybersecurity, and therefore should be executed with all the best-practices in mind. Luckily, the government publishes the NIST Standards which recommend the best ways to minimize security risks related to cryptographic keys. The NIST Standards discuss how keys should be used, what cryptographic algorithms are approved for government work, and what cryptoperiods for keys should be set to. As NIST Standards are updated, it is worth keeping track of to ensure your security system is always up to date.
*** This is a Security Bloggers Network syndicated blog from Blogs – AppViewX authored by Riley Dickens. Read the original post at: https://www.appviewx.com/blogs/key-management-and-nist-recommendations/