A note on terminology –

  • Cloud KMS refers to Google’s KMS offering. It will never be used for AWS. AWS KMS is known as AWS KMS.
  • CMK (Customer managed key) in AWS is CMEK (Customer managed encryption key) in Cloud KMS
  • Customer MANAGED keys (CMEKs) should be distinguished from Customer GENERATED keys (CSEK –  Customer Supplied Encryption Key)
  • Symmetric encryption requires just one common key (used for both encrypt and decrypt operations). Asymmetric encryption requires a different key for encryption and a corresponding key for decryption.
  • Envelope Encryption – is simply treating a key as your data (payload) and encrypting this payload with another key.

What happens when you make an encrypt call in AWS KMS ( or – how does AWS KMS actually encrypt EBS volumes etc. ?)

AWS always requires you to pass in a CMK to any encrypt call.  Note that this is simply the key that encrypts the data key  (envelope encryption). The actual data key is not passed in to the encrypt call. The actual data key is generated automatically for you.

An envelope containing the encrypted data key is produced alongside the encrypted payload.

This results in a size limitation – AWS KMS cannot encrypt more than 4KB of data.

What use is it then? And how in the world does it encrypt giant EBS volumes? 

As it turns out, KMS DOES NOT encrypt the EBS volumes – it simply encrypts the data key that encrypts the EBS volumes. The actual encryption of the volumes uses the data key and a symmetric AES 256 algorithm (not KMS).

NOTE: Since Nov 2019, AWS KMS DOES support both symmetric and asymmetric encryption. However, this simply refers again to the CMK – the CMK can be a single key (symmetric) or a key pair (asymmetric). Once again, the encrypt call will simply accept a CMK and not an actual Data Key.

Do AWS Admins automatically get access to all KMS keys in the account?

No. A default access policy is attached to each new key. While the default polices  gives the AWS account that owns the KMS key full access to the KMS key, it does not automatically assign IAM users.

  • Unlike other AWS resource policies, an AWS KMS key policy does not automatically give permission to the account or any of its identities. To give permission to account administrators, the key policy must include an explicit statement that provides this permission, like this one.
  • It allows the account to use IAM policies to allow access to the KMS key, in addition to the key policy.
  • Without this permission, IAM policies that allow access to the key are ineffective, although IAM policies that deny access to the key are still effective.

Does AWS KMS only support Envelope Encryption? What about other encryption types – such as regular asymmetric encryption used for digital signatures?

AWS KMS DOES now supports creating asymmetric key pairs (such as RSA pairs for digital signatures) 

Slightly confusing terminology – but this section will try and explain symmetric and asymmetric encryption support in AWS KMS.

  • Firstly, remember the distinction between CMKs and data keys. The CMK is used to encrypt other keys. Data keys are used to encrypt actual payloads (data).
  • Now that we have this distinction in mind, KMS in AWS provides you with two types of CMKs – a symmetric CMK and an asymmetric CMK Pair.  Each of these can be used independently to perform envelope encryption – i.e. you can either use a symmetric  CMK to encrypt other keys – OR you can use the public part of a CMK key pair to encrypt other keys .
  • In addition, when we talk about encrypting payloads (not other keys), the data key used can also either be a single symmetric key (e.g. AES 256 encryption) or it can be an asymmetric key pair (e.g. RSA key pairs).
  • These data keys (symmetric or asymmetric) can be used outside of the AWS infrastructure – i.e. you can download these keys on a client PC and use them for either AES ( symmetric data key ) or RSA / ECC ( asymmetric key pair) encryption. All KMS will do is generate these data keys for you – and also tie them to a CMK internally.
  • You can use the public part of the data key pair within AWS KMS by calling the AWS KMS API operations, or download the public key and use it outside of AWS KMS.

Great. So AWS KMS supports asymmetric key pairs – for use only within AWS?

  • Not so. The key pairs can be used outside of the service – i.e. the public key can be both outside and inside. The private key is protected by KMS by envelope encrypting it with a CMK.  The public key can be used internally using KMS’ encrypt decrypt calls – or used outside of AWS.
  • Public keys can be distributed to customers  – they can either verify your signature our encrypt data that only you can decrypt. They can do this without involving AWS KMS.
  • All key usage is logged in AWS CloudTrail, the same as previous Symmetric CMK based encryption.

What about GCP KMS aka Cloud KMS? How is it different from AWS KMS?

GCP’s Cloud KMS can be used to encrypt any size payload (for Symmetric use cases).

For asymmetric encryption, again, just like AWS KMS, there is a size limitation, to where Cloud KMS is also only used for  encryption small workloads (typically other encryption keys).

Asymmetric encryption only supports a very small plaintext size, so asymmetric encryption is generally used for encryption keys, not large pieces data.

Envelope Encryption is a special case accommodated by Cloud KMS – using either a symmetric or an asymmetric key (public part of the key pair).

As an example, you can use asymmetric encryption as a variation of envelope encryption. In this scenario, anyone with access to the public key can encrypt the data encryption key (DEK). Only Cloud KMS can then decrypt the encrypted DEK, on behalf of the owner of the asymmetric key.

How else is Cloud KMS different ? What is a KeyRing?

Each key in cloud KMS must belong to a Key Ring. Key Rings need to be created before any cloud keys can be created.

There is no counterpart to this in AWS KMS. Keys can exist stand alone and the only way to keep track of keys is via tags and their key alias.

What about IAM? Are Key Policies any difference in AWS KMS vs Policies in GCP

The most important thing to realize is that although policies apply to resources, in GCP, there is no concept of a ‘resource level IAM policy’. In effect, there are IAM policies that can be defined at different levels – and are essentially ‘applied’ to every resource on that level.  One can assign a Cloud IAM policy at the organization level, the folder level, the project level, or (in SOME cases) the resource level.

The effective policy for a resource is the union of the policy set on the resource and the policy inherited from its ancestors.

So – Cloud KMS policies are inherited from the project to which the KMS keyring belongs.

Cloud KMS Key Management – Who can USE keys and who can MANAGE keys?

Cloud KMS IAM roles are largely divided into two categories:

  • Permission to manage keys
  • Permission to use keys

For example, the roles/cloudkms.admin role allows the holder to create Key Rings, Crypto Keys, set IAM policies, and perform management-related operations.

  • The roles/cloudkms.cryptoKeyEncrypterDecrypter grants the holder the encrypt and decrypt data, but it does not include management permissions.
  • IAM roles are inherited by their parent resource. If someone has the roles/cloudkms.admin role on the Google Cloud project, they are an admin of all keys in that project.
  • If they have roles/cloudkms.admin on a Key Ring, they are an admin of all keys in that Key Ring. If they have roles/cloudkms.admin on a single Crypto Key, they are only an admin of that key.

Summary

While they sound similar on the surface, there are notable differences between Google Cloud’s KMS and AWS’s KMS Services.   Cloud KMS, from the start, supported both symmetric and asymmetric key generation and payload encryption.  In addition, envelope encryption is just a special case of the already supported Cloud KMS symmetric encryption.

AWS originally only supported envelope encryption. To the extent that even when AWS KMS was used for EBS encryption, it wasn’t a KMS encrypt call that encrypted the EBS volume. Only regular AES encryption was used for the EBS encryption. KMS simply encrypted the encryption key.

Recently, AWS KMS has gone beyond envelope encryption, by offering asymmetric encryption.  The asymmetric AWS KMS capabilities can be used to generate data key pairs, which can be used internally as well as externally (i.e. one can use the public key outside of the AWS environment).

Next Steps?

For an initial infrastructure security, KMS or data encryption consultation on AWS, Azure or GCP, pick a time here. For a general consultation, Set up a time here .

Appendix A : Quickstart Cloud KMS Encryption (Symmetric)

  1. Create a key ring and a key as described in Creating key rings and keys.
  2. Ensure the user that is calling the encrypt and decrypt methods has the cloudkms.cryptoKeyVersions.useToEncrypt and cloudkms.cryptoKeyVersions.useToDecrypt permissions on the key used to encrypt or decrypt. One way to permit a user to encrypt or decrypt is to add the user to the roles/cloudkms.cryptoKeyEncrypter, roles/cloudkms.cryptoKeyDecrypter, or roles/cloudkms.cryptoKeyEncrypterDecrypter

Anuj holds professional certifications in Google Cloud, AWS as well as certifications in Docker and App Performance Tools such as New Relic. He specializes in Cloud Security, Data Encryption and Container Technologies.

Initial Consultation

Anuj Varma – who has written posts on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

 Twitter Linkedin