In this lecture I am going to focus on diving deeper into some of the components of the KMS service to help you understand how it’s put together and how it works.  

Let me start out by focusing on the different key types that are available within KMS.

Firstly, let me start with the AWS KMS Keys, these are the primary keys within the KMS service and can be used to perform cryptographic operations such as encrypting and decrypting your data.  This key can also be used to generate data keys which are used outside of KMS to encrypt data  

By default when a KMS key is generated, it is created as a symmetric 256-bit AES-GCM encryption key.  As a reminder, symmetric encryption means that the same key has to be used to decrypt data as was used to encrypt it.  As a result, when a symmetric KMS key is created the key will reside within KMS and never leave the service to ensure it remains secure at all times and stored on the underlying hardware security modules (HSMs).

You will find that any AWS service that provides encryption on your behalf will use symmetric encryption, integrating directly with the KMS keys residing within the KMS service to perform the encryption/decryption operations required. 

However, and interestingly, you can also create asymmetric KMS keys which can also be used for encryption and signing, but not both!  Whereas symmetric encryption just uses 1 key, asymmetric encryption uses 2 keys, one private and public, and so when an asymmetric KMS key is created it will of course create both a public and private KMS key pair.  The public key of the pair can be used outside of KMS and is freely accessible via KMS operation calls and can also be downloaded, however the Private asymmetric KMS key will never leave KMS without first being encrypted.  Generally the use of asymmetric KMS keys are required when encryption is needed outside of AWS, or by users who are not able to call upon KMS directly to encrypt the data. 

As a customer we have the ability to create these asymmetric KMS keys, which gives us greater control of the keys themselves from a permission and management perspective.  

Customer, AWS Managed Keys, and AWS Owned keys:

There are 3 different types of keys from an ownership perspective when working with KMS, these being:

• Customer managed
• AWS managed
• AWS owned

Customer managed keys: When working with KMS we are able to create our own KMS keys, which are referred to as Customer Managed Keys, and are asymmetric keys.  Once created, we as the customer have far greater control over the key itself from both a permissions and management aspect.  This means that we can create and associate key policies and other access control methods with the resource such as IAM policies and grants to ensure it can only be accessed by the people we allow.  We also have administrative functions and capabilities over the key such as 

• Being able to enable or disable the key
• Manage the Key rotation
• Adding Tags
• Creating Aliases
• And manage Key deletion

When working with some AWS Services, we can specify a customer managed KMS key to use to encrypt data.  

AWS managed keys:  AWS Managed keys are keys that are generated automatically by AWS services that integrate with KMS to help protect your data and perform the same function as Customer managed keys.

KMS integrated services may give you a choice of selecting an AWS managed KMS key or a Customer managed KMS key when configuring your encryption options within the service to protect your resource and data, and it's up to you to decide which option you would like.  If you select an AWS managed key then the management of that key is handled by AWS and you have no administration duties to maintain, instead it will all be managed by AWS. These AWS managed keys are explicitly created by the associated AWS service and will only be used by that service.  

AWS managed keys can be viewed from within KMS and are easily identifiable by the name and they have the following format: aws/servicename, for example aws/rds.   Although you can view AWS managed keys and view information such as the associated key policy, you can't manage the key in any way.  For example, it’s not possible to manage the key rotation settings, and you can’t change the key policy or delete the key itself.

Firstly, let me just define what Hash-based authentication codes, or HMAC, is.  At a high level, it can be defined as:

“....a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. As with any MAC, it may be used to simultaneously verify both the data integrity and authenticity of a message.” - Wikipedia

So how does it work? HMAC algorithms take your message or data and combine it with the key material of the HMAC key to create a unique fixed-size tag and is associated with the data.  When viewing the encrypted data, it will be able to detect if just a single character has changed from the original data or secret key as the resulting fixed-size tag will be different.  This allows you to check the integrity and authenticity  of the data to ensure that it was not tampered with in any way from the original point of encryption.  

Within KMS, a HMAC key conforms to the standards set out in RDS 2104 and is created as a symmetric key at varied lengths, and is used to create and verify HMAC codes.  The key material embedded within the HMAC key never leaves the KMS service without being encrypted first as it contains the secret key that associated HMAC algorithms use.  When working with HMAC keys you will need to use different operations to help you verify the integrity and authenticity of your data that you are working with though the use of the following operations: GenerateMac and VerifyMac.

Data keys are generated by KMS Keys and are used to encrypt and decrypt data, but KMS itself does not use Data Keys to encrypt data.  Instead the data keys are designed to be used outside of KMS to encrypt data, for example when working with the AWS Encryption SDK which is a client-side encryption library which helps to simplify encryption.  More information on the Encryption SDK can be found here: https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html

To generate a data key you can create it using the GenerateDataKey operation which will use an existing KMS key to create it.  This will create both an encrypted version of the Data Key, in addition to a Plaintext Data Key.  

To encrypt your data using these keys you will use the Plaintext data key in addition to an encryption algorithm to turn it into Ciphertext.  At this stage the plaintext data key is removed from memory and the encrypted data key is stored and associated with the newly encrypted data.  

To decrypt your data, the encrypted data key will be sent to KMS where the KMS key that was used to create the data key is used to decrypt it and return the key as a Plaintext data key, which is then used to decrypt your original data using a decryption algorithm.  

You should also be aware that it is also possible to create an encrypted Data Key without generating a Plaintext data key using the GenerateDataKeyWithoutPlaintext operation.  

This encrypted data key can then be sent to KMS when you need to decrypt it to use a plaintext version of the key for your cryptographic operations.

Although when using Data Keys it can create 2 keys, one encrypted and one plaintext it is still classed as symmetric encryption as it only uses one key, it’s just that there are 2 versions of the key, one is plaintext and the other is exactly the SAME key but it is encrypted.  

Whereas Data Keys are symmetric by definition, Data Key pairs are asymmetric, meaning they use 2 different keys, one for encryption and one for decryption, but what are Data Key Pairs used for? Well they are primarily designed for use outside of KMS, such as client-side cryptography operations, in addition to signing and verification.  

KMS supports a number of different Data Key pairs, which include the following:

• RSA key pairs (Generally used for certificates): RSA_2048, RSA_3072, and RSA_4096
• Elliptic curve key pairs (Generally used for digital signatures): ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521, and ECC_SECG_P256K1 (Cryptocurrencies) 
• SM key pairs (China Regions only): SM2

Being an asymmetric pair, the Private key is stored within KMS as you would expect, and is itself encrypted by a symmetric KMS key of your choice.  

During the creation of a Data Key Pair using an existing KMS key, a Public key is created in addition to an Plaintext Private Key, and an Encrypted version of the Plaintext private key.  Much like with Data Keys, you can also create a Data Key Pair without the plaintext key being created using the relevant KMS operation.

When it comes to encryption using the data key pairs, it’s the Public key that is used in conjunction with an encryption algorithm to take your plaintext data and return the data as ciphertext.  When it comes to decrypting the object, it’s the plaintext version of the data key pair that is used in addition to the same encryption algorithm to return the ciphertext data as plaintext data.  Again, once decrypted the plaintext key is removed from memory.  When the plaintext key is required again for a decrypt operation, the encrypted version of the private key will be used with the original KMS key to return a plaintext version.

Key material is an essential part that is associated with a key within AWS, it’s the element that is used as a part of a cryptographic algorithm, and it's effectively just a string of bits.  There is private key material, which must be kept protected and used with symmetric encryption, and then we have Public key material which is commonly used for asymmetric encryption within the public key.  

For symmetric keys the origin of this key material can be stored from a variety of secure sources, such as:

• From with AWS KMS itself
• It can also be sourced from outside of KMS from your own external key manager if the corresponding KMS key is backed by an external key store
• You can also select CloudHSM as the source when it is stored within a CloudHSM key store.  For more information on CloudHSM please see this existing course: https://cloudacademy.com/course/get-started-with-aws-cloudhsm/
• You can also import your own key material, however with this you are responsible for securing this key material

The key material for each key is unique, however, if you are looking to create a KMS key that can be used across multiple regions then the key material for each of these keys stored in multiple regions will have the same key material.  This helps you to encrypt/decrypt data stored in multiple regions as if you were using the same key.  Multi-region keys are often used for disaster recovery and data management spanning wide geographic areas.

As a security best practice when working within KMS you should implement a level of Key rotation for your customer managed keys.  Key rotation is the process of changing the key material with new key material for your keys.  You can implement automatic key rotation which is recommended, and AWS KMS will manage this rotation for you.  It’s important to understand that the KMS key itself does not change, it’s just the key material associated with the key that changes, which means you do not need to update anything in your applications that refer to a specific key.  For keys that are AWS managed or AWS Owned, KMS will automatically manage the rotation of the key material for these. 

When rotating your keys, all existing key material is retained, this allows KMS to decrypt data that was encrypted with any previous version of the key material used.  From a management perspective, it’s not possible to choose which version of the key material you would like your data to be encrypted with, it will always be encrypted with the key material that is associated with the key at the time of encryption.  

The key policy is a security feature within KMS that allows you to define who can use and access a particular key within KMS. These policies are tied to the KMS keys, making these resource-based policies, and different key policies can be created for different KMS keys. These permissions are defined within this key policy document, which is JSON-based, much like IAM policies are. 

Grants are another method of controlling access to the use of the KMS keys and are primarily used for temporary access. Again, they are a resource-based policy, but they allow you to delegate a subset of your own access to a KMS Key for another principal, such as another user within your AWS account. The benefit of this is that there is less risk of someone altering the access control permissions for that KMS Key. If anyone has the KMS putkey policy permission, then they could simply replace the key policy with a different one. Using grants eliminates this possibility, as a grant is created and applied to the KMS Key for each principle requiring access.