翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
内部通信セキュリティ
サービスホスト間または AWS KMS オペレーターと HSM の間のコマンドは、認証済みセッション に示されている定足数署名付きリクエストメソッドと HSM サービスホストプロトコルを使用した認証セッションという 2 つのメカニズムによって保護されます。
定足数署名付きコマンドは、HSM が提供する重要なセキュリティ保護を 1 人のオペレーターが改変できないように設計されています。認証されたセッションで実行されるコマンドは、許可されたサービスオペレーターだけが KMS キーに関連する操作を実行できるようにするのに役立ちます。お客様にバインドされたすべての秘密情報は、AWS インフラストラクチャ全体で保護されます。
キー確立
内部通信を保護するために、AWS KMS では、2 つの異なるキー確立方法を使用します。1 つ目は、「Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revision 2)
2 つ目のキー確立方法は、 (2, 2, ECC, DH)
HSM セキュリティ境界
AWS KMS の内部セキュリティ境界は HSM です。HSM には独自のインターフェイスがあり、動作状態では他のアクティブな物理インターフェイスはありません。動作中の HSM は、ドメイン内でのロールを確立するために必要な暗号化キーを使用して初期化中にプロビジョニングされます。HSM の機密暗号化マテリアルは、揮発性メモリにのみ保存され、意図的であるかないかにかかわらず、シャットダウンやリセットなど、動作状態でなくなると消去されます。
HSM API オペレーションは、個々のコマンドによって、またはサービスホストによって確立された相互に認証された機密セッションによって認証されます。
![HSM API オペレーション](images/HSM-API-Operations.png)
定足数署名付きコマンド
定足数署名付きコマンドは、オペレーターによって HSM に対して発行されます。このセクションでは、定足数ベースのコマンドを作成、署名、および認証する方法について説明します。これらのルールはかなり簡単です。例えば、コマンド Foo には、ロール Bar からの 2 人のメンバーが必要といったものです。定足数ベースのコマンドの作成と検証には、3 つのステップがあります。最初のステップは元になるコマンドの作成で、2 番目のステップは署名する追加のオペレーターへの送信、3 番目のステップは検証と実行です。
概念を説明するために、次のように仮定します。オペレーターのパブリックキーとロールの信頼できるセット {QOSs} があり、一連の定足数ルール QR = {Commandi, Rule{i, t}} があるとします。ここで、各ルールはロールと最小数 N {Rolet, Nt} のセットです。コマンドが定足数ルールを満たすためには、{QOSs} にリストされている一連のオペレーターが、そのコマンド用にリストされているルールのいずれかを満たすように、コマンドデータセットに署名する必要があります。前述のように、定足数ルールとオペレーターのセットは、ドメイン状態とエクスポートされたドメイントークンに保存されます。
実際には、最初の署名者はコマンド Sig1 = Sign(dOp1, Command) に署名します。2 番目のオペレーターもコマンド Sig2 = Sign(dOp2, Command) に署名します。2 者に署名されたメッセージは、実行のために HSM に送信されます。HSM は、次の内容を実行します。
-
署名ごとに、ドメイン状態から署名者のパブリックキーを抽出し、コマンドの署名を検証します。
-
署名者のセットがコマンドのルールを満たしていることを確認します。
認証済みセッション
キーのオペレーションは、外部に向けられた AWS KMS ホストと HSM の間で実行されます。これらのコマンドは、暗号キーの作成と使用、および安全な乱数の生成に関係します。コマンドは、サービスホストと HSM の間のセッション認証チャネル上で実行されます。これらのセッションには、真正性が必要なだけでなく、機密性も必要です。これらのセッションで実行されるコマンドは、発行者に向けてクリアテキストのデータキーや復号化されたメッセージを返送することがあります。これらのセッションを man-in-the-middle 攻撃によって覆すことがないように、セッションは認証されます。
このプロトコルは、HSM とサービスホスト間で相互に認証された ECDHE キー共有を実行します。交換はサービスホストが開始し、HSM が完了させます。HSM は、ネゴシエートされたキーによって暗号化されたセッションキー (SK) と、セッションキーを含むエクスポートされたキートークンも返します。エクスポートされたキートークンには有効期間が含まれています。有効期間が終了すると、サービスホストはセッションキーを再ネゴシエートする必要があります。
サービスホストはドメインのメンバーであり、ID 署名キーペア (dHOSi, QHOSi) と HSM の ID パブリックキーの信頼できるコピーを持っています。サービスホストは、ID 署名キーのセットを使用して、サービスホストとドメイン内の任意の HSM との間で使用できるセッションキーを安全にネゴシエートします。エクスポートされたキートークンには有効期間が関連付けられています。有効期間が終了すると、新しいキーをネゴシエートする必要があります。
![HSM とサービスホストのオペレーターが認証したセッション](images/HSM-Host-Operator-Sessions.png)
このプロセスは、サービスホストが、自身とドメインの HSM メンバー間で機密通信フローを送受信するにはセッションキーが必要であることを認識することから始まります。
-
サービスホストが ECDH 一時的キーペア (d1, Q1) を生成し、これに ID キー Sig1 = Sign(dOS,Q1) で署名します。
-
HSM は、受信したパブリックキーの署名を現在のドメイントークンを使用して検証し、ECDH 一時的キーペア (d2, Q2) を作成します。その後、「Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)
」に従って ECDH キー交換を完了させ、ネゴシエートされた 256 ビット AES-GCM キーを形成します。HSM は、新しい 256 ビット AES-GCM セッションキーを生成します。ネゴシエートされたキーを使用してセッションキーを暗号化し、暗号化されたセッションキー (ESK) を形成します。また、ドメインキーの下にあるセッションキーをエクスポートされたキートークン EKT として暗号化します。最後に、ID キーペア Sig2 = Sign(dHSK, (Q2, ESK, EKT)) で戻り値に署名します。 -
サービスホストは、現在のドメイントークンを使用して、受信したキーの署名を検証します。次に、サービスホストは「Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)
」に従って、 ECDH キー交換を完了させます。次に ESK を復号化し、セッションキー SK を取得します。
EKT の有効期間中は、サービスホストはネゴシエートされたセッションキー SK を使用して、エンベロープで暗号化されたコマンドを HSM に送信できます。この認証済みセッションのすべての service-host-initiated コマンドには、EKT が含まれます。HSM は、ネゴシエートされた同じセッションキー SK を使用して応答します。