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.
Validieren Sie ein NitroTPM-Bescheinigungsdokument
Anmerkung
Dieses Thema richtet sich an Benutzer, die einen Schlüsselverwaltungsdienst eines Drittanbieters verwenden und ihre eigenen Mechanismen zur Überprüfung von Bescheinigungsdokumenten erstellen müssen.
Dieses Thema bietet einen detaillierten Überblick über den gesamten Ablauf der NitroTPM-Bescheinigungen. Es wird auch erörtert, was vom AWS Nitro-System generiert wird, wenn ein Bestätigungsdokument angefordert wird, und es wird erklärt, wie ein Schlüsselverwaltungsdienst ein Bescheinigungsdokument verarbeiten sollte.
Der Zweck einer Bescheinigung besteht darin, anhand des Codes und der Konfiguration, die sie ausführt, nachzuweisen, dass es sich bei einer Instanz um eine vertrauenswürdige Entität handelt. Die Vertrauensbasis für die Instanz liegt im AWS Nitro-System, das Bescheinigungsdokumente bereitstellt.
Bescheinigungsdokumente werden von der AWS Nitro Attestation Public Key Infrastructure (PKI) signiert, zu der auch eine veröffentlichte Zertifizierungsstelle gehört, die in jeden Dienst integriert werden kann.
Das Beglaubigungsdokument
Bescheinigungsdokumente werden in Concise Binary Object Representation (CBOR) codiert und mit CBOR Object Signing and Encryption (COSE) signiert.
Weitere Informationen zu CBOR finden Sie unter RFC 8949
Spezifikation des Beglaubigungsdokuments
Im Folgenden wird die Struktur eines Beglaubigungsdokuments dargestellt.
AttestationDocument = { module_id: text, ; issuing Nitro hypervisor module ID timestamp: uint .size 8, ; UTC time when document was created, in ; milliseconds since UNIX epoch digest: digest, ; the digest function used for calculating the ; register values nitrotpm_pcrs: { + index => pcr }, ; map of PCRs at the moment the Attestation Document was generated certificate: cert, ; the public key certificate for the public key ; that was used to sign the Attestation Document cabundle: [* cert], ; issuing CA bundle for infrastructure certificate ? public_key: user_data, ; an optional DER-encoded key the attestation ; consumer can use to encrypt data with ? user_data: user_data, ; additional signed user data, defined by protocol ? nonce: user_data, ; an optional cryptographic nonce provided by the ; attestation consumer as a proof of authenticity } cert = bytes .size (1..1024) ; DER encoded certificate user_data = bytes .size (0..1024) pcr = bytes .size (32/48/64) ; PCR content index = 0..31 digest = "SHA384"
Die optionalen Parameter im Bestätigungsdokument (public_key, undnonce) können verwendet werdenuser_data, um ein benutzerdefiniertes Validierungsprotokoll zwischen einer bestätigenden Instanz und dem externen Dienst einzurichten.
Validierung des Beglaubigungsdokuments
Wenn Sie ein Bestätigungsdokument vom Nitro Hypervisor anfordern, erhalten Sie einen binären Blob, der das signierte Bestätigungsdokument enthält. Das signierte Beglaubigungsdokument ist ein CBOR-kodiertes, COSE-signiertes Objekt (unter Verwendung der Cose_Sign1-Signaturstruktur). Der gesamte Validierungsprozess umfasst die folgenden Schritte:
-
Dekodieren Sie das CBOR-Objekt und ordnen Sie es einer Cose_Sign1-Struktur zu.
-
Extrahieren Sie das Bescheinigungsdokument aus der Cose_Sign1-Struktur.
-
Überprüfen Sie die Kette des Zertifikats.
-
Stellen Sie sicher, dass das Bescheinigungsdokument ordnungsgemäß signiert ist.
Die Bescheinigungsdokumente werden von der AWS Nitro Attestation PKI signiert, die ein Stammzertifikat für die kommerziellen Partitionen enthält. AWS Das Stammzertifikat kann von https://aws-nitro-enclaves.amazonaws.com//AWS_NitroEnclaves_Root-G1.zip heruntergeladen und mit dem folgenden
64:1A:03:21:A3:E2:44:EF:E4:56:46:31:95:D6:06:31:7E:D7:CD:CC:3C:17:56:E0:98:93:F3:C6:8F:79:BB:5B
Das Stammzertifikat basiert auf einem AWS Certificate Manager privaten Schlüssel der Private Certificate Authority (AWS Private CA) und hat eine Lebensdauer von 30 Jahren. Der Betreff der PCA hat das folgende Format.
CN=aws.nitro-enclaves, C=US, O=Amazon, OU=AWS
COSE und CBOR
Normalerweise wird die Cose_Sign1-Signaturstruktur verwendet, wenn nur eine Signatur auf einer Nachricht platziert werden soll. Die Parameter, die sich mit dem Inhalt und der Signatur befassen, werden im geschützten Header platziert, anstatt die Trennung von CoSe_Sign zu haben. Die Struktur kann entweder mit oder ohne Tags kodiert werden, je nachdem, in welchem Kontext sie verwendet wird. Eine mit Cose_Sign1 markierte Struktur wird durch das CBOR-Tag 18 identifiziert.
Das CBOR-Objekt, das den Hauptteil, die Signatur und die Informationen über den Hauptteil und die Signatur enthält, wird als Cose_Sign1-Struktur bezeichnet. Die Cose_Sign1-Struktur ist ein CBOR-Array. Das Array umfasst die folgenden Felder.
[ protected: Header, unprotected: Header, payload: This field contains the serialized content to be signed, signature: This field contains the computed signature value. ]
Im Kontext eines Beglaubigungsdokuments umfasst das Array Folgendes.
18(/* COSE_Sign1 CBOR tag is 18 */ {1: -35}, /* This is equivalent with {algorithm: ECDS 384} */ {}, /* We have nothing in unprotected */ $ATTESTATION_DOCUMENT_CONTENT /* Attestation Document */, signature /* This is the signature */ )
Weitere Informationen zu CBOR finden Sie unter RFC 8949: Concise Binary
Semantische Validität
Das CA-Bundle eines Attestierungsdokuments wird immer in der folgenden Reihenfolge aufgeführt.
[ ROOT_CERT - INTERM_1 - INTERM_2 .... - INTERM_N] 0 1 2 N - 1
Beachten Sie diese Reihenfolge, da für einige vorhandene Tools, wie z. B. für Java CertPath aus dem Java PKI API Programmer's Guide
Um die Zertifikate zu validieren, beginnen Sie mit dem CA-Bundle für das Attestation Document und generieren Sie die erforderliche Kette. Wo TARGET_CERT ist das Zertifikat im Attestation Document?
[TARGET_CERT, INTERM_N, ..... , INTERM_2, INTERM_1, ROOT_CERT]
Gültigkeit des Zertifikats
Für alle Zertifikate in der Kette müssen Sie sicherstellen, dass das aktuelle Datum innerhalb des im Zertifikat angegebenen Gültigkeitszeitraums liegt.
Gültigkeit der Zertifikatskette
Im Allgemeinen kann eine Kette von mehreren Zertifikaten erforderlich sein, die aus einem Zertifikat des Besitzers des öffentlichen Schlüssels besteht, das von einer Zertifizierungsstelle signiert wurde, und aus null oder mehr zusätzlichen Zertifikaten, die von einer anderen CAs signiert wurden CAs. Solche Ketten, die als Zertifizierungspfade bezeichnet werden, sind erforderlich, da ein Benutzer mit einem öffentlichen Schlüssel nur mit einer begrenzten Anzahl von gesicherten öffentlichen Schlüsseln der Zertifizierungsstelle initialisiert wird. Die Verfahren zur Validierung des Zertifizierungspfads für die Internet-PKI basieren auf dem in X.509 enthaltenen Algorithmus. Bei der Verarbeitung des Zertifizierungspfads wird die Verbindung zwischen dem eindeutigen Namen des Antragstellers, dem alternativen Namen des and/or Antragstellers und dem öffentlichen Schlüssel des Antragstellers überprüft. Die Bindung wird durch Einschränkungen eingeschränkt, die in den Zertifikaten angegeben sind, aus denen sich der Pfad zusammensetzt, und durch Eingaben, die von der vertrauenden Partei angegeben werden. Die grundlegenden Einschränkungen und Erweiterungen der Richtlinieneinschränkungen ermöglichen es der Verarbeitungslogik für den Zertifizierungspfad, den Entscheidungsprozess zu automatisieren.
Anmerkung
CRL muss bei der Validierung deaktiviert sein.
Bei Verwendung von Java erfolgt die Kettenvalidierung, ausgehend vom Stammpfad und der generierten Zertifikatskette, wie folgt.
validateCertsPath(certChain, rootCertficate) { /* The trust anchor is the root CA to trust */ trustAnchors.add(rootCertificate); /* We need PKIX parameters to specify the trust anchors * and disable the CRL validation */ validationParameters = new PKIXParameters(trustAnchors); certPathValidator = CertPathValidator.getInstance(PKIX); validationParameters.setRevocationEnabled(false); /* We are ensuring that certificates are chained correctly */ certPathValidator.validate(certPath, validationParameters); }
