DICE staat voor Device Identifier Composition Engine . Het is een hardwarematige Root of Trust (RoT) zoals gedefinieerd door de Trusted Computing Group (TCG). Het kernidee is eenvoudig maar krachtig: neem een ​​geheim dat fysiek in de chip is ingebed tijdens de fabricage, combineer dit met een meting van de firmware die op die chip wordt geladen, en leid daaruit een cryptografische sleutel af. Die sleutel is hardwarematig gebonden, iets wat softwarematige sleutels nooit zijn.
De specificatie van de TCG DICE-certificaatprofielen
De TCG DICE Certificate Profiles-specificatie, versie 1.1 (gepubliceerd op 24 april 2025) , is het normatieve document dat definieert hoe DICE-afgeleide sleutels worden weergegeven als X.509-certificaten . Het definieert vier certificaatprofielen en de bijbehorende beleids-OID's. Alles in deze sectie is rechtstreeks overgenomen uit de gepubliceerde specificatie.
Wat de specificatie definieert
Deze specificatie gaat ervan uit dat de lezer bekend is met de TCG-hardwarevereisten voor DICE en de DICE-laagarchitectuurspecificatie. Voortbouwend op deze basis definieert deze specificatie het volgende:
- X.509-certificaat conventies voor DICE-afgeleide sleutelparen (serienummer, geldigheid, naamgeving)
- Beleids-OID's uit de tcg-dice-kp-naamruimte die het doel en de binding van elke sleutel identificeren.
- Vier certificaatprofielen: IDevID, LDevID, ECA en Attestatie
- Vereisten op veldniveau voor elk profiel (Uitgever, Onderwerp, Sleutelgebruik, Uitgebreid sleutelgebruik, Basisbeperkingen, CRLDistributionPoints)
Certificaatconventies
- Serienummer: Certificaatserienummers MOETEN uniek zijn per CA voor elk alias-sleutelcertificaat. Verschillende ingebedde CA's kunnen certificaten uitgeven met dezelfde serienummervelden.
- Levensduur van het certificaat: Apparaten met een beveiligde klok stellen geldigheidsperioden op conventionele wijze in. Apparaten zonder een beveiligde klok, waaronder de meeste AI-accelerators en embedded hardware, stellen de notAfter-waarde in op de GeneralizedTime-waarde van X.509. 99991231235959Z or onbeperkte geldigheidsduurDe waarde van notBefore is ingesteld op een bekende datum in het recente verleden, zoals de TCB-bouwtijd. Deze waarde geeft aan dat er geen gedefinieerde vervaldatum is.
- Onderwerpnaamgeving: Onderwerpnamen MOET identificeer de componentomgeving waar de private key Bevat mogelijk het serienummer van het apparaat, firmware-identificaties of DICE-laagcoördinaten. Onderwerpnamen MOETEN worden geformatteerd voor vergelijkingen met byte-arrays. Attestatieverificateurs wordt aangeraden geen attestatieclaims te verkrijgen uit de velden Onderwerp of Alternatieve Onderwerpnaam.
- Naamgeving van de emittent: De naam van de uitgever op laag n+1 MOET overeenkomen met de Onderwerp van de afgifte van certificaat op laag n. Dit is de ketenregel waarmee de DICE-identiteit kan worden getraceerd vanaf de siliciumchip tot aan elke firmwarelaag.
Beleids-OID's: de tcg-dice-kp-naamruimte
De specificatie definieert zeven beleids-OID's in de tcg-dice-kp-naamruimte. Deze worden in de Extended Key Usage-extensie van DICE -certificaten geplaatst om aan te geven waarvoor de sleutel is geautoriseerd en hoe deze is gekoppeld. De OID-reeks is afkomstig uit de specificatie (bijlage 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-naam | OID-waarde | Doel en bindende regel |
|---|---|---|
| tcg-dice-kp-identityInit | identiteit-init(6) | IDevID. Initiële apparaatidentificatie. De sleutel MOET tijdens de fabricage worden gekoppeld. De sleutel MOET door de fabrikant worden gecertificeerd. |
| tcg-dice-kp-identityLoc | identiteit-loc(7) | LDevID. Lokale apparaatidentificatie. De sleutel MOET na de fabricage worden gekoppeld. De sleutel MOET worden gecertificeerd door een lokale uitgever. |
| tcg-dice-kp-attestInit | attest-init(8) | Initiële attestatie. Attestatiesleutel voor het ondertekenen van apparaatbewijs. De sleutel MOET tijdens de fabricage worden gebonden en door de fabrikant worden gecertificeerd. |
| tcg-dice-kp-attestLoc | attest-loc(9) | Lokale certificering. Certificeringssleutel, bindend na productie. MOET gecertificeerd worden door de lokale uitgever. |
| tcg-dice-kp-assertInit | assert-init(10) | Initiële bewering. Sleutel voor het ondertekenen van referentiemetingen met betrekking tot het apparaat. Productiegebonden. |
| tcg-dice-kp-assertLoc | assert-loc(11) | Lokale verklaring. Sleutel voor het ondertekenen van referentiemetingen. Na de productie. MOET gecertificeerd worden door de lokale instantie. |
| tcg-dice-kp-eca | eca(12) | Ingebouwde CA. Autoriseert de uitgifte van certificaten voor sleutels op het huidige apparaat. De ondertekeningssleutel van de uitgever MOET gecertificeerd zijn door de fabrikant of een lokale uitgever. |
De vier certificaatprofielen
De specificatie definieert vier certificaatprofielen . Elk profiel heeft een tabel met vereisten op veldniveau (Tabel 14 in de specificatie). Hieronder volgt een beknopte samenvatting van de X.509-certificaatmetadata die voor elk certificaatprofiel vereist zijn.
IDevID: Initiële apparaat-ID
Bron: TCG DICE Certificate Profiles v1.1, Tabel 1
De IDevID is het geboortecertificaat of certificaat van het apparaat. Het wordt uitgegeven tijdens de fabricage en kan niet opnieuw worden uitgegeven omdat de sleutel hardwarematig is gekoppeld.
| Veld | eis |
|---|---|
| Emittent | MUST Identificeer of koppel aan de fabrikant van het apparaat of de entiteit in de toeleveringsketen. Als de uitgever een ingebedde CA is, de ECA-uitgever. MUST De certificaatketen loopt door tot het CA-certificaat van de fabrikant. Daarom MOET de certificaatketen gevalideerd worden. |
| Onderwerp | Het maakt doorgaans gebruik van Relative Distinguished Names (RDN's) zoals Common Name (CN), Organization (O) of Organizational Unit (OU) om de TCB-klasse of -instantie aan te duiden. Vaak worden unieke hardware-identificaties (zoals een Unique Device ID of UEID) ingebed als extensies of in de SAN om de apparaatinstantie uniek te identificeren. Let op: de TCB moet worden geïdentificeerd. (Trusted Computing Base) De eigenaar van de privésleutel IDevID. Kan een klasse-identificatiecode zijn (meerdere apparaatinstanties met dezelfde naam). |
| Onderwerp Publieke sleutel | Bevat de publieke sleutel en de algoritme-identificatie. De sleutel MOET worden beschermd door een onveranderlijke TCB-laag, of een TCB-laag die alleen door de uitgever kan worden gewijzigd. De privésleutel MOET worden beveiligd in een hardwarematige module, zoals een Hardware Security Module (HSM). |
| Sleutelgebruik | Als het onderwerp een ECA is: MOET keyCertSign bevatten, MAG GEEN cRLSign bevatten. Anders: MAG GEEN keyCertSign bevatten. |
| Uitgebreid sleutelgebruik | MOET tcg-dice-kp-identityInit bevatten. MAG id-kp-clientAuth, tcg-dice-kp-eca of tcg-dice-kp-attestInit bevatten. |
| Basisbeperkingen | Als Subject een ECA is: MOET cA:TRUE en pathLengthConstraint bevatten. Anders: MAG GEEN BasicConstraints bevatten. |
LDevID: Lokale apparaat-ID
Bron: TCG DICE Certificate Profiles v1.1, Tabel 2
De LDevID wordt na de fabricage door de apparaateigenaar uitgegeven. Deze LDevID bepaalt de operationele identiteit van het apparaat binnen de omgeving van de eigenaar. Het structurele verschil met de IDevID zit hem in de uitgever (de CA van de eigenaar, niet de CA van de fabrikant) en de beleids-OID (identityLoc, niet identityInit).
| Veld | eis |
|---|---|
| Emittent | De eigenaar-CA moet worden geïdentificeerd of ernaar worden doorverwezen. Als de uitgever een ingebedde CA is, moet de ECA-uitgever naar de eigenaar-CA doorverwijzen. |
| Onderwerp | De TCB die de LDevID-privésleutel bezit, moet worden geïdentificeerd. Dit mag een klasse-identificatiecode zijn. |
| Onderwerp Publieke sleutel | Bevat de publieke sleutel en de algoritme-identificatie. De sleutel wordt beschermd door een onveranderlijke TCB-laag of een TCB die alleen door de uitgever kan worden gewijzigd. |
| Sleutelgebruik | Als het onderwerp een ECA is: MOET keyCertSign bevatten, MAG GEEN cRLSign bevatten. Anders: MAG GEEN keyCertSign bevatten. |
| Uitgebreid sleutelgebruik | MOET tcg-dice-kp-identityLoc bevatten. MAG tcg-dice-kp-eca, tcg-dice-kp-attestLoc en/of id-kp-clientAuth bevatten. |
| Basisbeperkingen | Als Subject een ECA is: MOET cA:TRUE en pathLengthConstraint bevatten. Anders: MAG GEEN BasicConstraints bevatten. |
ECA: Ingebouwde certificeringsinstantie
Bron: TCG DICE Certificate Profiles v1.1, Tabel 3 (§5.1.6.3)
De ECA is een certificeringsinstantie (CA) die zich in de firmware van het apparaat bevindt. Deze geeft certificaten uit aan de firmwarelagen erboven. De ECA zelf moet tijdens de productie gecertificeerd worden door de CA van de fabrikant (of de lokale uitgever in het geval van LDevID).
| Veld | eis |
|---|---|
| Emittent | De certificeringsinstantie (CA) of ingebedde CA die dit certificaat uitgeeft, moet worden geïdentificeerd. De uitgever moet ervoor zorgen dat het privégedeelte van de publieke sleutel van het onderwerp wordt beschermd door een TCB. Als de uitgever een ECA is, moet de TCB-instantie worden geïdentificeerd. |
| Onderwerp | De onderwerpnaam kan een klasse-identificatieDit geeft aan dat meerdere apparaatinstanties dezelfde naam kunnen delen. De TCB met ECA-functionaliteit MOET worden geïdentificeerd. |
| Onderwerp Publieke sleutel | MOET de huidige openbare sleutel en algoritme-identificatiecode van de TCB Layer ECA bevatten. |
| Sleutelgebruik | Moet keyCertSign bevatten. Mag geen cRLSign bevatten. Mag andere Key Usage-attributen bevatten. |
| Uitgebreid sleutelgebruik | MOET tcg-dice-kp-eca bevatten. MAG tcg-dice-kp-attestInit, tcg-dice-kp-attestLoc, tcg-dice-kp-identityInit of tcg-dice-kp-identityLoc bevatten. |
| Basisbeperkingen | MOET cA:TRUE en pathLengthConstraint bevatten, indien van toepassing. |
| CRLDistributionPoints | De extensie MOET aanwezig zijn. |
Attestatiecertificaat
Bron: TCG DICE Certificate Profiles v1.1, Tabel 4
Attestatiecertificaten machtigen een sleutel om bewijsmateriaal te ondertekenen met betrekking tot een apparaat, firmware-hash, hardwareconfiguratie, productnaam of meetstatus. Deze certificaten worden uitgegeven door een ECA of een externe CA.
| Veld | eis |
|---|---|
| Emittent | MOET de naam bevatten van de ingebedde CA of externe CA die het certificaat uitgeeft. Als de uitgever een ECA is, MOET het TCB-exemplaar worden geïdentificeerd. |
| Onderwerp | U MOET een TCB-klasse of -instantie identificeren. |
| Onderwerp Publieke sleutel | MOET een actuele TCB-attestatie publieke sleutel en algoritme-identificatie bevatten. |
| Sleutelgebruik | Als het onderwerp een ECA is: MOET keyCertSign bevatten, MAG GEEN cRLSign bevatten. Anders: MAG GEEN keyCertSign bevatten. |
| Uitgebreid sleutelgebruik | MOET ofwel tcg-dice-kp-attestInit ofwel tcg-dice-kp-attestLoc bevatten. MAG id-kp-clientAuth en andere relevante waarden bevatten. |
| Basisbeperkingen | Als Subject een ECA is: MOET cA:TRUE en pathLengthConstraint bevatten. Anders: MAG GEEN BasicConstraints bevatten. |
De rol van DICE in hardware-identificatie
Nu de specificaties duidelijk zijn, rijst de grotere vraag waarom DICE relevant is voor hardware-identificatie en welke rol het speelt in de gelaagde beveiligingsstructuur voor moderne AI-hardware.
DICE als hardware-root of trust
Elk beveiligingssysteem heeft een uitgangspunt nodig dat op basis van aannames als betrouwbaar wordt beschouwd. Voor softwaresystemen is dit doorgaans een HSM , een TPM of een beveiligde enclave. Voor hardware-identificatie is DICE dat uitgangspunt. De UDS is de basisaanname; het is de enige waarde die als betrouwbaar wordt beschouwd omdat deze door de fabrikant tijdens een gecontroleerd proces is ingebed en niet door software kan worden gelezen of gekopieerd.
Elke identiteitsclaim die is afgeleid van DICE is slechts zo sterk als de UDS. Als de UDS goed beveiligd is, is de hele DICE-keten erboven betrouwbaar. Dit maakt DICE tot een echte hardwarematige vertrouwensbasis: het verankert identiteit in de natuurkunde, niet in beleid.
DICE creëert een firmware-bewuste identiteit.
Standaard X.509 -certificaten koppelen een sleutel aan een naam. DICE-certificaten koppelen een sleutel aan een specifiek hardwareapparaat met een specifieke firmwarestack. De CDI-afleiding zorgt ervoor dat:
- Twee apparaten met verschillende hardware (verschillende UDS-waarden) produceren verschillende sleutels, zelfs met identieke firmware.
- Hetzelfde apparaat met aangepaste firmware produceert een andere sleutel.
- Een certificaat uitgegeven voor CDI_n is verifieerbaar en vertegenwoordigt zowel de hardware als de exacte TCB die op het moment van uitgifte in gebruik was.
Voor AI-hardware, zoals GPU's, NPU's, DPU's en inferentieversnellers, is deze kennis van de firmware cruciaal. Aanvallen in de toeleveringsketen waarbij de firmware van de versneller vóór de implementatie wordt gewijzigd, vormen een reële bedreiging. DICE maakt dergelijke wijzigingen detecteerbaar: het apparaat genereert na de wijziging een andere DICE-identiteit, en dat verschil is cryptografisch aantoonbaar.
DICE in het IEEE 802.1AR-raamwerk
De IDevID- en LDevID-referentietypen zijn gedefinieerd in IEEE 802.1AR-2018 (Secure Device Identity). DICE biedt het sleutelafleidingsmechanisme dat deze referenties genereert met hardwarematige beveiliging. Wanneer een DICE-compatibel apparaat zijn IDevID presenteert aan een 802.1AR-compatibele netwerkinfrastructuur (bedrijfsswitches, toegangscontrolesystemen, zero-trustplatforms), ontvangt de infrastructuur een referentie die aantoonbaar is gekoppeld aan de PKI van de fabrikant en aan de specifieke geleverde hardware.
Zonder DICE is een IDevID een softwarematige sleutel in een certificaat. Met DICE is het een hardwarematige sleutel in een certificaat, met een afleidingsketen die terug te voeren is op een geheim op siliciumniveau dat tijdens de fabricage is gecertificeerd. Het 802.1AR-framework blijft in beide gevallen hetzelfde; DICE is wat de authenticatie zijn hardwarematige beveiligingsniveau geeft.
DICE als PKI-anker voor agentische AI
Bij AI-implementaties met een agent heeft een AI-agent die op een hardwareversneller draait een identiteit nodig die aan de volgende criteria voldoet:
- Uniek voor de specifieke hardware waarop het draait.
- Dit kan door een orchestrator worden geverifieerd voordat de hardware aan een workload wordt toevertrouwd.
- Dit is terug te voeren op de garantie van de fabrikant dat de hardware authentiek is.
- Gevoelig voor firmwarewijzigingen, waardoor gemanipuleerde hardware een andere identiteit produceert.
DICE biedt ze alle vier. Het IDevID-certificaat, geworteld in de CA van de fabrikant en afgeleid van de CDI-keten, met de OID tcg-dice-kp-identityInit, is de referentie die de AI-orchestrator via SPDM-attestatie controleert voordat een gevoelige workload wordt verzonden. De DICE-keten vormt de basis; SPDM is het runtimeprotocol dat deze gebruikt; het operationele certificaat van de agent is daarop gebouwd.
Verwijder DICE en de keten van hardwarevertrouwen wordt bij de eerste schakel verbroken. Het certificaat van de agent is dan een softwareclaim, geen hardwareclaim. Softwareclaims kunnen worden vervalst. Hardware-gebaseerde claims, mits correct geïmplementeerd, kunnen dat niet.
DICE en de certificaatlevenscyclus
Een aspect van DICE-identiteit dat vaak over het hoofd wordt gezien: de levenscyclus van het certificaat is gekoppeld aan de levenscyclus van de firmware, niet aan de kalender. In de praktijk zullen apparaten die DICE implementeren ofwel sleutels opnieuw certificeren bij elke opstart (omdat sleutelparen bij elke opstart opnieuw worden gegenereerd) ofwel sleutels behouden wanneer de firmware ongewijzigd blijft.
Dit betekent dat het CLM- model (Certificate Lifecycle Management) voor DICE-certificaten verschilt van het model voor TLS-certificaten:
- Een firmware-update activeert een nieuwe CDI-afleiding, een nieuw sleutelpaar en een nieuw certificaatverzoek.
- Een apparaat dat opstart met ongewijzigde firmware kan hetzelfde certificaat tonen dat bij de fabricage is uitgegeven.
- De vervaldatum van certificaten is minder relevant dan de frequentie van firmware-updates voor het beheren van de actualiteit van DICE-referenties.
Een PKI-infrastructuur die DICE ondersteunt, moet op basis van deze kenmerken worden ontworpen. Statisch, op vervaldatum gebaseerd levenscyclusbeheer, ontworpen voor server- en gebruikerscertificaten, is zonder aanpassingen niet toepasbaar op hardwarecertificaten voor DICE.
Hoe kan Encryption Consulting u helpen?
Het bouwen en beheren van een CA-hiërarchie voor fabrikanten die DICE-certificaatprofielen correct ondersteunt, is voor de meeste hardwareleveranciers geen interne taak. De benodigde CA-infrastructuur, inclusief offline root-CA, geïntegreerde uitgevende CA voor de productie, CRL-publicatie, OCSP- infrastructuur, HSM-beheer en de technische expertise om dit alles te configureren voor DICE-specifieke profielen, is specialistisch werk dat aanzienlijke resources vergt als het volledig vanaf nul wordt opgebouwd.
Dit is precies het gebruiksscenario waarvoor het PKIaaS-aanbod van Encryption Consulting is ontworpen.
Wat PKIaaS voor hardware-identiteit betekent
PKI as a Service (PKIaaS) betekent dat de CA-hiërarchie wordt ontworpen, geïmplementeerd en beheerd door Encryption Consulting namens de hardwareleverancier of implementerende organisatie. De leverancier hoeft geen HSM's aan te schaffen, CA-software te configureren, root key ceremonies te beheren of CRL-infrastructuur te beheren. EC doet dit allemaal. De leverancier integreert met EC's PKIaaS via API's en beheerinterfaces om apparaatcertificaten uit te geven en te beheren.
Voor hardware-identificatie op basis van DICE biedt PKIaaS het volgende:
- DICE-gealigneerde fabrikant-CA-hiërarchie: Een hiërarchie van root-CA's en uitgevende CA's geconfigureerd voor hardwarecertificaatprofielen. Dit omvat de vereiste geldigheidsduur van 40-50 jaar of niet-verlopende geldigheidsduur van de root-CA om op een consistente manier IDevID-certificaten met 99991231235959Z notAfter-datums uit te geven, de TCG DICE-kp OID's die zijn geregistreerd in de OID-database van de CA, en certificaatsjablonen voor elk profieltype: IDevID, LDevID, ECA en Attestation.
- Integratie van productieprocessen: De uitgevende certificeringsinstantie (CA) is geïntegreerd in het productieproces van het apparaat, zodat IDevID-certificaten tijdens de productie worden verstrekt. Voor apparaten die de DICE-laagarchitectuur implementeren, omvat dit ECA-sleutelcertificering, waarbij de CA van de fabrikant de openbare ECA-sleutel certificeert voordat het apparaat wordt verzonden. EC ontwerpt en implementeert de API-integratie voor de productie.
- Hardware-specifieke certificaatprofielconfiguratie: Standaard CA-platformen vereisen configuratiewerk om DICE-compatibele certificaten uit te geven. EC configureert de CA voor: het afhandelen van de 99991231235959Z-validiteit zonder platformafwijzingen te veroorzaken; de verplichte TCG OID's in Extended Key Usage; correct sleutelgebruik voor ECA-certificaten versus niet-ECA-certificaten; de afwezigheid van BasicConstraints op niet-ECA-bladcertificaten; en CRLDistributionPoints op ECA-certificaten zoals vereist door de specificatie.
- CRL- en OCSP-infrastructuur: De hardwarematige CA CRL-infrastructuur is ontworpen voor een lage intrekkingsfrequentie, maar moet wel zeer beschikbaar zijn, omdat elke SPDM-attestatie de certificaatketen valideert. EC beheert de CRL- en OCSP-infrastructuur op het beschikbaarheidsniveau dat vereist is voor hardwarematige implementaties.
- PKI-overbrugging voor eigenaars: Wanneer de IDevID PKI van de hardwareleverancier moet worden verbonden met de LDevID en de PKI voor het operationele certificaat van de agent van de implementerende organisatie, ontwerpt en implementeert EC de brug: de beleidsmatige en technische verbinding tussen door de fabrikant uitgegeven en door de eigenaar uitgegeven referenties in dezelfde DICE-vertrouwensketen.
- CertSecure Manager voor agent CLM: Naarmate apparaten in gebruik worden genomen en de eigenaar van de PKI LDevID- en agent-operationele certificaten uitgeeft, CertSecure Manager Dit beheert de levenscyclus van certificaten: geautomatiseerde verlenging via EST, intrekkingsbeheer, detectie op vlootniveau en auditlogboek. Dit is de operationele laag boven de DICE-hiërarchie die ervoor zorgt dat de PKI zonder handmatige tussenkomst blijft functioneren.
Conclusie
DICE-certificaatprofielen, zoals IDevID, LDevID, ECA en Attestation, zijn geen abstracte specificaties. Ze vormen de technische basis die een hardwareversneller transformeert van een anonieme component naar een verifieerbare, aan de fabrikant gekoppelde identiteit. Elke veldvereiste in de TCG DICE-specificatie bestaat met een reden: om ervoor te zorgen dat wanneer een SPDM-attestatieverificateur een apparaatcertificaatketen valideert, deze er zeker van kan zijn dat de sleutel hardwarematig is gekoppeld, de firmware is gemeten en de keten terug te voeren is op een vertrouwensanker dat niet via software kan worden vervalst.
Voor AI-infrastructuur, waar workloads draaien op hardware die mogelijk tientallen handen in de toeleveringsketen heeft gepasseerd voordat deze wordt ingezet, is dit niveau van cryptografische beveiliging niet optioneel.
Het opzetten en beheren van een DICE-compatibele CA-hiërarchie is veeleisend en specialistisch werk. De root-CA moet een onbeperkte geldigheidsduur hebben. Certificaatsjablonen moeten worden geconfigureerd voor profielen die de meeste CA-platformen niet standaard kunnen uitgeven. CRL- en OCSP-infrastructuur moet beschikbaar zijn bij elke attestatie.
Naarmate het aantal apparaten toeneemt, moet de certificaatlevenscyclus niet alleen de vervaldatum, maar ook firmware-updates bijhouden. De PKIaaS-oplossing van Encryption Consulting neemt die last volledig weg: wij bouwen het, wij beheren het, u beheert uw hardware . Van de offline root-CA en de door de fabrikant uitgevende CA tot de eigenaars-PKI-brug, OCSP-responders en CertSecure Manager voor CLM op vlootniveau, de volledige stack wordt door ons ontworpen, geïmplementeerd en beheerd, zodat uw team zich kan concentreren op het leveren van hardware in plaats van het beheren van een CA.
