TPM-nyckelattestering: Vad det är, hur det fungerar och varför Enterprise PKI behöver det

De flesta PKI-team ( public key infrastructure ) på företag lägger ner avsevärd tid på att bestämma vilka certifikatmallar som ska driftsättas, vilka nyckelstorlekar som ska krävas och vilka registreringsprotokoll som ska stödjas. Mycket färre lägger ner tid på en tystare fråga som ligger bakom alltihop: när ett certifikat väl har utfärdats, hur vet certifikatutfärdaren (CA) egentligen att den privata nyckeln bakom det är där organisationen tror att den finns?

Det vanliga svaret är att det inte finns några direkta bevis. CA utfärdar certifikatet baserat på vem som autentiserade och vilken mall de begärde. Huruvida den privata nyckeln hamnade inlåst i en hårdvarusäkerhetsmodul (HSM), genererad i en kryptoleverantör av programvara eller exporterad till ett USB-minne och tagits hem av en entreprenör är, ur CA:s perspektiv, osynligt. TPM-nyckelbekräftelse (Trusted Platform Module) är den mekanism som täcker den luckan. Det ger CA:n kryptografiska bevis, inte bara ett påstående, att en privat nyckel genererades av en riktig TPM och aldrig har lämnat den.

Den här bloggen tar upp vad TPM-nyckelatestering egentligen är på en teknisk nivå, hur det fungerar i Active Directory Certificate Services (AD CS), de tre tillgängliga förtroendemodellerna och var det passar in i en bredare företagsidentitets- och PKI-strategi.

Vad TPM-nyckelattestering faktiskt bevisar

En TPM är en manipulationssäker mikrokontroller, inbyggd direkt på moderkortet i de flesta moderna datorer, bärbara datorer och servrar, som kan generera kryptografiska nyckelpar internt och säkerställa att den privata nyckeln aldrig lämnar chipet i användbar form. Nycklar som genereras på detta sätt är inte migrerbara och inte exporterbara: inte ens en administratör med fullständig åtkomst till operativsystemet kan extrahera dem.

Utmaningen innan TPM-nyckelatestering existerade var att även om Windows kunde generera nycklar inuti TPM:n, fanns det inget sätt för den utfärdande certifikatutfärdaren att verifiera att detta faktiskt hände. En certifikatbegäran kom fram och såg identisk ut oavsett om den privata nyckeln fanns i TPM:n eller i en programvarubutik. Certifikatutfärdaren hade ingen mekanism för att skilja mellan dem och inget sätt att genomdriva skydd av hårdvarunyckeln vid utfärdandetillfället.

TPM-nyckelattestering löser detta genom att lägga till ett kryptografiskt bevissteg i registreringsflödet. Enheten använder en attesteringsidentitetsnyckel (AIK), en separat TPM-resident nyckel vars privata hälft aldrig heller lämnar chipet, för att signera ett uttalande om certifikatnyckelns egenskaper, vilket bekräftar att den genererades inuti TPM:n och markerades som icke-exporterbar. CA:n tar emot det signerade uttalandet tillsammans med certifikatbegäran och kan oberoende verifiera både AIK:ns legitimitet och nyckelns egenskaper innan den beslutar att utfärda.

Resultatet är en kvalitativt annorlunda typ av försäkring. Det utfärdade certifikatet representerar inte bara autentisering baserad på domänuppgifter. Det representerar hårdvarubundet, icke-exporterbart nyckelskydd, verifierat av CA före utfärdande och registrerat i själva certifikatet via en objektidentifierare (OID) i utfärdandepolicytillägget.

För att förstå varför det beviset är tillförlitligt måste du följa den förtroendekedja det är beroende av.

Hur förtroendekedjan fungerar: EK, AIK och CA

Varje TPM innehåller ett Endorsement Primary Seed: ett hemligt värde som genereras under tillverkningen och som aldrig lämnar chipet. Från detta frö genererar TPM deterministiskt Endorsement Key (EK)-paret på begäran. I TPM 1.2 fabrikskonfigurerades en enda RSA-2048 EK som en permanent nyckel; i TPM 2.0 återskapas EK från fröet efter behov och behöver inte lagras permanent på enheten. Tillverkare tillhandahåller vanligtvis ett EK-certifikat som täcker standard EK:s publika nyckel (EKPub) på fabriken. Den väsentliga egenskapen är densamma oavsett TPM-version: den privata EK-nyckeln är bunden till det specifika chipet och kan aldrig extraheras från det.

AIK genereras oberoende inuti TPM. De två nycklarna är länkade via en TCG-definierad aktiveringsprocess för autentiseringsuppgifter: CA krypterar en hemlig utmaning med hjälp av enhetens offentliga EK-nyckel, som endast den äkta TPM:en kan dekryptera med hjälp av EK:ens privata nyckel. Att lyckas slutföra denna utmaning bevisar att AIK finns i samma TPM som EK, vilket överför förtroende från EK till AIK utan att exponera något privat nyckelmaterial. När enheten utför nyckelattestering för en certifikatbegäran använder den AIK:ens privata nyckel för att signera attesteringsutlåtandet. Eftersom AIK:ens privata nyckel bara kan användas inuti den TPM som genererade den, och eftersom AIK:ens legitimitet har knutits till EK genom aktivering, kan en CA som litar på EK lita på att AIK-signaturen är äkta och att nyckeln som attesteras verkligen är TPM-resident.

CA:s uppgift är att verifiera denna kedja innan certifikatet utfärdas. Den kontrollerar att:

• AIK-signaturen är giltig
• Den attesterade nyckeln har de anspråkade egenskaperna (ej exporterbar, TPM-genererad)
• EK spåras tillbaka till en tillverkare eller enhet som organisationen litar på, beroende på vilken förtroendemodell som används.

När den kedjan är etablerad blir frågan vilken förtroendemodell din AD CS-distribution ska använda.

Tre sätt att etablera TPM-förtroende i AD CS

Microsofts AD CS-implementering stöder tre olika metoder för att etablera förtroende för den attesterande TPM:n. Var och en erbjuder en annan avvägning mellan administrativ ansträngning och säkerhetsnivå. Alla tre infogar ett OID i det utfärdade certifikatet som registrerar vilken metod som godkändes.

Förtroendemetod	Så fungerar det	Administrativ insats	Säkerhetsnivå
Användare / AIK-certifikat	CA accepterar alla giltiga AIK, förtroende baserat enbart på domänuppgifter	Låg: inga enhetslistor krävs	Låg: bevisar att en nyckel finns i någon TPM, inte nödvändigtvis en verifierad sådan
EKCert (Certifikat för godkännandenyckel)	CA validerar enhetens EK-certifikat mot betrodda TPM-tillverkares rot-CA:er som importerats till CA:n	Medium: engångsimport av tillverkarens rot-CA:er	Hög: bevisar att TPM:n kommer från en pålitlig tillverkare
EKPub (Endorsement Key Public Key)	CA validerar EK:n mot en administratörsstyrd lista över specifika, registrerade EKPub-hashar.	Hög: varje enhet måste registreras individuellt	Högsta: bevisar att nyckeln kommer från en specifik, känd enhet

De flesta företag använder EKCert som praktisk standard. Att importera tillverkarnas rot-CA:er är en engångsåtgärd som täcker hela den hanterade flottan utan registreringskostnader per enhet. Observera att inte alla TPM-tillverkare tillhandahåller EK-certifikat på sina chip, så EKCerts tillgänglighet bör verifieras mot dina specifika enhetsmodeller innan du förbinder dig till denna förtroendemodell. EKPub är rätt val för miljöer som explicit behöver kontrollera vilka enskilda enheter som kan producera certifikat, till exempel högsäkerhetsinfrastruktur inom offentlig eller finansiell infrastruktur.

Med den valda förtroendemodellen är nästa steg att konfigurera certifikatmallarna som tillämpar den.

Konfigurera certifikatmallar för attestering

Attesteringskravet finns på mallnivå i certifikatmallarkonsolen, vilket innebär att det gäller per certifikattyp snarare än globalt för alla utfärdanden. Innan du trycker på attesteringsinställningen måste två förutsättningar vara uppfyllda:

Microsoft Platform Crypto Provider KSP

Mallen måste specifikt använda Microsoft Platform Crypto Provider , under kategorin Key Storage Provider. Tredjeparts smartkorts-KSP:er stöds inte för TPM-nyckelattestering, även om de är CNG-baserade. Dessutom måste algoritmen vara inställd på RSA : TPM-nyckelattestering i AD CS fungerar bara för RSA-nycklar. ECC- nycklar stöds inte för attestering.

Signatur Syfte

Syftet för hantering av förfrågningar måste vara inställt på Signatur (eller Signatur och kryptering), och alternativen Tillåt export av privat nyckel och Arkivera ämnets krypterings privata nyckel måste båda vara avmarkerade.

När dessa är uppfyllda visar fliken Kryptografi attesteringsinställningen med tre alternativ:

Inga:
Ingen attestering krävs. Standardinställningen för de flesta mallar. CA utfärdar utan någon hårdvarunyckelbevis.

Obligatoriskt, om klienten är kapabel:
CA:n accepterar och registrerar attestering om enheten stöder det, men utfärdar fortfarande till enheter som inte kan attestera (äldre TPM:er, virtuella maskiner utan vTPM, etc.). Användbart som en övergångsinställning medan du utvärderar TPM-täckningen över hela flottan. Attesterade certifikat kännetecknas av ett OID för utfärdandepolicy; icke-attesterade certifikat utfärdas utan det.

Nödvändig:
CA vägrar att utfärda om giltig attestering inte finns. Det är den här inställningen som faktiskt tillämpar skydd för hårdvarunyckeln.

När en CNG-kompatibel Windows-enhet registreras mot en obligatorisk mall hanterar registreringsstacken attesteringsflödet automatiskt. TPM genererar nyckeln, AIK signerar satsen och allt paketeras i certifikatbegäran utan att slutanvändaren behöver vidta några åtgärder. Om enheten inte har någon TPM eller om attesteringen misslyckas, misslyckas registreringen. Det misslyckandet är det avsedda beteendet: det förhindrar att en enhet hämtar ett certifikat som skulle ge en felaktig bild av dess nyckelskyddsnivå.

Det OID som skrivits in i det utfärdade certifikatets utfärdandepolicytillägg är den granskningsartefakt som registrerar vilken förtroendenivå som passerat. Principer för villkorlig åtkomst, regler för nedströmsåtkomst och granskningsverktyg kan alla fråga det OID:t för att skilja hårdvaruattesterade certifikat från programvarulagrade certifikat.

När mekaniken är förstådd är nästa fråga var detta faktiskt förändrar säkerhetsresultaten i praktiken.

Var TPM-nyckelattestering passar in i företaget

Det praktiska värdet av TPM-nyckelattestering är mest synligt i fyra scenarier:

Nollåtkomst till enheter med förtroende

Zero Trust- arkitekturer kräver att enhetsidentitet verifieras noggrant, inte antas från nätverksplatsen. Ett certifikat med en TPM-attesterad privat nyckel ger en betydligt starkare säkerhet än ett programvarulagrat certifikat: en angripare som komprometterar operativsystemet kan fortfarande inte exportera nyckeln och imitera enheten från en annan maskin. Att kräva TPM-attesterade certifikat för VPN, Wi-Fi (802.1x) och applikationsåtkomst stänger den vanligaste sidoförflyttningsvägen för stöld av autentiseringsuppgifter.

Windows Hello for Business

WHfB ersätter lösenord med en PIN-kod eller biometrisk gest som backas upp av ett kryptografiskt nyckelpar. Säkerhetsmodellen är helt beroende av att den privata nyckeln är hårdvarubunden. TPM-nyckelatestering är hur certifikatutfärdaren verifierar den bindningen innan WHfB-autentiseringscertifikatet utfärdas. WHfB-certifikatmallar kräver CNG-registrering och är vanligtvis konfigurerade för att framtvinga attestering, i enlighet med den hårdvarubindningsgaranti som gör WHfB:s säkerhetsmodell meningsfull.

Intune-hanterad enhetsautentisering

SCEP- och PKCS- certifikatprofiler som distribueras via Intune kan kräva TPM-registrering. Kombinerat med attesteringskrav på CA-sidan ger detta enhetscertifikat som utfärdas via Intune samma hårdvarubundna garanti som de från traditionell automatisk AD CS-registrering, även på molnbaserade enheter som inte är domänanslutna.

Reglerade miljöer och efterlevnad

FIPS 140-3- kraven i amerikanska federala och entreprenörsmiljöer, och NIST SP 800-157-riktlinjerna för härledda PIV-autentiseringsuppgifter, överensstämmer direkt med vad TPM Key Attestation tillhandahåller. OID:t i det utfärdade certifikatet ger granskare en verifierbar registrering av hårdvaruskyddsanspråket snarare än ett overifierbart policypåstående.

Det finns också en viktig gräns att förstå: TPM-nyckelattestering är inte en komplett hälsosignal för enheten.

Vad TPM-nyckelattestering inte täcker

TPM-nyckelatestering är specifikt begränsad till tidpunkten för certifikatutfärdande och skyddet av den privata nyckeln. Den mäter eller intygar inte enhetens programvarustatus, startkedjans integritet eller om operativsystemet har manipulerats efter etableringen. Dessa problem hör till andra mekanismer för hårdvaruatestering:

• PCR-mätningar (Platform Configuration Register) registrerar starttid firmware och operativsystemets status inuti TPM:n
• Fjärratestering via SPDM möjliggör verifiering av hårdvaruidentitet mellan komponenter under körning
• DICE-baserade ramverk för hårdvaruidentitet (en TCG-specifikation) tillhandahåller fabriksförankrad lageridentitet över hårdvaruklasser inklusive slutpunkter, servrar och inbäddade enheter.

En TPM-nyckelintyg på ett certifikat betyder att "denna nyckel finns verkligen i hårdvaran". Det betyder inte att "denna enhet är i ett skick som vi vet är bra". Båda påståendena spelar roll i en mogen Zero Trust-arkitektur, och de kommer från olika håll. Att behandla intyg som en fullständig hälsokontroll av enheten är ett av de vanligaste missuppfattningarna om vad funktionen faktiskt tillhandahåller.

Det finns också två viktiga omfångsbegränsningar som är värda att känna till innan du driftsätter. För det första fungerar TPM-nyckelattestering i AD CS bara för RSA-nycklar: ECC-baserade certifikatmallar kan inte använda attestering, oavsett hur de är konfigurerade. För det andra stöds inte TPM-nyckelattestering på fristående certifikatutfärdare: det kräver en företags-CA integrerad med Active Directory. Om din utfärdande certifikatutfärdare är en fristående certifikatutfärdare är attestering inte alls tillgänglig för den.

Hur krypteringskonsulting kan hjälpa

Att implementera TPM-nyckelattestering ligger i skärningspunkten mellan PKI-design, enhetshantering och identitetsstyrning: tre discipliner som sällan delar en gemensam färdplan i de flesta företag.

Att göra det rätt innebär flera rörliga delar:

• Certifikatmallar korrekt konfigurerade för CNG och lämplig attesteringsnivå
• AD CS-infrastruktur laddad med rätt TPM-tillverkares rot-CA:er för EKCert-förtroende
• Intune- eller grupprincipregistreringsprofiler i linje med attesteringskraven på CA-sidan
• Principer för villkorlig åtkomst och nedströmsåtkomst som faktiskt förbrukar attesterings-OID:t

Encryption Consultings PKI-tjänsteteam arbetar med hela kedjan, från design av CA-hierarki och härdning av certifikatmallar till Intune-integration och Zero Trust-policyjustering. Oavsett om du bygger en ny PKI-miljö med TPM-attestering inbyggd från början, eller härdar en befintlig AD CS-distribution där skydd av hårdvarunyckel tidigare var valfritt, har vårt team den djupa erfarenhet som kommer från att köra PKI-program för företag inom finansiella tjänster, hälso- och sjukvård, myndigheter och teknikorganisationer.

Om du utvärderar din nuvarande PKI-situation eller planerar en modernisering som inkluderar Windows Hello för företag, villkorlig åtkomst eller enhetsidentitet med noll förtroende, kontakta oss för att förstå hur en strukturerad PKI-hälsobedömning skulle se ut för din miljö.

Slutsats

TPM-nyckelattestering är en av de mest underutnyttjade funktionerna inom företags- PKI . De flesta organisationer har redan den hårdvaru- och mjukvaruinfrastruktur som krävs för att använda den. Windows 11 kräver TPM 2.0 som ett systemkrav, AD CS har stöttat attestering sedan Windows Server 2012 R2, och att aktivera det är en ändring av certifikatmallens konfiguration snarare än ett större infrastrukturprojekt. Det som saknas, oftast, är medvetenhet om vad funktionen faktiskt gör och den operativa tryggheten att ställa in den på Krävs snarare än att lämna den på Krävs om klienten är kapabel eller Ingen.

Ett certifikat som utfärdats enligt en obligatorisk attesteringspolicy är en kategoriskt annorlunda säkerhetsartefakt. Den privata nyckeln bakom det kan inte extraheras och replikeras av en angripare som komprometterar operativsystemet. Det är en meningsfull garanti i en värld där stöld av autentiseringsuppgifter driver den mesta sidoförflyttningen och där Zero Trust-ramverk kräver att enhetsidentitetsanspråk ska vara verifierbara snarare än antagna. Om din organisation ännu inte använder TPM-nyckelatestering på certifikatmallar med högt värde är det värt att inkludera det i PKI-moderniseringsplanen.