De identiteitscrisis aan de rand van agentische AI

De wereldwijde markt voor AI-agenten bereikte in 2025 een waarde van 7.6 miljard dollar en zal naar verwachting in 2034 de 196.6 miljard dollar overschrijden. De meeste implementaties hebben echter geen hardwarematige agentidentiteit.

Traditionele softwarereferenties zoals API-sleutels, OAuth-tokens, mTLS-certificaten en service-identiteiten helpen bij het authenticeren van de software of workload. Ze bewijzen dat een proces de juiste referenties heeft verstrekt. Ze bewijzen echter niet dat de onderliggende hardware betrouwbaar is, dat de firmware niet is gewijzigd of dat de agent op het verwachte platform draait.

Dit is de grootste beveiligingsuitdaging voor AI-agenten.

Een certificaat kan aantonen dat een workload de juiste privésleutel heeft. Het kan echter op zichzelf niet aantonen of de machine waarop die workload draait, is gecompromitteerd. Simpel gezegd: software-identiteit is als een badge. Hardware-identiteit ligt dichter bij een biometrie, omdat deze in het apparaat zelf is verankerd.

Hardwaregebaseerde identiteit biedt een sterkere basis van vertrouwen door de identiteit van de agent te koppelen aan een hardwarematige vertrouwensbasis. In plaats van alleen te vragen: "Is dit de juiste software?", kunnen organisaties vragen: "Is dit de juiste software, draait deze op de juiste hardware, met de juiste firmware, en is deze geverifieerd?" Dit onderscheid wordt uiterst belangrijk naarmate AI-agenten hun intrede doen in bedrijfsomgevingen en gereguleerde omgevingen.

De basis voor dit vertrouwensmodel is reeds gelegd door standaarden zoals DICE van TCG, SPDM van DMTF en CMS met X.509-certificaten . Samen kunnen deze standaarden helpen bij het opzetten van een identiteitsketen van hardware naar agent, waarmee kan worden aangetoond waar een agent draait, in welke status het platform zich bevindt en of dat platform te vertrouwen is.

Wat betekent "hardware-identiteit" nu eigenlijk?

Hardware-identiteit is het principe dat de identiteit van een apparaat verankerd moet zijn in iets dat niet uit de hardware kan worden gehaald zonder fysieke vernietiging: een cryptografische sleutel die tijdens de fabricage is ingebed, alleen toegankelijk is voor de firmware die direct op die chip draait, en waarschijnlijk gekoppeld is aan het specifieke geproduceerde apparaat.

De meest gangbare implementatie van dit principe is de Trusted Platform Module (TPM), die al tientallen jaren aanwezig is in bedrijfsservers en laptops. TPM's zijn echter ontworpen voor een wereld van relatief statische machines en relatief eenvoudige vertrouwensverklaringen. De uitdaging van AI-agenten die draaien op speciaal daarvoor ontwikkelde AI-acceleratoren, edge-inferentiehardware, cloudgebaseerde chips en GPU-clusters vereist een flexibelere, combineerbare aanpak voor hardwarematige identiteitsverificatie.

Die aanpak is gebaseerd op drie onderling samenhangende standaarden. Elk van deze standaarden krijgt een eigen, uitgebreide blogpost in deze serie, maar hieronder volgt een korte uitleg van wat elke standaard inhoudt:

DICE: Device Identifier Composition Engine (TCG)

DICE, ontwikkeld door de Trusted Computing Group, biedt de basis: een mechanisme voor het afleiden van een unieke, hardwaregebonden cryptografische identiteit uit een geheim dat tijdens de fabricage is ingebed. Elke firmwarelaag die bovenop deze basis wordt toegevoegd, wordt gemeten en meegenomen in de identiteitsafleiding, zodat de identiteit die op de applicatielaag ontstaat niet alleen de hardware zelf weerspiegelt, maar ook de specifieke firmwarestatus die erop draait. Een agent die hardware met aangepaste firmware gebruikt, heeft een andere identiteit dan dezelfde hardware met onaangepaste firmware, en dat verschil is cryptografisch aantoonbaar.

SPDM: Beveiligingsprotocol en datamodel (DMTF)

SPDM is het communicatieprotocol waarmee een component zijn hardware-identiteit aan een andere component kan bewijzen. Waar DICE de identiteit creëert, is SPDM het mechanisme waarmee die identiteit tijdens een live interactie wordt gepresenteerd en geverifieerd. Een AI-orkestrator die SPDM gebruikt, kan een hardwarecomponent, een GPU, een netwerkkaart of een beveiligde enclave uitdagen en een cryptografisch ondertekende bevestiging van de identiteit en meetstatus van die component ontvangen voordat deze component een workload krijgt toegewezen.

CMS en X.509: De PKI-envelop

Cryptografische berichtensyntaxis (CMS, RFC 5652) en X.509-certificaatprofielen vormen de laag waarop hardware-identiteit verbinding maakt met het bredere PKI-ecosysteem . DICE genereert een certificaatketen die is gebaseerd op hardware. SPDM bevestigt de integriteit van de hardware tijdens de uitvoering. CMS biedt de basis voor het ondertekenen van individuele agentacties, transacties of berichten, waardoor deze gekoppeld worden aan de hardware-identiteit van de agent die ze heeft gegenereerd. Samen vormen deze drie standaarden een complete vertrouwensketen, van silicium tot ondertekende actie.

Hardware-gebaseerde identiteit voor AI-agenten

DICE, SPDM, IEEE 802.1AR-2018 (Secure Device Identity) en CMS zijn goed gespecificeerd en worden actief geïmplementeerd in zakelijke hardware. AI-acceleratoren van grote hardwareleveranciers implementeren al DICE. Zakelijke servers ondersteunen al SPDM. De certificaten die deze attestaties koppelen aan een bruikbare PKI voldoen al aan de gevestigde X.509- en IEEE 802.1AR-profielen.

De uitdaging is dat er nog niemand de operationele infrastructuur heeft gebouwd die deze hardwarestandaarden verbindt met de implementatiecyclus van AI-agenten. Platformen voor certificaatuitgifte zijn gebouwd voor servers, gebruikers en apparaten. Ze zijn niet ontworpen om:

• Registreer de hardware-identiteit van een AI-accelerator met behulp van certificaatketens die zijn afgeleid van DICE.
• Controleer de integriteit van de firmware via SPDM voordat u een operationeel agentcertificaat uitgeeft.
• Beheren certificaat levenscyclus voor agentidentiteiten die mogelijk meerdere keren per dag worden aangemaakt en weer worden verwijderd.
• Koppel ondertekende agentacties via het CMS terug aan de hardwarematige keten die de herkomst van de agent bewijst.

Die operationele kloof tussen de bestaande standaarden en de infrastructuur die ze implementeert voor agentische AI ​​is precies waar risico's ontstaan. Onze samenwerking met een Fortune 100-organisatie op het gebied van SPDM-compatibele PKI voor apparaatcertificaten, afgestemd op DICE X.509 en IEEE 802.1AR, vertegenwoordigt het soort praktijkimplementatie dat de meeste leveranciers nog steeds als een toekomstig onderdeel van hun roadmap beschouwen. De standaarden bestaan, de hardware ondersteunt ze en de implementatie is in volle gang voor organisaties die ervoor kiezen om ze te vereisen.

Vijf manieren waarop hardware-PKI structureel anders is.

Hieronder volgen de 5 PKI-implicaties die structureel verschillen en waarmee rekening moet worden gehouden tijdens de hardwareproductie.

1. De privésleutel is fysiek aan silicium gebonden.

Bij server- PKI kan een privésleutel worden geëxporteerd, geback-upt, gemigreerd of volgens een schema worden geroteerd. Bij hardware-identiteits-PKI wordt de privésleutel afgeleid van de UDS (Unique Device Secret), een waarde die fysiek in de chip is ingebed tijdens de fabricage, zoals gespecificeerd in de TCG DICE-architectuur. Deze kan niet worden geëxporteerd en er kan geen back-up van worden gemaakt. Een compromittering van de sleutel betekent het buiten gebruik stellen van het apparaat, niet het vervangen van het certificaat.

Implicaties voor PKI:

• Geen sleutelbewaringsmodel voor hardwaregebonden sleutels
• Voor het draaien van de sleutel is een fysieke vervanging van het apparaat vereist.
• Uw certificeringsinstantie (CA) kan de sleutel niet alleen via een standaard CSR-workflow verifiëren; de DICE-afleidingsketen levert het bewijs van binding.

2. De geldigheidsduur van certificaten moet worden afgestemd op de levensduur van het apparaat, niet op de nalevingsperioden.

Het CA/Browser Forum heeft een maximale levensduur van 47 dagen voor TLS-certificaten vastgesteld (stemming SC-081, van kracht vanaf maart 2026). Een AI-accelerator die vandaag de dag wordt uitgebracht, kan in 2045 nog steeds in gebruik zijn. De TCG DICE Certificate Profiles-specificatie behandelt dit direct:

Apparaten zonder een beveiligde klok kunnen het 'Niet na'-gedeelte van de geldigheidsperiode van het certificaat instellen op de door X.509 gedefinieerde GeneralizedTime-waarde van 99991231235959Z . Deze waarde wordt gebruikt om aan te geven dat het certificaat geen gedefinieerde vervaldatum heeft.

Dit is niet optioneel en geen tijdelijke oplossing. Het is de standaardprocedure voor hardwarecertificaten op apparaten zonder realtimeklok. Uw CA-infrastructuur moet geconfigureerd zijn om certificaten met deze waarde uit te geven. De meeste CA-platformen voor bedrijven hanteren standaard maximale geldigheidsperioden; u hebt expliciete configuratie-uitzonderingen nodig voor hardwarecertificaatprofielen.

3. Twee afzonderlijke identiteitsfasen vereisen twee volledig gescheiden PKI-hiërarchieën.

Hardware-identificatie werkt in twee fasen met verschillende vertrouwensankers:

Fase 1 - Productietijdidentiteit (IDevID)	Fase 2 - Identiteit tijdens implementatie (LDevID)
Standaard: IEEE 802.1AR-2018 + TCG DICE X.509	Standaard: IEEE 802.1AR-2018 + TCG DICE X.509
Uitgegeven door: CA van de fabrikant van het apparaat	Uitgegeven door: De certificeringsinstantie van de apparaateigenaar (volledig gescheiden van de certificeringsinstantie van de fabrikant)
Beleids-OID: id-tcg-kp-identityInit {id-tcg-kp 6}	Beleids-OID: id-tcg-kp-identityLoc {id-tcg-kp 7}
Doel: Bewijst dat dit originele hardware van deze fabrikant is.	Doel: Operationele identiteit binnen de omgeving van de eigenaar
Dit is de geboorteakte van het apparaat. Deze kan na fabricage niet opnieuw worden uitgegeven.	Uitgegeven nadat de SPDM-attestatie van de IDevID-keten succesvol is afgerond.

Deze twee hiërarchieën mogen nooit een gemeenschappelijke basis hebben. De CA van de fabrikant heeft geen zeggenschap over de operationele omgeving van de eigenaar. Door ze samen te voegen, krijgt de hardwareleverancier voortdurende controle over de PKI-beslissingen van een implementerende organisatie, wat zowel een schending van het vertrouwensmodel is als, in gereguleerde sectoren, een complianceprobleem.

4. Intrekking betekent een fysieke handeling, geen vervanging van het certificaat.

Het intrekken van een IDevID geeft u niet de mogelijkheid om deze opnieuw uit te geven met een nieuwe sleutel. De sleutel is hardwaregebonden. Intrekking betekent dat het apparaat in quarantaine wordt geplaatst of buiten gebruik wordt gesteld. Uw CRL- en OCSP- infrastructuur moet op deze realiteit zijn gebaseerd.

• IDevID CRL-vermeldingen zouden workflows voor apparaatquarantaine moeten activeren, niet alleen certificaatongeldigverklaring.
• De OCSP-SLA's voor hardware-CA's moeten strikt zijn, oftewel: een apparaat dat zijn certificaatketen niet kan valideren, is operationeel onbruikbaar.
• De publicatiefrequentie van CRL's voor hardware-CA's kan langer zijn dan die voor server-CA's (wekelijks tot maandelijks), omdat sleutelcompromissen zeldzaam zijn en fysiek beperkt zijn.

5. De uitgevende CA kan in de firmware van het apparaat zijn ingebed.

De TCG DICE-specificatie definieert een Embedded Certificate Authority (ECA), een CA die zich in de firmware van het apparaat bevindt en certificaten uitgeeft aan firmwarelagen daarboven.

De ECA is een echte CA. Het beschikt over een sleutelpaar dat is afgeleid van de DICE CDI (Compound Device Identifier). Het ondertekent certificaten. Het moet tijdens het productieproces door de CA van de fabrikant worden gecertificeerd. Dit betekent:

• De door de fabrikant afgegeven certificeringsinstantie (CA) moet beschikbaar zijn en in de productielijn geïntegreerd zijn.
• Het ECA-certificaat MOET het volgende bevatten: keyCertSign in Key Usage, cA: TRUE in Basic Constraints met pathLengthConstraint, Policy OID id-tcg-kp-eca {id-tcg-kp 12}, en CRLDistributionPoints MOET aanwezig zijn.
• Als je ontdekt dat de ECA (Engineering Control Authority) gecertificeerd moet worden nadat de productie al is gestart, dan herontwerp je het productieproces. Dit is dus vanaf dag één een aandachtspunt.

De PKI-hiërarchie voor hardware-identiteit

Hieronder vindt u de volledige CA-hiërarchie, met de vereisten op elk niveau. Dit is van toepassing op hardwareleveranciers die de PKI van de fabrikant bouwen.

CA-niveau	Algoritme / HSM	Geldigheid	Sleutelgebruik	Problemen
Fabrikant Root CA	ECDSA P-384 / FIPS 140-3 L3+ HSM, offline air-gapped	99991231235959Z (geen klok) of gedefinieerd	Alleen CA	Fabrikant Intermediate CAs alleen
Fabrikant Tussenliggend CA	ECDSA P-384 / FIPS 140-3 L3 HSM, online beperkt	99991231235959Z (geen klok) of gedefinieerd	CA + CRLSign	IDevID-certificaten of ECA-certificaten
ECA (on-device, DICE)	ECDSA P-256/384 / DICE CDI-afgeleid	Komt overeen met IDevID levenslang	Alleen keyCertSign (MAG NIET cRLSign)	Attestatiecertificaten voor firmwarelagen
IDevID-bladcertificaat	ECDSA P-256/P-384 / siliciumgebonden	99991231235959Z (geen klok) of gedefinieerd	MAG GEEN keyCertSign	Eindentiteit voor apparaatidentiteit

TCG-beleid OID's: elk certificaat moet de juiste OID bevatten.

De TCG DICE-specificatie definieert een set beleids-OID's in de id-tcg-kp-naamruimte. Elke OID codeert waarvoor een certificaat geautoriseerd is en hoe de bijbehorende sleutel is gekoppeld. Een onjuiste OID betekent dat het certificaat de validatie niet doorstaat bij elke SPDM-verifier en elk 802.1AR-compatibel systeem.

OID-naam	OID-waarde	Certificaattype	Sleutel moet worden gekoppeld
id-tcg-kp-identityInit	{id-tcg-kp 6}	IDevID	Tijdens de productie. Gecertificeerd door de fabrikant (CA).
id-tcg-kp-identityLoc	{id-tcg-kp 7}	LDevID	Na de productie. Gecertificeerd door de lokale eigenaar (CA).
id-tcg-kp-attestInit	{id-tcg-kp 8}	Verklaring (paraaf)	Tijdens de productie. Tekens die informatie geven over de firmware/configuratie van het apparaat.
id-tcg-kp-attestLoc	{id-tcg-kp 9}	Attestatie (lokaal)	Na de productie. Gecertificeerd door een lokale instantie.
id-tcg-kp-assertInit	{id-tcg-kp 10}	Bewering (initieel)	Tijdens de productie. Geeft referentiematen aan.
id-tcg-kp-assertLoc	{id-tcg-kp 11}	Bewering (lokaal)	Na de productie. Gecertificeerd door een lokale instantie.
id-tcg-kp-eca	{id-tcg-kp 12}	ACE	Productie of nabewerking. Autoriseert de uitgifte van certificaten door de ingebouwde CA.

Praktische regels voor uw CA-configuratie:

• IDevID MOET id-tcg-kp-identityInit bevatten. Het MAG ook id-tcg-kp-eca (als het apparaat een ECA is) en id-tcg-kp-attestInit (als het ook attestatieondertekening uitvoert) bevatten.
• LDevID MOET id-tcg-kp-identityLoc bevatten. Het MAG ook id-tcg-kp-eca en id-tcg-kp-attestLoc bevatten.
• ECA-certificaten MOETEN de extensie id-tcg-kp-eca bevatten. De extensie CRLDistributionPoints MOET aanwezig zijn.
• Attestatiecertificaten MOETEN id-tcg-kp-attestInit of id-tcg-kp-attestLoc bevatten.

De zes meest voorkomende PKI-fouten die hardwareleveranciers maken

Hieronder volgen zes veelvoorkomende fouten die hardwareleveranciers kunnen maken bij het ontwerpen of implementeren van hardwarematige identiteits- en beveiligingscontroles. Deze punten zijn niet per se van toepassing op elke hardwareleverancier en kunnen variëren afhankelijk van de productarchitectuur, het implementatiemodel, het dreigingslandschap, de wettelijke vereisten en het specifieke gebruiksscenario. Ze moeten worden beschouwd als algemene overwegingen en niet als universele aannames.

Het gebruik van servercertificaatprofielen voor apparaatcertificaten. CA/Browser Forum-profielen zijn ontworpen voor TLS. Ze stellen eisen aan de onderwerpnaam, SAN-vereisten en geldigheidsperioden die niet van toepassing zijn op hardware-identiteit. Een IDevID uitgegeven met een CABF-profiel bevat geen id-tcg-kp-identityInit, heeft een korte geldigheidsperiode en wordt afgewezen door SPDM-verificatiesystemen die controleren op TCG OID's.

De CA is niet geconfigureerd voor een geldigheidsduur van 99991231235959Z. Enterprise CA's hanteren een maximale geldigheidsperiode. Als uw hardwareteam een ​​IDevID aanvraagt ​​en de CA deze afwijst omdat de geldigheidsduur de beleidslimieten overschrijdt, krijgt u ofwel een verkeerd geconfigureerd certificaat, ofwel een tijdelijk certificaat met een willekeurig lange datum, maar niet de door de specificaties voorgeschreven waarde.

Het samenvoegen van de CA-hiërarchieën van de fabrikant en de eigenaar. Het creëren van één PKI die zowel IDevID als LDevID vanuit dezelfde root uitgeeft, geeft de hardwareleverancier autoriteit over de operationele identiteit van de implementerende organisatie. Dit doorbreekt het tweefasen-identiteitsmodel zoals gedefinieerd in IEEE 802.1AR-2018, waardoor een single point of failure ontstaat voor beide fasen.

Het niet plannen van ECA-certificering tijdens de productie. Als uw apparaat DICE implementeert, moet de ECA gecertificeerd zijn voordat het apparaat wordt verzonden. Dit betekent dat de intermediaire certificeringsinstantie (CA) van de fabrikant beschikbaar moet zijn en geïntegreerd moet worden in de productieworkflow. Teams die deze vereiste pas ontdekken nadat de productie is gestart, worden geconfronteerd met kostbare herontwerpen van processen of verzenden apparaten zonder een correct gecertificeerde ECA.

Het SPDM-certificaatketenformaat wordt genegeerd. SPDM GET_CERTIFICATE retourneert een keten in een specifiek formaat: totale lengte van 2 bytes → lengte van de root-hash van 2 bytes → hash van het rootcertificaat → samengevoegde DER-certificaten. Als uw PKI standaard DER-ketens uitgeeft en uw SPDM-implementatie deze onjuist verwerkt, zal de CHALLENGE_AUTH-verificatie mislukken.

Er is geen CRL/OCSP-infrastructuur voor hardware-CA's. Het ECA-certificaatprofiel vereist de aanwezigheid van CRLDistributionPoints. De CRL-infrastructuur van hardware-CA's moet zodanig gedimensioneerd zijn dat de intrekkingsfrequentie zeer laag is, maar de validatiefrequentie zeer hoog. Elke SPDM-attestatie valideert de certificaatketen, inclusief CRL/OCSP-controles.

Hoe kan Encryption Consulting u helpen?

Encryption Consulting is gespecialiseerd in PKI-architectuur voor hardwaregebaseerde identiteitsverificatie. Onze samenwerking met hardwareleveranciers en implementerende organisaties omvat de onderwerpen die in dit blog worden besproken: het ontwerpen van CA-hiërarchieën voor fabrikanten, het configureren van hardwarecertificaatprofielen, het implementeren van ECA-provisioning in productieprocessen en het bouwen van de eigenaar-PKI die IDevID koppelt aan de operationele identiteit van de agent.

• PKI-ontwerp voor fabrikanten: Wij ontwerpen CA-hiërarchieën die zijn afgestemd op TCG DICE, IEEE 802.1AR en DMTF SPDM. Dit omvat de planning van offline root CA-ceremonies, de selectie en configuratie van HSM's en de specificaties voor certificaatprofielen die uw CA nodig heeft voor IDevID-, ECA- en attestatiecertificaten.
• Integratie van de productieworkflow: ECA-sleutelcertificering vereist dat de CA van de fabrikant beschikbaar is en geïntegreerd is tijdens het productieproces. Wij ontwerpen en implementeren de PKI-naar-productie-integratie, inclusief HSM-connectiviteit, certificaatgeneratie en -verificatie, waardoor dit operationeel haalbaar wordt.
• SPDM- en DICE-implementatie: Wij overbruggen de kloof tussen hardware-PKI en runtime-attestatie, waardoor de certificaatketen die uw PKI uitgeeft, de SPDM GET_CERTIFICATE- en CHALLENGE_AUTH-validatie doorstaat. Onze Casestudy SPDM van een Fortune 100-bedrijf is een productiereferentie voor dit werk.
• CertSecure Manager Voor agent CLM: Voor de operationele certificaatlevenscycli van de PKI-beheeragent van de eigenaar op grote schaal biedt CertSecure Manager detectie, geautomatiseerde EST-vernieuwing, geautomatiseerde intrekking en een audit trail-infrastructuur.

Conclusie

Hardware-identiteit voor AI-agenten is geen toekomstig probleem. AI-accelerators implementeren DICE al. Enterprise-hardware ondersteunt al SPDM. De certificaten die deze attestaties koppelen aan een bruikbare PKI voldoen al aan de gevestigde X.509- en CMS-standaarden. Wat ontbreekt, is de operationele architectuur die ze verbindt en de organisatorische wil om hardware-gebaseerd vertrouwen als basis te stellen voor de implementatie van AI-agenten.

De resterende vier blogs in deze serie bouwen die architectuur stap voor stap op. Aan het einde heb je een compleet blauwdruk voor een identiteitsstructuur voor AI-agenten, die begint in de chip en eindigt met een ondertekend, controleerbaar register van elke belangrijke actie die je agenten ondernemen.