Hello and welcome to this lecture where I shall explain what the KMS service is and the function that it provides to enhance your data security. 

Before we dive into KMS itself, I want to first provide a high-level overview of encryption to help you understand which cryptography method AWS KMS uses. Unencrypted data can be read and seen by anyone who has access to it and data stored at rest or sent between two locations in transit is known as plain text or clear text data. The data is plain to see and could be seen and understood by any recipient. There is no problem with this as long as the data is not sensitive in any way and doesn't need to be restricted. However, on the other hand, if you have data that is sensitive and you need to ensure that the contents of that data is only viewable by a particular recipient or recipients, then you need to add a level of encryption to that data. But what is data encryption? 

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. When encrypted, the original plain text is now known as cipher text which is unreadable. To decrypt the data, an encryption key is required to revert the cipher text back into a readable format of plain text. A key is simply a string of characters used in conjunction with the encryption algorithm and the longer the key the more robust the encryption. This encryption involving keys can be categorized by either being symmetric cryptography or asymmetric cryptography. 

AWS KMS only uses symmetric cryptography so let's take a look at what this is and what this means. With symmetric encryption, a single key is used to both encrypt and also decrypt the data. So for example if someone was using a symmetric encryption method, they would encrypt the data with a key and then when that same person needed to access that data, they would use the same key that they used to encrypt the data to decrypt the data. However, if the encrypted data was being read by a different person, that person would need to be issued the same key. Remember, the same key is needed to decrypt the data that was used to encrypt it. As a result, this key must be sent securely between the two parties and here it exposes a weakness in this method. If the key is intercepted by anyone during that transmission, then that third party could easily decrypt any data associated with that key. 

AWS KMS resolves this issue by acting as a central repository, governing and storing the keys required and only issues the decryption keys to those who have sufficient permissions to do so. Some common symmetric cryptography algorithms that are used are AES which is Advanced Encryption Standard, DES, Digital Encryption Standard, Triple DES and Blowfish. 

Now let's compare this to asymmetric encryption which involves two separate keys. One is used to encrypt the data and a separate key is used to decrypt the data. These keys are created both at the same time and are linked through a mathematical algorithm. One key is considered the private key and should be kept by a single party and should never be shared with anyone else. The other key is considered the public key and this key can be given and shared with anyone. Unlike with the symmetric encryption, this public key does not have to be sent over secure transmission. It doesn't matter who has access to this public key as without the private key, any data encrypted with it cannot be accessed. Both the private and public key is required to decrypt the data when asymmetric encryption is being used. So how does it work? 

If another party wanted to send you an encrypted message or data, they would encrypt the message using your own public key which can be made freely available to them or anyone. It's public for a reason. The message is then sent to you where you will use your own private key which has that mathematical relationship with your public key to decrypt the data. This allows you to send encrypted data to anyone without the risk of exposing your private key, resolving the issue highlighted with symmetric encryption. 

The advantage that symmetric has over asymmetric is the speed of encryption and decryption. Symmetric is a lot faster from a performance perspective. However, it does carry an additional risk as highlighted. Some common examples of asymmetric cryptography algorithms are RSA, Diffie-Hellman, and Digital Signature Algorithm. So now we know that AWS KSM uses symmetric cryptography for its encryption. Let me explain a little more about the service itself. 

The Key Management Service is a managed service used to store and generate encryption keys that can be used by other AWS services and applications to encrypt your data. For example, S3 may use the KMS service to enable S3 to offer and perform server-side encryption using KMS generated keys known as SSE-KMS. There are different types of keys used within KMS which perform different roles and functions. I will go into detail on these key types in the next lecture.

Due to the nature of this service, the contents contain highly sensitive data, the key is to decrypt your private data. As a result, administrators at AWS do not have access to your keys within KMS and they cannot recover your keys for you should you delete them. AWS simply administers the underlying operating system and application. All administrative actions performed by Amazon on the underlying system require dual authentication by two Amazon administrators to make sure the action is correct and will not cause any issues with the service. As AWS has no access to your keys, it's our responsibility as the customer and users of the KMS service to administer our own encryption keys and administer and restrict how those keys are deployed and used within our own environment against the data that we want to protect. It is important to understand that the KMS service is for encryption at rest only which can include for example S3 Object Storage, RDS, EMR and EBS Encryption to name a few. KMS does not perform encryption for data in transit or in motion. If you want to encrypt data while in transit, then you would need to use a different method such as SSL. However, if your data was encrypted at rest using KMS, then when it was sent from one source to another, that data would be a cipher text which could only be converted to plain text with the corresponding key. 

Another important aspect of encryption at rest is whether it is done server-side by the server or client-side by the end user. Examples of server-side encryption are back end servers that encrypt the data as it arrives transparent to the end user such as the example I gave earlier with SSE-KMS. The overhead of performing the encryption and managing the keys is handled by the server, in this case S3, not by the client-side application or the end user. Client-side encryption is quite different. Client-side encryption requires the user to interact with the data to make the data encrypted and the overhead of encryption process is on the client rather than the server. 

When working with encrypted data, compliance and regulations are often tightly integrated. As a result, KMS works seamlessly with AWS CloudTrail to audit and track how your encryption keys are being used and by whom in addition to other metadata captured by the APIs used such as the source IP address, et cetera. The CloudTrail logs that are stored in S3 record KMS API calls such as Decrypt, Encrypt, GenerateDataKey and GetKeyPolicy among others as shown on the screen. 

When architecting your environment with regards to data encryption, you need to be aware that AWS KMS is not a multi-region service like IAM is for example. It is region specific. Therefore, if you are working in a multi-region system with multi-region failover, you need to establish a Key Management Service in each region that you want to encrypt data. 

Now we have a base understanding that KMS generates and provides a secure central repository of encryption keys to allow you to encrypt your data at rest or integrating with numerous AWS services. In the next lecture, I want to expand the components that makeup the service.