SPDM- certificaten moeten voldoen aan de X.509-versie 3-standaard en gecodeerd zijn in ASN.1 DER . PEM wordt niet verzonden in SPDM-berichten. De validatie van het certificaatpad volgt volledig RFC 5280 .

De certificaatketen loopt van root naar leaf, dat wil zeggen dat elke root-CA het certificaat van de sub-CA (Sub CA) uitgeeft, en de Sub CA geeft het leaf-certificaat uit, dat de publieke sleutel bevat die wordt gebruikt voor SPDM-authenticatie. Een apparaat kan maximaal acht certificaatketensleuven bevatten, genummerd van 0 tot en met 7. Sleuf 0 is de primaire identiteitssleuf en moet altijd een geldige DeviceCert- of AliasCert-keten bevatten. Sleuven 1 tot en met 7 kunnen GenericCert-vermeldingen bevatten voor aanvullende doeleinden.

Een specifiek detail van SPDM is dat de certificaatketen wordt geleverd met de hash van het rootcertificaat als voorvoegsel in de DER-gecodeerde certificaatketen. De aanvrager gebruikt deze hash om het rootcertificaat onafhankelijk te verifiëren aan de hand van zijn vertrouwensarchief, alvorens de rest van de keten te valideren.

Verplichte X.509-velden

Voor DeviceCert- en AliasCert- certificaten identificeert SPDM de volgende certificaatvelden als verplicht.

Basisvereisten: CA-certificaten moeten op elk niveau van de keten correct worden onderscheiden van eindcertificaten.
X.509-versie - moet versie 3 zijn.
Serienummer - moet aanwezig en uniek zijn binnen elke CA.
Handtekeningalgoritme - identificeert het algoritme dat is gebruikt om het certificaat te ondertekenen.
Uitgever - identificeert de CA die het document heeft ondertekend.
Onderwerp - identificeert de certificaathouder
Geldigheid - notBefore en notAfter; zie het gedeelte over geldigheid hieronder.
Onderwerp: Informatie over de publieke sleutel - de publieke sleutel en het bijbehorende algoritme
Belangrijk gebruik - moet een digitale handtekening bevatten voor authenticatie van bladcertificaten.

Voor GenericCert-vermeldingen in slots 1 tot en met 7 stelt SPDM minder eisen. Basisbeperkingen, versie, serienummer en informatie over de openbare sleutel van het onderwerp blijven verplicht, terwijl andere velden vanuit SPDM-perspectief optioneel zijn. RFC 5280 en uw eigen organisatiebeleid kunnen echter nog steeds strengere eisen stellen aan GenericCert.

Basisbeperkingen

De basisbeperkingen moeten elk certificaat in de keten correct labelen. Een fout hierin is een van de meest voorkomende oorzaken van mislukte SPDM-ketenvalidatie.

Normaal SPDM-bladcertificaat: CA = FALSEDit is het eindgebruikerscertificaat dat direct voor authenticatie wordt gebruikt.
Root-CA: CA = WAAR.
Tussenliggende CA: CA = WAAR.
Apparaatcertificaat-CA in het AliasCert-model: CA = TRUE. Dit is de CA op het apparaat zelf. Deze moet ook een geschikte pathLengthConstraint bevatten om te beperken hoeveel extra paden er nog kunnen worden gebruikt. CA Certificaten kunnen eronder worden gekoppeld.

Sleutelgebruik

Voor een SPDM-authenticatie-bladcertificaat moet het sleutelgebruik worden ingesteld op digitalSignature . Het apparaat ondertekent de SPDM-uitdaging en het sessietranscript met zijn privésleutel, dus digitalSignature is wat die bewerking autoriseert.

CA-certificaten in de keten moeten keyCertSign en, waar van toepassing, cRLSign bevatten , conform hun rol zoals beschreven in RFC 5280. Een tussenliggende CA zonder keyCertSign zal de padvalidatie niet doorstaan.

Het apparaatidentificatienummer wordt in de alternatieve naam van het onderwerp vermeld.

SPDM raadt aan om het veld otherName in de Subject Alternative Name- extensie te gebruiken voor het overbrengen van gestructureerde apparaatinformatie. Het door DMTF gedefinieerde formaat geeft het apparaat als volgt weer:

OID: 1.3.6.1.4.1.412.274.1 (DMTF-apparaatinformatie)
Waarde: Fabrikant: Product: Serienummer
Voorbeeld: ACME Corp : GPU-X100 : SN123456789

Deze koppeling is belangrijk omdat de cryptografische sleutel niet alleen aan een generieke onderwerpnaam wordt gekoppeld, maar aan een specifieke hardwarefabrikant, productlijn en serienummer . Wanneer een AI-orkestrator of een BMC de certificaatketen opvraagt , kan deze verifiëren dat het apparaat waarmee het communiceert, daadwerkelijk het fysieke apparaat is dat in de database is geregistreerd, en niet zomaar een apparaat van de juiste fabrikant.

Geldigheid van het certificaat

Slot 0 is het primaire apparaatidentificatieslot en het geldigheidsbeleid ervan verschilt van dat van de andere slots.

Voor een duurzame, onveranderlijke Slot 0-identiteit, een door de fabrikant geïnstalleerd certificaat dat naar verwachting de gehele operationele levensduur van het apparaat meegaat, bespreekt de specificatie het gebruik van 99991231235959Z als de notAfter-waarde. Dit geeft aan dat er geen gedefinieerde vervaldatum is. De meeste hardwareapparaten hebben geen betrouwbare realtimeklok en de identiteit moet mogelijk 10, 15 of 20 jaar meegaan na de implementatie. notBefore wordt doorgaans ingesteld op de aanmaak- of fabricagedatum van het certificaat.

Slots 1 tot en met 7 kunnen certificaten met conventionele vervaldatums bevatten. Dit biedt PKI- teams een beheersbare operationele levenscyclus voor veranderlijke en operationele referenties: de permanente hardware-identiteit in Slot 0 blijft stabiel, terwijl certificaten met een kortere geldigheidsduur in andere slots kunnen worden vernieuwd, vervangen en ingetrokken met standaardtools en binnen standaardtermijnen.

SPDM DMTF OID's

SPDM definieert zes OID 's in de DMTF-naamruimte. Uw CA moet geconfigureerd zijn om, waar nodig, certificaten met deze OID's uit te geven. Geen van deze OID's is opgenomen in de standaard OID-sets van de meeste commerciële CA-platformen; ze vereisen allemaal expliciete configuratie.

Uitgebreide sleutelgebruik OID's

SPDM definieert twee EKU OID's voor authenticatie. Deze zijn optioneel in het basis-SPDM-profiel, maar worden sterk aanbevolen voor elke implementatie waarbij u wilt afdwingen dat certificaten expliciet geautoriseerd zijn voor gebruik door SPDM.

Authenticatie van de respondent: 1.3.6.1.4.1.412.274.3, opgenomen in het leaf-certificaat van een hardwareapparaat dat fungeert als SPDM Responder. Een GPU, NPU, DPU of NIC die deze EKU presenteert, verklaart dat het certificaat specifiek geautoriseerd is voor SPDM Responder-authenticatie.
Authenticatie van de aanvrager: 1.3.6.1.4.1.412.274.4, opgenomen in het certificaat dat door een SPDM-aanvrager wordt gepresenteerd tijdens wederzijdse authenticatie. Een apparaat dat deelneemt aan wederzijdse authenticatie heeft mogelijk beide EKU's nodig. Een apparaat dat alleen als responder fungeert, heeft alleen de responder-EKU nodig.

Hardware-identiteit en wijzigbare certificaat-OID's

Deze twee OID's coderen een beveiligingsrelevant onderscheid waarop SPDM-aanvragers en vertrouwensbeheersystemen programmatisch kunnen reageren.

Hardware-identiteit: 1.3.6.1.4.1.412.274.2 markeert het certificaat dat de permanente apparaatidentiteit vertegenwoordigt. In het AliasCert-model hoort deze OID thuis op de CA van het apparaatcertificaat, niet op de veranderlijke aliascertificaten daaronder. Een aanvrager die een hardwaregebonden beleid afdwingt, kan deze OID controleren om te bevestigen dat hij communiceert met een door de fabrikant geïnstalleerde permanente identiteit.
Veranderlijk certificaat: 1.3.6.1.4.1.412.274.5 markeert certificaten die een veranderlijke status vertegenwoordigen: firmwareversie, configuratie of een operationele sleutel die na de fabricage is gegenereerd. Aliascertificaten dragen deze OID. Het apparaatcertificaat CA en permanente certificaten in IDevID-stijl mogen deze niet dragen.
SPDM-extensiecontainer: 1.3.6.1.4.1.412.274.6, een containeruitbreiding voor extra gestructureerde SPDM-specifieke gegevens wanneer het certificaat inhoud moet bevatten die verder gaat dan wat de andere OID's vertegenwoordigen.

De drie certificaatmodellen

Hieronder volgen de drie certificaatmodellen:

ApparaatCert-model

Het DeviceCert-model is de meest eenvoudige optie. Het apparaatcertificaat is het blad. De privésleutel die bij dat certificaat hoort, bevindt zich in het apparaat en wordt direct gebruikt voor SPDM-authenticatie. De certificaatketen loopt van de root-CA via alle tussenliggende CA's naar het blad van het apparaat met CA=FALSE.

Gebruik DeviceCert wanneer het apparaat een permanente sleutel heeft die rechtstreeks authenticatie uitvoert en u de hardware-identiteit niet hoeft te scheiden van de operationele status. Het is eenvoudiger te implementeren en te beheren.

AliasCert-model en de CA voor apparaatcertificaten

Het AliasCert-model introduceert een CA op het apparaat zelf. De PKI van de onderneming geeft een apparaatcertificaat-CA uit aan het apparaat met CA=TRUE, de Hardware Identity OID (1.3.6.1.4.1.412.274.2) en een passende pathLengthConstraint. Dit apparaatcertificaat-CA vertegenwoordigt de permanente hardware-identiteit die tijdens de fabricage is geïnstalleerd.

Het apparaat gebruikt vervolgens de CA-sleutel van het apparaatcertificaat om lokaal aliascertificaten te ondertekenen. Aliascertificaten vertegenwoordigen een veranderlijke status: de huidige firmwareversie, de opstartconfiguratie van het apparaat of een nieuw gegenereerde operationele sleutel. Ze bevatten de OID voor veranderlijke certificaten (1.3.6.1.4.1.412.274.5) en hebben een kortere geldigheidsduur. De daadwerkelijke SPDM-authenticatie maakt gebruik van het aliascertificaat, niet rechtstreeks van de CA van het apparaatcertificaat.

De vertrouwensketen loopt nog steeds terug naar de Root CA: de Root CA vertrouwt de Device Certificate CA, die het aliascertificaat ondertekent; daarom is de alias gekoppeld aan de vertrouwde hardware-identiteit. De enterprise PKI beheert alles boven de Device Certificate CA. Het apparaat beheert de aliaslaag daaronder.

Waarom het AliasCert-model belangrijk is: Het scheidt twee identiteiten met zeer verschillende levenscycli. De permanente hardware-identiteit moet extreem stabiel zijn; deze vertegenwoordigt het fysieke apparaat en mag niet veranderen, tenzij de hardware verandert. De operationele identiteit moet flexibel zijn, de huidige firmwarestatus weerspiegelen en kunnen roteren bij firmware-updates of wijzigingen in de beveiligingsstatus. DeviceCert voegt deze twee identiteiten samen tot één. AliasCert scheidt ze duidelijk van elkaar.

Let op: De CA voor apparaatcertificaten mag niet worden beschouwd als een algemene, bedrijfsbrede CA. De autoriteit ervan is beperkt tot dat specifieke apparaat. Gebruik pathLengthConstraint en, waar nodig, naambeperkingen om de autoriteit te beperken tot sleutels op dat apparaat.

Generiek certificaat model

GenericCert is bedoeld voor slots 1 tot en met 7 wanneer het apparaat meerdere asymmetrische sleutelparen ondersteunt en certificaten nodig heeft voor verschillende doeleinden. Slot 0 moet altijd DeviceCert of AliasCert gebruiken. GenericCert stelt minder identiteitsspecifieke eisen aan SPDM, maar moet nog steeds voldoen aan RFC 5280 en het beleid van uw organisatie.

Uw bedrijfs-PKI afstemmen op SPDM

SPDM biedt het runtime-mechanisme om te bewijzen: "Dit apparaat beschikt over de privésleutel die is gekoppeld aan een certificaat dat door mijn platform wordt vertrouwd" . PKI vormt de basis voor het bepalen van factoren zoals wie die identiteit heeft uitgegeven, welke hardware deze vertegenwoordigt, waarvoor deze is gemachtigd, hoe lang deze wordt vertrouwd en hoe dat vertrouwen wordt ingetrokken.

Bouw een speciale SPDM CA-hiërarchie.

Houd de uitgifte van SPDM-apparaatcertificaten gescheiden van uw algemene TLS- en gebruikers-CA-hiërarchie. Een dedicated SPDM Device Issuing CA onder een offline SPDM Root CA geeft u meer controle over apparaatprofielen, productieregistratie en de distributie van vertrouwensankers. Voor toeleveringsketens kunnen aparte uitgifteniveaus of aparte certificaatslots afzonderlijk worden gekoppeld aan fabrikanten, platformintegrators en zakelijke klanten.

Definieer certificaatprofielen voor elk SPDM-certificaattype.

Eén profiel is niet voldoende. Definieer een apart profiel voor elk certificaattype dat in een SPDM-keten voorkomt:

SPDM-apparaatauthenticatieblad: CA=FALSE, digitale handtekening, Responder EKU (1.3.6.1.4.1.412.274.3), 99991231235959Z geldigheid voor Slot 0
SPDM-apparaatcertificaat CA: CA=TRUE, keyCertSign, Hardware Identity OID (1.3.6.1.4.1.412.274.2), pathLengthConstraint om de diepte van de aliasketen te beperken
SPDM-aliasblad: CA=FALSE, digitale handtekening, Responder EKU, Mutable Certificate OID (1.3.6.1.4.1.412.274.5), kortere geldigheidsperiode
SPDM-aanvragerverificatie: Aanvrager EKU (1.3.6.1.4.1.412.274.4) voor scenario's met wederzijdse authenticatie

Bescherm de privésleutels van apparaten op de juiste manier.

Genereer apparaatsleutels in een hardwarematige Root of Trust, TPM, beveiligd element of beveiligde apparaatfirmware, zoals een Hardware Security Module (HSM) . Markeer de privésleutel als niet-exporteerbaar. Voorzie elk fysiek apparaat van een uniek sleutelpaar; gedeelde sleutels binnen een productiebatch ondermijnen het authenticatiemodel volledig. Bescherm de Root- en Issuing CA-sleutels met HSM's van de onderneming.

Integreer de uitgifte van certificaten met de productie.

De initiële certificaatvoorziening vindt plaats voordat SPDM wordt uitgevoerd, dus hiervoor is een out-of-band inschrijvingsmechanisme nodig: EST, SCEP, een aangepaste REST API of een gecontroleerde batchproductie-interface. SPDM v1.3.0 voegt GET_CSR en SET_CERTIFICATE toe voor in-band voorziening na implementatie, maar het initiële Slot 0-certificaat moet tijdens de productie worden verstrekt voordat het apparaat wordt verzonden.

Een typische productiesequentie: het apparaat genereert intern zijn sleutelpaar, het productiesysteem leest de publieke sleutel en apparaat-ID's, er wordt een CSR aangemaakt, de PKI valideert de fabrikant en het serienummer, er wordt een certificaat uitgegeven, de certificaatketen wordt naar de SPDM-sleuf geschreven en het apparaat wordt getest met een live SPDM-uitdaging om te bevestigen dat de sleuf correct is geconfigureerd.

Verdeel vertrouwensankers onder aanvragers.

De aanvrager heeft het root-CA-certificaat of de hash ervan nodig voordat hij een respondent kan vertrouwen. Het beleid voor vertrouwensverdeling moet antwoord geven op de volgende vragen: welke rootcertificaten van fabrikanten worden in deze omgeving vertrouwd, hoe worden gecompromitteerde rootcertificaten van leveranciers verwijderd en hoe wordt het vertrouwen beheerd wanneer een apparaat naar een andere organisatie wordt overgedragen. Zonder gecontroleerd beheer van vertrouwensankers kan een technisch geldig certificaat nog steeds niet geautoriseerd zijn voor de omgeving waarin het wordt gepresenteerd.

Definieer de levenscyclus en het intrekkingsbeleid.

Voor AliasCert-implementaties is een praktische aanpak als volgt: zorg ervoor dat de CA van het apparaatcertificaat lang geldig en goed beveiligd is, geef aliascertificaten uit met een kortere geldigheidsduur en conventionele vernieuwingscycli, genereer aliascertificaten opnieuw na firmware-updates en hanteer een duidelijk proces voor het weigeren van gecompromitteerde hardware-serienummers via out-of-band updates van de vertrouwensopslag of via blokkeerlijsten.

Hoe Encryption Consulting u kan helpen

Encryption Consulting biedt ondersteuning voor SPDM PKI als een complete PKI-implementatie en PKIaaS-service.

PKIaaS voor SPDM . EC's PKI as a Service-aanbod biedt de voor SPDM-conformiteit geconfigureerde CA-hiërarchie van de fabrikant: alle DMTF OID's geregistreerd en van sjablonen voorzien, specifieke SPDM-certificaatprofielen voor DeviceCert- en AliasCert-ketens, ontwerp van pathLengthConstraint en naambeperking voor Device Certificate CA, en afhandeling van SPDM-ketenformaten voor GET_CERTIFICATE-levering.

PKI-ontwerp en -implementatie : EC ontwerpt de specifieke SPDM CA-hiërarchie los van uw algemene TLS- en gebruikers-CA's, selecteert het juiste certificaatmodel voor elk apparaattype, bouwt alle certificaatsjablonen met de juiste veldvereisten en documenteert de CP/CPS- secties met betrekking tot de uitgifte van apparaatidentiteiten.

EC ontwerpt de integratie tussen het productiesysteem, de gateway voor apparaatprovisionering, de PKIaaS-uitgevende CA en de SPDM-certificaatsleuf. De initiële provisionering vindt plaats via EST, SCEP, REST API of de batchproductie-interface, afhankelijk van wat het beste past bij de productieomgeving. Onze SPDM-case study bij een Fortune 100-bedrijf dient als productiereferentie voor dit werk.

PKI-beoordeling : Als u al een apparaatidentiteitsarchitectuur hebt, kan EC deze beoordelen aan de hand van de DSP0274 X.509-vereisten: correcte basisbeperkingen op elk ketenniveau, aanwezigheid van vereiste OID's, SAN otherName-structuur, geldigheidsbeleid, sleutelbescherming en vertrouwensankerdistributie – en eventuele tekortkomingen identificeren voordat ze problemen in de productieomgeving veroorzaken.

Conclusie

De X.509-vereisten die SPDM stelt aan certificaten zijn specifiek en aanvullend op standaard PKI-profielen. De DMTF OID's moeten geregistreerd en geconfigureerd zijn in uw CA. De certificaatmodellen moeten weloverwogen gekozen worden. De geldigheidsperioden moeten de levensduur van het apparaat weerspiegelen in plaats van de vernieuwingscycli van de software. En de distributie van vertrouwensankers moet de volledige toeleveringsketen bestrijken, van fabrikant via integrator tot eindgebruiker.

SPDM-vereisten voor X.509-certificaat