Questions About Encryption Keys and the Cloud

Questions About Encryption Keys and the Cloud

If you implement cybersecurity in your company, do you know where your encryption keys are stored, how they are accessed, and who administers them? If any of the answers to this is, “I don’t know”, then read on.

Like it or not we are moving to the public cloud. Why? It is often so much less expensive to build our information systems wouldn’t haven’t to worry about investing in hardware. And,

KMS (Key Management Store)

In the AWS cloud, we use the KMS (Key Management Store) to create our keys (Figure 1), and which can then be used to encrypt/decrypt data, sign/verify signatures, export data keys, and generate/verify MACs (Message Authentication Codes).

Overall you have keys that are AWS managed (such as for the Lambda service), Customer managed keys (these are created and managed by the customer), and Custom key stores (these are key stores where the customer has complete control over the keys).

What key types can be used with AWS?

The keys can then be used for ECS (Compute), EBS and S3 (Storage), and a range of other services. Overall, we use either a symmetric key or an RSA key pair to encrypt and decrypt. The symmetric key uses AES encryption, while RSA uses either 2K, 3K or 4K keys, and uses either “RSAES_OAEP_SHA_1” or “RSAES_OAEP_SHA_256" padding. With RSA, we encrypt with the public key and decrypt with the private key. For signatures, we can use either RSA or ECC signing. For RSA, we have 2K, 3K, or 4K keys, whereas ECC signing uses NIST P256, NIST P384, NIST P521, and SECG P256k1 (as used in Bitcoin and Ethereum).

I have outlined demos of these here:

• Symmetric Key Encryption. Go. An additional lab to outline the usage of symmetric key encryption using KMS.
• Public Key Encryption. Go. An additional lab to outline the usage of public key encryption using RSA, and in storing the key pair in KMS.
• Digital Signing. Go. An additional lab to outline the usage of public key encryption in generating an ECDSA signature, and in storing the key pair in KMS.

Can AWS access my keys?

KMS uses hardware security modules (HSMs) with FIPS 140–2 and which cannot be accessed by AWS employees (or any other customer). These can never appear on any disk or backup, only existing the memory of the HSM, and are only loaded when used. Along with this, the keys can be restricted to one region of the world (unless defined by the user).

With symmetric keys, the key never appears outside the HSM, and for asymmetric keys (public key encryption), the private key stages inside the HSM, and only the public key is exported outside.

How do I audit the usage of encryption keys?

It is important to audit how encryption keys are being used — both from a security and cost point-of-view. As seen in Figure 1, we can enable CloudWatch, and which will show how and when the encryption keys are being used.

What Happens if We Delete Keys By Mistake (or in a Hack)?

One of the most serious problems we can have with encryption keys is where the keys are deleted. A malicious person — either an insider or someone who has gained access to the Cloud infrastructure — could thus delete keys. The minimum time that can be set for a key to be deleted is seven days (and up to 30 days maximum):

This delay in deletion will mean that a log would identify that a key will be deleted, and hopefully caught if deleted incorrectly. It must be remembered that we will not be able to decrypt data that was encrypted by a key that has been deleted.

I don’t trust AWS, Can I have my own HSM?

While the KMS uses HSM, an organisation can also create its own HSM with the CloudHSM cluster. When a key is then created in KMS, it is then stored in the cluster:

Have we limited access to administration and usage?

Encryption keys are the crown jewels of your organisation, and access to the keys in the cloud can provide access to sensitive data, or in signing valid transactions. One use case is to separate the key managers and the key users. In this case, we can define a Key Management (KEY_ADMINISTRATOR) role and limit access to the usage of the keys. These key managers can perform actions of create, revoke, put, get, list and disable keys, such as:

"kms:Create*",
                "kms:Describe*",
                "kms:Enable*",
                "kms:List*",
                "kms:Put*",
                "kms:Update*",
                "kms:Revoke*",
                "kms:Disable*",
                "kms:Get*",
                "kms:Delete*",
                "kms:TagResource",
                "kms:UntagResource",
                "kms:ScheduleKeyDeletion",
                "kms:CancelKeyDeletion"

We can then define the permissions on the usage of the keys, such as with a KEY_WORKER role. The actions on this role can then be be:

"kms:Encrypt",
               "kms:Decrypt",
               "kms:ReEncrypt*",
               "kms:GenerateDataKey*",
               "kms:DescribeKey"

A WORKER can then not create or delete keys, and an ADMINISTRATOR cannot encrypt or decrypt data.

Overall, the rule of minimum access rights is the core of this, and to simplify user access by defining key administration and usage roles. Users are then added to these roles.

Can I have key rotation?

It is not a good task to manually update keys, and where some people may have access to previous keys. One way to overcome this is to implement key rotation, and where the keys are changed automatically every year. But, what if you have encrypted with a previously used key? Well, KMS keeps all the previous keys and will use them as required. The usage of key rotation is logged to CloudWatch and CloudTrail.

Does the key management infrastructure comply with PCI DSS Level 1, FIPS 140–2 and HIPAA?

A key element of many systems is compliance with key compliance standards. KMS complies with PCI DSS Level 1, FIPS 140–2, FedRAMP, HIPAA and others defined [here]. The AWS KMS (Key Management System) cryptographic module is matched to FIPS 140–2 Level 2, and with some elements matching to Level 3 — including aspects of physical security. FIP 140–2 is defined here:

Conclusions

The rules are simple. Zero Trust. Minimum rights for the task to be conducted, and audit and log accesses to keys.