DICE X.509-Zertifikatprofile für Hardware-Identität

DICE steht für Device Identifier Composition Engine . Es handelt sich um einen Hardware-Root of Trust (RoT) gemäß der Definition der Trusted Computing Group (TCG). Die Kernidee ist einfach, aber wirkungsvoll: Man nimmt ein Geheimnis, das bei der Herstellung physisch im Silizium eingebettet ist, kombiniert es mit einer Messung der auf diesem Silizium geladenen Firmware und leitet daraus einen kryptografischen Schlüssel ab. Dieser Schlüssel ist hardwaregebunden, im Gegensatz zu Software-Schlüsseln.

Spezifikation der TCG DICE-Zertifikatsprofile

Die Spezifikation der TCG DICE-Zertifikatprofile, Version 1.1 (veröffentlicht am 24. April 2025) , ist das normative Dokument, das definiert, wie von DICE abgeleitete Schlüssel als X.509-Zertifikate dargestellt werden . Sie definiert vier Zertifikatprofile und die zugehörigen Policy-OIDs. Alle Inhalte dieses Abschnitts stammen direkt aus der veröffentlichten Spezifikation.

Was die Spezifikation definiert

Die Spezifikation setzt voraus, dass der Leser mit den TCG-Hardwareanforderungen für DICE und der DICE-Schichtarchitekturspezifikation vertraut ist. Darauf aufbauend definiert sie Folgendes:

• X.509-Zertifikat Konventionen für von DICE abgeleitete Schlüsselpaare (Seriennummer, Gültigkeit, Benennung)
• Richtlinien-OIDs aus dem tcg-dice-kp-Namensraum, die den Zweck und die Bindung jedes Schlüssels identifizieren
• Vier Zertifikatsprofile: IDevID, LDevID, ECA und Attestierung
• Anforderungen auf Feldebene für jedes Profil (Aussteller, Subjekt, Schlüsselverwendung, Erweiterte Schlüsselverwendung, Grundlegende Einschränkungen, CRL-Verteilungspunkte)

Zertifikatskonventionen

• Ordnungsnummer: Zertifikatseriennummern MÜSSEN pro Zertifizierungsstelle und Alias-Schlüsselzertifikat eindeutig sein. Verschiedene eingebettete Zertifizierungsstellen können Zertifikate mit denselben Seriennummernfeldern ausstellen.
• Gültigkeitsdauer des Zertifikats: Geräte mit einer sicheren Uhr legen Gültigkeitszeiträume konventionell fest. Geräte ohne sichere Uhr, was auf die meisten KI-Beschleuniger und eingebettete Hardware zutrifft, setzen notAfter auf den X.509-Wert GeneralizedTime. 99991231235959Z or unbefristete GültigkeitDer Wert für „notBefore“ ist auf ein bekanntes Datum in der jüngeren Vergangenheit festgelegt, beispielsweise den Zeitpunkt der TCB-Erstellung. Dieser Wert bedeutet, dass kein Ablaufdatum definiert ist.
• Betreffbenennung: Betreffnamen SOLLTE identifizieren Sie die Komponentenumgebung, in der die privater Schlüssel Enthält möglicherweise die Seriennummer des Geräts, Firmware-Kennungen oder DICE-Layering-Koordinaten. Subjektnamen MÜSSEN für Byte-Array-Vergleiche formatiert sein. Es wird empfohlen, Attestierungsnachweise nicht aus den Feldern „Subject“ oder „SubjectAltName“ abzurufen.
• Namensgebung des Emittenten: Der Name des Emittenten auf Ebene n+1 MUSS übereinstimmen Subjekt Name Ausstellungsbescheinigung auf Ebene n. Dies ist die Verkettungsregel, die es ermöglicht, die DICE-Identität vom Silizium bis hin zu jeder Firmware-Ebene zurückzuverfolgen.

Richtlinien-OIDs: der tcg-dice-kp-Namensraum

Die Spezifikation definiert sieben Policy-OIDs im Namespace tcg-dice-kp. Diese werden in der Erweiterung „Extended Key Usage“ von DICE -Zertifikaten platziert , um zu kennzeichnen, wofür der Schlüssel autorisiert ist und wie er gebunden wurde. Der OID-Arc aus der Spezifikation (Anhang A):

tcg OBJECT IDENTIFIER ::= { 2 23 133 }
tcg-dice OBJECT IDENTIFIER ::= { tcg platformClass(5) dice(4) }
tcg-dice-kp OBJECT IDENTIFIER ::= { tcg-dice kp(100) }

OID-Name	OID-Wert	Zweck und verbindliche Regel
tcg-dice-kp-identityInit	identity-init(6)	IDevID. Initiale Geräteidentität. Der Schlüssel muss bei der Herstellung gebunden werden. Der Schlüssel muss vom Hersteller zertifiziert werden.
tcg-dice-kp-identityLoc	Identitätslokal(7)	LDevID. Lokale Geräteidentität. Der Schlüssel SOLLTE nach der Herstellung gebunden werden. Der Schlüssel MUSS von einem lokalen Aussteller zertifiziert werden.
tcg-dice-kp-attestInit	attest-init(8)	Erstbestätigung. Bestätigungsschlüssel für die Unterzeichnung des Gerätenachweises. Der Schlüssel muss bei der Herstellung gebunden und vom Hersteller zertifiziert werden.
tcg-dice-kp-attestLoc	attest-loc(9)	Lokale Beglaubigung. Beglaubigungsschlüssel, Bindung nach der Herstellung. Muss vom lokalen Aussteller zertifiziert werden.
tcg-dice-kp-assertInit	assert-init(10)	Erste Bestätigung. Schlüssel zur Signierung von Referenzmessungen am Gerät. Fertigungsgebunden.
tcg-dice-kp-assertLoc	assert-loc(11)	Lokale Bestätigung. Schlüssel zur Signierung von Referenzmessungen. Nach der Fertigung. Muss vom lokalen Aussteller zertifiziert werden.
tcg-dice-kp-eca	eca(12)	Eingebettete Zertifizierungsstelle. Autorisiert die Zertifikatsausstellung für Schlüssel auf dem aktuellen Gerät. Der signierte Schlüssel des Ausstellers MUSS vom Hersteller oder einer lokalen Zertifizierungsstelle zertifiziert sein.

Die vier Zertifikatsprofile

Die Spezifikation definiert vier Zertifikatsprofile . Jedes Profil verfügt über eine Tabelle mit Feldanforderungen (Tabelle 14 in der Spezifikation). Nachfolgend finden Sie eine kurze Zusammenfassung der erforderlichen X.509-Zertifikatmetadaten für jedes Zertifikatsprofil.

IDevID: Initial Device Identifier

Quelle: TCG DICE Zertifikatsprofile v1.1, Tabelle 1

Die IDevID ist die Geburtsurkunde oder das Zertifikat des Geräts. Sie wird bei der Herstellung ausgestellt und kann nicht neu ausgestellt werden, da der Schlüssel an die Hardware gebunden ist.

Feld	Anforderung
Aussteller	MUST macht Identifizieren oder verknüpfen Sie die Zertifizierungsstelle mit dem Gerätehersteller oder dem Unternehmen der Lieferkette. Wenn es sich bei dem Aussteller um eine eingebettete Zertifizierungsstelle handelt, ist der ECA-Aussteller zuständig. MUST macht Die Zertifizierungskette muss bis zur Herstellerzertifizierungsstelle zurückreichen. Daher muss die Zertifizierungskette validiert werden.
Betreff	Typischerweise werden relative Distinguished Names (RDNs) wie Common Name (CN), Organization (O) oder Organizational Unit (OU) verwendet, um die TCB-Klasse oder -Instanz zu bezeichnen. Häufig werden eindeutige Hardware-Kennungen (wie eine Unique Device ID oder UEID) als Erweiterungen oder innerhalb des SAN eingebettet, um die Geräteinstanz eindeutig zu identifizieren. Hinweis: Die TCB muss unbedingt identifiziert werden. (Vertrauenswürdige Rechenbasis) Besitzt den privaten Schlüssel der IDevID. Kann eine Klassenkennung sein (mehrere Geräteinstanzen teilen sich denselben Namen).
Betreff Öffentlicher Schlüssel	Enthält den öffentlichen Schlüssel und die Algorithmenkennung. Der Schlüssel MUSS durch eine unveränderliche TCB-Schicht oder eine nur vom Aussteller änderbare TCB-Schicht geschützt sein. Der private Schlüssel MUSS in einem hardwarebasierten Modul, wie z. B. einem Hardware-Sicherheitsmodul (HSM), gesichert sein.
Schlüsselverwendung	Wenn es sich beim Subjekt um eine ECA handelt: Muss keyCertSign enthalten, darf aber nicht cRLSign enthalten. Andernfalls: Darf nicht keyCertSign enthalten.
Erweiterte Schlüsselverwendung	Muss tcg-dice-kp-identityInit enthalten. Kann id-kp-clientAuth, tcg-dice-kp-eca oder tcg-dice-kp-attestInit enthalten.
Grundlegende Einschränkungen	Wenn Subject ein ECA ist: MUSS cA:TRUE und pathLengthConstraint enthalten. Andernfalls: SOLLTE keine BasicConstraints enthalten.

LDevID: Lokale Geräte-ID

Quelle: TCG DICE Zertifikatsprofile v1.1, Tabelle 2

Die LDevID wird nach der Herstellung vom Gerätebesitzer vergeben. Sie legt die Betriebsidentität des Geräts in der Umgebung des Besitzers fest. Der strukturelle Unterschied zur IDevID besteht im Aussteller (Zertifizierungsstelle des Besitzers, nicht des Herstellers) und der Richtlinien-OID (identityLoc, nicht identityInit).

Feld	Anforderung
Aussteller	Die Inhaber-CA muss identifiziert oder mit ihr verknüpft werden. Wenn es sich bei dem Emittenten um eine eingebettete CA handelt, muss der ECA-Emittent mit der Inhaber-CA verknüpft werden.
Betreff	Die TCB, der der private Schlüssel der LDevID gehört, muss identifiziert werden. Es kann sich um eine Klassenkennung handeln.
Betreff Öffentlicher Schlüssel	Enthält den öffentlichen Schlüssel und die Algorithmenkennung. Der Schlüssel ist durch eine unveränderliche TCB-Schicht geschützt, oder die TCB kann nur vom Aussteller geändert werden.
Schlüsselverwendung	Wenn es sich beim Subjekt um eine ECA handelt: Muss keyCertSign enthalten, darf aber nicht cRLSign enthalten. Andernfalls: Darf nicht keyCertSign enthalten.
Erweiterte Schlüsselverwendung	MUSS tcg-dice-kp-identityLoc enthalten. KANN tcg-dice-kp-eca, tcg-dice-kp-attestLoc und/oder id-kp-clientAuth enthalten.
Grundlegende Einschränkungen	Wenn Subject ein ECA ist: MUSS cA:TRUE und pathLengthConstraint enthalten. Andernfalls: SOLLTE keine BasicConstraints enthalten.

ECA: Eingebettete Zertifizierungsstelle

Quelle: TCG DICE Zertifikatsprofile v1.1, Tabelle 3 (§5.1.6.3)

Die ECA ( Endbenutzer-Zertifizierungsstelle) ist in die Geräte-Firmware integriert. Sie stellt Zertifikate für darüberliegende Firmware-Schichten aus. Die ECA selbst muss während der Herstellung von der Hersteller-CA (bzw. dem lokalen Aussteller bei LDevID-Kontexten) zertifiziert werden.

Feld	Anforderung
Aussteller	Die ausstellende Zertifizierungsstelle (CA) oder eingebettete CA muss angegeben werden. Der Aussteller muss sicherstellen, dass der private Teil des öffentlichen Schlüssels des Subjekts durch einen TCB geschützt ist. Handelt es sich beim Aussteller um eine ECA, muss die TCB-Instanz angegeben werden.
Betreff	Der Betreffname kann ein KlassenbezeichnerDies deutet darauf hin, dass mehrere Geräteinstanzen denselben Namen haben könnten. Es muss die TCB identifiziert werden, die die ECA-Funktionalität enthält.
Betreff Öffentlicher Schlüssel	MUSS den aktuellen öffentlichen TCB Layer ECA-Schlüssel und die Algorithmenkennung enthalten.
Schlüsselverwendung	Muss keyCertSign enthalten. Darf nicht cRLSign enthalten. Kann weitere Schlüsselverwendungsattribute enthalten.
Erweiterte Schlüsselverwendung	Muss tcg-dice-kp-eca enthalten. Kann tcg-dice-kp-attestInit, tcg-dice-kp-attestLoc, tcg-dice-kp-identityInit oder tcg-dice-kp-identityLoc enthalten.
Grundlegende Einschränkungen	MUSS gegebenenfalls cA:TRUE und pathLengthConstraint enthalten.
CRLDistributionPoints	Eine Erweiterung muss vorhanden sein.

Bescheinigung

Quelle: TCG DICE Zertifikatsprofile v1.1, Tabelle 4

Attestierungszertifikate autorisieren einen Schlüssel zur Signierung von Nachweisen über ein Gerät, einen Firmware-Hash, eine Hardwarekonfiguration, einen Produktnamen oder einen Messstatus. Sie werden entweder von einer ECA oder einer externen CA ausgestellt.

Feld	Anforderung
Aussteller	Muss den Namen der eingebetteten oder externen Zertifizierungsstelle enthalten, die das Zertifikat ausstellt. Wenn der Aussteller eine externe Zertifizierungsstelle ist, muss die TCB-Instanz angegeben werden.
Betreff	Es muss eine TCB-Klasse oder -Instanz identifiziert werden.
Betreff Öffentlicher Schlüssel	MUSS einen aktuellen TCB-Attestierungsschlüssel und eine Algorithmuskennung enthalten.
Schlüsselverwendung	Wenn es sich beim Subjekt um eine ECA handelt: Muss keyCertSign enthalten, darf aber nicht cRLSign enthalten. Andernfalls: Darf nicht keyCertSign enthalten.
Erweiterte Schlüsselverwendung	Muss entweder tcg-dice-kp-attestInit oder tcg-dice-kp-attestLoc enthalten. Kann id-kp-clientAuth und andere geeignete Werte enthalten.
Grundlegende Einschränkungen	Wenn Subject ein ECA ist: MUSS cA:TRUE und pathLengthConstraint enthalten. Andernfalls: SOLLTE keine BasicConstraints enthalten.

Rolle von DICE bei der Hardware-Identität

Nachdem die Spezifikation verstanden wurde, stellt sich die wichtigere Frage, warum DICE für den Anwendungsfall der Hardwareidentität relevant ist und welche Rolle es im mehrschichtigen Sicherheitsaufbau für moderne KI-Hardware spielt.

DICE als Hardware-Vertrauensbasis

Jedes Sicherheitssystem benötigt einen Ausgangspunkt, dem grundsätzlich vertraut wird. Bei Softwaresystemen ist dies typischerweise ein HSM , ein TPM oder eine sichere Enklave. Bei Hardware-Identitätssystemen ist DICE dieser Ausgangspunkt. Der UDS bildet die Grundlage für die Annahme, dass er der einzige vertrauenswürdige Wert ist, da er vom Hersteller in einem kontrollierten Prozess eingebettet wurde und von Software weder gelesen noch kopiert werden kann.

Jeder von DICE abgeleitete Identitätsanspruch ist nur so stark wie das UDS. Ist das UDS angemessen geschützt, ist die gesamte darüber liegende DICE-Kette vertrauenswürdig. Genau das macht DICE zu einer echten Hardware-Vertrauensgrundlage: Es verankert Identität in physikalischen Prinzipien, nicht in Richtlinien.

DICE erzeugt firmwarebasierte Identität

Standardmäßige X.509 -Zertifikate binden einen Schlüssel an einen Namen. DICE-Zertifikate binden einen Schlüssel an ein bestimmtes Hardwaregerät, auf dem ein bestimmter Firmware-Stack ausgeführt wird. Die CDI-Ableitung stellt sicher, dass:

• Zwei Geräte mit unterschiedlicher Hardware (unterschiedlichen UDS-Werten) erzeugen unterschiedliche Schlüssel, selbst bei identischer Firmware.
• Dasselbe Gerät mit modifizierter Firmware erzeugt einen anderen Schlüssel.
• Ein gegen CDI_n ausgestelltes Zertifikat kann nachweislich sowohl die Hardware als auch den exakten TCB repräsentieren, der zum Zeitpunkt der Ausstellung verwendet wurde.

Für KI-Hardware wie GPUs, NPUs, DPUs und Inferenzbeschleuniger ist diese Firmware-Kenntnis von entscheidender Bedeutung. Lieferkettenangriffe , die die Firmware von Beschleunigern vor der Auslieferung verändern, stellen eine reale Bedrohung dar. DICE macht solche Modifikationen erkennbar: Das Gerät generiert nach der Modifikation eine andere DICE-Identität, und dieser Unterschied ist kryptografisch nachweisbar.

DICE im IEEE 802.1AR-Framework

Die Anmeldeinformationstypen IDevID und LDevID sind in IEEE 802.1AR-2018 (Secure Device Identity) definiert. DICE stellt den Schlüsselableitungsmechanismus bereit, der diese Anmeldeinformationen mit hardwarebasierter Sicherheit erzeugt. Wenn ein DICE-fähiges Gerät seine IDevID an eine 802.1AR-fähige Netzwerkinfrastruktur (z. B. Unternehmens-Switches, Zugriffskontrollsysteme, Zero-Trust-Plattformen) übermittelt, erhält die Infrastruktur eine Anmeldeinformation, die nachweislich mit der PKI des Herstellers und der ausgelieferten Hardware verknüpft ist.

Ohne DICE ist eine IDevID ein Softwareschlüssel in einem Zertifikat. Mit DICE ist sie ein hardwaregebundener Schlüssel in einem Zertifikat mit einer Ableitungskette, die bis zu einem auf Siliziumebene gespeicherten und bei der Herstellung zertifizierten Geheimnis zurückverfolgt werden kann. Das 802.1AR-Framework bleibt in beiden Fällen gleich; DICE verleiht dem Zertifikat seine hardwarebasierte Sicherheitsstufe.

DICE als PKI-Anker für agentenbasierte KI

Bei agentenbasierten KI-Implementierungen benötigt ein KI-Agent, der auf einem Hardwarebeschleuniger läuft, eine Identität, die Folgendes aufweist:

• Einzigartig für die spezifische Hardware, auf der es läuft
• Kann von einem Orchestrator verifiziert werden, bevor die Hardware mit einer Arbeitslast betraut wird.
• Rückverfolgbar bis zur Zusicherung des Herstellers, dass die Hardware echt ist
• Da es empfindlich auf Firmware-Modifikationen reagiert, führt manipulierte Hardware zu einer anderen Identität.

DICE stellt alle vier bereit. Das IDevID-Zertifikat, das auf der Hersteller-CA basiert, aus der CDI-Kette abgeleitet ist und die OID „tcg-dice-kp-identityInit“ trägt, ist die Berechtigung, die der KI-Orchestrator per SPDM-Attestierung überprüft, bevor er eine sensible Arbeitslast ausführt. Die DICE-Kette bildet die Grundlage; SPDM ist das Laufzeitprotokoll, das sie nutzt; das Betriebszertifikat des Agenten baut darauf auf.

Entfernt man DICE, bricht die Vertrauenskette der Hardware an der ersten Stelle. Das Agentenzertifikat ist dann ein Software-Zertifikat, kein Hardware-Zertifikat. Software-Zertifikate können gefälscht werden. Hardwarebasierte Zertifikate hingegen können, sofern sie korrekt implementiert sind, nicht gefälscht werden.

DICE und der Zertifikatslebenszyklus

Ein oft übersehener Aspekt der DICE-Identität: Der Zertifikatslebenszyklus ist an den Firmware-Lebenszyklus und nicht an den Kalender gekoppelt. In der Praxis werden Geräte, die DICE implementieren, ihre Schlüssel entweder bei jedem Neustart neu zertifizieren (da die Schlüsselpaare bei jedem Neustart neu generiert werden) oder die Schlüssel beibehalten, solange die Firmware unverändert bleibt.

Dies bedeutet, dass sich das CLM- Modell (Certificate Lifecycle Management) für DICE-Zertifikate vom Modell für TLS-Zertifikate unterscheidet:

• Ein Firmware-Update löst eine neue CDI-Ableitung, ein neues Schlüsselpaar und eine neue Zertifikatsanforderung aus.
• Ein Gerät, das mit unveränderter Firmware startet, kann dasselbe Zertifikat vorweisen, das ihm bei der Herstellung ausgestellt wurde.
• Für die Verwaltung der Aktualität der DICE-Anmeldeinformationen ist der Ablauf des Zertifikats weniger relevant als die Aktualisierungsfrequenz der Firmware.

Eine PKI-Infrastruktur, die DICE unterstützt, muss auf diese Eigenschaften ausgelegt sein. Statische, ablaufbasierte Lebenszyklusverwaltung, die für Server- und Benutzerzertifikate konzipiert wurde, lässt sich ohne Anpassung nicht auf DICE-Hardwarezertifikate übertragen.

Wie kann Encryption Consulting helfen?

Der Aufbau und Betrieb einer Hersteller-CA-Hierarchie, die DICE-Zertifikatsprofile korrekt unterstützt, ist für die meisten Hardwarehersteller keine Aufgabe, die sie intern bewältigen müssen. Die erforderliche CA-Infrastruktur – Offline-Root-CA, herstellerintegrierte ausstellende CA, CRL-Veröffentlichung, OCSP- Infrastruktur, HSM-Management und die Konfiguration all dessen für DICE-spezifische Profile – ist eine spezialisierte Aufgabe, die erhebliche Ressourcen in Anspruch nimmt, wenn sie von Grund auf neu entwickelt wird.

Genau für diesen Anwendungsfall wurde das PKIaaS-Angebot von Encryption Consulting entwickelt.

Was PKIaaS für Hardwareidentität bedeutet

PKI as a Service (PKIaaS) bedeutet, dass die Zertifizierungsstellenhierarchie von Encryption Consulting im Auftrag des Hardwareherstellers oder der implementierenden Organisation entworfen, bereitgestellt und betrieben wird. Der Hersteller muss weder HSMs beschaffen, noch die Zertifizierungsstellensoftware konfigurieren, Root-Key-Zeremonien verwalten oder die CRL-Infrastruktur betreiben. EC übernimmt all dies. Der Hersteller integriert sich über APIs und Management-Schnittstellen in ECs PKIaaS, um Gerätezertifikate auszustellen und zu verwalten.

Für DICE-basierte Hardwareidentität bietet PKIaaS Folgendes:

• DICE-konforme Hersteller-CA-Hierarchie: Eine für Hardware-Zertifikatprofile konfigurierte Root-CA- und Ausstellungs-CA-Hierarchie. Diese umfasst die 40- bis 50-jährige oder unbefristete Gültigkeit der Root-CA, die für die konsistente Ausstellung von IDevID-Zertifikaten mit dem Ablaufdatum 99991231235959Z erforderlich ist, die in der OID-Datenbank der CA registrierten TCG DICE-kp OIDs sowie Zertifikatvorlagen für jeden Profiltyp: IDevID, LDevID, ECA und Attestation.
• Integration des Fertigungsworkflows: Die ausstellende Zertifizierungsstelle (CA) ist in den Geräteherstellungsprozess integriert, sodass IDevID-Zertifikate während der Produktion bereitgestellt werden. Bei Geräten mit DICE-Layering-Architektur umfasst dies die ECA-Schlüsselzertifizierung, bei der die Hersteller-CA den öffentlichen ECA-Schlüssel vor Auslieferung des Geräts zertifiziert. EC entwirft und implementiert die API-Integration für die Fertigung.
• Hardwarespezifische Zertifikatsprofilkonfiguration: Standard-CA-Plattformen erfordern Konfigurationsarbeiten zur Ausstellung von DICE-konformen Zertifikaten. EC konfiguriert die CA für: die Gültigkeitsbehandlung von 99991231235959Z ohne Auslösung von Ablehnungen auf Plattformebene; die obligatorischen TCG-OIDs in der erweiterten Schlüsselverwendung; die korrekte Schlüsselverwendung für ECA- und Nicht-ECA-Zertifikate; das Fehlen von BasicConstraints auf Nicht-ECA-Endzertifikaten; und CRLDistributionPoints auf ECA-Zertifikaten gemäß Spezifikation.
• CRL- und OCSP-Infrastruktur: Die Hardware-CA-CRL-Infrastruktur ist auf eine geringe Widerrufshäufigkeit ausgelegt, muss aber hochverfügbar sein, da jede SPDM-Attestierung die Zertifikatskette validiert. EC betreibt die CRL- und OCSP-Infrastruktur mit der für Hardware-Bereitstellungen erforderlichen Verfügbarkeit.
• Owner-PKI-Brücke: Wenn die IDevID-PKI des Hardwareherstellers mit der LDevID- und Agenten-Betriebszertifikat-PKI der einsetzenden Organisation verbunden werden muss, entwirft und implementiert EC die Brücke: die Richtlinien- und technische Verbindung zwischen herstellerseitig und besitzerseitig ausgestellten Anmeldeinformationen in derselben DICE-Vertrauenskette.
• CertSecure Manager für Agent CLM: Sobald Geräte in den Einsatz gehen und die PKI des Eigentümers LDevID- und Agentenbetriebszertifikate ausstellt, CertSecure Manager Sie verwaltet den gesamten Zertifikatslebenszyklus: automatische Verlängerung über EST, Sperrverwaltung, Flottenerkennung und Audit-Trail. Dies ist die operative Ebene oberhalb der DICE-Hierarchie, die den PKI-Betrieb ohne manuelle Eingriffe sicherstellt.

Fazit 

DICE-Zertifikatsprofile wie IDevID, LDevID, ECA und Attestation sind keine abstrakten Spezifikationen. Sie bilden die technische Grundlage, die einen Hardwarebeschleuniger von einer anonymen Komponente in eine verifizierbare, herstellergebundene Identität verwandelt. Jede Feldanforderung in der TCG-DICE-Spezifikation hat ihren Sinn: Sie soll sicherstellen, dass ein SPDM-Attestationsprüfer bei der Validierung einer Gerätezertifikatskette mit Sicherheit feststellen kann, dass der Schlüssel hardwaregebunden war, die Firmware gemessen wurde und die Kette auf einen Vertrauensanker zurückgeführt werden kann, der nicht softwareseitig gefälscht werden kann.

Für KI-Infrastrukturen, bei denen Arbeitslasten auf Hardware ausgeführt werden, die vor dem Einsatz möglicherweise Dutzende von Lieferanten durchlaufen hat, ist diese Art der kryptografischen Absicherung nicht optional.

Der Aufbau und Betrieb einer DICE-konformen CA-Hierarchie ist eine anspruchsvolle und spezialisierte Aufgabe. Die Root-CA muss über eine unbegrenzte Gültigkeit verfügen. Zertifikatvorlagen müssen für Profile konfiguriert werden, für deren Ausstellung die meisten CA-Plattformen standardmäßig nicht ausgelegt sind. CRL- und OCSP-Infrastruktur muss bei jedem Attestierungsereignis verfügbar sein.

Mit wachsender Geräteflotte muss der Zertifikatslebenszyklus Firmware-Updates und nicht nur das Ablaufdatum berücksichtigen. Encryption Consultings PKIaaS nimmt Ihnen diese Last vollständig ab: Wir entwickeln und verwalten die Infrastruktur, Sie betreiben Ihre Hardware . Von der Offline-Root-CA und der herstellerseitigen ausstellenden CA bis hin zur PKI-Bridge des Eigentümers, OCSP-Respondern und dem CertSecure Manager für das CLM auf Flottenebene – der gesamte Stack wird von uns entworfen, bereitgestellt und betrieben. So kann sich Ihr Team auf die Hardware-Auslieferung konzentrieren, anstatt eine CA zu betreiben.