|
|
本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
内部通信安全
服务主机或 AWS KMS 运营商与 HSM 之间的命令通过 经身份验证的会话 中描述的两种机制进行保护：仲裁签名请求方法和使用 HSM 服务主机协议的经身份验证会话。
仲裁签名命令旨在让任何单个运营商都无法修改 HSM 提供的重要安全保护。在经过身份验证的会话中运行的命令可帮助确保只有授权的服务运营商才能执行涉及 KMS 密钥的操作。所有客户绑定的机密信息均可跨 AWS 基础设施进行保护。
为了保护内部通信,AWS KMS 使用两种不同的密钥建立方法。第一种方法定义为
Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revision 2)
第二种密钥建立方法是
C(2, 2, ECC, DH)
HSM 安全边界
AWS KMS 的内部安全边界是 HSM。HSM 具有专有接口，在其处于运行状态时没有其他活动物理接口。运行的 HSM 在初始化期间使用必要的加密密钥进行预置，从而在域中建立其角色。HSM 的敏感加密材料仅存储在易失性存储器中，并在 HSM 退出运行状态（包括预期或非预期关机或重置）时擦除。
HSM API 操作可以通过单个命令进行身份验证，也可以通过服务主机建立的相互认证的机密会话进行身份验证。
仲裁签名命令
仲裁签名命令由运营商发给 HSM。本节介绍如何创建、签名和验证基于仲裁的命令。这些规则相当简单。例如，命令 Foo 需要对角色 Bar 的两名成员进行身份验证。创建和验证基于仲裁的命令有三个步骤。第一步是初始命令创建；第二步是提交给要签名的其他运营商；第三步是验证和执行。
为介绍这些概念，假设有一组真实的运营商公有密钥和角色 { QOS s } ，以及一组仲裁规则 QR = { Command i , Rule { i, t} } ，其中每个 Rule 均为一组角色，且最小数字为 N { Role t , N t } 。为使命令满足仲裁规则，命令数据集必须由 { QOS s } 中列出的一组运营商进行签名，以使其满足该命令列出的规则之一。如前所述，仲裁规则和运营商组存储在域状态和导出的域令牌中。
实际上，初始签名者会将命令 Sig 1 = Sign(dO p1 , Command) 签名。第二个运营商也会将命令 Sig 2 = Sign(dO p2 , Command) 签名。双重签名的消息将发送给 HSM 执行。HSM 将执行以下操作：
经身份验证的会话
您的密钥操作在面向外部的 AWS KMS 主机和 HSM 之间运行。这些命令与加密密钥的创建和使用以及安全随机数生成有关。这些命令在服务主机与 HSM 之间的会话验证的通道上运行。除了需要真实性以外，这些会话还需要机密性。这些会话上运行的命令包括返回明文数据密钥和为您解密的消息。为了确保这些会话不会被 man-in-the-middle 攻击颠覆，会话需要经过身份验证。
此协议在 HSM 与服务主机之间执行经过相互身份验证的 ECDHE 密钥协议。交换由服务主机发起，并由 HSM 完成。HSM 还返回通过协商密钥加密的会话密钥 (SK) 和包含会话密钥的导出密钥令牌。导出的密钥令牌包含一个有效期，经过该期限后服务主机必须重新协商会话密钥。
服务主机是域成员，具有身份签名密钥对 (dHOS i , QHOS i ) 和 HSM 身份公有密钥的真实副本。它使用其身份签名密钥组来安全地协商会话密钥，该密钥可在服务主机与域中的任何 HSM 之间使用。导出的密钥令牌有一个与其关联的有效期，经过该期限后必须协商一个新密钥。
服务主机会生成 ECDH 临时密钥对 (d 1 , Q 1 ) ，并使用其身份密钥 Sig1 = Sign(dOS,Q 1 ) 进行签名。