Data-at-rest Archives

Deep Dive on AWS-Key Management Service

by Dipanshu Bhatnagar

Posted on November 21, 2020Last updated on September 5, 2022

Read Time: 08 min

Data encryption on the cloud is the most prominent thought every security professional has in their mind these days. While performing data encryption, Security keys are of the utmost importance. When it comes to managing a single security key manually, it is relatively easy, however, if the number of security keys in use are huge, the task of managing those keys becomes cumbersome. Thus, the need arises for automated key management services for data encryption.

AWS KMS (Key Management Service) provides an easy to use WebUI to deal with the management of security keys to protect data-at-rest and data-in-use. AWS KMS is a placeholder for CMK (Customer Master Key) resources containing key metadata to encrypt & decrypt the data. Also, AWS KMS can be integrated with various other AWS services, such as Redshift, EBS, EFS, S3, and Secret Manager, to name a few.

In today’s post, we will discuss the key concepts of AWS KMS and its various features and integration with other AWS services.

Key Types

AWS Managed CMKsThese CMKs are created, managed and used by an AWS service integrated with KMS on behalf of the customer in theirs AWS account. For example, “aws/s3” is the default key in S3 and is used only for your account to encrypt your S3 buckets.
Customer Managed CMKsThese CMKs are created, managed and used by the customer in the AWS account. This is the most widely used method while using KMS, as it provides complete granular level access control over the security keys in an AWS account.
AWS Owned CMKsThese CMKs are owned and managed by AWS service/s for use in multiple AWS accounts. The key for these CMKs is not visible to users. For example, if you choose S3 default encryption, S3 uses its own KMS CMKs that are shared across multiple AWS accounts.

Data Keys

Data keys are encryption keys that the user can use to encrypt large amounts of data and other data encryption keys. Users can use AWS CMKs to generate, encrypt, and decrypt data keys. However, AWS KMS does not store, manage, or track the data keys or perform cryptographic operations with data keys. Users must use and manage data keys outside of AWS KMS’ scope.

Access Control to KMS CMKs

The primary way to control the access to your AWS KMS CMKs is with IAM & Key policies. Policy is a combination of declarative statements that describe who has access to what.

IAM PoliciesPolicies attached to an IAM identity are called identity-based policies.
Key PoliciesPolicies attached to resources are called resource-based policies.

In AWS KMS, you must attach resource-based policies to your CMKs i.e. key policies. IAM policies alone cannot permit access to CMKs to IAM users or roles.

Type of CMK	CMK management via IAM Policy	CMK management via Key Policy	Can view **CMK Metadata	Used only for specific user account	Automatic Rotation
Customer Managed	Yes	Yes	Yes	Yes	Optional*
AWS Managed	No	No	Yes	Yes	Every 3 Years
AWS Owned	No	No	No	No	Varies

* Be default “Automatic Rotation” is disabled, however, user can enable it upto 1 year.

** CMK Metadata is information about the CMK such as Key identifiers, Origin, KeyUsage, KeyState etc.

For example, the metadata type “Origin” signifies the source of the CMK’s key material. When this value is AWS_KMS, AWS KMS created the key material. When this value is EXTERNAL, the key material was imported from external key management infrastructure. When this value is AWS_CLOUDHSM, the key material was created in the AWS CloudHSM cluster associated with a custom key store.

Symmetric and Asymmetric CMKs:

AWS KMS protects the CMK that you use to protect your data and data keys. The CMKs are generated and used only in hardware security modules designed so that no one can access the plaintext key material.

AWS KMS supports symmetric and asymmetric CMKs:

Symmetric CMK: This represents a single 256-bit secret encryption key that never leaves AWS KMS unencrypted.
Asymmetric CMK: This represents a mathematically related public key and private key pair that you can use for encryption and decryption or signing and verification, but not both. The private key never leaves AWS KMS unencrypted. You can use the public key within AWS KMS by calling the AWS KMS API operations, or download the public key and use it outside of AWS KMS.

AWS KMS also provides symmetric data keys and asymmetric data key pairs that are designed to be used for client-side cryptography outside of AWS KMS. The symmetric data key and the private key in an asymmetric data key pair are protected by a symmetric CMK in AWS KMS.

KMS Custom Key store

A key store is a secure location for storing cryptographic keys. By default, the customer master keys (CMKs) that you create in AWS KMS are generated in and protected by hardware security modules (HSMs) that are FIPS 140-2 Level 2 compliant cryptographic modules. The CMKs never leave the modules unencrypted.

A custom key store is an AWS KMS resource that is associated with an AWS CloudHSM cluster backed by FIPS 140-2 Level 3 HSMs that are owned and managed by user.

When a user creates an AWS KMS CMK in their custom key store, AWS KMS generates a 256-bit, persistent, non-exportable Advanced Encryption Standard (AES) symmetric key in the associated AWS CloudHSM cluster. This key material never leaves your HSM unencrypted. When you use a CMK in a custom key store, the cryptographic operations are performed in the HSMs in the cluster.

What is Bring Your Own Key (BYOK):

A CMK is a logical representation of a master key in which the key material is generated and owned by the AWS. However, users can create a CMK without any key material, and then import external key material into that CMK. This is known as BYOK i.e. Bring Your Own Key

Imported key material is supported for symmetric CMK in AWS KMS key stores; however, this is not supported for asymmetric CMK and Custom Key stores as well.

When imported key material is used, the users remain responsible for the key material while allowing AWS KMS to use a copy of it. This is a common use case where the user wants to have complete control over the key material for regulatory/business/compliance/legal purpose.

Conclusion

AWS KMS is a widely used KMS service among all the KMS as-a-service options available from Cloud vendors. Since AWS KMS provides multiple options for CMKs, it becomes difficult to decide at times which option one should choose under different scenarios. Considering the functionality and feature set available in each CMK, if a user wants to use a key available to all IAM entities in its AWS account, AWS Managed CMK is better choice as the CMK is available for all the IAM users in the same account. However, if user wants to have a granular access control over keys then Customer Managed CMK or BYOK appears to be a better option.

Tags:

About the Author

Dipanshu Bhatnagar

Dipanshu Bhatnagar is a Principal Consultant Cloud Security Specialty at Encryption Consulting working with PKIs, AWS Cloud Cryptographic services and tools, Google Cloud Cryptographic Services, and helping high profile clients towards their cloud journey with complete data privacy assurance.

Cloud Key Management

Key Management – Recommendations and Best Practices

by Riley Dickens

Posted on September 26, 2020Last updated on August 16, 2022

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 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.

NIST Standards

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.

Conclusion

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.

About the Author

Riley Dickens

Riley Dickens is a Consultant at Encryption Consulting, working with PKIs, creating Google Cloud applications, and working as a consultant with high-profile clients.

Common Encryption Algorithms, Education Center

How encryption can be used to protect data throughout its lifecycle (data-at-rest, data-in-transit, data-in-use)

by Puneet

Posted on September 23, 2020Last updated on November 17, 2022

Encryption can be used to protect data in all three of its states:

Encryption-at-rest: Encrypts data stored in servers and/or in databases. In the case of data exfiltration, or if the network/systems are compromised, the data will remain encrypted.
Example: AES , DES, and Triple DES.
Encryption-in-transit: Encrypts traffic between two entities or systems. It protects against MITM or sniffing, where even if the communication is intercepted, it becomes useless. Encryption is done at the transport layer. Upon receiving the message, the endpoint is authenticated, then data is decrypted and verified.
Example: TLS or Transport Layer Security is often used for encryption in transit
Encryption-in-use: Protects the data while it is being used to run analytics or computation.
Example: Format Preserving Encryption

Tags:

Data-at-rest data-in-motion Data-in-use Encryption

About the Author

Puneet

President at Encryption Consulting LLC focusing on providing consulting to customers in the Applied Cryptography space.

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.

Tag: Data-at-rest