DICE X.509-certifikatprofiler för hårdvaruidentitet

DICE står för Device Identifier Composition Engine . Det är en hårdvarubaserad Root of Trust (RoT) enligt definitionen av Trusted Computing Group (TCG). Kärnidén är enkel men kraftfull: ta en hemlighet som är fysiskt inbäddad i kiseln vid tillverkningen, kombinera den med en mätning av den firmware som laddas på den kiseln och härled en kryptografisk nyckel från resultatet. Den nyckeln är hårdvarubunden på ett sätt som programnycklar aldrig är.

Specifikationen för TCG DICE-certifikatprofiler

TCG DICE-certifikatprofilspecifikationen, version 1.1 (publicerad 24 april 2025) , är det normativa dokument som definierar hur DICE-härledda nycklar uttrycks som X.509-certifikat . Den definierar fyra certifikatprofiler och de policy-OID:er som medföljer dem. Allt i det här avsnittet är hämtat direkt från den publicerade specifikationen.

Vad specifikationen definierar

Specifikationen förutsätter att läsaren är bekant med TCG:s hårdvarukrav för DICE och DICE:s lagerarkitekturspecifikation. Byggande på dessa grunder definierar den:

• X.509 certifikat konventioner för DICE-härledda nyckelpar (serienummer, giltighet, namngivning)
• Policy-OID:er från namnrymden tcg-dice-kp som identifierar syftet och bindningen för varje nyckel
• Fyra certifikatprofiler: IDevID, LDevID, ECA och attestering
• Fältnivåkrav för varje profil (Utfärdare, Ämne, Nyckelanvändning, Utökad nyckelanvändning, Grundläggande begränsningar, CRLDistributionPoints)

Certifikatkonventioner

• Serienummer: Certifikatets serienummer MÅSTE vara unika per CA för varje Alias ​​Key-certifikat. Olika inbäddade CA:er kan utfärda certifikat med samma serienummerfält.
• Certifikatets livslängd: Enheter med en säker klocka ställer in giltighetsperioder på konventionellt sätt. Enheter utan en säker klocka, vilket täcker de flesta AI-acceleratorer och inbäddad hårdvara, ställer in notAfter till värdet X.509 GeneralizedTime. 99991231235959Z or giltighetstid som inte löper utnotBefore är satt till ett känt datum i den närmaste förflutna, till exempel TCB-byggtiden. Detta värde indikerar inget definierat utgångsdatum.
• Ämnesnamn: Ämnesnamn SKALL identifiera komponentmiljön där privat nyckel finns. Kan innehålla enhetens serienummer, firmware-identifierare eller DICE-lagerkoordinater. Ämnesnamn MÅSTE formateras för byte-matrisjämförelser. Attesteringsverifierare rekommenderas att inte hämta attesteringsanspråk från fälten Ämne eller SubjectAltName.
• Utgivarens namngivning: Utgivarens namn på lager n+1 MÅSTE matcha Ämnesnamn av utfärdande av certifikat på lager n. Detta är kedjeregeln som gör att DICE-identiteten kan spåras från kisel och upp genom varje firmwarelager.

Policy-OID:er: namnrymden tcg-dice-kp

Specifikationen definierar sju policy-OID:er i namnrymden tcg-dice-kp. Dessa placeras i tillägget Extended Key Usage för DICE- certifikat för att identifiera vad nyckeln är auktoriserad för och hur den bands. OID-bågen från specifikationen (bilaga 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-namn	OID-värde	Syfte och bindande regel
tcg-dice-kp-identitetsInit	identitet-init(6)	IDevID. Ursprunglig enhetsidentitet. Nyckeln MÅSTE vara bunden vid tillverkning. Nyckeln MÅSTE vara certifierad av tillverkaren.
tcg-dice-kp-identitetslokal	identitetslokalisering(7)	LDevID. Lokal enhetsidentitet. Nyckeln BÖR vara bunden efter tillverkning. Nyckeln MÅSTE vara certifierad av en lokal utfärdare.
tcg-dice-kp-attestInit	attest-init(8)	Initial attestering. Attesteringsnyckel för bevis på signeringsenhet. Nyckeln MÅSTE vara bunden vid tillverkning och certifierad av tillverkaren.
tcg-dice-kp-attestLoc	attest-loc(9)	Lokal attestering. Attesteringsnyckel, bindande efter tillverkning. MÅSTE certifieras av lokal utfärdare.
tcg-dice-kp-assertInit	assert-init(10)	Initial påstående. Nyckel för signering av referensmätningar om enheten. Tillverkningsbunden.
tcg-dice-kp-assertLoc	assert-loc(11)	Lokalt påstående. Nyckel för signering av referensmätningar. Efter tillverkning. MÅSTE certifieras av lokal utfärdare.
tcg-tärningar-kp-eca	eca(12)	Inbäddad certifikatutfärdare. Auktoriserar certifikatutfärdande för nycklar på den aktuella enheten. Utfärdarens signeringsnyckel MÅSTE vara certifierad av tillverkaren eller den lokala utfärdaren.

De fyra certifikatprofilerna

Specifikationen definierar fyra certifikatprofiler . Var och en har en tabell med krav på fältnivå (tabell 14 i specifikationen). Nedan följer en kortfattad sammanfattning av vilka X.509-certifikatmetadata som krävs för varje certifikatprofil.

IDevID: Ursprunglig enhetsidentifierare

Källa: TCG DICE-certifikatprofiler v1.1, tabell 1

IDevID är enhetens födelsebevis eller lövbevis. Det utfärdas vid tillverkningstillfället och kan inte utfärdas på nytt eftersom nyckeln är hårdvarubunden.

Fält	Krav
emittent	MÅSTE identifiera eller kedja till enhetstillverkaren eller enheten i leveranskedjan. Om utfärdaren är en inbäddad CA, ECA-utfärdaren MÅSTE kedjan till tillverkarens CA. Därför MÅSTE certifikatkedjan valideras
Ämne	Den använder vanligtvis relativa distinguished names (RDN) som Common Name (CN), Organization (O) eller Organizational Unit (OU) för att beteckna TCB-klassen eller -instansen. Ofta är unika hårdvaruidentifierare (som ett unikt enhets-ID eller UEID) inbäddade som tillägg eller inuti SAN:et för att unikt identifiera enhetsinstansen. Obs: MÅSTE identifiera TCB:n (Tillförlitlig databas) äger den privata nyckeln IDevID. Kan vara en klassidentifierare (flera enhetsinstanser som delar samma namn).
Ämnesnyckel	Innehåller den publika nyckeln och algoritmidentifieraren. Nyckeln MÅSTE skyddas av ett oföränderligt TCB-lager, eller ett TCB-lager som endast kan modifieras av utfärdaren. Den privata nyckeln MÅSTE säkras i en hårdvarubaserad modul, till exempel en Hardware Security Module (HSM).
Nyckelanvändning	Om ämnet är en ECA: MÅSTE innehålla keyCertSign, FÅR INTE innehålla cRLSign. Annars: FÅR INTE innehålla keyCertSign.
Utökad nyckelanvändning	MÅSTE innehålla tcg-dice-kp-identityInit. KAN innehålla id-kp-clientAuth, tcg-dice-kp-eca eller tcg-dice-kp-attestInit.
Grundläggande begränsningar	Om Subjektet är en ECA: MÅSTE innehålla cA:TRUE och pathLengthConstraint. Annars: BÖR INTE innehålla BasicConstraints.

LDevID: Lokal enhetsidentifierare

Källa: TCG DICE-certifikatprofiler v1.1, tabell 2

LDevID utfärdas efter tillverkning av enhetens ägare. Det fastställer enhetens operativa identitet i ägarens miljö. Den strukturella skillnaden från IDevID är utfärdaren (ägarens CA, inte tillverkarens CA) och policyns OID (identityLoc, inte identityInit).

Fält	Krav
emittent	MÅSTE identifiera eller länka till ägar-CA. Om utfärdaren är en inbäddad CA MÅSTE ECA-utfärdaren länka till ägar-CA.
Ämne	MÅSTE identifiera den TCB som äger den privata nyckeln LDevID. KAN vara en klassidentifierare.
Ämnesnyckel	Innehåller den publika nyckeln och algoritmidentifieraren. Nyckeln skyddas av ett oföränderligt TCB-lager eller en TCB som endast kan modifieras av utfärdaren.
Nyckelanvändning	Om ämnet är en ECA: MÅSTE innehålla keyCertSign, FÅR INTE innehålla cRLSign. Annars: FÅR INTE innehålla keyCertSign.
Utökad nyckelanvändning	MÅSTE innehålla tcg-dice-kp-identityLoc. KAN innehålla tcg-dice-kp-eca, tcg-dice-kp-attestLoc och/eller id-kp-clientAuth.
Grundläggande begränsningar	Om Subjektet är en ECA: MÅSTE innehålla cA:TRUE och pathLengthConstraint. Annars: BÖR INTE innehålla BasicConstraints.

ECA: Inbäddad certifikatutfärdare

Källa: TCG DICE-certifikatprofiler v1.1, tabell 3 (§5.1.6.3)

ECA är en CA som finns inuti enhetens firmware. Den utfärdar certifikat till firmwarelager ovanför den. Själva ECA:n måste certifieras av tillverkarens CA (eller lokal utfärdare för LDevID-sammanhang) under tillverkningen.

Fält	Krav
emittent	MÅSTE identifiera den CA eller inbäddade CA som utfärdar detta certifikat. Utfärdaren MÅSTE säkerställa att den privata delen av den subjekterade publika nyckeln skyddas av en TCB. Om utfärdaren är en ECA, MÅSTE identifiera TCB-instansen.
Ämne	Ämnesnamnet kan vara ett klassidentifierare, vilket indikerar att flera enhetsinstanser kan dela samma namn. MÅSTE identifiera den TCB som innehåller ECA-funktionalitet.
Ämnesnyckel	MÅSTE innehålla den aktuella offentliga nyckeln och algoritmidentifieraren för TCB-skiktet ECA.
Nyckelanvändning	MÅSTE innehålla keyCertSign. FÅR INTE innehålla cRLSign. Kan innehålla andra attribut för nyckelanvändning.
Utökad nyckelanvändning	MÅSTE innehålla tcg-dice-kp-eca. KAN innehålla tcg-dice-kp-attestInit, tcg-dice-kp-attestLoc, tcg-dice-kp-identityInit eller tcg-dice-kp-identityLoc.
Grundläggande begränsningar	MÅSTE innehålla cA:TRUE och pathLengthConstraint efter behov.
CRL-fördelningspunkter	Tillägg MÅSTE finnas.

Attestationscertifikat

Källa: TCG DICE-certifikatprofiler v1.1, tabell 4

Attesteringscertifikat auktoriserar en nyckel för att signera bevis om en enhet, firmware-hash, hårdvarukonfiguration, produktnamn eller mätstatus. Utfärdas antingen av en ECA eller en extern CA.

Fält	Krav
emittent	MÅSTE innehålla namnet på den inbäddade CA eller externa CA som utfärdar certifikatet. Om utfärdaren är en ECA MÅSTE den identifiera TCB-instansen.
Ämne	MÅSTE identifiera en TCB-klass eller -instans.
Ämnesnyckel	MÅSTE innehålla en aktuell offentlig nyckel och algoritmidentifierare för TCB-attestering.
Nyckelanvändning	Om ämnet är en ECA: MÅSTE innehålla keyCertSign, FÅR INTE innehålla cRLSign. Annars: FÅR INTE innehålla keyCertSign.
Utökad nyckelanvändning	MÅSTE innehålla antingen tcg-dice-kp-attestInit eller tcg-dice-kp-attestLoc. KAN innehålla id-kp-clientAuth och andra lämpliga värden.
Grundläggande begränsningar	Om Subjektet är en ECA: MÅSTE innehålla cA:TRUE och pathLengthConstraint. Annars: BÖR INTE innehålla BasicConstraints.

DICE:s roll i hårdvaruidentitet

Med specifikationen förstått är den större frågan varför DICE är viktigt för användningsfall av hårdvaruidentitet, och vilken roll det spelar i den lager-på-lager-säkerhetsstacken för modern AI-hårdvara.

DICE som hårdvarurotan för förtroende

Varje säkerhetssystem behöver en utgångspunkt som är betrodd genom antaganden. För programvarusystem är detta vanligtvis en HSM , en TPM eller en säker enklav. För hårdvaruidentitet är DICE utgångspunkten. UDS är rotantagandet – det är det enda värdet som är betrott eftersom det bäddades in av tillverkaren under en kontrollerad process och det kan inte läsas eller kopieras av programvara.

Varje identitetsanspråk som härrör från DICE är bara så starkt som UDS. Om UDS är ordentligt skyddat är hela DICE-kedjan ovanför pålitlig. Det är detta som gör DICE till en sann hårdvarurot för förtroende: den förankrar identitet i fysik, inte policy.

DICE skapar firmware-medveten identitet

Standard X.509 -certifikat binder en nyckel till ett namn. DICE-certifikat binder en nyckel till en specifik hårdvaruenhet som kör en specifik firmware-stack. CDI-deriveringen säkerställer att:

• Två enheter med olika hårdvara (olika UDS-värden) producerar olika nycklar, även med identisk firmware
• Samma enhet som kör modifierad firmware producerar en annan nyckel
• Ett certifikat utfärdat mot CDI_n kan verifieras som representerande både hårdvaran och den exakta TCB som används vid utfärdandetillfället.

För AI-hårdvara, såsom GPU:er, NPU:er, DPU:er och inferensacceleratorer, är denna medvetenhet om firmware avgörande. Leveranskedjans attacker som modifierar acceleratorns firmware före driftsättning är en verklig hotvektor. DICE gör sådana modifieringar detekterbara: enheten kommer att producera en annan DICE-identitet efter modifieringen, och den skillnaden är kryptografiskt bevisbar.

DICE i IEEE 802.1AR-ramverket

Autentiseringsuppgifterna IDevID och LDevID definieras i IEEE 802.1AR-2018 (Secure Device Identity). DICE tillhandahåller nyckelderiveringsmekanismen som producerar dessa autentiseringsuppgifter med hårdvarubaserad assurans. När en DICE-aktiverad enhet presenterar sitt IDevID för en 802.1AR-medveten nätverksinfrastruktur (företagsväxlar, åtkomstkontrollsystem och nolltrustplattformar) får infrastrukturen en autentiseringsuppgift som är verifierbart länkad till tillverkarens PKI och till den specifika hårdvara som levereras.

Utan DICE är ett IDevID en programvarunyckel i ett certifikat. Med DICE är det en hårdvarubunden nyckel i ett certifikat, med en härledningskedja som kan spåras tillbaka till en hemlighet på kiselnivå som certifierats vid tillverkningen. 802.1AR-ramverket är detsamma i båda fallen; DICE är det som ger autentiseringsuppgifterna dess hårdvarusäkerhetsnivå.

DICE som PKI-ankare för agentisk AI

I agentbaserade AI-distributioner behöver en AI-agent som körs på en hårdvaruaccelerator en identitet som är:

• Unikt för den specifika hårdvaran den körs på
• Verifierbar av en orkestrator innan hårdvaran anlitas för en arbetsbelastning
• Spårbar tillbaka till tillverkarens försäkran om att hårdvaran är äkta
• Känslig för modifiering av firmware, så manipulerad hårdvara producerar en annan identitet

DICE tillhandahåller alla fyra. IDevID-certifikatet som är rotat i tillverkarens CA, härlett från CDI-kedjan, och bär tcg-dice-kp-identityInit OID är den autentiseringsuppgifter som AI-orkestratorn kontrollerar via SPDM-attestering innan en känslig arbetsbelastning skickas. DICE-kedjan är grunden; SPDM är runtime-protokollet som använder den; agentens operativa certifikat är byggt ovanpå den.

Ta bort DICE, och kedjan av hårdvaruförtroende bryts vid den första länken. Agentens certifikat är då ett programvaruanspråk, inte ett hårdvaruanspråk. Programvaruanspråk kan förfalskas. Hårdvarubaserade anspråk, korrekt implementerade, kan inte det.

DICE och certifikatets livscykel

En aspekt av DICE-identitet som ofta förbises: certifikatets livscykel är knuten till firmware-livscykeln, inte kalendern. I praktiken kommer enheter som implementerar DICE antingen att omcertifiera nycklar vid varje start (eftersom nyckelpar härleds på nytt vid varje start) eller bevara nycklar när firmware förblir oförändrad.

Det här innebär att CLM- modellen (Certificate Lifecycle Management) för DICE-certifikat skiljer sig från modellen för TLS-certifikat:

• En firmwareuppdatering utlöser en ny CDI-derivering, ett nytt nyckelpar och en ny certifikatbegäran
• En enhet som startar oförändrad firmware kan uppvisa samma certifikat som den utfärdade vid tillverkningen.
• Certifikatets utgångsdatum är mindre relevant än firmwareuppdateringsfrekvensen för att hantera DICE-autentiseringsuppgifternas aktualitet.

En PKI-infrastruktur som stöder DICE måste utformas kring dessa egenskaper. Statisk livscykelhantering baserad på utgångsdatum, utformad för server- och användarcertifikat, kan inte översättas till DICE-hårdvarucertifikat utan modifiering.

Hur kan krypteringskonsulting hjälpa till?

Att bygga och driva en tillverkar-CA-hierarki som korrekt stöder DICE-certifikatprofiler är inte något som de flesta hårdvaruleverantörer behöver göra internt. Den CA-infrastruktur som krävs, offline-rot-CA, tillverkningsintegrerad utfärdande CA, CRL-publicering, OCSP- infrastruktur, HSM-hantering och tekniken för att konfigurera allt för DICE-specifika profiler, är specialiserat arbete som förbrukar betydande resurser om det byggs från grunden.

Det är just detta användningsfall som Encryption Consultings PKIaaS-erbjudande är utformat för.

Vad PKIaaS för hårdvaruidentitet innebär

PKI as a Service (PKIaaS) innebär att CA-hierarkin utformas, driftsätts och drivs av Encryption Consulting på uppdrag av hårdvaruleverantören eller driftsättande organisation. Leverantören behöver inte anskaffa HSM:er, konfigurera CA-programvara, hantera rotnyckelceremonier eller driva CRL-infrastruktur. EC gör allt detta. Leverantören integrerar med EC:s PKIaaS via API:er och hanteringsgränssnitt för att utfärda och hantera enhetscertifikat.

För DICE-baserad hårdvaruidentitet tillhandahåller PKIaaS:

• DICE-anpassad tillverkar-CA-hierarki: En rot-CA och utfärdande CA-hierarki konfigurerad för hårdvarucertifikatprofiler. Detta inkluderar den 40–50 år långa eller icke-utgångna giltigheten för rot-CA som krävs för att koherent utfärda IDevID-certifikat med 99991231235959Z notAfter-datum, TCG DICE-kp OID:er registrerade i CA:ns OID-databas och certifikatmallar för varje profiltyp: IDevID, LDevID, ECA och Attestation.
• Integrering av tillverkningsarbetsflöden: Den utfärdande CA:n är integrerad i enhetens tillverkningsprocessen så att IDevID-certifikat tillhandahålls under produktionen. För enheter som implementerar DICE-lagerarkitekturen inkluderar detta ECA-nyckelcertifiering, där tillverkarens CA certifierar den offentliga ECA-nyckeln innan enheten levereras. EC utformar och implementerar tillverknings-API-integrationen.
• Konfiguration av maskinvaruspecifik certifikatprofil: Standard CA-plattformar kräver konfigurationsarbete för att utfärda DICE-kompatibla certifikat. EC konfigurerar CA för: 99991231235959Z-giltighetshantering utan att utlösa avslag på plattformsnivå; obligatoriska TCG OID:er i Extended Key Usage; korrekt nyckelanvändning för ECA- kontra icke-ECA-certifikat; avsaknaden av BasicConstraints på icke-ECA-lövcertifikat; och CRLDistributionPoints på ECA-certifikat enligt kraven i specifikationen.
• CRL- och OCSP-infrastruktur: Hårdvaruinfrastrukturen för CA CRL är byggd för låg återkallningsfrekvens men måste ha hög tillgänglighet, eftersom varje SPDM-attestering validerar certifikatkedjan. EC driver CRL- och OCSP-infrastrukturen på den tillgänglighetsnivå som krävs av hårdvarudistributioner.
• Ägar-PKI-bryggning: När hårdvaruleverantörens IDevID PKI behöver anslutas till den driftsättande organisationens LDevID och agentens operativa certifikat-PKI, utformar och implementerar EC bryggan: policyn och den tekniska kopplingen mellan tillverkarutfärdade och ägarutfärdade autentiseringsuppgifter i samma DICE-förtroendekedja.
• CertSecure-hanterare för agent CLM: Allt eftersom enheterna börjar driftsättas och ägar-PKI:n utfärdar LDevID och agentens operativa certifikat, CertSecure-hanterare hanterar certifikatets livscykel: automatiserad förnyelse via EST, återkallningshantering, identifiering på flottnivå och revisionslogg. Detta är det operativa lagret ovanför DICE-hierarkin som håller PKI igång utan manuella ingrepp.

Slutsats 

DICE-certifikatprofiler, såsom IDevID, LDevID, ECA och Attestation, är inte abstrakta specifikationer. De är den tekniska grunden som omvandlar en hårdvaruaccelerator från en anonym komponent till en verifierbar, tillverkarförankrad identitet. Varje fältkrav i TCG DICE-specifikationen finns av en anledning: för att säkerställa att när en SPDM-attesteringsverifierare validerar en enhetscertifikatkedja, kan den vara säker på att nyckeln var hårdvarubunden, att den inbyggda programvaran mättes och att kedjan spåras tillbaka till ett förtroendeankare som inte kan förfalskas i programvara.

För AI-infrastruktur, där arbetsbelastningar körs på hårdvara som kan ha gått igenom dussintals leveranskedjor före driftsättning, är denna nivå av kryptografisk säkring inte valfri.

Att bygga och driva en DICE-kompatibel CA-hierarki är krävande och specialiserat arbete. Rot-CA:n måste ha en giltighetstid som inte löper ut. Certifikatmallar måste konfigureras för profiler som de flesta CA-plattformar inte är utformade för att utfärda direkt. CRL- och OCSP-infrastruktur måste vara tillgänglig vid varje attesteringshändelse.

Allt eftersom enhetsflottan växer måste certifikatlivscykeln spåra firmwareuppdateringar, inte bara kalenderutgångar. Encryption Consultings PKIaaS tar bort den bördan helt: vi bygger det, vi hanterar det, du kör din hårdvara . Från offline-rot-CA och tillverkarens utfärdande CA till ägarens PKI-brygga, OCSP-svarare och CertSecure Manager för CLM på flottnivå, designas, driftsätts och drivs hela stacken av oss, så ditt team fokuserar på att leverera hårdvara, inte på att köra en CA.