Interne Kommunikationssicherheit - AWS Key Management Service
Schlüssel-EinrichtungHSM-SicherheitsgrenzeQuorumsignierte BefehleAuthentifizierte Sitzungen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Interne Kommunikationssicherheit

Befehle zwischen den Dienst-Hosts oder AWS KMS -Operatoren und den HSMs werden durch zwei Mechanismen gesichert, die unter beschrieben sindAuthentifizierte Sitzungen: eine quorumsignierte Anforderungsmethode und eine authentifizierte Sitzung unter Verwendung eines HSM-Service-Hostprotokolls.

Die quorumsignierten Befehle sind so konzipiert, dass kein einzelner Bediener die kritischen Sicherheitsvorkehrungen, die sie bieten, ändern kann. HSMs Die Befehle, die über die authentifizierten Sitzungen ausgeführt werden, tragen dazu bei, dass nur autorisierte Service-Operatoren Operationen mit KMS-Schlüsseln ausführen können. Alle an Kunden gebundenen geheimen Informationen sind in der gesamten Infrastruktur gesichert. AWS

Schlüssel-Einrichtung

AWS KMS Verwendet zur Sicherung der internen Kommunikation zwei verschiedene wichtige Methoden zur Einrichtung. Die erste ist als C(1, 2, ECC DH) in der Empfehlung für Paarweise Schlüsseleinrichtungsschemata mit diskreter Logarithmus-Kryptographie (Revision 2) definiert. Dieses Schema hat einen Initiator mit einem statischen Signaturschlüssel. Der Initiator generiert und signiert einen ephemeren elliptischen Kurven-Diffie-Hellman-Schlüssel (ECDH), der für einen Empfänger mit einem statischen ECDH-Übereinstimmungsschlüssel bestimmt ist. Diese Methode verwendet einen ephemeren Schlüssel und zwei statische Schlüssel mit ECDH. Das ist die Ableitung der Markierung C (1, 2, ECC DH). Diese Methode wird manchmal als One-Pass-ECDH bezeichnet.

Die zweite Methode zur Schlüsseleinrichtung ist C(2, 2, ECC, DH). In diesem Schema haben beide Parteien einen statischen Signaturschlüssel, und sie generieren, signieren und tauschen einen ephemeren ECDH-Schlüssel aus. Diese Methode verwendet zwei statische Schlüssel und zwei ephemere Schlüssel, die jeweils ECDH verwenden. Das ist die Ableitung der Markierung C (2, 2, ECC DH). Diese Methode wird manchmal als ephemere ECDH oder ECDHE bezeichnet. Alle ECDH-Schlüssel werden auf der Kurve secp384r1 (NIST-P384) generiert.

HSM-Sicherheitsgrenze

Die innere Sicherheitsgrenze von AWS KMS ist das HSM. Das HSM verfügt über eine proprietäre Schnittstelle und keine anderen aktiven physikalischen Schnittstellen im Betriebszustand. Ein operatives HSM wird während der Initialisierung mit den erforderlichen kryptografischen Schlüsseln bereitgestellt, um seine Rolle in der Domäne festzulegen. Sensible kryptografische Materialien des HSM werden nur im flüchtigen Speicher gespeichert und gelöscht, wenn das HSM den Betriebszustand verlässt, einschließlich beabsichtigter oder unbeabsichtigter Abschaltungen oder Rücksetzungen.

Die HSM-API-Operationen werden entweder durch einzelne Befehle oder über eine gegenseitig authentifizierte vertrauliche Sitzung authentifiziert, die von einem Service-Host eingerichtet wird.

HMS-API-Operationen.

Quorumsignierte Befehle

Befehle mit Quorumsignierung werden von Operatoren an ausgegeben. HSMs In diesem Abschnitt wird beschrieben, wie quorumbasierte Befehle erstellt, signiert und authentifiziert werden. Diese Regeln sind ziemlich einfach. Beispielsweise erfordert der Befehl Foo, dass zwei Mitglieder der Rolle Bar authentifiziert werden. Es gibt drei Schritte bei der Erstellung und Überprüfung eines quorumbasierten Befehls. Der erste Schritt ist die anfängliche Befehlserstellung; die zweite ist die Vorlage an zusätzliche Operatoren zur Unterzeichnung; und die dritte ist die Überprüfung und Ausführung.

Gehen Sie zur Einführung der Konzepte davon aus, dass es einen authentischen Satz von öffentlichen Schlüsseln und Rollen des Operators {QOSs} und einen Satz von Quorum-Regeln QR = {Command, Rule{i, t}} gibti, wobei jede Regel aus einer Gruppe von Rollen und der Mindestanzahl N {Role, N} besteht. t t Damit ein Befehl die Quorumregel erfüllt, muss die Befehlsdatei von einer in {QOSs} aufgelisteten Gruppe von Operatoren signiert sein, sodass sie eine der für diesen Befehl aufgeführten Regeln erfüllen. Wie bereits erwähnt, werden die Quorumregeln und Operatoren im Domänenstatus und im exportierten Domänen-Token gespeichert.

In der Praxis signiert ein Initialsignierer den Befehl Sig1 = Sign(dOp1, Befehl) . Ein zweiter Operator signiert auch den Befehl Sig2 = Sign(dOp2, Befehl) . Die doppelt signierte Nachricht wird zur Ausführung an ein HSM gesendet. Die HMS führt Folgendes aus:

  1. Für jede Signatur wird der öffentliche Schlüssel des Unterzeichners aus dem Domainstatus extrahiert und die Signatur des Befehls überprüft.

  2. Es überprüft, ob die Gruppe von Unterzeichnern eine Regel für den Befehl erfüllt.

Authentifizierte Sitzungen

Ihre wichtigsten Operationen laufen zwischen den nach außen gerichteten AWS KMS Hosts und dem. HSMs Diese Befehle beziehen sich auf die Erstellung und Verwendung von kryptografischen Schlüsseln und die sichere Zufallszahlengenerierung. Die Befehle werden über einen sitzungsauthentifizierten Kanal zwischen den Service-Hosts und dem ausgeführt. HSMs Neben der Notwendigkeit der Authentizität erfordern diese Sitzungen Vertraulichkeit. Befehle, die über diese Sitzungen ausgeführt werden, umfassen die Rückgabe von Klartext-Datenschlüsseln und entschlüsselten Nachrichten, die für Sie bestimmt sind. Um sicherzustellen, dass diese Sitzungen nicht durch man-in-the-middle Angriffe unterlaufen werden können, werden die Sitzungen authentifiziert.

Dieses Protokoll führt eine gegenseitig authentifizierte ECDHE-Schlüsselvereinbarung zwischen dem HSM und dem Service-Host durch. Der Austausch wird vom Service-Host initiiert und vom HSM abgeschlossen. Der HSM gibt auch einen durch den ausgehandelten Schlüssel verschlüsselten Sitzungsschlüssel (SK) und einen exportierten Schlüssel-Token zurück, der den Sitzungsschlüssel enthält. Das exportierte Schlüssel-Token enthält einen Gültigkeitszeitraum, nach dem der Service-Host einen Sitzungsschlüssel neu aushandeln muss.

Ein Service-Host ist Mitglied der Domain und verfügt über ein Identity-Signing-Schlüsselpaar (DHOSi, QHOSi) und eine authentische Kopie der öffentlichen Identitätsschlüssel HSMs. Es verwendet seinen Satz von Identitätssignierungsschlüsseln, um sicher einen Sitzungsschlüssel auszuhandeln, der zwischen dem Service-Host und jedem HSM in der Domäne verwendet werden kann. Den exportierten Schlüssel-Token ist ein Gültigkeitszeitraum zugeordnet, nach dem ein neuer Schlüssel ausgehandelt werden muss.

HSM-Service-Hostoperator authentifizierte Sitzungen.

Der Prozess beginnt damit, dass der Service-Host erkennt, dass er einen Sitzungsschlüssel benötigt, um vertrauliche Kommunikationsflüsse zwischen ihm und einem HSM-Mitglied der Domäne zu senden und zu empfangen.

  1. Ein Service-Host generiert ein ephemeres ECDH-Schlüsselpaar (d1, Q1) und signiert es mit seinem Identitätsschlüssel Sig1 = Sign(dOS,Q1).

  2. Das HSM überprüft die Signatur auf dem empfangenen öffentlichen Schlüssel mit seinem aktuellen Domänen-Token und erstellt ein ephemeres ECDH-Schlüsselpaar (d2, Q2). Anschließend vervollständigt er die ECDH-key-exchange gemäß der Empfehlung für paarweise Verfahren zur Einrichtung von Schlüsseln unter Verwendung diskreter Logarithmus-Kryptografie (überarbeitet), um einen ausgehandelten 256-Bit-AES-GCM-Schlüssel zu erstellen. Das HSM generiert einen neuen 256-Bit-AES-GCM-Sitzungsschlüssel. Es verschlüsselt den Sitzungsschlüssel mit dem ausgehandelten Schlüssel, um den verschlüsselten Sitzungsschlüssel (ESK) zu bilden. Es verschlüsselt auch den Sitzungsschlüssel unter dem Domänenschlüssel als exportiertes Schlüssel-Token EKT. Schließlich signiert es einen Rückgabewert mit seinem Identitätsschlüsselpaar Sig2 = Sign(dHSK, (Q2, ESK, EKT)).

  3. Der Service-Host überprüft die Signatur für die empfangenen Schlüssel mit seinem aktuellen Domänen-Token. Der Service-Host schließt dann den ECDH-Schlüsselaustausch gemäß der -Empfehlung für paarweise Schlüsseleinrichtungsschemata unter Verwendung von diskreter Logarithmus-Kryptographie (überarbeitet) ab. Es entschlüsselt als nächstes den ESK, um den Sitzungsschlüssel SK zu erhalten.

Während der Gültigkeitsdauer im EKT kann der Service-Host den ausgehandelten Sitzungsschlüssel SK verwenden, um mit einen Envelope-verschlüsselten Befehl an das HSM zu senden. Jeder Befehl, der über diese authentifizierte Sitzung ausgeführt wird, beinhaltet das EKT. service-host-initiated Der HSM antwortet mit demselben ausgehandelten Sitzungsschlüssel SK.