KMS
KMS overview and attacks
Last updated
Was this helpful?
KMS overview and attacks
Last updated
Was this helpful?
KMS can directly encrypt/decrypt data but only up to 4096 bytes. Anything over this size limit requires leveraging a Data Encryption Key (DEK). Reference the for more as there are other use cases and types of keys.
When leveraging the AWS CLI (AWS SDK under the hood), the data is sent to the KMS service, and a KMS key is used to encrypt the data. The data is sent to the service because the KMS key cannot leave.
Again, the data is sent to the KMS service to be decrypted.
Data encryption keys can be generated when you need to encrypt / decrypt data larger than 4096 bytes. These keys are generated from a KMS key and the plaintext version performs the encryption. After the plaintext key encrypts the data, it should be deleted, and the encrypted version of the key stored alongside the encrypted data. The encrypted key contains metadata which describes the KMS key required to decrypt itself.
When generating a data encryption key using the AWS CLI (or AWS SDK) you must remember to delete the plaintext key otherwise an attacker can access your data. The AWS Encryption SDK can perform this task for you.
Store the CiphertextBlob
and Plaintext
like so.
Since the AWS CLI cannot utilize data encryption keys, you must use another solution such as openssl
.
Now, the plaintext_key
should be deleted and the encrypted_key
stored alongside the encrypted data.
Now, use the KMS key to decrypt the the encrypted_key
and store the plaintext key in a file, plaintext_key
.
Again, leverage openssl
or similar to decrypt the data.
A metadata file is generated which details the encryption process such as the KMS key used, algorithm, and more.
The can be leveraged as a CLI tool or in code such as Python, Java, JavaScript, .NET, and C. Utilizing this SDK will handle KMS and DEKs for you, simplifying the process compared to the previous examples of generating DEKs and using 3rd party solutions like openssl
.