SPDM-krav för X.509-certifikat

SPDM- certifikat måste vara X.509 version 3 , kodade i ASN.1 DER . PEM överförs inte i SPDM-meddelanden. Validering av certifikatsökväg följer RFC 5280 i sin helhet.

Certifikatkedjan går från rot till löv, dvs. varje rot-CA utfärdar det underordnade CA-certifikatet (sub-CA), och sub-CA utfärdar lövet, vilket innehåller den publika nyckeln som används för SPDM-autentisering. En enhet kan innehålla upp till åtta certifikatkedjeplatser, numrerade 0 till 7. Plats 0 är den primära identitetsplatsen och måste alltid innehålla en giltig DeviceCert- eller AliasCert-kedja. Plats 1 till 7 kan innehålla GenericCert-poster för ytterligare ändamål.

En detalj specifik för SPDM är att kedjan levereras med rotcertifikatets hash prefix till den DER-kodade certifikatkedjan. Begäraren använder denna hash för att verifiera rotcertifikatet oberoende mot dess förtroendelager innan resten av kedjan valideras.

Obligatoriska X.509-fält

För DeviceCert- och AliasCert -certifikat identifierar SPDM följande certifikatfält som obligatoriska

• Grundläggande begränsningar - måste korrekt skilja CA-certifikat från slutgiltiga lövcertifikat på varje nivå i kedjan.
• X.509-version – måste vara v3
• Serienummer – måste finnas och vara unikt inom varje CA
• Signaturalgoritm - identifierar algoritmen som används för att signera certifikatet
• Utgivare - identifierar den CA som signerade den
• Ämne - identifierar certifikatinnehavaren
• Giltighet - inte före och inte efter; se giltighetsavsnittet nedan
• Information om den publika nyckeln för ämnet – den publika nyckeln och dess algoritm
• Nyckelanvändning - måste inkludera digital signatur för autentiseringsbladcertifikat

För GenericCert-poster i slot 1 till 7 ställer SPDM färre krav. Grundläggande begränsningar, version, serienummer och ämnesinformation om publik nyckel är fortfarande obligatoriska, medan andra fält är valfria ur SPDM-perspektivet. RFC 5280 och dina egna organisationspolicyer kan fortfarande ställa strängare krav på GenericCert.

Grundläggande begränsningar

Grundläggande begränsningar måste korrekt märka varje certifikat i kedjan. Att göra fel är en av de vanligaste orsakerna till att SPDM-kedjevalidering misslyckas.

• Normalt SPDM-bladcertifikat: CA = FALSKDetta är det slutgiltiga entitetscertifikat som används direkt för autentisering.
• Rot CA: CA = SANT.
• Intermediär CA: CA = SANT.
• Enhetscertifikat-CA i AliasCert-modellen: CA = TRUE. Detta är enhetens CA. Den måste också ha en lämplig pathLengthConstraint för att begränsa hur många ytterligare CA certifikat kan kedjas under den.

Nyckelanvändning

För ett SPDM-autentiseringscertifikat måste nyckelanvändningen vara inställd på digitalSignature . Enheten signerar SPDM-utmaningen och sessionstranskriptet med sin privata nyckel, så det är digitalSignature som auktoriserar den åtgärden.

CA-certifikat i kedjan måste bära keyCertSign och, där så är lämpligt, cRLSign , i enlighet med deras roll enligt RFC 5280. En mellanliggande CA som saknar keyCertSign kommer att misslyckas med sökvägsvalidering.

Bäranordningsidentitet i ämnesalternativet

SPDM rekommenderar att man använder fältet otherName i tillägget Subject Alternative Name för att överföra strukturerad enhetsinformation. Det DMTF-definierade formatet representerar enheten som:

• OID: 1.3.6.1.4.1.412.274.1 (DMTF-enhetsinformation)
• Värde: Tillverkare: Produkt: Serienummer
• Exempel: ACME Corp: GPU-X100: SN123456789

Denna bindning är meningsfull eftersom den kopplar den kryptografiska nyckeln inte bara till ett generiskt ämnesnamn utan till en specifik hårdvarutillverkare, produktlinje och serienummer . När en AI-orkestrator eller en BMC hämtar certifikatkedjan kan den verifiera att enheten den kommunicerar med är den specifika fysiska enhet den har registrerad, inte bara någon enhet från rätt tillverkare.

Certifikatets giltighetstid

Plats 0 är den primära platsen för enhetsidentitet och dess giltighetspolicy skiljer sig från de andra platserna.

För en långlivad, oföränderlig Slot 0-identitet, ett tillverkningsinstallerat certifikat som förväntas bestå under enhetens hela livslängd, diskuterar specifikationen användningen av 99991231235959Z som notAfter-värde. Detta signalerar inget definierat utgångsdatum . De flesta hårdvaruenheter har ingen tillförlitlig realtidsklocka, och identiteten kan behöva överleva 10, 15 eller 20 års driftsättning. notBefore sätts vanligtvis till certifikatets skapande- eller tillverkningsdatum.

Platserna 1 till 7 kan innehålla certifikat med konventionella utgångsdatum. Detta ger PKI- team en hanterbar operativ livscykel för föränderliga och operativa autentiseringsuppgifter: den permanenta hårdvaruidentiteten i plats 0 förblir stabil, medan certifikat med kortare livslängd i andra platser kan förnyas, ersättas och återkallas med standardverktyg och tidslinjer.

SPDM DMTF OID:er

SPDM definierar sex OID: er i DMTF-namnrymden. Din CA måste vara konfigurerad för att utfärda certifikat med dessa OID:er där så är lämpligt. Inget av dem finns i standard-OID-uppsättningarna för de flesta kommersiella CA-plattformar; de kräver alla explicit konfiguration.

Utökad nyckelanvändnings-OID:er

SPDM definierar två EKU OID:er för autentisering. Dessa är valfria i SPDM-basprofilen men rekommenderas starkt för alla distributioner där du vill se till att certifikat uttryckligen är auktoriserade för SPDM-användning.

• Svarsautentisering: 1.3.6.1.4.1.412.274.3, placerad i bladcertifikatet för en hårdvaruenhet som fungerar som en SPDM-responder. En GPU, NPU, DPU eller NIC som presenterar denna EKU deklarerar att dess certifikat är auktoriserat specifikt för SPDM-responderautentisering.
• Begärarens autentisering: 1.3.6.1.4.1.412.274.4, placerad i certifikatet som presenteras av en SPDM-begärare under ömsesidig autentisering. En enhet som deltar i ömsesidig autentisering kan behöva båda EKU:erna. En enhet som endast fungerar som en svarare behöver endast svararens EKU.

Hårdvaruidentitet och OID:er för muterbara certifikat

Dessa två OID: er kodar en säkerhetsrelevant distinktion som SPDM-begärande och förtroendehanteringssystem kan agera utifrån programmatiskt.

• Hårdvaruidentitet: 1.3.6.1.4.1.412.274.2 markerar certifikatet som representerar den permanenta enhetsidentiteten. I AliasCert-modellen hör detta OID hemma på enhetscertifikatutfärdaren, inte på de föränderliga aliascertifikaten under det. En begärande part som tillämpar en hårdvarubunden policy kan kontrollera detta OID för att bekräfta att det kommunicerar med en permanent identitet installerad av tillverkningsföretaget.
• Föränderligt certifikat: 1.3.6.1.4.1.412.274.5 markerar certifikat som representerar ett föränderligt tillstånd: firmwareversion, konfiguration eller en operativ nyckel som genererats efter tillverkning. Aliascertifikat bär detta OID. Enhetscertifikatets CA och permanenta certifikat i IDevID-stil bör inte.
• SPDM-tilläggsbehållare: 1.3.6.1.4.1.412.274.6, ett containertillägg för ytterligare strukturerad SPDM-specifik data när certifikatet behöver innehålla utöver vad de andra OID:erna representerar.

De tre certifikatmodellerna

Följande är de tre certifikatmodellerna:

DeviceCert-modell

DeviceCert-modellen är det enklaste alternativet. Enhetscertifikatet är lövet. Den privata nyckeln som motsvarar certifikatet finns inuti enheten och används direkt för SPDM-autentisering. Kedjan går från rot-CA ner genom eventuella mellanliggande CA:er till enhetslövet med CA=FALSE.

Använd DeviceCert när enheten har en permanent nyckel som utför autentisering direkt, och du inte behöver separera hårdvaruidentiteten från drifttillståndet. Det är enklare att distribuera och enklare att hantera.

AliasCert-modell och enhetscertifikatutfärdaren

AliasCert-modellen introducerar en enhetsbaserad CA. Företags-PKI:n utfärdar en enhetscertifikat-CA till enheten – ett certifikat med CA=TRUE, hårdvaruidentitetens OID (1.3.6.1.4.1.412.274.2) och en lämplig pathLengthConstraint. Denna enhetscertifikat-CA representerar den permanenta hårdvaruidentiteten som installerades vid tillverkningstillfället.

Enheten använder sedan nyckeln för enhetscertifikatets CA för att signera aliascertifikat lokalt. Aliascertifikat representerar ett föränderligt tillstånd: den aktuella firmwareversionen, enhetens startkonfiguration eller en nyligen genererad operativ nyckel. De har OID för föränderligt certifikat (1.3.6.1.4.1.412.274.5) och har kortare giltighetsperioder. Den faktiska SPDM-autentiseringen använder aliasbladet, inte direkt enhetscertifikatets CA.

Förtroendekedjan flyter fortfarande tillbaka till rot-CA:n: rot-CA:n litar på enhetscertifikat-CA:n, som signerar aliascertifikatet; därför är aliaset länkat till den betrodda hårdvaruidentiteten. Företags-PKI:n hanterar allt ovanför enhetscertifikat-CA:n. Enheten hanterar aliaslagret under det.

Varför AliasCert-modellen är viktig: Den separerar två identiteter med väldigt olika livscykler. Den permanenta hårdvaruidentiteten måste vara extremt stabil, den representerar den fysiska enheten och bör inte ändras om inte hårdvaran ändras. Den operativa identiteten måste vara flexibel, den bör återspegla den aktuella firmware-statusen och den bör kunna roteras när firmwareuppdateringar eller säkerhetsstatus ändras. DeviceCert slår samman dessa två identiteter till en. AliasCert separerar dem tydligt.

Obs! Enhetscertifikatutfärdaren får inte behandlas som en allmän företagsutfärdande certifikatutfärdare. Den är begränsad till den specifika enheten. Använd pathLengthConstraint och, där så är lämpligt, namnbegränsningar för att begränsa dess behörighet till nycklar endast på den enheten.

GenericCert-modellen

GenericCert är för slot 1 till 7 när enheten stöder flera asymmetriska nyckelpar och behöver certifikat för separata ändamål. Slot 0 måste alltid använda DeviceCert eller AliasCert. GenericCert har färre identitetsspecifika krav från SPDM men måste fortfarande uppfylla RFC 5280 och dina organisationspolicyer.

Anpassa din företags-PKI till SPDM

SPDM tillhandahåller körtidsmekanismen för att bevisa att "Denna enhet innehar den privata nyckeln som är associerad med ett certifikat som är betrott av min plattform" . PKI utgör grunden för att bestämma faktorer som vem som utfärdade den identiteten, vilken hårdvara den representerar, vad den är behörig att göra, hur länge den är betrodd och hur förtroendet tas bort.

Bygg en dedikerad SPDM CA-hierarki

Håll utfärdandet av SPDM-enhetscertifikat separat från din allmänna TLS- och användar-CA-hierarki. En dedikerad SPDM-enhetsutfärdande CA under en offline SPDM-rot-CA ger dig bättre kontroll över enhetsprofiler, tillverkningsregistrering och distribution av förtroendeankare. För leveranskedjemiljöer kan separata utfärdandenivåer eller separata certifikatplatser mappas till tillverkare, plattformsintegratörer och företagskunder individuellt.

Definiera certifikatprofiler för varje SPDM-certifikattyp

En profil räcker inte. Definiera en separat profil för varje certifikattyp som ska visas i en SPDM-kedja:

• SPDM-enhetsautentiseringsblad: CA=FALSE, digitalsignatur, Responder EKU (1.3.6.1.4.1.412.274.3), 99991231235959Z giltighet för kortplats 0
• SPDM-enhetscertifikat CA: CA=TRUE, keyCertSign, Hardware Identity OID (1.3.6.1.4.1.412.274.2), pathLengthConstraint för att begränsa aliaskedjans djup
• SPDM Alias ​​Leaf: CA=FALSK, digital signatur, svars-EKU, föränderligt certifikat-OID (1.3.6.1.4.1.412.274.5), kortare giltighetsperiod
• SPDM-begärarens autentisering: Begärande EKU (1.3.6.1.4.1.412.274.4) för ömsesidiga autentiseringsscenarier

Skydda enhetens privata nycklar korrekt

Generera enhetsnycklar inuti en hårdvarubaserad rot av förtroende, TPM, säkert element eller skyddad enhetsfirmware, till exempel Hardware Security Module (HSM) . Markera den privata nyckeln som icke-exporterbar. Tillhandahåll ett unikt nyckelpar för varje fysisk enhet, delade nycklar över en produktionsbatch undergräver autentiseringsmodellen helt. Skydda rot- och utfärdande CA-nycklar med företags-HSM:er.

Integrera certifikatutfärdande med tillverkning

Initial certifikatprovisionering sker innan SPDM körs, så det kräver en out-of-band-registreringsmekanism: EST, SCEP, ett anpassat REST API eller ett kontrollerat gränssnitt för batchtillverkning. SPDM v1.3.0 lägger till GET_CSR och SET_CERTIFICATE för provisionering inom band efter distribution, men det initiala Slot 0-certifikatet måste provisioneras under tillverkningen innan enheten levereras.

En typisk tillverkningssekvens: enheten genererar sitt nyckelpar internt, tillverkningssystemet läser den publika nyckeln och enhetsidentifierarna, en CSR skapas, PKI validerar tillverkaren och serienumret, ett certifikat utfärdas, kedjan skrivs till SPDM-platsen och enheten testas med en live SPDM-utmaning för att bekräfta att platsen är korrekt provisionerad.

Distribuera förtroendeankare till begäranden

Begäraren behöver rot-CA-certifikatet eller dess hash innan den kan lita på någon svarare. Förtroendedistributionspolicyn måste svara på: vilka tillverkarrötter som är betrodda i den här miljön, hur komprometterade leverantörsrötter tas bort och hur förtroende hanteras när en enhet överförs till en annan organisation. Utan kontrollerad hantering av förtroendeankare kan ett tekniskt giltigt certifikat fortfarande vara obehörigt för den miljö det presenteras i.

Definiera livscykel- och återkallningspolicy

För AliasCert-distributioner, en praktisk metod: håll enhetscertifikatutfärdaren långlivad och väl skyddad, utfärda aliascertifikat med kortare livslängd med konventionella förnyelsecykler, generera aliascertifikat efter firmwareuppdateringar och ha en tydlig process för att neka komprometterade hårdvaruserienummer genom out-of-band-förtroendeuppdateringar eller neka-listor.

Hur krypteringskonsulting kan hjälpa

Encryption Consulting stöder SPDM PKI som en heltäckande PKI-implementering och PKIaaS-tjänst.

PKIaaS för SPDM . EC:s PKI as a Service-erbjudande tillhandahåller tillverkarens CA-hierarki konfigurerad för SPDM-efterlevnad: alla DMTF OID:er registrerade och mallade, dedikerade SPDM-certifikatprofiler för DeviceCert- och AliasCert-kedjor, pathLengthConstraint- och namnbegränsningsdesign för enhetscertifikat-CA och hantering av SPDM-kedjeformat för GET_CERTIFICATE-leverans.

PKI-design och implementering : EC utformar den dedikerade SPDM CA-hierarkin separat från era allmänna TLS- och användar-CA:er, väljer rätt certifikatmodell för varje enhetstyp, bygger alla certifikatmallar med korrekta krav på fältnivå och dokumenterar CP/CPS -avsnitten som täcker utfärdande av enhetsidentitet.

EC utformar integrationen mellan tillverkningssystemet, enhetsprovisioneringsgatewayen, PKIaaS-utfärdande CA och SPDM-certifikatplatsen. Initial provisionering via EST, SCEP, REST API eller batchtillverkningsgränssnitt beroende på vad som passar produktionsmiljön. Vår Fortune 100 SPDM-fallstudie är en produktionsreferens för detta arbete.

PKI-bedömning : Om du redan har en enhetsidentitetsarkitektur kan EC bedöma den mot DSP0274 X.509-krav: korrekta grundläggande begränsningar på varje kedjenivå, nödvändiga OID:er, SAN otherName-struktur, giltighetspolicy, nyckelskydd och distribution av förtroendeankare – och identifiera luckorna innan de blir produktionsproblem.

Slutsats

X.509-kraven som SPDM ställer på certifikat är specifika och kompletterar standard PKI-profiler. DMTF OID:erna måste registreras och konfigureras i din CA. Certifikatmodellerna måste väljas medvetet. Giltighetsperioderna måste återspegla enhetens livslängd snarare än programvaruförnyelsecykler. Och distributionen av förtroendeankare måste täcka hela leveranskedjan från tillverkare via integratör till slutoperatör.