Welcome to this final lecture of this course, where I shall summarize some of the key points made throughout the previous lectures. 

I started by explaining some of the core concepts of encryption that’s used by AWS KMS.  In this lecture I explained that:

• Unencrypted data is data that can be read and seen by anyone who has access to it
• Unencrypted data is commonly known as ‘plaintext’ or ‘cleartext’ 
• Data containing sensitive information should be encrypted
• Data encryption is the mechanism in which information is altered, rendering the plain text data unreadable through the use of mathematical algorithms and encryption keys
• Encrypted data is known as cipher text which is unreadable
• An encryption key is simply a string of characters used in conjunction with an encryption algorithm
• Symmetric encryption uses a single key to both encrypt and decrypt data
• Common symmetric cryptography algorithms include: AES, DES, Triple DES and Blowfish
• Asymmetric encryption involves two separate keys, where one is used to encrypt the data (Public Key) and a separate key is used to decrypt the data (Private Key).
• Public keys should be accessible by anyone who needs it 
• Private keys should be secured and kept private
• Common examples of asymmetric cryptography algorithms are RSA, Diffie-Hellman, and Digital Signature Algorithm. 

Following this, I covered some of the basics of what the AWS KMS service is and does. During this lecture, I discussed the following: 

• The Key Management Service is a managed service used to store and generate encryption keys 
• Any AWS service that offers encryption capabilities it is very likely that it interfaces with KMS to perform that encryption
• The KMS keys that are used to perform cryptographic operations must remain highly secure and are backed by Hardware Security Modules (HSMs)
• AWS employees do not have access to your keys within KMS and they cannot recover your keys for you should you delete them
• KMS is only capable of implementing encryption at rest using these Keys
• KMS does not perform encryption for data in transit or in motion
• KMS works seamlessly with AWS CloudTrail to audit and track how your encryption keys are being used and by whom 

Finally, in the last lecture, I dived a bit deeper into the various components of AWS KMS to help you understand some of the core elements and features. In this lecture I explained that:

• KMS Keys are the primary keys within the KMS service and can be used to perform cryptographic operations such as encrypting and decrypting your data.  
• By default KMS keys are created as a symmetric 256-bit AES-GCM key
• KMS keys never leave the KMS service 
• AWS services that provide encryption on your behalf will use symmetric encryption using KMS Keys
• You can also create asymmetric KMS keys which can also be used for encryption and signing, but not both! 
• 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 
• Customers can create asymmetric KMS keys giving greater control of the key itself known as customer managed keys
• There are 3 different types of keys from an ownership perspective when working with KMS, these being:

1. Customer managed
2. AWS managed
3. AWS owned

• When working with some AWS Services, we can specify a customer managed KMS key to use to encrypt data 
• AWS Managed keys are keys that are generated automatically by AWS services that integrate with KMS
• AWS managed keys are managed by AWS and you have no administration duties to maintain
• AWS managed keys are explicitly created by a specific service and will only be used by that service
• AWS managed keys have the following format: aws/servicename
• HMAC Keys are symmetric keys which allows you to create and verify hash-based message authentication codes (HMAC) 
• HMAC algorithms combine your data with the key material of the HMAC key to create a unique fixed-size tag and is associated with the data
• Verifying fixed-size tags allows you to check the integrity and authenticity of encrypted data  
• 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. 
• Data keys are designed to be used outside of KMS to encrypt data
• You can create an encrypted Data Key, or an encrypted data key, plus a plaintext version of the same key  
• Plaintext data keys are used to encrypt data 
• Data Keys use symmetric encryption
• Data Key pairs are asymmetric
• Data Key pairs are designed for use outside of KMS, such as client-side cryptography operations, in addition to signing and verification 
• The private key of a key pair remains in KMS
• The Public key of a Data key pair is used in conjunction with an encryption algorithm to encrypt data.  
• The Private key is used for decryption, but it must be decrypted to a plaintext key first.
• Key material is just a string of bits and the element that is used as a part of a cryptographic algorithm
• The origin of symmetric keys can be stored from a variety of secure sources
• Key material for each key is unique, unless using Multi Region KMS Keys
• Key rotation should be implemented as a security best practice 
• Key rotation is the process of changing the key material with new key material for your keys.  
• All existing key material is retained during rotation
• A key policy is a security feature within KMS that allows you to define who can use and access a particular key within KMS
• Grants are another method of controlling access to the use of the KMS keys and are primarily used for temporary access

That now brings me to the end of this course covering the fundamentals of the AWS Key Management Service (KMS), and so you should now have a better understanding of the basics of encryption, what the AWS KMS service is and what is has been designed to provide, along with the core components and features of KMS.

Feedback on our courses here at Cloud Academy is valuable to both us as trainers and any students looking to take the same course in the future. If you have any feedback, positive or negative, it would be greatly appreciated if you could contact support@cloudacademy.com.

Thank you for your time, and good luck with your continued learning of cloud computing. Thank you.