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 and 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 wherekey 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 uses 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.
The process for getting a certificate authority to issue a signed certificate is explained below:
The requestor or client creates a key pair (public and private key) and submits a request known as a certificate signing request (CSR) to a trusted certificate authority. The CSR contains the public key of the client and all the information about the requestor.
The CA validates whether the information on the CSR is true. If so, it issues and signs a certificate using the CA’s private key and then gives it to the requestor to use.
The requester can use the signed certificate for the appropriate security protocol:
Uses of a certificate authority
Certificate authorities issues various types of certificates, one of which is an SSL certificate. SSL certificates are used on servers and are the most common certificate that an everyday user would come in contact with. The three levels of an SSL certificate are
Extended Validation (EV)
Organization Validation (OV)
Domain Validation (DV)
Certificates with higher levels of trust usually cost more as they require more work on the part of the certificate authority.
Extended Validation (EV)These Certificates provide the highest level of assurance from the certificate authority that it has validated the entity requesting the certificate.During verification of an EV SSL Certificate, the owner of the website passes a thorough and globally standardized identity verification process (a set of vetting principles and policies ratified by the CA/Browser forum) to prove exclusive rights to use a domain, confirm its legal, operational and physical existence, and prove the entity has been authorized the issuance of the certificate. This verified identity information is included within the certificate.For example: An individual requesting an EV certificate must be validated through face-to-face interaction with the applicant as well as review of a personal statement, one primary form of identification, such as a passport or driver’s license, as well as two secondary forms of identification.
Organization Validation (OV)OV certificates take security assurance and require human verification of the organization’s identity.OV SSL certificates assures visitors that they’re on a website run by an authentic business. Before an OV certificate is granted, a member of the security team must contact the business to confirm that the owners actually requested the SSL certificate.
Domain Validation (DV)Domain Validation certificates are the easiest to get among all the other certificates, since no manual identity check takes place.DV SSL Certificates require only that the applicant demonstrate ownership of the domain for which the certificate is being requested.DV certificates can be acquired almost instantly and at low to no cost.
For example: ACM Cert Manager’s DNS or Email validation.
Certificate authorities also issue other types of digital certificates:
Code Signing CertificatesCode signing certificates are used by software publishers and developers to sign their software distributions. End-users use these to authenticate and validate software downloads from the vendor or developer.
Email certificatesEnable entities to sign, encrypt, and authenticate email using the S/MIME (Secure Multipurpose Internet Mail Extension) protocol for secure email attachments.
Device certificatesIssued to internet of things (IOT) devices to enable secure administration and authentication of software or firmware updates.
Object certificatesUsed to sign and authenticate any type of software object.
User or client certificatesUsed by individuals for various authentication purposes.
Client-Server Authentication via Certificate Authority (CA):
The CA establish a digital certificate also known as an SSL/TLS certificate that binds a public key to some information related to the entity that owns that public key. This enables any system to verify the entity-key binding of any presented certificate.
Step 1 The first step is finding out if the CA is a trusted CA. The CA name is taken from the certificate and compared to a list of trusted CA’s provided by the web browser. If the CA name is found to be a trusted CA, the client will then get the CA’s corresponding public key to use in the next validation step.Step 2 In this step, the digital signature on the server’s certificate will be validated. It is basically the hash of the CA’s Public key.Step 3 To validate the digital signature, the client hashes the CA’s public key with the same hash algorithm used by the CA to get the digital signature.Step 4 If the two hashes match then the digital signature is valid and the certificate is authenticated. If the hashes do not match then the certificate is invalid and cannot be authenticated.Step 5 Certificate expiration dates also need to be checked to validate the certificate.Step 6 Once a certificate is authenticated, the identity of the owner of the certificate will be authenticated as well.
CA Hierarchy options:
CAs are hierarchical in structure, and there are generally three types of hierarchies: one-tier, two-tier, and three-tier.
In this type of hierarchy, the single CA is both an Issuing CA and a Root CA. The Root CA is installed as an Enterprise CA, leaving the Root CA in the network as a member of a specific domain. In short, the Root CA is always available to issue certificates to requesting users, computers, network devices etc.
This single-tier hierarchy is not recommended for any production scenario because with this hierarchy, a compromise of this single CA equates to a compromise of the entire PKI.
A two-tier hierarchy meets most company’s needs. This design comprises an offline Root CA and an online Subordinate issuing CA. In this model, the level of security is increased because the Root CA is detached from the network, so the private key of the Root CA is better protected from any compromises. The two-tier hierarchy also increases scalability and flexibility, since there can be multiple Issuing CAs subordinate to the Root CA. This allows CAs to exist in different geographical locations, as well as at different security levels.
In a three-tier CA hierarchy, an offline Root CA is installed as a standalone Root CA, and one or more offline Intermediate/Policy CAs and one or more issuing CAs are installed as Enterprise Subordinate CAs. The Policy CA is configured to issue certificates to the Issuing CA which is restricted in what type of certificates it issues. One of the reasons the second layer is added in this hierarchy is that if you need to revoke a number of CAs due to a key compromise, you can perform it at the Second level, leaving other “branches from the root” available. It should be noted that Second Tier CAs in this hierarchy can, like the Root, be kept offline.
A certificate authority plays the key role of facilitating secure communication and building trust between a user and a resource by verifying that the organization and client in question are authentic or valid.
For a complete list of the recommendations for planning a CA hierarchy, along with the level of business impact at which you should consider implementing them, refer to Securing PKI: Appendix F: List of Recommendations by Impact Level.
Parnashree Saha is a data protection senior consultant at Encryption Consulting LLC working with PKI, AWS cryptographic services, GCP cryptographic services, and other data protection solutions such as Vormetric, Voltage etc.