With more and more sensitive applications being migrated to the public cloud, we’ve received several requests from our users to help them evaluate how the major cloud providers support crypto and key-management. In a series of posts, we’ll be taking a look at the cloud crypto APIs of AWS, Google, and Microsoft (Azure).
Why would you want to manage keys and perform cryptography using your cloud provider’s own platform rather than just doing it in software on your hosted virtual machine? The main incentive is greater security for the keys, but there are other advantages such as eliminating the need to provision keys during deployment of new versions of the application or easier compliance with various security standards.
In this first piece, we’ll take a quick outline look at the cryptography services offered by the big three. We will characterize them by what kind of secrets they will store, and what crypto they allow you to perform with them.
Amazon Key Management Service currently stores 256-bit AES keys as what they term Customer Master Keys (CMKs). These keys cannot be exported.
The AES keys can be used to encrypt and decrypt only. You can encrypt up to 4kB of data using the KMS API – the idea is that you will use this to encrypt a data key that will be used for encryption in your application, but you could also use it to encrypt other API keys or similar credentials. The current encryption algorithm is AES-GCM.
While encrypting, you can supply cleartext associated data that will be authenticated along with the ciphertext. The same associated data will be required as input in order for decryption to succeed. The initialisation vector (IV) is generated directly by the crypto provider, which should help to avoid problems with repeated IVs.
If you want to inject your own CMKs rather than leaving AWS to generate them, this is possible. You do so by generating a temporary (24-hour) 2048 bit RSA keypair for wrapping and unwrapping. You then generate the CMK yourself in your infrastructure, wrap it under the public key and send it AWS where you can unwrap it into the AWS store.
The wrapping and unwrapping algorithms include OAEP and, unfortunately, PKCS#1v1.5. However, you can at least select the algorithm to be used at wrap key generation time. This prevents a would-be attacker from using a PKCS#1v1.5 padding oracle to decrypt your key even though you wrapped it under OAEP.
You can also generate secrets of 1-1024 bytes in length, but these are exported immediately (either in the clear or encrypted by a CMK) and not stored.
Note If the KMS doesn’t give you the cryptographic functionality you need, Amazon also have a Cloud-hosted HSM available which offers a PKCS#11 interface. We’ll write more about that in a future article.
Google cloud platform KMS also generates and stores only 256-bit AES keys. You can use the keys to encrypt up to 64kB, so again this would most likely be used to encrypt another key, or to store credentials. The exact encryption algorithm used is a little vague in the documentation but seems to be AES-GCM with again the IV being generated directly by the crypto provider.
It is not currently possible to inject your own AES keys (or extract the keys Google generates). The encryption API does not seem to support associated data either.
The Azure keyvault supports RSA keys only at the moment. The keys can be used to encrypt one block of data, which means they will have to be used to encrypt data keys to treat larger volumes. It seems clear that MS intend to support symmetric keys in the future – for example some of the documentation already refers to them (which makes things a little confusing).
In addition to RSA keys, you can generate generic secret values of up to 25kB in size. These secrets have no semantics as keys though – you can just read them into software and use them.
The RSA keys can be used to sign and verify as well as encrypt and decrypt data. They can also be used to wrap and unwrap symmetric keys, though since at the moment Keyvault doesn’t support symmetric key cryptography, you could only use this to import generic secret values that you then use for symmetric crypto in software.
There is a mechanism for importing your own RSA keypairs from a Thales HSM, but the cryptographic details do not appear to be public.
|Host||Symmetric key||Asymmetric key||Data Size||Unwrap keys||Sign/Verify|
|AWS KMS||AES-GCM-256||×||4kB||with RSA-OAEP
|Azure Keyvault||×||RSA-2048 with RSA-OAEP
|with RSA-OAEP and
The top 3 providers are in fierce competition for larger accounts, for which they know secure crypto is a key selling point. As such their feature sets are moving fast and the docs are often confusing. In this first article we’ve tried to straighten out just what crypto is available in their core key management products. In future articles we’ll look at access control and key refresh. Got a topic you’d like to see covered? Let us know.