內部通訊安全

透過 已驗證的工作階段 中描述的兩種機制：仲裁簽署的請求方法和使用 HSM 服務主機通訊協定驗證的工作階段對服務主機或 AWS KMS 電信業者與 HSM 之間的命令進行保護。

仲裁簽署命令的設計是為了讓任何單一電信業者都無法修改 HSM 提供的重要安全保護。在已驗證工作階段上執行的命令有助於確保只有授權的服務電信業者可以執行涉及 KMS 金鑰的操作。所有客戶綁定的機密資訊都會在 AWS 基礎設施得到保護。

金鑰建立

為了保護內部通訊，AWS KMS 使用兩種不同的金鑰建立方法。第一種被定義為使用離散對數密碼編譯的成對金鑰建立配置的建議 (修訂版 2)中的 C(1, 2, ECC DH)。此配置擁有搭配靜態簽署金鑰的啟動器。啟動器會產生並簽署暫時橢圓曲線 Diffie-Hellman (ECDH) 金鑰，用於具有靜態 ECDH 協定金鑰的收件人。此方法使用一個暫時金鑰和兩個的靜態金鑰 (使用 ECDH)。這是標籤 C(1, 2, ECC DH) 的衍生。此方法有時稱為單通 ECDH。

第二種金鑰建立方法是 C(2, 2, ECC, DH)。在這個配置中，雙方都有一個靜態簽署金鑰，其產生、簽署和交換暫時的 ECDH 金鑰。這個方法使用兩個靜態金鑰和兩個暫時金鑰，每個金鑰都使用 ECDH。這是標籤 C(2, 2, ECC, DH) 的衍生。這種方法有時被稱為 ECDH 暫時或 ECDHE。所有 ECDH 金鑰都會在曲線 secp384r1 (NIST-P384) 上產生。

HSM 安全邊界

AWS KMS 的內部安全邊界是 HSM。HSM 擁有專有界面，而且沒有其他處於操作狀態的作用中實體界面。在初始化期間，會使用必要的密碼編譯金鑰來佈建操作 HSM，以便在網域中建立其角色。HSM 的敏感密碼編譯材料只會存放在揮發性記憶體中，並在 HSM 移出操作狀態時清除，包括預期或非預期的關機或重設。

HSM API 操作會透過個別命令或透過服務主機建立的互相驗證機密工作階段進行驗證。

仲裁簽署的命令

仲裁簽署的命令是由電信業者核發給 HSM。本節描述了如何建立、簽署和驗證以仲裁為基礎的命令。這些規則相當簡單。例如，命令 Foo 需要角色 Bar 的兩個成員，以進行驗證。建立和驗證以仲裁為基礎的命令有三個步驟。第一步是初始命令建立；第二步是提交給其他電信業者進行簽署；第三步是驗證和執行。

為了引入這些概念，假設有一組真實的電信業者公有金鑰和角色 {QOS_s}，以及一組仲裁規則 QR = {Command_i, Rule_{{i, t}}}，其中每個規則是一組角色和最小數量 N {Role_t, N_t}。對於滿足仲裁規則的命令，命令資料集必須由列於 {QOS_s} 中的一組電信業者簽署，使其符合為該命令列出的規則之一。如前所述，仲裁規則和電信業者集會以網域狀態和匯出的網域字符存放。

實際上，初始簽署者會簽署命令 Sig₁ = Sign(dO_p1, Command)。第二名電信業者也會簽署命令 Sig₂ = Sign(dO_p2, Command)。雙重簽署的訊息會傳送至 HSM 執行。HSM 將執行以下內容：

1. 對於每個簽章，它會從網域狀態擷取簽署者的公有金鑰，並驗證命令上的簽章。

2. 它會驗證該組簽署者是否滿足命令的規則。

已驗證的工作階段

您的金鑰操作會在面向外部的 AWS KMS 主機和 HSM 之間執行。這些命令與密碼編譯金鑰的建立和使用以及安全的隨機數字產生有關。命令會在服務主機和 HSM 之間的工作階段驗證通道上執行。除了需要真實性之外，這些工作階段還需要機密性。在這些工作階段上執行的命令包括傳回純文字資料金鑰，以及為您提供的解密訊息。為了確保這些工作階段無法透過 man-in-the-middle 攻擊顛覆，工作階段會經過驗證。

此通訊協定會在 HSM 與服務主機之間執行相互驗證的 ECDHE 金鑰協定。交換由服務主機啟動，並由 HSM 完成。HSM 也會傳回由交涉金鑰加密的工作階段金鑰 (SK)，以及包含工作階段金鑰的匯出金鑰字符。匯出的金鑰字符包含有效期間，之後服務主機必須重新交涉工作階段金鑰。

服務主機是網域的成員，且具有身分簽署金鑰對 (dHOS_i, QHOS_i) 和 HSM 身分公有金鑰的真實複本。它會使用其一組身分簽署金鑰來安全地交涉可在服務主機與網域中任何 HSM 之間使用的工作階段金鑰。匯出的金鑰字符具有與其相關聯的有效期間，之後必須交涉新的金鑰。

程序從服務主機辨識開始，它需要工作階段金鑰來傳送和接收本身與網域的 HSM 成員之間的敏感通訊流程。

1. 服務主機會產生 ECDH 暫時金鑰對 (d₁, Q₁) 並使用其身分金鑰 Sig1 = Sign(dOS,Q₁) 進行簽署。

2. HSM 會使用目前的網域字符來驗證已接收公有金鑰上的簽章，並建立 ECDH 暫時金鑰對 (d₂, Q₂)。然後，它會根據使用離散對數密碼編譯的成對金鑰建立配置的建議 (修訂版 2) 完成 ECDH-key-exchange，以形成交涉的 256 位元 AES-GCM 金鑰。HSM 會產生全新的 256 位元 AES-GCM 工作階段金鑰。它會使用交涉的金鑰加密工作階段金鑰，以形成加密的工作階段金鑰 (ESK)。它還會將網域金鑰下的工作階段金鑰加密為匯出的金鑰字符 EKT。最後，它會用其身分金鑰對 Sig₂ = Sign(dHSK, (Q₂, ESK, EKT)) 簽署傳回值。

3. 服務主機會使用其目前的網域字符來驗證已接收金鑰上的簽章。然後，服務主機會根據使用離散對數密碼編譯的成對金鑰建立配置的建議 (修訂版 2) 完成 EDCH 金鑰交換。接下來會解密 ESK 以取得工作階段金鑰 SK。

在 EKT 有效期間，服務主機可以使用交涉的工作階段金鑰 SK，將信封加密的命名傳送至 HSM。通過此身份驗證會話的每個 service-host-initiated 命令都包含 EKT。HSM 會使用相同交涉的工作階段金鑰 SK 進行回應。