Certified Security - Specialty

Sign Up Free or Log In to participate!

Use KMS external token across regions

can the same KMS external token downloaded from one region be used in another region to generate a CMK so that multiple CMK are made available in multiple region in case a regional event affect KMS service?

4 Answers

I will be honest,
I don’t know. You would need to look at the relationship between the token and the KMS and if it can be validated remotely.

Have you tried it in a lab ? It does not look like it would cost more that a few dollars to test the theory.

Also before you come up with a custom BCP solution do take a look at what AWS recommend for high availability  😉



It seems the answer to the question you are asking is – No. Can’t do that.

Text from AWS Docs:


When you encrypt data under a KMS CMK, the ciphertext cannot be decrypted with any other CMK. This is true even when you import the same key material into a different CMK.


Source: https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html#importing-keys-considerations

Under the section titled: One CMK per ciphertext

My take: This is probably the reason why the terminology used in this concept is "key material" and not "your copy of the key". The underlying HSM behind KMS that creates the CMK might be adding some more "randomness" to the process that ensures that two CMKs created by the same imported key material are different for crypto purposes. I would be more confident in my assumptions here if I weren’t too lazy to try it out. If someone else has, or can give a more authoritative answer, please add to the reply!! Thanks!

If you’re asking if the we can import the same key material into two different CMKs, the answer is yes-and-no.

Yes, you can import the same key material into multiple CMKs across multiple regions — but…

No, you cannot decrypt data that was encrypted with a different CMK.

Data encrypted by a CMK can only ever decrypt data that exact same CMK, and no other CMK — even if it has identical key material (the 256-bit backing key between them is an exact match).

The way this works, is when you GenerateDataKey or use KMS to encrypt any data (files in S3 etc), the CMK is set in the metadata of the file (see ssekms_key_id of S3 objects).

Hence, encryption operations must specify the encryption key (or they default to the service key), but decryption operations do not need to specify any keys — as the CMK is already specified in the metadata of the object, or within the content of the EncryptedBlob.

For example a data key generated by a CMK in region A, will contain a pointer to the CMK inside the EncryptedBlob. That EncryptedBlob cannot be decrypted by anything except the original CMK that encrypted it.

I wrote a post about it, to jot down my understanding here:


As others have mentioned you can’t really create a KMS key across region like this.  If the data you are protecting with encryption was so critical it needed multi-region redundancy like this then the best solution is to have the data replicated or backed up to a second region ( exactly how you do this depends on the data storage type). The data backed up in the secondary region would be assigned a different KMS key located in the second region.  While you could try and get the source and destination KMS keys to use the same key data there would be no real benefit to this because of the reasons highlighted in the earlier answers.

Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!

Get Started
Who’s going to be learning?