AWS kms documentation change
Summary
Updated NIST standard references to Revision 3 and removed an image reference
Security assessment
The update to NIST SP 800-56A Revision 3 references maintains alignment with current cryptographic standards, improving documentation accuracy. While this enhances security documentation quality, there is no indication of a specific resolved vulnerability.
Diff
diff --git a/kms/latest/developerguide/internal-communication-security.md b/kms/latest/developerguide/internal-communication-security.md index 4aaa85989..5d457f8df 100644 --- a//kms/latest/developerguide/internal-communication-security.md +++ b//kms/latest/developerguide/internal-communication-security.md @@ -15 +15 @@ The quorum-signed commands are designed so that no single operator can modify th -To secure internal communications, AWS KMS uses two different _key establishment_ methods. The first is defined as C(1, 2, ECC DH) in [Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revision 2)](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf). This scheme has an initiator with a static signing key. The initiator generates and signs an ephemeral elliptic curve Diffie-Hellman (ECDH) key, intended for a recipient with a static ECDH agreement key. This method uses one ephemeral key and two static keys using ECDH. That is the derivation of the label C(1, 2, ECC DH). This method is sometimes called one-pass ECDH. +To secure internal communications, AWS KMS uses two different _key establishment_ methods. The first is defined as C(1, 2, ECC DH) in [Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final). This scheme has an initiator with a static signing key. The initiator generates and signs an ephemeral elliptic curve Diffie-Hellman (ECDH) key, intended for a recipient with a static ECDH agreement key. This method uses one ephemeral key and two static keys using ECDH. That is the derivation of the label C(1, 2, ECC DH). This method is sometimes called one-pass ECDH. @@ -17 +17 @@ To secure internal communications, AWS KMS uses two different _key establishment -The second key establishment method is [C(2, 2, ECC, DH)](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf). In this scheme, both parties have a static signing key, and they generate, sign, and exchange an ephemeral ECDH key. This method uses two static keys and two ephemeral keys, each using ECDH. That is the derivation of the label C(2, 2, ECC, DH). This method is sometimes called ECDH ephemeral or ECDHE. All ECDH keys are generated on the curve secp384r1 (NIST-P384). +The second key establishment method is [C(2, 2, ECC, DH)](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final). In this scheme, both parties have a static signing key, and they generate, sign, and exchange an ephemeral ECDH key. This method uses two static keys and two ephemeral keys, each using ECDH. That is the derivation of the label C(2, 2, ECC, DH). This method is sometimes called ECDH ephemeral or ECDHE. All ECDH keys are generated on the curve secp384r1 (NIST-P384). @@ -25,2 +24,0 @@ The HSM API operations are authenticated either by individual commands or over a - - @@ -56 +54 @@ The process begins with the service host recognition that it requires a session - 2. The HSM verifies the signature on the received public key using its current domain token and creates an ECDH ephemeral key pair _(d 2, Q2)_. It then completes the ECDH-key-exchange according to [Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf) to form a negotiated 256-bit AES-GCM key. The HSM generates a fresh 256-bit AES-GCM session key. It encrypts the session key with the negotiated key to form the encrypted session key (ESK). It also encrypts the session key under the domain key as an exported key token _EKT_. Finally, it signs a return value with its identity key pair _Sig 2 = Sign(dHSK, (Q2, ESK, EKT))_. + 2. The HSM verifies the signature on the received public key using its current domain token and creates an ECDH ephemeral key pair _(d 2, Q2)_. It then completes the ECDH-key-exchange according to [Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final) to form a negotiated 256-bit AES-GCM key. The HSM generates a fresh 256-bit AES-GCM session key. It encrypts the session key with the negotiated key to form the encrypted session key (ESK). It also encrypts the session key under the domain key as an exported key token _EKT_. Finally, it signs a return value with its identity key pair _Sig 2 = Sign(dHSK, (Q2, ESK, EKT))_. @@ -58 +56 @@ The process begins with the service host recognition that it requires a session - 3. The service host verifies the signature on the received keys using its current domain token. The service host then completes the ECDH key exchange according to [Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf). It next decrypts the ESK to obtain the session key SK. + 3. The service host verifies the signature on the received keys using its current domain token. The service host then completes the ECDH key exchange according to [Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final). It next decrypts the ESK to obtain the session key SK.