BitLocker: TPM pre-boot PIN versus UEFI / BIOS boot wachtwoord

Enkele maanden geleden vroeg ik mijn LinkedIN netwerk om hulp inzake BitLocker. Ik wilde graag weten of een UEFI / BIOS boot wachtwoord, vergeleken met een TPM pre-boot PIN, ook bescherming biedt tegen het zogenaamde ‘running state’ risico. Microsoft lijkt namelijk te impliceren dat dit zo is, maar ik had moeite om in deze interpretatie mee te gaan. Hoewel ik niet direct een antwoord kreeg, werd ik wel in de juiste richting gestuurd. Na het nodige speurwerk ben ik eruit: alleen een TPM pre-boot PIN biedt bescherming tegen het running state risico.

Running state risico

Eerst even een stapje terug. Veel organisaties passen BitLocker versleuteling toe om te borgen dat verlies of diefstal van een laptop niet resulteert in een (meldplichtig) datalek. Doordat BitLocker alle data op de SSD van de laptop versleuteld, beschikt de dief (of vinder) wel over de hardware, maar heeft deze geen toegang tot de data.

De decryptiesleutel van BitLocker is opgeslagen in een TPM chip. Deze chip voert na het inschakelen van de laptop een aantal technische validaties uit om vast te stellen of de systeemintegriteit nog intact is. Wanneer dat het geval is, dan geeft de TPM chip de decryptiesleutel vrij en wordt de SSD ontsleuteld. Pas daarna start het besturingssysteem (bijvoorbeeld Windows 10) op.

Het probleem hierbij is, wat mij betreft, dat de TPM chip standaard geen pre-boot PIN vereist alvorens deze de BitLocker sleutel vrijgeeft. Dit betekent dat de laptop (waarvan de systeemintegriteit intact is) zonder enige vorm van authenticatie volledig automatisch opstart en aan de dief een Windows inlogscherm presenteert. Op dat moment verkeert de laptop in een toestand die ik ‘running state’ noem.

Een laptop in een ‘running state’ kent aanzienlijk meer aanvalsvectoren die de kans op een datalek flink doen toenemen. Denk aan de BitLocker decryptiesleutel die in het geheugen is geladen, een (relatief) zwak Windows wachtwoord, of een ongepatchte kwetsbaarheid in Windows. Vooral de laatste twee type kwetsbaarheden zijn aanzienlijk makkelijker te misbruiken dan een aanval op de TPM chip. Kortom, het restrisico is (vergeleken met BitLocker mét TPM pre-boot PIN) veel groter en neemt bovendien automatisch (lees: zonder inspanning van de dief) in omvang toe naarmate de tijd vordert.

Neem bijvoorbeeld een laptop met Windows 10 die volledig was gepatched toen deze werd verloren of gestolen. Wanneer we uitsluitend kijken naar het besturingssysteem zelf, en niet naar andere applicaties die op de laptop zijn geïnstalleerd, dan zien we honderden ontdekte kwetsbaarheden in 2022. Wanneer we daar verder op inzoomen, dan zien we 31 kwetsbaarheden met een CVSS score van 9 of hoger. Stel dat voor 10% van de kritieke kwetsbaarheden een publieke exploit beschikbaar komt. Dan zou je grofweg kunnen stellen dat het tussen de 3 en 6 maanden duurt alvorens een dief kan beschikken over middelen waarmee deze toegang kan verkrijgen tot de laptop en de daarop opgeslagen data.

TPM pre-boot PIN is het advies

Nu begrijp ik best dat dieven doorgaans niet geïnteresseerd zijn in data; meestal willen ze snel geld verdienen door een laptop opnieuw te installeren en verkopen. Dat betekent echter niet dat je een (meldplichtig) datalek kunt uitsluiten. Daarom adviseer ik organisaties om BitLocker uitsluitend te gebruiken in combinatie met een mét pre-boot PIN. Ik vind het toepassen van BitLocker zonder pre-boot PIN toch een beetje een wassen neus. Met name omdat de kans op een datalek, als gevolg van het running state risico, feitelijk helemaal niet zo laag ligt terwijl dit wél de gangbare opvatting is wanneer BitLocker is ingeschakeld.

Enige tijd geleden kreeg ik de vraag of een UEFI / BIOS boot wachtwoord (wat reeds op veel laptops was ingesteld) niet dezelfde waarborgen bood als een TPM pre-boot PIN. Hierbij werd verwezen naar deze pagina van Microsoft waar het volgende staat:

The following types of system changes can cause an integrity check failure and prevent the TPM from releasing the BitLocker key to decrypt the protected operating system drive:

• Moving the BitLocker-protected drive into a new computer.
• Installing a new motherboard with a new TPM.
• Turning off, disabling, or clearing the TPM.
• Changing any boot configuration settings.
• Changing the BIOS, UEFI firmware, master boot record, boot sector, boot manager, option ROM, or other early boot components or boot configuration data.

Microsoft wekt hier de indruk dat een gereset of gewijzigd UEFI / BIOS boot wachtwoord (als gevolg van een aanval) resulteert in een falende integriteitscontrole van het systeem. De TPM chip geeft de decryptiesleutel dan niet automatisch vrijgeeft en BitLocker vraagt om een recovery key alvorens de laptop verder opstart. Dit is dan wel gebaseerd op de aanname dat het boot wachtwoord (of diens opslaglocatie) een onderdeel is van de integriteitscontrole. En daar zit de crux, want is dat wel zo?

Omdat Microsoft het wachtwoord niet expliciet noemt, maar ook vanwege een (van oudsher) laag vertrouwen in BIOS beveiligingsmaatregelen, twijfelde ik. Maar feiten of kennis ontbraken om mijn twijfel te bevestigen of weg te nemen. Tijdens mijn zoektocht naar meer informatie, schakelde ik de hulp in van mijn LinkedIN netwerk. Dit leverde een aantal interessante bronnen op die mij op het juiste spoor zetten.

Is het UEFI / BIOS wachtwoord onderdeel van een TPM integriteitscontrole?

Dit artikel op Elcomsoft beschrijft de rol die een TPM chip speelt in een BitLocker context. Tijdens het opstarten worden achtereenvolgens verschillende validatiewaarden gegenereerd (hashes) als gevolg van uitgevoerde controles. Iedere validatiewaarde (het resultaat van een uitgevoerde controle) wordt opgeslagen in een zogenaamd Platform Configuration Register (PCR). Dit is een speciaal geheugenadres op de TPM chip waarvan er en in totaal 24 zijn (0 tot 23).

Er wordt een validatieketen van PCRs gecreëerd door de validatiewaarde van de voorgaande PCR te gebruiken bij het calculeren van de validatiewaarde van de huidige PCR. Wanneer één van de validatiewaarden niet klopt (vergeleken met de laatste keer dat het systeem volledig was opgestart), dan komt de laatst gebruikte PCR in de keten niet overeen met de beoogde waarde en kan worden geconcludeerd dat de integriteitscontrole is gefaald. Wanneer dat gebeurt wordt de decryptiesleutel niet vrijgegeven en zal BitLocker vragen om een recovery key die nodig is om het opstarten van de laptop te hervatten.

Dit inzicht helpt om de vraag verder aan te scherpen: is de integriteitscontrole van (de opslaglocatie van) het UEFI / BIOS wachtwoord input voor één van de gebruikte PCRs? Alleen wanneer dit zo is geeft een dergelijk wachtwoord (net zoals een TPM pre-boot PIN) bescherming tegen het eerder beschreven running state risico.

Uit deze documentatie over Group Policies is af te leiden hoe de verschillende PCRs heten én welke er standaard worden gebruikt door Windows. Blijkbaar zit er een verschil tussen laptops met moderne UEFI firmware en laptops met oudere BIOS firmware.

Computers with a native UEFI firmware:

The default platform validation profile secures the encryption key against changes to the core system firmware executable code (PCR 0), extended or pluggable executable code (PCR 2), boot manager (PCR 4), and the BitLocker access control (PCR 11).

Computers with BIOS configurations or to computers with UEFI firmware with a Compatibility Service Module (CSM) enabled:

The default platform validation profile secures the encryption key against changes to the Core Root of Trust of Measurement (CRTM), BIOS, and Platform Extensions (PCR 0), the Option ROM Code (PCR 2), the Master Boot Record (MBR) Code (PCR 4), the NTFS Boot Sector (PCR 8), the NTFS Boot Block (PCR 9), the Boot Manager (PCR 10), and the BitLocker Access Control (PCR 11).

Gewoonlijk maken UEFI laptops dus gebruikt van de PCRs 0, 2, 4 en 11, terwijl BIOS laptops gebruik maken van 0, 2, 4, 8, 9, 10 en 11. Ook wordt duidelijk dat de waarden van de overige PCRs genegeerd worden en dus geen onderdeel uitmaken van de validatieketen. Blijkbaar is de validatieketen (met aan elkaar gelinkte PCR waarden) configureerbaar en kun je zelf kiezen welke PCRs samen de keten vormen. Je moet hierbij natuurlijk wel goed opletten:

Warning: Changing from the default platform validation profile affects the security and manageability of your computer. BitLocker’s sensitivity to platform modifications (malicious or authorized) is increased or decreased depending upon inclusion or exclusion (respectively) of the PCRs. Specifically, setting this policy with PCR 7 omitted, will override the “Allow Secure Boot for integrity validation” group policy, preventing BitLocker from using Secure Boot for platform or Boot Configuration Data (BCD) integrity validation.

Helaas is niet gedocumenteerd welke controles er exact aan de verschillende PCRs ten grondslag liggen, maar in een wat ouder artikel over Zero-Touch BitLocker Deployment staat het volgende geschreven over PCR 1:

This PCR detects unauthorized changes to Bios configuration. This includes things as SMBios structures, CMOS data, passwords, etc… By default, this is not used by BitLocker.

Dit bevestigt twee dingen:

1. TPM integriteitscontroles ten aanzien van UEFI / BIOS wachtwoorden hebben te maken met PCR 1.
2. PCR 1 wordt (standaard) niet gebruikt door BitLocker (wat overeenkomt met de Group Policy documentatie die ik eerder quootte).

Ook de UEFI specificatie door Trusted Computing Group (TCG PC Client Platform Firmware Profile Specification Version 1.05 Revision 23) stelt in het gedeelte over PCR 1 (paragraaf 3.3.4.2) het volgende:

Security-relevant CMOS data and security-relevant configuration data stored in Platform NVRAM and in effect when the platform boots SHOULD be measured. If measured, these events MUST use the event type EV_EFI_HANDOFF_TABLES as described in Section 10.4.1 Event Types. Sensitive data like passwords MUST be omitted from the NVRAM data because it could be placed unencrypted in the TCG event log.

In Section 10.4.1 Event Types, staat vervolgens dat het event EV_EFI_HANDOFF_TABLES is vervangen door event EV_EFI_HANDOFF_TABLES2. En bij dit event staat: “Used for PCR[1] only”. Wederom de bevestiging dat de resultaten van controles omtrent ingestelde UEFI / BIOS wachtwoorden worden vastgelegd in PCR 1. Hoewel impliciet, interpreteer ik de documentatie van het TianoCore EDK II project (UEFI referentie implementatie door Intel) ook als een bevestiging van dit feit.

Klein zijstapje: interessant dat de UEFI specificatie vereist dat opgeslagen wachtwoorden niet verwerkt mogen worden bij het uitvoeren van de integriteitscontrole, omdat wachtwoorden mogelijk leesbaar in een log kunnen worden opgeslagen. Ik ben hier verder niet ingedoken, maar dit zou zelfs kunnen betekenen dat wanneer PCR 1 wél een onderdeel is van de validatieketen, het boot wachtwoord er alsnog buiten valt.

Conclusie

Door de TPM chip uitgevoerde integriteitscontroles omtrent UEFI / BIOS wachtwoorden zijn gerelateerd aan PCR 1. Echter, de inhoud van PCR 1 wordt (in ieder geval door Windows) standaard niet meegenomen in de PCR validatieketen. Dit betekent dat gerommel met het UEFI / BIOS boot wachtwoord NIET tot gevolg heeft dat de integriteitscontrole faalt en de TPM de decryptiesleutel dus automatisch vrijgeeft tijdens het opstarten. Om je laptop te beschermen tegen het eerder beschreven running state risico dien je dus een TPM pre-boot PIN in te schakelen.