Hello, and welcome to this lecture where I'm going to drill down into the different elements and components that make up the KMS service to allow you to understand how it operates and functions. This section will consist of customer master keys, data keys, or data encryption keys, key policies and grants. 

Let me start off by explaining the CMK, the customer master key. This is the main key type within KMS. This key can encrypt data up to 4 kilobytes in size, however it is typically used in relation to your data encryption keys, DEKs. The CMK can generate, encrypt and decrypt these DEKs, which are then used outside of the KMS service by other AWS services to perform encryption against your data.

It's important to understand that there are two types of customer master keys. Firstly, those which are managed and created by you and I, as customers of AWS, which can either be created by using KMS or by importing key material from existing key management applications into a new CMK. And secondly, those that are managed and created by AWS themselves. The CMKs which are managed by AWS, are used by other AWS services that have the ability to interact with KMS directly to perform encryption against data. For example, Amazon S3, in particular, SSE KMS, these AWS managed keys can only be used by the corresponding AWS service that created them within a particular region. As remember, AWS KMS is a regional service. 

These CMKs that are used by the services, are generally created the first time you implement encryption using that particular service. CMKs that are generated and created by us, rather than AWS, provide the ability to implement greater flexibility, such as being able to manage the key, including rotation, governing access and key policy configuration, along with being able to both enable and disable the key when it is no longer required. Now there is a big difference between disabling a CMK and deleting a CMK, which can have significant effect on being able to access your data, governed by the CMK that encrypts it. I shall discuss more on these differences in an upcoming lecture, where I'll talk about key management. 

Like the AWS managed CMKs, AWS services can be configured to use your own customer CMKs, too. Depending on the service and your own internal security policies, the choice is yours as to which CMK the supported services uses to encrypt your data. Any CMKs created within KMS are protected by FIPS, validated cryptography modules. As I mentioned in the previous few slides, data encryption keys, or data keys, are created by the CMK and are used to encrypt your data of any size. When a request to generate a key is issued, the CMK specified in the request will create a plain text data encryption key and an encrypted version of the same data encryption key. Both of these keys are then used to complete the encryption process. As a part of this process, your plain text data is encrypted with the plain text data key using an encryption algorithm. Once encrypted, the plain text data is deleted from memory and the encrypted data key is stored alongside the encrypted data. If anyone gains access to the encrypted data, they will not be able to decrypt it, even if they have access to the encrypted key, as this key was encrypted by the CMK, which remains within the KMS service. This process of having one key encrypted by another key is known as envelope encryption. The only way you would be able to decrypt the object is if you have the relevant decrypt permission for that CMK that the data keys are associated to. 

Let me explain the process of how these data keys are used with the CMK outside of KMS, such as S3. And I shall stick with the example of SSE KMS, server side encryption, using KMS keys.

***Start of SSE-KMS Sketch Demonstration***

Hello, and welcome to this Cloud Academy sketch video. I'm going to be talking about S3, and in particular, server side encryption with KMS, which is the key management service. So I'm going to show you how the process works from both an encryption point of view and also decryption. Let's start by creating our user over here. And let's call our user Bob, keep it nice and simple. 

Now, Bob has a document that contains sensitive information. So when he stores it on his S3 bucket, he wants to make sure it's encrypted, and he's going to select server side encryption using KMS. So S3 will handle the encryption process for him using keys that are generated by the KMS service. So when he uploads it to his S3 bucket, he specifies that he wants to use SSE KMS. At this point S3 realizes that it needs to invoke services from the KMS service. So it calls upon KMS to generate some data keys for us. So it then sends a request over to KMS. At this point, KMS uses the customer master key, the CMK, to generate two keys. Now the first key is just a plain text data key, and the second key that's generated is the same key but an encrypted version of that key. 

Now both of these keys are then sent back to S3. So S3 receives both those keys, both the plain text key and the encrypted data key. Now S3 has all the keys it needs to perform the encryption process. So S3 will take the object uploaded by Bob, which is his document. It will then combine this with the plain text data key, and it will perform an encryption algorithm, and then that will generate an encrypted version of Bob's document. So now his document is encrypted. And S3 will store and associate the encrypted data key alongside this object. So these two objects are then stored on S3. Meanwhile, the plain text data key is then deleted from memory. So that's how encryption works using SSE KMS. 

So just to recap. The end user or client will upload the object to S3, specifying that SSE KMS should be used. S3 will then contact KMS, and using the specified CMK, it will generate two data keys, a plain text data key and an encrypted version of that data key. Both of these keys are then sent back to S3, at which point S3 can then encrypt the object that was uploaded, using the plain text data key, to generate an encrypted version of your object. And then S3 will associate and store the encrypted data key alongside your encrypted object. 

Okay, so let's now look at how the decryption process works. So if we just get rid of some of this detail. So Bob will request the object from S3. At this point, S3 knows that the object is encrypted and it has the associated encrypted data key. So what it does, it sends that associated encrypted data key over to KMS, and it asks KMS to generate a plain text data key. So what it'll do, it'll use the same CMK plus the encrypted data key. And this will generate a plain text version of that data key. Now just this single plain text data key is then returned to S3. At this point, S3 can then access the encrypted object and use the plain text data key that it just got back from KMS, perform an encryption algorithm again to decrypt the object. And this will generate a plain text version of the object, at which point this can then be returned to Bob. 

So just to recap. The user will request access to the encrypted object. S3 will then send the associated encrypted data key to KMS, to generate a plain text version of that encrypted data key, using the associated CMK. This plain text data key is then sent back to S3. The plain text data key is then used to decrypt the encrypted object, generating a plain text version of the object, which can then be returned to the user. So that's how the encryption process works for S3, SSE KMS. Thank you.

***End of SSE-KMS Sketch Demonstration***

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 CMKs, making these resource-based policies, and different key policies can be created for different CMKs. These permissions are defined within this key policy document, which is JSON-based, much like IAM policies are. I will cover key policies in far greater depth in the next lecture, when I discuss permissions and access control. 

Grants are another method of controlling access and use of the CMKs held within KMS. Again, they are a resource-based policy, but they allow you to delegate a subset of your own access to a CMK for principals, such as another AWS service within your AWS account. The benefit of this is that there is less risk of someone altering the access control permissions for that CMK. If anyone has the KMS put key 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 CMK for each principle requiring access. Again, coming up in the following lecture, I shall dive deeper into grants and how they work. 

That now brings me to the end of this lecture, which leads me nicely onto permissions and access control within KMS. And I shall look at key policies and grants in greater detail.