

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 内部通信安全
<a name="internal-communication-security"></a>

服务主机或 AWS KMS 操作员与之间的命令通过中描述的 HSMs 两种机制进行保护[经身份验证的会话](#authenticated-sessions)：法定签名的请求方法和使用 HSM-Service 主机协议的经过身份验证的会话。

经过法定签名的命令经过精心设计，任何操作员都无法修改其提供的关键安全保护。 HSMs 在经过身份验证的会话中运行的命令可帮助确保只有授权的服务运营商才能执行涉及 KMS 密钥的操作。所有与客户绑定的机密信息在整个 AWS 基础架构中都受到保护。

## 密钥建立
<a name="key-establishment"></a>

为了保护内部通信， AWS KMS 使用两种不同的密钥建立方法。第一种方法定义为 [Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revision 2)](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf) 中的 C(1, 2, ECC DH)。此方案有一个带静态签名密钥的启动程序。启动程序会生成一个临时椭圆曲线 Diffie-Hellman (ECDH) 密钥并签名，旨在用于具有静态 ECDH 协议密钥的收件人。此方法使用一个临时密钥和两个使用 ECDH 的静态密钥。这是标签 C(1, 2, ECC DH) 的衍生。此方法有时称为一次性 ECDH。

第二种密钥建立方法是 [C(2, 2, ECC, DH)](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf)。在此方案中，双方都有一个静态签名密钥，然后会生成、签名和交换临时 ECDH 密钥。此方法使用两个静态密钥和两个临时密钥（各自使用 ECDH）。这是标签 C(2, 2, ECC, DH) 的衍生。此方法有时称为临时 ECDH 或 ECDHE。所有 ECDH 密钥均在曲线 secp384r1 (NIST-P384) 上生成。

## HSM 安全边界
<a name="hsm-security-boundary"></a>

的内部安全边界 AWS KMS 是 HSM。HSM 具有专有接口，在其处于运行状态时没有其他活动物理接口。运行的 HSM 在初始化期间使用必要的加密密钥进行预置，从而在域中建立其角色。HSM 的敏感加密材料仅存储在易失性存储器中，并在 HSM 退出运行状态（包括预期或非预期关机或重置）时擦除。

HSM API 操作可以通过单个命令进行身份验证，也可以通过服务主机建立的相互认证的机密会话进行身份验证。

![\[HSM API 操作。\]](http://docs.aws.amazon.com/zh_cn/kms/latest/cryptographic-details/images/HSM-API-Operations.png)


## 仲裁签名命令
<a name="quorum-signed-commands"></a>

法定签名的命令由操作员向发出。 HSMs本节介绍如何创建、签名和验证基于仲裁的命令。这些规则相当简单。例如，命令 *Foo* 需要对角色 *Bar* 的两名成员进行身份验证。创建和验证基于仲裁的命令有三个步骤。第一步是初始命令创建；第二步是提交给要签名的其他运营商；第三步是验证和执行。

为介绍这些概念，假设有一组真实的运营商公有密钥和角色 *\$1QOSs\$1*，以及一组仲裁规则 *QR = \$1Commandi, Rule\$1i, t\$1\$1*，其中每个 *Rule* 均为一组角色，且最小数字为 *N \$1Rolet, Nt\$1*。为使命令满足仲裁规则，命令数据集必须由 *\$1QOSs\$1* 中列出的一组运营商进行签名，以使其满足该命令列出的规则之一。如前所述，仲裁规则和运营商组存储在域状态和导出的域令牌中。

实际上，初始签名者会将命令 *Sig1 = Sign(dOp1, Command) * 签名。第二个运营商也会将命令 *Sig2 = Sign(dOp2, Command) * 签名。双重签名的消息将发送给 HSM 执行。HSM 将执行以下操作：

1. 对于每个签名，它会从域状态中提取签名者的公有密钥，并验证命令中的签名。

1. 它会验证该组签名者是否满足命令规则。

## 经身份验证的会话
<a name="authenticated-sessions"></a>

您的密钥操作在面向外部 AWS KMS 的主机和. HSMs 这些命令与加密密钥的创建和使用以及安全随机数生成有关。这些命令在服务主机与之间经过会话验证的通道上运行。 HSMs除了需要真实性以外，这些会话还需要机密性。这些会话上运行的命令包括返回明文数据密钥和为您解密的消息。为了确保这些会话不会被 man-in-the-middle攻击颠覆，会话需要经过身份验证。

此协议在 HSM 与服务主机之间执行经过相互身份验证的 ECDHE 密钥协议。交换由服务主机发起，并由 HSM 完成。HSM 还返回通过协商密钥加密的会话密钥 (SK) 和包含会话密钥的导出密钥令牌。导出的密钥令牌包含一个有效期，经过该期限后服务主机必须重新协商会话密钥。

服务主机是域的成员，拥有身份签名密钥对*（DHO i、QHOSi）*和 “身份 HSMs” 公钥的真实副本。它使用其身份签名密钥组来安全地协商会话密钥，该密钥可在服务主机与域中的任何 HSM 之间使用。导出的密钥令牌有一个与其关联的有效期，经过该期限后必须协商一个新密钥。

![\[HSM 服务主机运营商经身份验证的会话。\]](http://docs.aws.amazon.com/zh_cn/kms/latest/cryptographic-details/images/HSM-Host-Operator-Sessions.png)


该过程从服务主机识别开始，它需要会话密钥才能在自身和域 HSM 成员之间发送和接收敏感通信流。

1. 服务主机会生成 ECDH 临时密钥对 *(d1, Q1)*，并使用其身份密钥 *Sig1 = Sign(dOS,Q1)* 进行签名。

1. HSM 使用其当前域令牌验证收到的公有密钥的签名，然后创建 ECDH 临时密钥对 *(d2, Q2)*。然后，它 ECDH-key-exchange根据[使用离散对数密码学的配对密钥建立方案建议（修订版）完成以形成协商的256位AES-GCM](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf) 密钥。HSM 会生成新的 256 位 AES-GCM 会话密钥。它使用协商密钥来加密会话密钥，从而形成加密的会话密钥 (ESK)。它还加密域密钥下的会话密钥作为导出的密钥令牌 *EKT*。最后，它使用其身份密钥对 *Sig2 = Sign(dHSK, (Q2, ESK, EKT))* 将返回值签名。

1. 服务主机使用其当前域令牌验证收到的密钥的签名。然后，服务主机会根据 [Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf) 完成 ECDH 密钥交换。接下来，它会解密 ESK 以获取会话密钥 SK。

在 *EKT* 的有效期内，服务主机可使用协商的会话密钥 *SK* 向 HSM 发送信封加密的命令。此经过身份验证的会话上的每个 service-host-initiated命令都包含 *EKT。*HSM 使用相同的协商会话密钥 SK 进行响应。