AWS KMS (Key Management Service)

• AWS services that integrate with AWS KMS differ in their support for CMKs.
• KMS can create and manage CMKs (Customer Master Keys).
• KMS can generate Data Keys but does not manage them.
• KMS integrates fully with IAM and CloudTrail for permissions management and auditing functions.
• AWS KMS cannot encrypt data over 4KB and cannot itself DO encryption using DEKs.
• The encryption SDK can handle the data item encryption and integrate with KMS for the CMK component.

Topics

• Customer Master Keys (CMKs) and Data Keys
• Types of CMK
• Encrypt data and decrypt data with a data key
• Encryption operations
• Envelop Encryption
• Encryption context
• Key rotation
• AWS Encryption SDK
• Managing access
• Grants and Grant Tokens
• KMS Key Policies for admins, same-account usage, cross-account usage, key deletion
• KMS Limits and Throttling Exception

---

Highlights

• Use CloudTrail to record KMS API calls. KMS is not one of the services that can send logs to CloudWatch Logs.
• If you use the SSE-KMS option for your default encryption configuration, you are subject to the RPS (requests per second) limits of AWS KMS. If need, lodge a support request to increase KMS limits.
• CMKs never leave KMS and never leave a region.
• CMKs can encrypt or decrypt data up to 4 KB in size.
• If the size of the individual encryption per data item is > 4 KB, use the AWS Encryption SDK, which can handle the data item encryption and integrate with KMS for the CMK component.
• Unlike most AWS services, the root user has no access to CMKs without specifically being allowed. In cases where nobody has access to CMKs, only AWS can restore access.
• KMS cannot itself DO encryption using DEKs.
• (DynamoDB) By default, all DynamoDB tables are encrypted under an AWS owned CMK in the DynamoDB service account.
  • You can select an option to encrypt the tables under an AWS managed CMK for DynamoDB in your account.
  • Encryption at rest does NOT support Customer managed CMKs.
• Automatic key rotation is not supported for imported keys or keys generated in an AWS CloudHSM cluster using the KMS custom key store feature.

---

Customer Master Keys (CMKs) and Data Keys

CMK (Customer Master Key)

• CMKs can encrypt or decrypt data up to 4 KB (4086 bytes) in size.
• You use CMKs to generate, encrypt, and decrypt the data keys that you use outside of AWS KMS to encrypt your data. This strategy is known as envelope encryption.
• CMKs are created in AWS KMS, and never leave AWS KMS unencrypted, and never leave a region.
• To use or manage your CMK, you access them through AWS KMS.
• Keys can be generated by KMS or imported.

Data Keys

• Data keys are encryption keys that you can use to encrypt data, including large amounts of data and other data encryption keys.
• AWS KMS does not store, manage, or track your data keys.
• AWS KMS does not perform cryptographic operations (encryption) with data keys.
• You must use them outside of AWS KMS.

Types of CMK

                        | Can view | Can manage | Used only for your AWS account
1. Customer managed CMK | Yes      | Yes        | Yes 
2. AWS managed CMK      | Yes      | No         | Yes 
3. AWS owned CMK        | No       | No         | No

Customer managed CMKs

• Customer managed CMKs are CMKs in your AWS account that you create, own, and manage.
• You have full control over these CMKs, including establishing and maintaining their key policies, IAM policies, and grants, enabling and disabling them, rotating their cryptographic material, adding tags, creating aliases that refer to the CMK, and scheduling the CMKs for deletion.
• You can use your customer managed CMKs in cryptographic operations and audit their use in AWS CloudTrail logs.
• Monthly fee + fees for use in excess of the free tier.
• Counted against the AWS KMS limits for your account.

AWS managed CMKs

• You can identify AWS managed CMKs by their aliases - aws/service-name (e.g. aws/redshift).
• You can view the AWS managed CMKs in your account, view their key policies, and audit their use in AWS CloudTrail logs.
  • To view the key policy for an AWS managed CMK, use the GetKeyPolicy operation.
  • You cannot view the key policy in the AWS Management Console, or change it by any means.
• You cannot manage these CMKs or change their permissions.
• You cannot use AWS managed CMKs in cryptographic operations directly; the service that creates them uses them on your behalf.
• No monthly fee, but fees for use in excess of the free tier.
• Do not count against limits on the number of CMKs in each region of your account, but when they are used on behalf of a principal in your account, they count against request rate limits.

AWS owned CMKs

• AWS owned CMKs are not in your AWS account. They are part of a collection of CMKs that AWS owns and manages for use in multiple AWS accounts. AWS services can use AWS owned CMKs to protect your data.
• You cannot view, manage, or use AWS owned CMKs, or audit their use. However, you do not need to do any work or change any programs to protect the keys that encrypt your data.
• No fee charged.
• Do not count against AWS KMS limits for your account.

Encrypt data and decrypt data with a data key

• Create data key
  • GenerateDataKey creates a plaintext data key and an encrypted data key.
    • PlaintextDataKey: The plaintext version is used to encrypt, and then discarded. It’s never stored in plaintext.
    • CipherDataKey: The encrypted version is stored along with the encrypted data; this is envelope encryption.
  • GenerateDataKeyWithoutPlaintext returns only an encrypted data key.
    • When you need to use the data key, ask AWS KMS to decrypt it.

      CMK -> encryption algorithm --> Encrypted data key & Plaintext data key
      

• Encrypt data with a data key
  • KMS cannot use a data key to encrypt data, but you can use the data key outside of KMS.
    • E.g. using OpenSSL or a cryptographic library like AWS Encryption SDK.
  • After using the plaintext data key to encrypt data, remove it from memory as soon as possible.
  • You can safely store the encrypted data key with the encrypted data so it is available to decrypt the data.

    Plaintext data -> Plaintext data key + encryption algorithm -> Ciphertext
    

• Decrypt data with a data key
  • To decrypt your data, pass the encrypted data key to the Decrypt operation.
  • AWS KMS uses your CMK to decrypt the data key and then it returns the plaintext data key.
  • Use the plaintext data key to decrypt your data and then remove the plaintext data key from memory as soon as possible.

    Encrypted data key -> CMK + decryption algorithm -> Plaintext data key
    

Operations

• kms:GenerateDataKey
• kms:Encrypt
• kms:Decrypt
  • Decrypts ciphertext. Ciphertext is plaintext that has been previously encrypted by using any of the following operations:
    • GenerateDataKey
    • GenerateDataKeyWithoutPlaintext
    • Encrypt
  • Whenever possible, use key policies to give users permission to call the Decrypt operation on the CMK, instead of IAM policies. Otherwise, you might create an IAM user policy that gives the user Decrypt permission on all CMKs.
  • This user could decrypt ciphertext that was encrypted by CMKs in other accounts if the key policy for the cross-account CMK permits it. If you must use an IAM policy for Decrypt permissions, limit the user to particular CMKs or particular trusted accounts.
  • The result of this operation varies with the key state of the CMK.
• kms:ReEncrypt
  • ReEncrypt encrypts data on the server side with a new CMK without exposing the plaintext of the data on the client side. The data is first decrypted and then reencrypted.
  • You can also use this operation to change the encryption context of a ciphertext.
  • You can reencrypt data using CMKs in different AWS accounts.
• kms:DescribeKey
  • DescribeKey allows your app to retrieve information about the CMKs.

Envelope Encryption

• Envelope encryption is the practice of encrypting plaintext data with a data key, and then encrypting the data key under another key.
• You can even encrypt the data encryption key under another encryption key, and encrypt that encryption key under another encryption key.
  • But, eventually, one key must remain in plaintext so you can decrypt the keys and your data.
  • This top-level plaintext key encryption key is known as the master key.

    Master key -> encryption algorithm -> Data key -> encryption algorithm -> Data
    (plaintext)
    

• AWS KMS helps you to protect your master keys by storing and managing them securely.
• Master keys stored in AWS KMS, known as customer master keys (CMKs), never leave the AWS KMS FIPS validated hardware security modules unencrypted.
• To use an AWS KMS CMK, you must call AWS KMS.

Envelope encryption offers several benefits:

1. Protecting data keys
   • When you encrypt a data key, you don’t have to worry about storing the encrypted data key, because the data key is inherently protected by encryption. You can safely store the encrypted data key alongside the encrypted data.
2. Encrypting the same data under multiple master keys
   • Encryption operations can be time consuming, particularly when the data being encrypted are large objects. Instead of re-encrypting raw data multiple times with different keys, you can re-encrypt only the data keys that protect the raw data.
3. Combining the strengths of multiple algorithms
   • In general, symmetric key algorithms are faster and produce smaller ciphertexts than public key algorithms, but public key algorithms provide inherent separation of roles and easier key management.
   • Envelope encryption lets you combine the strengths of each strategy.

Encryption Context

• AWS KMS uses the encryption context as additional authenticated data (AAD) to support authenticated encryption.
• Encryption Context is an optional set of key–value pairs that can contain additional contextual information about the data.
• All AWS KMS cryptographic operations (the Encrypt, Decrypt, ReEncrypt, GenerateDataKey, and GenerateDataKeyWithoutPlaintext) accept an encryption context.
• When an encryption context is provided in an encryption request, it is cryptographically bound to the ciphertext such that the same encryption context is required to decrypt (or decrypt and re-encrypt) the data. If the encryption context provided in the decryption request is not an exact, case-sensitive match, the decrypt request fails.
• Only the order of the encryption context pairs can vary.
• The encryption context is not secret. It appears in plaintext in AWS CloudTrail Logs so you can use it to identify and categorize your cryptographic operations.
• So your encryption context should not include sensitive information.
• We recommend that your encryption context describe the data being encrypted or decrypted.
  • For example, when you encrypt a file, you might use part of the file path as encryption context.
  • For example, S3 uses an encryption context in which the key is aws:s3:arn and the value is the S3 bucket path to the file that is being encrypted.

    "encryptionContext": {"aws:s3:arn": "arn:aws:s3:::bucket_name/file_name"},
    

• You can use the encryption context to refine or limit access to customer master keys (CMKs) in your account.
• You can use the encryption context as a constraint in grants and as a condition in policy statements.

Key Rotation

• Key rotation can be automatic (if enabled)
  • every 3 years for AWS managed CMKs, or
  • every 1 year for Customer managed CMKs
• How to rotate CMK Key?
  • You can choose to have AWS KMS automatically rotate CMKs every year (12 months), provided that those keys were generated by AWS KMS.
  • Automatic key rotation is not supported for imported keys or keys generated in an AWS CloudHSM cluster using the KMS custom key store feature.
• How to rotate imported key?
  • If you choose to import keys to AWS KMS or use a custom key store, you can manually rotate them whenever you want by creating a new CMK and mapping a key alias from the old key to the new key.

AWS Encryption SDK

• AWS KMS cannot encrypt data over 4KB and cannot itself DO encryption using data keys.
• The AWS Encryption SDK can handle the data item encryption and integrate with KMS for the CMK component.

Managing access

• KMS uses FIPS140-2 compliant hardware modules to manage access to key material.
• An IAM user can be configured as a key administrator.
  • This user can perform management tasks on keys.
  • This user cannot perform any cryptographic operations using those keys. Additional permissions are required.
• Managing Permissions
  1. Key Policies
  2. Grants, can be used for giving long-term access that allows AWS principals to use your customer managed CMKs.

Grants and Grant Tokens

• When you create a grant, the permissions specified in the grant might not take effect immediately due to eventual consistency.
• If you need to mitigate the potential delay, use the grant token that you receive in the response to your CreateGrant API request.
• You can pass the grant token with some AWS KMS API requests to make the permissions in the grant take effect immediately. The following AWS KMS API operations accept grant tokens:
  • CreateGrant
  • Decrypt
  • DescribeKey
  • Encrypt
  • GenerateDataKey
  • GenerateDataKeyWithoutPlaintext
  • ReEncrypt
  • RetireGrant
• A grant token is not a secret. The grant token contains information about who the grant is for and therefore who can use it to cause the grant’s permissions to take effect more quickly.

KMS Key Policies

• KMS Key policies are resource policies that control access to the Customer Master Keys (CMKs).
• You can use the key policy to add, remove, or change permissions at any time for a Customer managed CMK.
• But you cannot edit the key policy for an AWS managed CMK.
• Unlike most AWS services, the root user has no access to CMKs without specifically being allowed.
• In cases where nobody has access to CMKs, only AWS can restore access.
• Separating roles/policies for Key Admin and Key Usage
  • A Key Policy can be used to give the account full control of a key, allowing IAM identity policies to control access.
  • Removing the policy, nothing can use the key. AWS support is required.

    {
      "Sid": "xxx",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
      "Action": "kms:*",
      "Resource": "*"
    }
    

  • Key admins can admin keys, not use them. Permissions granted via IAM policy, or key policy, or both.

    {
      "Sid": "Allow access for Key Administrators",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::111122223333:user/KMSKeyAdmin"},
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    }
    

  • KMS has specific operations which are used to utilise the CMKs. CMKs generally are not used to encrypt data. CMKs generate data keys which perform the encryption and decryption:

      "Resource": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
    

  • Multi-account configuration for using CMK
    • CMKs can be configured to allow other accounts to use them.
    • The Key won’t appear in the external account, but if it is configured using a key policy, that account can interact with the key for cryptographic functions.
    • AccountA:

      "Resource": [
        "arn:...<AccountB_ID>:key/<keyID>"
      ],
      

    • AccountB:
      • CloudTrail: putObject to AccountA’s “logs”
  • For Key admins to be able to delete CMK

      "Action": [
        ...
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
      ]
    

  • Key policy for the AWS managed CMK for Amazon EBS.
    • The Principal element specifies all AWS identities with the kms:CallerAccount condition key to effectively allow access to all identities in AWS account 111122223333.
    • It contains an additional AWS KMS condition key (kms:ViaService) to further limit the permissions by only allowing requests that come through Amazon EBS.

      {
      "Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
      "Effect": "Allow",
      "Principal": {"AWS": "*"},
      "Condition": {
        "StringEquals": {
          "kms:CallerAccount": "111122223333",
          "kms:ViaService": "ec2.us-west-2.amazonaws.com"
        }
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:CreateGrant",
        "kms:DescribeKey"
      ],
      "Resource": "*"
      }
      

KMS Limits

• 1000 Customer managed CMKs per region.
• 1100 Aliases per account.
• 2500 Grants per CMK (e.g. max of 2500 EBS volumes using a CMK).
• 5500 Shared API limit
• Breaching the shared, or per operation limits, result in KMS throttling the requests.
• Cross-account applies to the SOURCE account.

Throttling Exception

• An application running in your AWS account is experiencing ‘ThrottlingException’ errors. What potential remedies can you suggest? (Choose 2)
  • Investigate the AWS Encryption SDK.
  • Lodge a support request to increase KMS limits.