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