Key stores
A key store is a secure location for storing and using
cryptographic keys. The default key store in Amazon KMS also supports methods for generating and
managing the keys that it stores. By default, the cryptographic key material for the
Amazon KMS keys that you create in Amazon KMS is generated in and protected by hardware security
modules (HSMs) that are NIST Federal Information
Processing Standards (FIPS) 140 Cryptographic Module Validation Program (FIPS) 140-2 Level
3validated cryptographic modules
Amazon KMS supports several types of key stores to protect your keys. material when using Amazon KMS to create and manage your encryption keys. All of the key store options supplied by Amazon KMS are continually validated under FIPS 140 at Security Level 3 and are designed to prevent anyone, including Amazon operators, from accessing your plaintext keys or using them without your permission.
Amazon KMS standard key store
By default, a KMS key is created using the standard Amazon KMS HSM. This HSM type can be thought of as a multi-tenant fleet of HSMs that allows for the most scalable, lowest cost and easiest key store to manage from your perspective. If you care creating a KMS key for use within one or more Amazon Web Services services so that service can encrypt your data on your behalf, you will create a symmetric key. If you are using a KMS key for your own application design, you may choose to create a symmetric encryption key, asymmetric key, or HMAC key.
In the standard key store option, Amazon KMS creates your key, then encrypts it under keys that the service manages internally. Multiple copies of encrypted versions of your keys are then stored in systems that are designed for durability. Generating and protecting your key material in the standard key store type lets you take full advantage of the scalability, availability, and durability of Amazon KMS with the lowest operational burden and cost of the Amazon key stores.
Amazon KMS standard key store with imported key material
Instead of asking Amazon KMS to both generate and store the only copies of a given key, you can choose to import key material into Amazon KMS, allowing you to generate your own 256-bit symmetric encryption key, RSA or elliptic curve (ECC) key, or Hash-Based Message Authentication Code (HMAC) key, and apply it to a KMS key identifier (keyId). This is sometimes referred to as bring your own key (BYOK). Imported key material from your local key management system must be protected by using a public key issued by Amazon KMS, a supported cryptographic wrapping algorithm, and a time-based import token provided by Amazon KMS. This process verifies that your encrypted, imported key can only ever be decrypted by an Amazon KMS HSM once it has left your environment.
Imported key material may be useful if you have specific requirements around the system that generates keys, or want a copy of your key outside of Amazon as a backup. Note that you are responsible for an imported key material's overall availability and durability. While Amazon KMS has a copy of your imported key and will keep highly available while you need it, imported keys offer a special API for deletion – DeleteImportedKeyMaterial. This API will immediately delete all copies of the imported key material that Amazon KMS has, with no option for Amazon to recover the key. In addition, you can set an expiration time on an imported key, after which the key will be unusable. To make the key useful again in Amazon KMS, you will have to re-import the key material and assign it to the same keyId. This deletion action for imported keys is different than standard keys that Amazon KMS generates and stored for you on your behalf. In the standard case, the key deletion process has a mandatory waiting period where a key scheduled for deletion is first blocked from usage. This action allows you to see access denied errors in logs from any application or Amazon service that might need that key to access data. If you see such access requests, you can choose to cancel the scheduled deletion and re-enable the key. After a configurable waiting period (between 7 and 30 days), only then will KMS actually delete the key material, the keyID and all metadata associated with the key. For more information about availability and durability, see Protecting imported key material in the Amazon KMS Developer Guide.
There are some additional limitations with imported key material to be aware of. Since Amazon KMS cannot generate new key material, there is no way to configure automatic rotation of imported keys. You will need to create a new KMS key with a new keyId, then import new key material to achieve an effective rotation. Also, ciphertexts created in Amazon KMS under an imported symmetric key cannot be easily decrypted using your local copy of the key outside of Amazon. This is because the authenticated encryption format used by Amazon KMS appends additional metadata to the ciphertext to provide assurances during the decryption operation that the ciphertext was created by the expected KMS key under a previous encrypt operation. Most external cryptographic systems won’t understand how to parse this metadata to gain access to the raw ciphertext to be able to use their copy of a symmetric key. Ciphertexts created under imported asymmetric keys (e.g. RSA or ECC) can be used outside of Amazon KMS with the matching (public or private) portion of the key because there is no additional metadata added by Amazon KMS to the ciphertext.
Amazon KMS custom key stores
However, if you require even more control of the HSMs, you can create a custom key store.
A custom key store is a key store within Amazon KMS that is backed by a key manager outside of Amazon KMS, which you own and manage. Custom key stores combine the convenient and comprehensive key management interface of Amazon KMS with the ability to own and control the key material and cryptographic operations. When you use a KMS key in a custom key store, the cryptographic operations are performed by your key manager using your cryptographic keys. As a result, you assume more responsibility for the availability and durability of cryptographic keys, and for the operation of the HSMs.
Owning your HSMs may be useful to help meet certain regulatory requirements that don’t yet allow multi-tenant web services like the standard KMS key store to hold your cryptographic keys. Custom key stores are not more secure than KMS key store that use Amazon-managed HSMs, but they have different (and higher) management and cost implications. As a result, you assume more responsibility for the availability and durability of cryptographic keys and for the operation of the HSMs. Regardless of whether you use the standard key store with Amazon KMS HSMs or a custom key store, the service is designed so that no one, including Amazon employees, can retrieve your plaintext keys or use them without your permission. Amazon KMS supports two types of custom key stores, Amazon CloudHSM key stores and external key stores.
Unsupported features
Amazon KMS does not support the following features in custom key stores.
Amazon CloudHSM key store
You can create a KMS key in an Amazon CloudHSM
External key store
You can configure Amazon KMS to use an External Key Store (XKS), where root user keys are
generated, stored and used in a key management system outside the Amazon Web Services Cloud. Requests to
Amazon KMS to use a key for some cryptographic operation are forwarded to your externally hosted
system to perform the operation. Specifically, requests are forwarded to an XKS Proxy in
your network, which then forwards the request to whichever cryptographic system you use. The
XKS Proxy is an open-source specification that anyone can integrate with. Many commercial
key management vendors support the XKS Proxy specification. Because an External Key Store is
hosted by you or some third party, you own all of the availability, durability, and
performance of the keys in the system. To see if an External Key Store is a good fit for
your requirements, read Announcing
Amazon KMS External Key Store (XKS)