Identitetskrisen vid kanten av agentisk AI

Den globala marknaden för agentbaserad AI nådde 7.6 miljarder dollar år 2025 och förväntas överstiga 196.6 miljarder dollar år 2034. Ändå har de flesta implementeringar ingen hårdvarubaserad agentidentitet.

Traditionella programvaruuppgifter som API-nycklar, OAuth-tokens, mTLS-certifikat och tjänstidentiteter hjälper till att autentisera programvaran eller arbetsbelastningen. De bevisar att en process har presenterat rätt uppgifter. De bevisar dock inte att den underliggande hårdvaran är betrodd, att den inbyggda programvaran inte har modifierats eller att agenten körs på den förväntade plattformen.

Detta är den viktigaste säkerhetsutmaningen för agentisk AI.

Ett certifikat kan visa att en arbetsbelastning har rätt privat nyckel. Det kan inte i sig självt berätta om maskinen som är värd för arbetsbelastningen har blivit komprometterad. Enkelt uttryckt är programvaruidentitet som en bricka. Hårdvarurotad identitet är närmare en biometrisk identitet eftersom den är förankrad i själva enheten.

Hårdvarubaserad identitet ger en starkare grund för förtroende genom att knyta agentens identitet till en hårdvarubaserad rot av förtroende. Istället för att bara fråga: "Är detta rätt programvara?" kan organisationer fråga: "Är detta rätt programvara, som körs på rätt hårdvara, med rätt firmware, i verifierat tillstånd?" Denna distinktion blir extremt viktig i takt med att agentbaserad AI flyttar in i företags- och reglerade miljöer.

Grunden för denna förtroendemodell finns redan genom standarder som DICE från TCG, SPDM från DMTF och CMS med X.509-certifikat . Tillsammans kan dessa standarder bidra till att etablera en identitetskedja från hårdvara till agent som bevisar var en agent körs, vilket tillstånd plattformen befinner sig i och om den plattformen kan litas på.

Vad betyder egentligen "hårdvaruidentitet"?

Hårdvaruidentitet är principen att en enhets identitet ska vara förankrad i något som inte kan extraheras från hårdvaran utan fysisk förstörelse: en kryptografisk nyckel inbäddad under tillverkningen, endast tillgänglig för den firmware som körs direkt på det kiselsystemet, och förmodligen kopplad till den specifika enhet som produceras.

Den mest etablerade implementeringen av denna princip är Trusted Platform Module (TPM), som funnits i företagsservrar och bärbara datorer i årtionden. Men TPM:er utformades för en värld av relativt statiska maskiner och relativt enkla förtroendepåståenden. Utmaningen med agentiska AI-agenter som körs på specialbyggda AI-acceleratorer, kantinferenshårdvara, molnbaserad kisel och GPU-kluster kräver en mer flexibel och sammansättningsbar strategi för hårdvarubaserad identitet.

Den metoden bygger på tre sammankopplade standarder. Var och en kommer att få sin egen djupgående blogg i den här serien, men här är vad var och en gör:

DICE: Enhetsidentifierarkompositionsmotor (TCG)

DICE, som utvecklats av Trusted Computing Group, tillhandahåller grunden: en mekanism för att härleda en unik, hårdvarubunden kryptografisk identitet från en hemlighet som bäddats in vid tillverkningstillfället. Varje lager av firmware som läggs till ovanpå den grunden mäts och införlivas i identitetshärledningen, så identiteten som framträder på applikationslagret återspeglar inte bara själva hårdvaran. Ändå det specifika firmwaretillståndet som körs på den. En agent som kör hårdvara med modifierad firmware kommer att ha en annan identitet än samma hårdvara som kör omodifierad firmware, och den skillnaden är kryptografiskt bevisbar.

SPDM: Säkerhetsprotokoll och datamodell (DMTF)

SPDM är kommunikationsprotokollet som gör det möjligt för en komponent att bevisa sin hårdvaruidentitet för en annan. Där DICE skapar identiteten, är SPDM den mekanism genom vilken identiteten presenteras och verifieras under en liveinteraktion. En AI-orkestrator som använder SPDM kan utmana en hårdvarukomponent, ett GPU, ett nätverkskort eller en säker enklav och få en kryptografiskt signerad intyg om komponentens identitet och mättillstånd innan den anförtros någon arbetsbelastning.

CMS och X.509: PKI-kuvertet

Cryptographic Message Syntax (CMS, RFC 5652) och X.509-certifikatprofiler är det lager där hårdvaruidentitet ansluter till det bredare PKI-ekosystemet . DICE producerar en certifikatkedja som är rotad i hårdvara. SPDM intygar hårdvarans integritet vid körning. CMS tillhandahåller kuvertet för att signera enskilda agentåtgärder, transaktioner eller meddelanden, och knyter dem tillbaka till den hårdvarurotade identiteten för den agent som producerade dem. Tillsammans bildar dessa tre standarder en komplett förtroendekedja från kisel till signerad åtgärd.

Hårdvarubaserad identitet för AI-agenter

DICE, SPDM, IEEE 802.1AR-2018 (Secure Device Identity) och CMS är välspecificerade och aktivt implementerade i företagshårdvara idag. AI-acceleratorer från stora hårdvarubaserade leverantörer implementerar redan DICE. Företagsservrar stöder redan SPDM. Certifikaten som knyter dessa attesteringar till en användbar PKI överensstämmer redan med väletablerade X.509- och IEEE 802.1AR-profiler.

Utmaningen är att ingen ännu har byggt den operativa infrastrukturen som kopplar samman dessa hårdvarustandarder med AI-agentens driftsättningslivscykel. Certifikatutgivningsplattformar byggdes för servrar, användare och enheter. De var inte utformade för att:

• Registrera en AI-accelerators hårdvaruidentitet med hjälp av DICE-härledda certifikatkedjor
• Verifiera firmwareintegriteten via SPDM innan ett operativt agentcertifikat utfärdas
• hantera certifikatets livscykel för agentidentiteter som kan starta och stängas av flera gånger per dag
• Koppla signerade agentåtgärder via CMS tillbaka till den hårdvarurotade kedjan som bevisar agentens ursprung

Det är just den operativa klyftan mellan de befintliga standarderna och den infrastruktur som implementerar dem för agentisk AI som ackumuleras. Vårt samarbete med en Fortune 100-organisation gällande SPDM-kompatibel PKI för enhetscertifikat, i linje med DICE X.509 och IEEE 802.1AR, representerar den typ av verklighetsbaserad implementering som de flesta leverantörer fortfarande positionerar som en framtida färdplan. Standarderna finns, hårdvaran stöder dem och implementeringsarbetet pågår för organisationer som väljer att kräva det.

Fem sätt som hårdvaru-PKI är strukturellt annorlunda

Följande är de 5 PKI-implikationerna som är strukturellt olika och som måste beaktas vid hårdvarutillverkning.

1. Den privata nyckeln är fysiskt bunden till kisel

I server- PKI kan en privat nyckel exporteras, säkerhetskopieras, migreras eller roteras enligt ett schema. I hårdvaruidentitets-PKI härleds den privata nyckeln från UDS (Unique Device Secret), ett värde som är fysiskt inbäddat i kisel vid tillverkningen, enligt specificeringen i TCG DICE-arkitekturen. Den kan inte exporteras. Den kan inte säkerhetskopieras. Nyckelkompromittering innebär att enheten tas ur bruk, inte att certifikatet ersätts.

PKI-konsekvenser:

• Ingen nyckeldepositionsmodell för hårdvarubundna nycklar
• Nyckelrotation kräver utbyte av fysisk enhet
• Din CA kan inte verifiera nyckeln enbart via ett standardiserat CSR-arbetsflöde — DICE-härledningskedjan tillhandahåller bevis på bindning.

2. Certifikatets giltighetstid måste utformas kring enhetens livslängd, inte efterlevnadsfönster

CA /Browser Forum har föreskrivit en maximal livslängd på 47 dagar för TLS-certifikat (Ballot SC-081, giltigt från mars 2026). En AI-accelerator som levereras idag kan fortfarande vara i produktion år 2045. TCG DICE-certifikatprofilspecifikationen hanterar detta direkt:

Enheter utan en säker klocka kan ställa in "Inte efter"-delen av certifikatets giltighetsperiod till det X.509-definierade GeneralizedTime-värdet 99991231235959Z . Detta värde används för att indikera att certifikatet inte har något definierat utgångsdatum.

Detta är inte valfritt och inte en lösning. Det är det normativa beteendet för hårdvarucertifikat på enheter utan realtidsklocka. Din CA-infrastruktur måste vara konfigurerad för att utfärda certifikat med detta värde. De flesta företags-CA-plattformar tillämpar begränsningar för maximal giltighetstid som standard; du kommer att behöva explicita konfigurationsundantag för hårdvarucertifikatprofiler.

3. Två distinkta identitetsfaser kräver två helt separata PKI-hierarkier

Hårdvaruidentitet fungerar i två faser med olika förtroendeankare:

Fas 1 – Tillverkningstidsidentitet (IDevID)	Fas 2 – Identitet vid driftsättningstid (LDevID)
Standard: IEEE 802.1AR-2018 + TCG DICE X.509	Standard: IEEE 802.1AR-2018 + TCG DICE X.509
Utfärdad av: Enhetstillverkarens CA	Utfärdad av: Enhetsägarens CA (helt separat från tillverkarens CA)
Policy-OID: id-tcg-kp-identityInit {id-tcg-kp 6}	Policy-OID: id-tcg-kp-identityLoc {id-tcg-kp 7}
Syfte: Bevisar att detta är äkta hårdvara från denna tillverkare	Syfte: Operativ identitet inom ägarens miljö
Detta är enhetens födelsebevis. Det kan inte utfärdas på nytt efter tillverkning.	Utfärdas efter att SPDM-attestering av IDevID-kedjan har lyckats.

Dessa två hierarkier får aldrig dela rot. Tillverkarens CA har ingen auktoritet över ägarens operativa miljö. Att slå samman dem ger hårdvaruleverantören kontinuerlig kontroll över en driftsättande organisations PKI-beslut, vilket är både ett misslyckande med förtroendemodellen och, inom reglerade branscher, ett efterlevnadsproblem.

4. Återkallelse innebär fysisk åtgärd, inte certifikatersättning

Att återkalla ett IDevID tillåter dig inte att utfärda det på nytt med en ny nyckel. Nyckeln är hårdvarubunden. Återkallelse innebär att enheten sätts i karantän eller tas ur bruk. Din CRL- och OCSP- infrastruktur måste byggas kring denna verklighet:

• IDevID CRL-poster bör utlösa arbetsflöden för enhetskarantän, inte bara ogiltigförklaring av certifikat
• OCSP-servicenivåavtal för hårdvaru-CA:er måste vara strikta, dvs. en enhet som inte kan validera sin certifikatkedja är driftdöd.
• CRL-publiceringsfrekvensen för hårdvaru-CA:er kan vara längre än för server-CA:er (veckovis till månadsvis) eftersom viktiga komprometteringshändelser är sällsynta och fysiskt begränsade.

5. Den utfärdande CA:n kan vara inbäddad i enhetens firmware

TCG DICE-specifikationen definierar en inbäddad certifikatutfärdare (ECA), en CA som finns inuti enhetens firmware och utfärdar certifikat till firmware-lager ovanför den.

En ECA är en riktig CA. Den har ett nyckelpar som härrör från DICE CDI (Compound Device Identifier). Den signerar certifikat. Den måste certifieras av tillverkarens CA under tillverkningsprocessen. Detta innebär:

• Tillverkarens utfärdande certifikat måste vara tillgängligt och integrerat i produktionslinjen.
• ECA-certifikatet MÅSTE innehålla: keyCertSign i nyckelanvändning, cA: TRUE i grundläggande begränsningar med pathLengthConstraint, policy-OID id-tcg-kp-eca {id-tcg-kp 12}, och CRLDistributionPoints MÅSTE finnas.
• Om du upptäcker att ECA behöver certifieras efter att tillverkningen har påbörjats, omformar du en produktionsarbetsflödesplan, så detta är med från dag ett.

PKI-hierarkin för hårdvaruidentitet

Här är den kompletta CA-hierarkin, med kraven på varje nivå. Detta gäller hårdvaruleverantörer som bygger tillverkarens PKI.

CA-nivå	Algoritm / HSM	Giltighet	Nyckelanvändning	Frågor
Tillverkarens rot-CA	ECDSA P-384 / FIPS 140-3 L3+ HSM, offline luftgap	99991231235959Z (ingen klocka) eller definierad	Endast CA	Endast mellanliggande certifikatutfärdare för tillverkare
Tillverkare Mellanliggande CA	ECDSA P-384 / FIPS 140-3 L3 HSM, onlinebegränsad	99991231235959Z (ingen klocka) eller definierad	CA + CRLSign	IDevID-certifikat eller ECA-certifikat
ECA (på enheten, DICE)	ECDSA P-256/384 / DICE CDI-härledd	Matchar IDevID-livstid	endast keyCertSign (FÅR INTE cRLSign)	Attesteringscertifikat för firmwarelager
IDevID Leaf-certifikat	ECDSA P-256/P-384 / kiselbunden	99991231235959Z (ingen klocka) eller definierad	FÅR INTE keyCertSign	Slutentitet för enhetsidentitet

TCG-policy-OID: varje certifikat måste ha rätt OID

TCG DICE-specifikationen definierar en uppsättning policy-OID:er i namnrymden id-tcg-kp. Varje OID kodar vad ett certifikat är auktoriserat för och hur dess nyckel var bunden. Om OID:t är felaktigt misslyckas certifikatet med validering vid varje SPDM-verifierare och 802.1AR-medvetet system.

OID-namn	OID-värde	Certifikattyp	Nyckeln måste vara bunden
id-tcg-kp-identitetsInit	{id-tcg-kp 6}	IDvID	Vid tillverkningstillfället. Certifierad av tillverkaren CA.
id-tcg-kp-identitetsplats	{id-tcg-kp 7}	LDevID	Efter tillverkning. Certifierad av lokal/ägar CA.
id-tcg-kp-attestInit	{id-tcg-kp 8}	Intyg (initialer)	Vid tillverkningstillfället. Skyltar som bevisar enhetens firmware/konfiguration.
id-tcg-kp-attestLoc	{id-tcg-kp 9}	Attestering (lokal)	Efter tillverkning. Certifierad av en lokal utfärdare.
id-tcg-kp-assertInit	{id-tcg-kp 10}	Påstående (initial)	Vid tillverkningstillfället. Skyltar referensmått.
id-tcg-kp-assertLoc	{id-tcg-kp 11}	Påstående (lokalt)	Efter tillverkning. Certifierad av en lokal utfärdare.
id-tcg-kp-eca	{id-tcg-kp 12}	ECA	Tillverkning eller eftertillverkning. Auktoriserar certifikatutfärdande av inbäddad CA.

Praktiska regler för din CA-konfiguration:

• IDevID MÅSTE innehålla id-tcg-kp-identityInit. Det KAN också innehålla id-tcg-kp-eca (om enheten är en ECA) och id-tcg-kp-attestInit (om den också utför attesteringssignering).
• LDevID MÅSTE innehålla id-tcg-kp-identityLoc. Det KAN också innehålla id-tcg-kp-eca och id-tcg-kp-attestLoc.
• ECA-certifikat MÅSTE innehålla id-tcg-kp-eca. CRLDistributionPoints-tillägget MÅSTE finnas.
• Attesteringscertifikat MÅSTE innehålla antingen id-tcg-kp-attestInit eller id-tcg-kp-attestLoc.

De sex vanligaste PKI-misstagen som hårdvaruleverantörer gör

Följande är sex vanliga misstag som hårdvaruleverantörer kan göra när de utformar eller implementerar hårdvarubaserade identitets- och säkerhetskontroller. Dessa punkter är inte nödvändigtvis tillämpliga på alla hårdvaruleverantörer och kan variera beroende på produktarkitektur, distributionsmodell, hotbild, myndighetskrav och specifikt användningsfall. De bör behandlas som allmänna överväganden snarare än universella antaganden.

Använda servercertifikatprofiler för enhetscertifikat. CA/Browser Forum-profiler är utformade för TLS. De ställer krav på ämnesnamn, SAN-krav och giltighetsperioder som inte gäller hårdvaruidentitet. Ett IDevID som utfärdats med en CABF-profil kommer inte att innehålla id-tcg-kp-identityInit, kommer att ha en kort giltighetsperiod och kommer att avvisas av SPDM-verifierare som kontrollerar TCG OID:er.

Konfigurerar inte certifikatutfärdaren för livslängden 99991231235959Z. Företagscertifikatutfärdare har maximal giltighetstid. Om ditt hårdvaruteam begär ett IDevID och certifikatutfärdaren avvisar det eftersom livslängden överskrider policygränserna får du antingen ett felkonfigurerat certifikat eller ett lösningscertifikat med ett godtyckligt långt datum, men inte det angivna värdet.

Sammanslagning av tillverkarens och ägarens CA-hierarkier. Att skapa en enda PKI som utfärdar både IDevID och LDevID från samma rot ger hårdvaruleverantören auktoritet över den driftsättande organisationens operativa identitet. Detta bryter mot den tvåfasiga identitetsmodellen som definieras i IEEE 802.1AR-2018, vilket skapar en enda felpunkt för båda faserna.

Planerar inte för ECA-certifiering vid tillverkningstillfället. Om din enhet implementerar DICE måste ECA:n certifieras innan enheten levereras. Det betyder att tillverkarens mellanliggande CA måste vara tillgänglig och integrerad i tillverkningsarbetsflödet. Team som upptäcker detta krav efter att tillverkningen har påbörjats ställs inför kostsamma processomdesigner eller levererar enheter utan en korrekt certifierad ECA.

Ignorerar SPDM-certifikatkedjeformatet. SPDM GET_CERTIFICATE returnerar en kedja i ett specifikt format: 2 byte total längd → 2 byte rot-hashlängd → rotcertifikat-hash → sammanfogade DER-certifikat. Om din PKI utfärdar standard-DER-kedjor och din SPDM-implementering slår in dem felaktigt, kommer CHALLENGE_AUTH-verifieringen att misslyckas.

Ingen CRL/OCSP-infrastruktur för hårdvaru-CA:er. ECA-certifikatprofilen kräver att CRLDistributionPoints finns. Hårdvaru-CA:s CRL-infrastruktur måste vara dimensionerad för mycket låg återkallningsfrekvens men mycket hög valideringsfrekvens. Varje SPDM-attestering validerar certifikatkedjan, vilket inkluderar CRL/OCSP-kontroller.

Hur kan krypteringskonsulting hjälpa till?

Encryption Consulting specialiserar sig på PKI-arkitektur för hårdvarubaserad identitet. Vårt arbete med hårdvaruleverantörer och driftsättningsorganisationer täcker hela den här blogginläggets omfattning: design av tillverkarnas CA-hierarkier, konfigurering av hårdvarucertifikatprofiler, implementering av ECA-provisionering i tillverkningsarbetsflöden och byggande av ägar-PKI som kopplar IDevID till agentens operativa identitet.

• Design av tillverkares PKI: Vi utformar CA-hierarkier anpassade till TCG DICE, IEEE 802.1AR och DMTF SPDM. Detta inkluderar planering av offline-root-CA-ceremonier, val och konfiguration av HSM samt de certifikatprofilspecifikationer som din CA behöver för IDevID, ECA och attesteringscertifikat.
• Integrering av tillverkningsarbetsflöden: ECA-nyckelcertifiering kräver att tillverkarens CA är tillgänglig och integrerad under produktionsprocessen. Vi designar och implementerar PKI-till-tillverkningsintegrationen HSM-anslutning, certifikatgenerering och verifiering som gör detta operativt praktiskt.
• SPDM- och DICE-implementering: Vi kopplar samman hårdvaru-PKI med runtime-attestering, vilket säkerställer att certifikatkedjan som din PKI utfärdar klarar SPDM GET_CERTIFICATE- och CHALLENGE_AUTH-valideringen. Fallstudie om Fortune 100 SPDM är en produktionsreferens för detta arbete.
• CertSecure-hanterare för agent CLM: För ägarens PKI-hanterande agents operativa certifikatlivscykler i stor skala tillhandahåller CertSecure Manager identifiering, automatiserad EST-förnyelse, automatisering av återkallelser och infrastruktur för revisionslogg.

Slutsats

Hårdvaruidentitet för AI-agenter är inte en framtida fråga. AI-acceleratorer implementerar redan DICE. Företagshårdvara stöder redan SPDM. Certifikaten som knyter dessa attesteringar till en användbar PKI överensstämmer redan med väletablerade X.509- och CMS-standarder. Det som saknas är den operativa arkitekturen som kopplar samman dem och den organisatoriska viljan att kräva hårdvarubaserat förtroende som en baslinje för agentbaserad AI-distribution.

De återstående fyra blogginläggen i den här serien bygger upp den arkitekturen bit för bit. I slutet kommer du att ha en komplett ritning för en AI-agentidentitetsstack som börjar i kisel och slutar med en signerad, granskningsbar registrering av varje följdåtgärd dina agenter vidtar.