SPDM- Zertifikate müssen X.509 Version 3 entsprechen und in ASN.1 DER kodiert sein . PEM wird nicht in SPDM-Nachrichten übertragen. Die Validierung des Zertifikatspfads erfolgt vollständig gemäß RFC 5280 .

Die Zertifikatskette verläuft von der Wurzel zum Blatt, d. h. jede Stammzertifizierungsstelle (Root CA) stellt das Zertifikat der untergeordneten Zertifizierungsstelle (Sub CA) aus, und die Sub CA stellt das Blatt aus, welches den für die SPDM-Authentifizierung verwendeten öffentlichen Schlüssel enthält. Ein Gerät kann bis zu acht Zertifikatskettenplätze (0 bis 7) verwalten. Platz 0 ist der primäre Identitätsplatz und muss stets eine gültige DeviceCert- oder AliasCert-Kette enthalten. Die Plätze 1 bis 7 können GenericCert-Einträge für zusätzliche Zwecke enthalten.

Eine Besonderheit von SPDM ist, dass die Zertifikatskette mit dem Hash des Stammzertifikats als Präfix an die DER-kodierte Zertifikatskette übermittelt wird. Der Anforderer verwendet diesen Hash, um das Stammzertifikat unabhängig anhand seines Vertrauensspeichers zu verifizieren, bevor er die restliche Kette validiert.

Pflichtfelder X.509

Für DeviceCert- und AliasCert- Zertifikate identifiziert SPDM die folgenden Zertifikatsfelder als Pflichtfelder.

Grundlegende Einschränkungen – CA-Zertifikate müssen auf jeder Ebene der Kette korrekt von Endbenutzer-Endgerätezertifikaten unterschieden werden.
X.509-Version – muss Version 3 sein
Seriennummer – muss vorhanden und innerhalb jeder CA eindeutig sein.
Signaturalgorithmus – identifiziert den Algorithmus, der zum Signieren des Zertifikats verwendet wurde
Aussteller – identifiziert die Zertifizierungsstelle, die es unterzeichnet hat
Subjekt – bezeichnet den Zertifikatsinhaber
Gültigkeit – nicht vorher und nicht nachher; siehe den Abschnitt „Gültigkeit“ weiter unten.
Subjektbezogene Informationen zum öffentlichen Schlüssel – der öffentliche Schlüssel und sein Algorithmus
Wichtiger Hinweis – muss eine digitale Signatur zur Authentifizierung von Endbenutzerzertifikaten enthalten.

Für GenericCert-Einträge in den Slots 1 bis 7 gelten gemäß SPDM weniger Anforderungen. Grundlegende Einschränkungen, Version, Seriennummer und Informationen zum öffentlichen Subjektschlüssel bleiben obligatorisch, während andere Felder aus SPDM-Sicht optional sind. RFC 5280 und Ihre eigenen Organisationsrichtlinien können jedoch weiterhin strengere Anforderungen an GenericCert stellen.

Grundlegende Einschränkungen

Die grundlegenden Einschränkungen müssen jedes Zertifikat in der Kette korrekt kennzeichnen. Ein Fehler hierbei ist eine der häufigsten Ursachen für das Fehlschlagen der SPDM-Kettenvalidierung.

Normales SPDM-Blattzertifikat: CA = FALSEDies ist das Endbenutzerzertifikat, das direkt zur Authentifizierung verwendet wird.
Stammzertifizierungsstelle: CA = WAHR.
Zwischen-CA: CA = WAHR.
Gerätezertifikat-CA im AliasCert-Modell: CA = TRUE. Dies ist die geräteinterne CA. Sie muss außerdem eine geeignete Pfadlängenbeschränkung enthalten, um die Anzahl zusätzlicher Pfadlängenbeschränkung zu begrenzen. CA Darunter können weitere Zertifikate verkettet werden.

Schlüsselverwendung

Für ein SPDM-Authentifizierungszertifikat muss die Schlüsselverwendung auf „digitale Signatur“ eingestellt sein . Das Gerät signiert die SPDM-Challenge und das Sitzungsprotokoll mit seinem privaten Schlüssel; die digitale Signatur autorisiert diesen Vorgang.

Die CA-Zertifikate in der Kette müssen gemäß ihrer Rolle nach RFC 5280 keyCertSign und gegebenenfalls cRLSign enthalten . Fehlt keyCertSign bei einer Zwischenzertifizierungsstelle, schlägt die Pfadvalidierung fehl.

Identität des Trägergeräts im alternativen Subjektnamen

SPDM empfiehlt die Verwendung des Felds „otherName“ in der Erweiterung „Subject Alternative Name“ zur Übermittlung strukturierter Geräteinformationen. Das von der DMTF definierte Format stellt das Gerät wie folgt dar:

OID: 1.3.6.1.4.1.412.274.1 (DMTF-Geräteinformationen)
Wert: Hersteller: Produkt: Seriennummer
Beispiel: ACME Corp : GPU-X100 : SN123456789

Diese Verknüpfung ist sinnvoll, da sie den kryptografischen Schlüssel nicht nur an einen generischen Subjektnamen, sondern an einen spezifischen Hardwarehersteller, eine Produktlinie und eine Seriennummer bindet . Wenn ein KI-Orchestrator oder ein BMC die Zertifikatskette abruft , kann er überprüfen, ob es sich bei dem Gerät, mit dem er kommuniziert, tatsächlich um das spezifische physische Gerät handelt, das er registriert hat, und nicht nur um ein beliebiges Gerät desselben Herstellers.

Gültigkeit des Zertifikats

Slot 0 ist der primäre Geräteidentitäts-Slot und seine Gültigkeitsrichtlinie unterscheidet sich von den anderen Slots.

Für eine langlebige, unveränderliche Slot-0-Identität – ein werkseitig installiertes Zertifikat, das während der gesamten Betriebsdauer des Geräts gültig sein soll – sieht die Spezifikation die Verwendung von 99991231235959Z als Wert für „notAfter“ vor. Dies bedeutet, dass kein Ablaufdatum definiert ist . Da die meisten Hardwaregeräte keine zuverlässige Echtzeituhr besitzen, muss die Identität möglicherweise 10, 15 oder 20 Jahre überdauern. „notBefore“ wird üblicherweise auf das Erstellungs- oder Herstellungsdatum des Zertifikats gesetzt.

Die Steckplätze 1 bis 7 können Zertifikate mit herkömmlichen Ablaufdaten aufnehmen. Dies ermöglicht PKI- Teams einen überschaubaren Betriebslebenszyklus für veränderliche und operative Anmeldeinformationen: Die permanente Hardware-Identität in Steckplatz 0 bleibt stabil, während kurzlebigere Zertifikate in anderen Steckplätzen mit Standardwerkzeugen und innerhalb der vorgegebenen Fristen erneuert, ersetzt und widerrufen werden können.

SPDM DMTF OIDs

SPDM definiert sechs OIDs im DMTF-Namensraum. Ihre Zertifizierungsstelle muss so konfiguriert sein, dass sie gegebenenfalls Zertifikate mit diesen OIDs ausstellt. Keine dieser OIDs ist in den Standard-OID-Sätzen der meisten kommerziellen Zertifizierungsstellenplattformen enthalten; sie alle erfordern eine explizite Konfiguration.

Erweiterte Schlüsselverwendungs-OIDs

SPDM definiert zwei EKU-OIDs zur Authentifizierung. Diese sind im Basis-SPDM-Profil optional, werden aber dringend empfohlen für jede Bereitstellung, bei der die explizite Autorisierung von Zertifikaten für die SPDM-Nutzung erzwungen werden soll.

Antwortauthentifizierung: 1.3.6.1.4.1.412.274.3, im Endbenutzerzertifikat eines Hardwaregeräts, das als SPDM-Responder fungiert. Eine GPU, NPU, DPU oder NIC, die diese EKU präsentiert, erklärt damit, dass ihr Zertifikat speziell für die SPDM-Responder-Authentifizierung autorisiert ist.
Authentifizierung des Anforderers: 1.3.6.1.4.1.412.274.4, die im Zertifikat eines SPDM-Anforderers während der gegenseitigen Authentifizierung enthalten ist. Ein Gerät, das an der gegenseitigen Authentifizierung teilnimmt, benötigt möglicherweise beide EKUs. Ein Gerät, das ausschließlich als Responder fungiert, benötigt nur die Responder-EKU.

Hardwareidentität und veränderliche Zertifikats-OIDs

Diese beiden OIDs kodieren eine sicherheitsrelevante Unterscheidung, auf die SPDM-Anforderer und Vertrauensverwaltungssysteme programmatisch reagieren können.

Hardware-Identität: Die OID 1.3.6.1.4.1.412.274.2 kennzeichnet das Zertifikat, das die permanente Geräteidentität repräsentiert. Im AliasCert-Modell gehört diese OID zur Gerätezertifizierungsstelle (CA) und nicht zu den darunterliegenden, veränderlichen Aliaszertifikaten. Ein Anforderer, der eine hardwaregebundene Richtlinie durchsetzt, kann anhand dieser OID überprüfen, ob er mit einer werkseitig installierten, permanenten Identität kommuniziert.
Veränderliches Zertifikat: 1.3.6.1.4.1.412.274.5 kennzeichnet Zertifikate, die einen veränderlichen Zustand repräsentieren: Firmware-Version, Konfiguration oder einen nach der Herstellung generierten Betriebsschlüssel. Alias-Zertifikate tragen diese OID. Die Gerätezertifizierungsstelle und permanente Zertifikate im IDevID-Stil sollten dies nicht tun.
SPDM-Erweiterungscontainer: 1.3.6.1.4.1.412.274.6, eine Containererweiterung für zusätzliche strukturierte SPDM-spezifische Daten, wenn das Zertifikat Inhalte enthalten muss, die über das hinausgehen, was die anderen OIDs darstellen.

Die drei Zertifikatsmodelle

Folgende drei Zertifikatsmodelle stehen zur Verfügung:

DeviceCert-Modell

Das DeviceCert-Modell ist die einfachste Option. Das Gerätezertifikat bildet das Endgerät. Der zugehörige private Schlüssel befindet sich im Gerät und wird direkt für die SPDM-Authentifizierung verwendet. Die Zertifikatskette verläuft von der Stammzertifizierungsstelle über alle Zwischenzertifizierungsstellen bis zum Endgerät mit CA=FALSE.

Verwenden Sie DeviceCert, wenn das Gerät über einen permanenten Schlüssel verfügt, der die Authentifizierung direkt durchführt, und Sie die Hardwareidentität nicht vom Betriebszustand trennen müssen. Es ist einfacher zu implementieren und zu verwalten.

AliasCert-Modell und die Gerätezertifizierungsstelle

Das AliasCert-Modell führt eine geräteinterne Zertifizierungsstelle (CA) ein. Die Unternehmens-PKI stellt dem Gerät ein Gerätezertifikat aus, das CA=TRUE, die Hardware-Identitäts-OID (1.3.6.1.4.1.412.274.2) und eine entsprechende Pfadlängenbeschränkung enthält. Dieses Gerätezertifikat repräsentiert die permanente Hardware-Identität, die bei der Herstellung installiert wurde.

Das Gerät verwendet anschließend den CA-Schlüssel des Gerätezertifikats, um Alias-Zertifikate lokal zu signieren. Alias-Zertifikate repräsentieren einen veränderlichen Zustand: die aktuelle Firmware-Version, die Boot-Konfiguration des Geräts oder einen neu generierten Betriebsschlüssel. Sie tragen die OID des veränderlichen Zertifikats (1.3.6.1.4.1.412.274.5) und haben kürzere Gültigkeitsdauern. Die eigentliche SPDM-Authentifizierung verwendet das Alias-Zertifikat, nicht direkt die Gerätezertifikats-CA.

Die Vertrauenskette führt weiterhin zurück zur Stammzertifizierungsstelle: Die Stammzertifizierungsstelle vertraut der Gerätezertifizierungsstelle, welche das Aliaszertifikat signiert; daher ist der Alias mit der vertrauenswürdigen Hardwareidentität verknüpft. Die Unternehmens-PKI verwaltet alles oberhalb der Gerätezertifizierungsstelle. Das Gerät verwaltet die darunterliegende Aliasschicht.

Warum das AliasCert-Modell wichtig ist: Es trennt zwei Identitäten mit sehr unterschiedlichen Lebenszyklen. Die permanente Hardware-Identität muss extrem stabil sein; sie repräsentiert das physische Gerät und sollte sich nur ändern, wenn sich die Hardware ändert. Die operative Identität muss flexibel sein; sie sollte den aktuellen Firmware-Status widerspiegeln und sich bei Firmware-Updates oder Änderungen des Sicherheitsstatus anpassen können. DeviceCert vermischt diese beiden Identitäten zu einer einzigen. AliasCert trennt sie klar.

Hinweis: Die Gerätezertifizierungsstelle darf nicht als allgemeine Unternehmenszertifizierungsstelle behandelt werden. Sie ist auf dieses spezifische Gerät beschränkt. Verwenden Sie Pfadlängenbeschränkungen und gegebenenfalls Namensbeschränkungen, um ihre Berechtigung auf Schlüssel auf diesem Gerät zu beschränken.

GenericCert-Modell

GenericCert ist für die Steckplätze 1 bis 7 vorgesehen, wenn das Gerät mehrere asymmetrische Schlüsselpaare unterstützt und Zertifikate für unterschiedliche Zwecke benötigt. Steckplatz 0 muss immer DeviceCert oder AliasCert verwenden. GenericCert unterliegt weniger identitätsspezifischen Anforderungen als SPDM, muss aber dennoch RFC 5280 und Ihre Unternehmensrichtlinien erfüllen.

Ausrichtung Ihrer unternehmensweiten PKI an SPDM

SPDM stellt den Laufzeitmechanismus bereit, um zu beweisen: „Dieses Gerät besitzt den privaten Schlüssel, der zu einem von meiner Plattform als vertrauenswürdig eingestuften Zertifikat gehört .“ PKI bildet die Grundlage für die Entscheidung von Faktoren wie dem Aussteller der Identität, der zugehörigen Hardware, den Berechtigungen, der Dauer des Vertrauens und der Art und Weise, wie dieses Vertrauen aufgehoben wird.

Erstellen Sie eine dedizierte SPDM-CA-Hierarchie

Die Ausstellung von SPDM-Gerätezertifikaten sollte von Ihrer allgemeinen TLS- und Benutzer-CA-Hierarchie getrennt sein. Eine dedizierte SPDM-Geräteausstellungs-CA unter einer Offline-SPDM-Root-CA ermöglicht eine präzisere Kontrolle über Geräteprofile, die Registrierung von Herstellern und die Verteilung von Vertrauensankern. In Lieferkettenumgebungen können separate Ausstellungsebenen oder separate Zertifikatsslots Herstellern, Plattformintegratoren und Unternehmenskunden individuell zugeordnet werden.

Definieren Sie Zertifikatsprofile für jeden SPDM-Zertifikatstyp

Ein einzelnes Profil genügt nicht. Definieren Sie für jeden Zertifikatstyp, der in einer SPDM-Kette erscheinen soll, ein separates Profil:

SPDM-Geräteauthentifizierungsblatt: CA=FALSE, digitale Signatur, Responder EKU (1.3.6.1.4.1.412.274.3), Gültigkeit 99991231235959Z für Slot 0
SPDM-Gerätezertifikats-CA: CA=TRUE, keyCertSign, Hardware Identity OID (1.3.6.1.4.1.412.274.2), pathLengthConstraint zur Begrenzung der Aliaskettentiefe
SPDM-Alias Blatt: CA=FALSE, digitale Signatur, Responder EKU, Mutable Certificate OID (1.3.6.1.4.1.412.274.5), kürzere Gültigkeitsdauer
SPDM-Anfordererauthentifizierung: Requester EKU (1.3.6.1.4.1.412.274.4) für Szenarien mit gegenseitiger Authentifizierung

Schützen Sie die privaten Schlüssel des Geräts korrekt

Generieren Sie Geräteschlüssel innerhalb eines Hardware-Root of Trust, TPM, Secure Element oder geschützter Geräte-Firmware, wie z. B. eines Hardware-Sicherheitsmoduls (HSM) . Kennzeichnen Sie den privaten Schlüssel als nicht exportierbar. Stellen Sie für jedes physische Gerät ein eindeutiges Schlüsselpaar bereit; gemeinsam genutzte Schlüssel innerhalb einer Produktionscharge untergraben das Authentifizierungsmodell vollständig. Schützen Sie Root- und ausstellende CA-Schlüssel mit Enterprise-HSMs.

Integration der Zertifikatsausstellung in die Fertigung

Die Erstbereitstellung des Zertifikats erfolgt vor dem Start von SPDM und erfordert daher einen externen Registrierungsmechanismus: EST, SCEP, eine benutzerdefinierte REST-API oder eine Schnittstelle für die kontrollierte Serienfertigung. SPDM v1.3.0 ergänzt GET_CSR und SET_CERTIFICATE um die interne Bereitstellung nach der Bereitstellung. Das erste Zertifikat für Steckplatz 0 muss jedoch während der Fertigung vor dem Versand des Geräts bereitgestellt werden.

Ein typischer Herstellungsablauf: Das Gerät generiert sein Schlüsselpaar intern, das Herstellungssystem liest den öffentlichen Schlüssel und die Geräteidentifikatoren, ein CSR wird erstellt, die PKI validiert Hersteller und Seriennummer, ein Zertifikat wird ausgestellt, die Kette wird in den SPDM-Steckplatz geschrieben und das Gerät wird mit einer Live-SPDM-Challenge getestet, um zu bestätigen, dass der Steckplatz korrekt bereitgestellt wurde.

Verteilen Sie Vertrauensanker an die Anforderer

Der Anforderer benötigt das Root-CA-Zertifikat oder dessen Hashwert, bevor er einem Responder vertrauen kann. Die Richtlinie zur Vertrauensverteilung muss folgende Fragen beantworten: Welchen Hersteller-Root-CA-Zertifikaten wird in dieser Umgebung vertraut? Wie werden kompromittierte Hersteller-Root-CA-Zertifikate entfernt? Und wie wird das Vertrauen gehandhabt, wenn ein Gerät an eine andere Organisation übertragen wird? Ohne kontrolliertes Trust-Anker-Management kann ein technisch gültiges Zertifikat in der Umgebung, in der es vorgelegt wird, dennoch nicht autorisiert sein.

Lebenszyklus- und Widerrufsrichtlinie definieren

Für AliasCert-Implementierungen empfiehlt sich folgender praktischer Ansatz: Die Gerätezertifikats-CA sollte langlebig und gut geschützt sein, es sollten kurzlebigere Aliaszertifikate mit herkömmlichen Erneuerungszyklen ausgestellt werden, Aliaszertifikate sollten nach Firmware-Updates neu generiert werden, und es sollte ein klarer Prozess zur Ablehnung kompromittierter Hardware-Seriennummern durch außerbandige Truststore-Updates oder Sperrlisten vorhanden sein.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting unterstützt SPDM PKI als durchgängige PKI-Implementierung und PKIaaS-Dienst.

PKIaaS für SPDM . Das PKI-as-a-Service-Angebot von EC stellt die für SPDM-Konformität konfigurierte Hersteller-CA-Hierarchie bereit: alle DMTF-OIDs sind registriert und als Vorlagen definiert, es gibt dedizierte SPDM-Zertifikatprofile für DeviceCert- und AliasCert-Ketten, ein Design für Pfadlängen- und Namensbeschränkungen für die Gerätezertifikats-CA sowie die Verarbeitung des SPDM-Kettenformats für die GET_CERTIFICATE-Zustellung.

PKI-Design und -Implementierung : EC entwirft die dedizierte SPDM-CA-Hierarchie getrennt von Ihren allgemeinen TLS- und Benutzer-CAs, wählt das richtige Zertifikatsmodell für jeden Gerätetyp aus, erstellt alle Zertifikatvorlagen mit den korrekten Feldebenenanforderungen und dokumentiert die CP/CPS -Abschnitte, die die Geräteidentitätsvergabe abdecken.

EC entwirft die Integration zwischen Fertigungssystem, Gerätebereitstellungs-Gateway, PKIaaS-Zertifizierungsstelle und SPDM-Zertifikatssteckplatz. Die Erstbereitstellung erfolgt je nach Produktionsumgebung über EST, SCEP, REST-API oder eine Schnittstelle für die Serienfertigung. Unsere SPDM-Fallstudie eines Fortune-100-Unternehmens dient als Produktionsreferenz für diese Arbeit.

PKI-Bewertung : Wenn Sie bereits über eine Geräteidentitätsarchitektur verfügen, kann EC diese anhand der DSP0274 X.509-Anforderungen bewerten: korrekte Basic Constraints auf jeder Kettenebene, Vorhandensein der erforderlichen OIDs, SAN otherName-Struktur, Gültigkeitsrichtlinie, Schlüsselschutz und Trust-Anker-Verteilung – und die Lücken identifizieren, bevor sie zu Produktionsproblemen werden.

Fazit

Die von SPDM an Zertifikate gestellten X.509-Anforderungen sind spezifisch und ergänzen die Standard-PKI-Profile. Die DMTF-OIDs müssen in Ihrer Zertifizierungsstelle registriert und konfiguriert werden. Die Zertifikatsmodelle müssen sorgfältig ausgewählt werden. Die Gültigkeitsdauer muss die Lebensdauer des Geräts und nicht die Software-Erneuerungszyklen widerspiegeln. Die Verteilung der Vertrauensanker muss die gesamte Lieferkette vom Hersteller über den Integrator bis zum Endbetreiber abdecken.

SPDM-Anforderungen für das X.509-Zertifikat