Hello and welcome to this lecture where I shall be explaining how to manage your keys within KMS. I will look at rotation of CMKs, How to import key material from an existing key management system outside of AWS, and the deletion of CMKs. So let me start off by looking at how rotation works within your CMKs. 

Firstly, why do we need to rotate keys? The simple answer is for security best practice reasons. Largely, the longer the same key is left in place, the more data is encrypted with that key, and if that key is breached, then the wider the blast area of data is at risk. In addition to this, the longer the key is active, the probability of it being breached increases. 

The simplest method of rotating keys is to use automatic key rotation, whereby KMS will automatically rotate your keys every 365 days. But what does that mean, exactly? When automatic key rotation is enabled, many of the details of the CMK remain the same, such as the CMK-ID and the ARN, along with any associated permissions and policies. The only thing that changes is the backing key of the CMK. This backing key is the fundamental cryptographic element that is used when the encryption process is taking place. During the rotation, older backing keys are retained to decrypt data that was encrypted prior to this rotation. 

One important point to bear in mind is that should a breach of the CMK occur, rotating the key would not remove the threat of that breach. Consider the following scenario. You have encrypted 100 objects which are stored on S3, using SSE-KMS with a customer-managed CMK. It has been made apparent that a breach of your cryptographic material, of your CMK, has occurred, and you decide to rotate the key. As we now know, rotating the key simply creates a new backing key, and retains the older key to allow you to continue to decrypt existing data, encrypted by the original backing key. So by rotating the key, doesn't prevent the malicious user from decrypting the 100 objects. However, by rotating the key, it does stop them from decrypting any future encryptions of objects, as it now has a new cryptographic material of the backing key. 

There are a couple of points to bear in mind when it comes to automatic key rotation. Firstly, Automatic key rotation is not possible with imported key material, and secondly, the key rotation happens every 365 days and there is no way to alter that time frame. If these two points are an issue, then the only solution is to perform a manual key rotation, which would give you greater flexibility and control of how and when you perform rotations of your keys. If your CMK is the state of disabled or pending deletion, then KMS will not perform a key rotation. If the key is re-enabled, or if the deletion process is canceled, then KMS will assess the age of the backing key, and if that key is older than 365 days, the automatic key rotation process will rotate the key immediately. 

One final point on automatic key rotation is that it's not possible to manage the key rotation for any AWS managed CMKs. These are by default rotated every 1095 days, which is essentially three years. Let me now look at manual key rotation, and how this differs from automatic key rotation.

The process of manual key rotation requires a new CMK to be created, which is different from the automatic process. By doing so, a new CMK-ID is created along with a backing key. As a result, if you have any applications that reference the CMK-ID of the old key, you will need to update them and point them to the new CMK-ID. To make things easier in this process, you could use alias names for your keys, and then simply update your alias target to point to the new CMK-ID. To do this, you can use the update alias API, as shown here. 

Once you have performed a manual key rotation, you should keep any CMKs that were used to encrypt data before it, as KMS will use the same CMK that it did to encrypt it. So, for example, let's say you had a document A encrypted with CMK-A, using the backing key of that CMK to perform the cryptographic mechanism. You then performed a manual key rotation to comply with your own internal security policies. In doing so, a new CMK was created, CMK-B, and this CMK then encrypted document B. You then deleted or disabled CMK-A. When Alice tries to retrieve document A in plain text format, the operation fails. This is because KMS knows which CMK was used to encrypt the object, and it must use the same CMK to decrypt it. However, if it is disabled or deleted, then this is not possible. To resolve this issue, the older CMKs must remain active. 

When I was just talking about key rotation, I mentioned that it's not possible to perform automatic key rotation of imported key material, but what is this key material? Key material is essentially the backing key, the component that completes and implements the encryption and decryption process on behalf of the CMK itself. When customer-managed CMKs are generated and created within KMS, the key material is automatically created for the CMK. However, it is possible to create CMKs without any key material at all. This is done by selecting the External option for the Key Material Origin, under the Advanced Options of the Create Alias and Description page of the CMK creation within the management console. By doing so, you can still create a CMK which will have its own ARN and CMK-ID. However the actual key material for the CMK can then be imported from your own key infrastructure that you may be using with your own on-premise material that you have already been using. When using your own key material, it becomes tied to that CMK, and no other key material can be used for that CMK. This is why it's not possible to enable automatic key rotation, as only this single backing key or key material can ever be used for that CMK. 

The process for importing your own material follows four key points. The first is, as I have already mentioned, creating your CMK with no key material generated by KMS by selecting External for your key origin. Following this, you will then be asked to download a wrapping key, which is also referred to as a public key, and an import token. This wrapping key is to allow you to upload your key material in an encrypted form. When you import your key material, you do not want this to be in plain text format, So AWS KMS provides a means of encrypting it with this public/wrapping key. During this step, you will be asked to select an encryption algorithm. The options for this are as shown. AWS recommends that you select option A that's shown if possible. If not, then to use option B, and lastly, C. The wrapping key then uses this method of encryption to encrypt your key material before it's uploaded. The import token that is downloaded is used as a part of the import process when uploading your encrypted key material, to ensure that the process completes correctly. Both the wrapping key and the import token is only active for 24 hours once you have downloaded it, so you need to ensure that you complete the process within this timeframe, otherwise you will need to complete this step again, and download a new key and import token. 

Once you have downloaded the wrapping key and import token, you are then ready to encrypt your key material that you've extracted from your own key management system or hardware security module. One point regarding this step is that the key material must be in a binary format to allow you to use the wrapping key. For detailed information on the commands to carry out this step, you can visit the following link. The final step is to actually import your key material that is now encrypted into KMS and to associate it with your currently empty CMK. This step can be performed programmatically, or from within the AWS Management Console, whereby you need to select your CMK, and select to import the key material. At this point, you would then be prompted for the location of the key material, along with the location of the import token. Optionally, you also have the option of setting an expiration of the key material being imported. If you do set an expiry, CMK would cease to operate when this expires. To activate the CMK again, you would need to re-upload the key material, following steps two to four. 

There are some considerations of using your own key material that differ from key material generated by KMS, which is largely down to durability and availability. The key material created by KMS for customer-managed CMKs receives a far higher durability and availability than that of your own key material that has been imported. For example, it's not possible to set an expiration time with key material generated by KMS, but you can for your own imported material. When this expires, the key material is deleted, but the CMK and metadata of that CMK is retained. Also, if a region-wide failure occurred where your keys were being used and stored, you would need to ensure that you had the key material to import back into the CMK, as KMS would not be able to retain this information. 

I now want to talk about the process involved with deleting CMKs. When you no longer have a need or requirement for a particular CMK, you may want to delete it for security best practices and general housekeeping of your key infrastructure. Deleting a key, of course, can have significant impact against your operations and data if there are services that are still using it without your knowledge. To help in this scenario, KMS enforces a scheduled deletion process, which can range from seven to 30 days. When a key is scheduled for deletion, the CMK is taken out of action and put in a state of Pending deletion. When a key is in this state, it can't be used to perform any encryption or decryption actions, neither can the backing keys for the CMK be rotated. You could also analyze AWS CloudTrail event logs to look for events relating to the use of your CMK, such as an encrypt action against the CMK-ID. 

AWS also recommends that you set up a Cloudwatch alarm to identify if anyone tries to use this key to perform an encryption or decryption request. This will help you identify if it is, in fact, still in use, allowing you to cancel the deletion. Details on how to configure this can be found using the link on screen. If you are not confident that your CMK is no longer in use, or that it should be deleted, then you can simply disable the CMK. Again, this will change the key to a state of disabled and prevent it from being used, and, again, prevent the backing key from being rotated. If you are using a CMK which has your own key material imported, then you can delete just the key material from the CMK, as well as having the option of deleting the entire CMK. 

I'm now going to perform a quick demonstration to show you how to schedule a deletion of a CMK, and how you can disable and re-enable CMKs via the AWS Management Console. 

Start of demonstration

Okay, so for this demonstration, I'm going to show you how to schedule a deletion of a CMK, and then also how to disable and re-enable a CMK. So, again, if we go to IAM. Go down to Encryption keys, which is essentially where KMS lives, and as you remember from the demonstration earlier, where we created the DemoKey, so now I'm going to schedule a deletion for this key. 

So if I select the key, and go across to Key actions, and then down to Schedule key deletion, now here you can enter a waiting period between seven and 30 days, so the minimum is seven and the maximum is 30 days. So this will give you a buffer to ensure that you do actually want to delete this key, and give you enough time to ascertain and see if it's still in use. So, let's just put in seven days there, go down to Schedule deletion. And we can see here, that the Status is now changed to Pending Deletion. So it won't be possible to use this CMK anymore, and it won't be rotated either. 

If you change your mind, and you don't want this CMK deleted, you can just select it again, go to Key actions, and Cancel key deletion. You'll see at this stage that it puts the key in this state of Disabled, so what you need to do, again, is to select the key, go to Key actions, and simply Enable the key and then it will be fully operational again, and you can use that CMK to encrypt and decrypt data. 

You may have noticed in the Key actions there, let me just select the key once more, to Disable the key, there's an option there, so we can just go ahead and Disable that, and you can see that the Status has changed, and, again, if you need to re-enable it, just simply click on Enable. So to disable and enable the key is very simple, simply selecting the CMK and then just selecting the appropriate option from the Key actions box. And that's it, so that's how you can schedule a deletion for your CMK and also disable and enable the key as required.

End of demonstration