TPM Sniffing-aanvallen tegen niet-Bitlocker doelen

Datum:
10 juni 2022 |
Author(s):

Jos Wetzels - Principal Security Consultant

Vorig jaar, tijdens een opleving in de media-aandacht voor de beveiliging van Trusted Platform Module (TPM), veroorzaakt door een blogbericht van de Dolos Group waarin een snuffelaanval op Windows Bitlocker werd beschreven die op een TPM steunde, vroeg een klant ons om hun TPM-gebaseerde Full Disk Encryption (FDE)-set-up te onderzoeken in het licht van dit type aanval. Het gerelateerde onderzoek en commentaar dat volgde, zoals het bericht van de Dolos Group, lijkt zich te concentreren op TPM's zoals gebruikt door Windows Bitlocker [1], [2], [3], [4]. Daarom leek het ons interessant om dit scenario verder uit te werken voor andere TPM-gebruiksscenario's.

In deze blogpost leert u meer over:

De achtergrond van Trusted Platform Module (TPM)
Ons Threat Model
Onderzoek
IoT en TPM's
Overwegingen voor Red Teams
Defensieve aanbevelingen

Achtergrond

Een Trusted Platform Module (TPM) verwijst meestal naar een speciale veilige cryptoprocessor die voldoet aan de ISO/IEC 11889 standaard van de Trusted Computing Group (TCG). TPM's kunnen voor verschillende doeleinden gebruikt worden, van platformintegriteit en FDE-ondersteuning tot opslag van sleutelmateriaal en inloggegevens (zoals voor SSH-authenticatie). TPM's kunnen op verschillende platformen gebruikt worden, van servers en laptops tot cloud-verbonden IoT-apparaten.

Er bestaan twee hoofdversies van de standaard, TPM 1.2 en TPM 2.0, waarbij de laatste niet achterwaarts compatibel is met de eerste. TPM's kunnen op verschillende manieren geïmplementeerd worden (waarbij dTPM's en fTPM's de meest voorkomende zijn):

Discrete TPM's (dTPM): deze worden geleverd in de vorm van een speciale, sabotagebestendige chip.
Geïntegreerde TPM's: die geïmplementeerd zijn als een hardware subsysteem binnen een andere chip.
Firmware TPM's (fTPM's): deze zijn gebaseerd op firmware en draaien meestal in de Trusted Execution Environment (TEE) van een CPU.
Hypervisor TPM's (vTPM's): deze zijn gescheiden van een virtuele machine door bovenop een hypervisor te draaien.
Software TPM's: deze zijn puur op software gebaseerd en de minst veilige implementatie.

Voor de integriteit van het platform bieden TPM's mechanismen om het opgemeten opstarten te ondersteunen. Uitgaande van een Core Root of Trust for Measurement (CRTM) (bijv. boot ROM van een bepaalde SoC), worden hashes berekend van verschillende platformcomponenten (bijv. BIOS/UEFI, bootloader, ingebedde controllerfirmware, etc.) en opgeslagen in Platform Configuration Register (PCR) slots. Deze informatie kan worden opgenomen in het beveiligde opstartproces (mogelijk als onderdeel van FDE) om ervoor te zorgen dat er niet met deze verschillende componenten geknoeid is.

TPM's bieden ook mechanismen ter ondersteuning van encryptieoplossingen om vertrouwelijkheid en integriteitsverificatie te garanderen. Deze mechanismen omvatten het genereren van sleutels, de mogelijkheid om sleutelmateriaal te coderen met een TPM-specifieke sleutel en manipulatiebestendige functies om de TPM te laten functioneren als een veilige opslagplaats voor geheimen. Het gebruik van een TPM-beschermde sleutel op zichzelf wordt meestal binden genoemd, terwijl het toevoegen van gemeten boot PCR-waarden aan de cryptografische mix meestal verzegelen genoemd wordt.

In versleutelingsscenario's kunnen TPM's meestal in één van verschillende modi geconfigureerd worden:

Alleen TPM: hier levert de TPM automatisch de sleutel aan de encryptieoplossing op verzoek (bijv. bij het opstarten).
TPM + PIN: hier heeft de TPM een door het systeem geleverd geheim nodig (meestal een door de gebruiker ingevoerde PIN) voordat het de sleutel zal ontzegelen.
TPM + PIN + MFA: hier is een extra factor nodig, zoals een USB-sleutel met een geheim of TOTP.

In het geval van FDE moeten er vóór het opstarten extra geheimen worden verstrekt. Manipulatiebestendige functies op de TPM (zouden moeten) voorkomen dat PIN's geforceerd worden, dat privésleutels ontfutseld worden en dat deze functies omzeild worden door glitching.

Hoewel er in het verleden al invasieve sonderingsaanvallen, verschillende side-channel aanvallen, interposer aanvallen en aanvallen op het ontwerp en de implementatie van TPM's zijn geweest, zullen we ons in dit artikel alleen richten op snuffelaanvallen op dTPM's in FDE-ondersteuningsscenario's, aangezien dit soort aanvallen inherent zijn aan het ontwerp van dTPM's.

Aangezien dTPM's speciale chips zijn die los staan van de hoofd-CPU en andere controllers op een apparaat, hebben ze een manier nodig om daarmee te communiceren. De standaard specificeert de LPC, I2C en SPI bussen voor dit doel, en de dTPM zal op een bus gezet moeten worden samen met elk apparaat dat ermee zou moeten praten (afhankelijk van of er single- of multi-master rollen zijn).

Om het enigszins vereenvoudigd uit te leggen: tijdens het instellen van de versleuteling neemt de CPU het eigendom van de TPM over, configureert deze en stuurt een sleutel naar de TPM om deze te binden of te verzegelen. De TPM versleutelt deze sleutel met authenticatiegegevens, haar eigen geheime sleutel en optionele PCR-metingen en stuurt de versleutelde sleutel terug. Deze blob wordt dan ergens opgeslagen (meestal als onderdeel van een versleutelde volumeheader). Tijdens de ontcijfering stuurt de CPU de versleutelde sleutel naar de TPM, en de verificatiegegevens en optionele metingen worden door de TPM verkregen en samen met de geheime sleutel gebruikt om de blob te ontcijferen. De klaartekstsleutel wordt teruggestuurd naar de CPU voor gebruik.

Op een bepaald moment tijdens het ontcijferingsproces kan de klaartekstsleutel dus in klaartekst over de bus naar de CPU gestuurd worden. Hoewel de TPM 2.0 standaard zogenaamde"parameterversleuteling" toestaat, wordt deze functie zelden geïmplementeerd door versleutelingsoplossingen en, zoals Trammell Hudson al aangaf, gaat dit gepaard met het kip-en-ei probleem van vertrouwen vestigen zonder de mogelijkheid om geheimen op de hoofd-CPU op te slaan.

Bedreigingsmodel

Ons bedreigingsmodel ging uit van de veronderstelling dat een aanvaller gedurende beperkte tijd fysieke toegang had tot een apparaat met een dTPM-ondersteunde FDE-oplossing. Hierbij werd ervan uitgegaan dat provisioning/commissioning had plaatsgevonden en dat de gegevens in kwestie versleuteld waren. Hoewel een heleboel andere bedreigingen onder dit toepassingsgebied vallen, hebben we ons specifiek gericht op het sniffen van de TPM-bus omdat PCR-metingen irrelevant zijn voor dit scenario.

Onderzoek

Tijdens ons onderzoek hebben we Windows 10 Bitlocker met TPM vergeleken met verschillende Linux-gebaseerde FDE-implementaties, namelijk: systemd-cryptsetup, clevis, luks-tpm2, safeboot en coreboot. De TPM in kwestie was een Infineon OPTIGA SLB 9670 TPM 2.0 module met een SPI-interface (hoewel dit scenario natuurlijk ook werkt tegen I2C en LPC, zoals eerder is aangetoond).

Zoals we kunnen zien, wordt parameterversleuteling in de praktijk gewoon niet gebruikt, en met uitzondering van safeboot dwingt geen van de oplossingen standaard PIN/MFA af. Hoewel we pureboot, U-Boot, tboot en TrustedGRUB2 niet in detail hebben bekeken, vermoeden we dat daar vergelijkbare bevindingen gelden.

Om anderen te helpen bij het assessment en demonstreren van de haalbaarheid van TPM sniffing aanvallen tegen Linux-gebaseerde FDE-implementaties, heb ik twee Saleae Logic 2 plugins ontwikkeld, zoals hieronder getoond. Ze zijn beschikbaar op Github.

Alle oplossingen die we onderzochten zijn gebaseerd op de Linux Unified Key Setup (LUKS). LUKS2 volumes hebben een hoofding met een keyslot gebied dat verschillende keyslots bevat voor verschillende wachtwoorden of sleutelbestanden die kunnen worden gebruikt om het volume te decoderen. Deze sleutelslotgegevens specificeren informatie over de sleutelafleiding, zoals prioriteit, sleutelafleidingsfunctie, parameters, salt en versleutelingsalgoritme. Een gecodeerde hoofdsleutel (MK), opgeslagen in anti-forensische (AF) strips, wordt vervolgens gedecodeerd met behulp van de afgeleide sleutel.

Om LUKS samen met een TPM te gebruiken, maken de meeste oplossingen (system-cryptsetup, safeboot, luks_tpm2) gebruik van tpm2-tools, een soort BusyBox-achtige toolkit voor interactie met de Trusted Computing Group's (TCG) TPM2 Software Stack (TSS).

In systemd-cryptsetup wordt een TPM-token geregistreerd en gekoppeld aan een LUKS2 keyslot. Met een `cryptsetup luksDump /dev/sda1 --debug-json` commando kunnen we zien dat het token een base64 gecodeerde tpm2-blob entry bevat die naar de TPM wordt gestuurd om te ontzegelen. Het ontzegelverkeer is vrij gemakkelijk te zien op een SPI-bus en bestaat uit een TPM_READ bedrijfsvoering op TPM_DATA_FIFO_0 (d40024) met een gegevensstructuur bestaande uit een DWORD met waarde 00000022 gevolgd door een WORD-lengteveld (meestal waarde 0020) en de daaropvolgende 256-bits sleutel.

Mijn Saleae Logic-plugin formatteert de sleutel voor LUKS keyfile-uitvoer:

Een volume kan worden aangekoppeld met `cryptsetup open ./sda1-luks myvolumename --key-slot 1 --key-file ./mykey --keyfile-size 44`.

Hoewel luks-tpm2 een beetje anders werkt, kan het sleutels opslaan in een verzegeld on-disk bestand of TPM NVRAM en heeft het passphrase ondersteuning voor ontzegelen. De bedrijfsvoering voor het ontzegelen ziet er hetzelfde uit over de SPI-bus en de plug-in werkt hier ook. Safeboot lijkt de meest robuuste van de onderzochte oplossingen, dwingt gebruikers standaard om PIN te gebruiken, en werkt een beetje anders onder de motorkap, maar de tpm2-tools plugin werkt ook voor deze.

Clevis is een pluggable automatisch decryptieframework met een aantal "pinnen" (niet te verwarren met een PIN), waarbij elke pin crypto-ondersteuning implementeert met behulp van een ander backend. Voor versleuteling neemt Clevis wat gegevens en een JSON-configuratie om een JSON Web Encryption (JWE) object te produceren dat gegevens bevat die versleuteld zijn met behulp van een JSON Web KEY (JWK) en wat metadata. Bij ontcijfering haalt Clevis de sleutel uit de JWK en metagegevens en ontcijfert de cijfertekst uit de JWE.

De Clevis tpm2 "pin" genereert een JWK, creëert een object in de TPM met de JWK als geheime gegevens en bindt of verzegelt het aan de TPM. De resulterende JWE (geassocieerd met een LUKS2-sleutelsleuf) bevat zowel de openbare als de verzegelde gevoelige delen van het aangemaakte object, evenals metadata over de verzegeling. Bij ontsleuteling neemt de tpm2 "pin" de JWE, laadt deze in de TPM, ontzegelt de JWK en ontsleutelt de cijfertekst in de JWE.

Als gevolg van deze aanpak ziet het TPM SPI-verkeer er een beetje anders uit. Wat we zoeken is een TPM_READ bedrijfsvoering op TPM_DATA_FIFO_0 (d40024) met een datastructuur bestaande uit een DWORD met waarde 00000072, gevolgd door een veld met variabele WORD-lengte, gevolgd door een hoop JSON-gegevens.

Mijn Saleae Logic plugin valideert de JSON en extraheert de sleutel en relevante metadata:

IoT en TPM's

IoT-apparaten vallen vaak onder het typische 'fysieke toegang door een tegenstander'-dreigingsmodel, vooral voor apparaten die op openbare locaties worden ingezet of waarbij de gebruiker een potentiële tegenstander is. Diverse gerelateerde use-cases vereisen een soort vertrouwde functionaliteit van het beveiligingssubsysteem, zoals apparaatauthenticatie, identificatie, veilig onderhoud, attestatie op afstand en bescherming van gegevens in rusttoestand en tijdens doorvoer.

Hoewel veel IoT-apparaten veilige coprocessors gebruiken die niet voldoen aan de TPM-standaard, kunnen zowel AWS- als Azure-platforms worden gebruikt voor veilige apparaatprovisioning en token-/inloggegevensbescherming.

Zoals hieronder geïllustreerd, is de Azure-aanpak voor Windows 10 IoT Core vrij typisch voor deze use case. Hier wordt tijdens het provisioningproces een gedeelde toegangssleutel (Shared Access Key, SAK) tussen het IoT-apparaat en de cloud ingesteld door de cloud te voorzien van de openbare delen van de Endorsement Key (EK) en Storage Root Key (SRK) van de TPM. De SAK wordt aan de kant van het apparaat in de TPM geprint, terwijl aan de kant van de cloud het fysieke apparaat geassocieerd wordt met een apparaat-ID in de hub van het cloud-apparaat. Vervolgens wordt er een SAS-token (Shared Access Signature) gegenereerd, die een verzoek om toegang specificeert dat aan bepaalde beleidsregels is gekoppeld. Dit token wordt door de TPM ondertekend met behulp van een HMAC-sleutel die met het SAK is gecodeerd.

De Windows 10 IoT Core TPM-implementatie gebruikt ook geen parameterversleuteling. De SAK kan dus tijdens de provisioning onderschept worden (wat geen erg verontrustend scenario is), en SAS-tokens kunnen tijdens de bedrijfsvoering onderschept worden. Afhankelijk van het bedreigingsmodel van het apparaat kan dit laatste een probleem zijn. Daarnaast zou een aanvaller met fysieke toegang tot het IoT-apparaat eenvoudigweg de TPM kunnen vragen om willekeurige gegevens te ondertekenen, hetzij door zich op de bus te begeven of door de TPM helemaal te verwijderen.

Verdediging tegen dit soort bedreigingen in IoT-apparaten wordt bemoeilijkt door het feit dat toegangscontrole tot de TPM, in de vorm van een PIN, gecompliceerd wordt door de typische behoefte aan nulinteractie van gebruikers tijdens de bedrijfsvoering (of niet-vertrouwde gebruikers in het geheel). En het simpelweg opslaan van de PIN voor automatische invoer door de hoofd-CPU levert een kip-en-ei-probleem op. Daarom zijn er twee aanvullende verdedigingslinies voor TPM-beveiligde IoT-apparaten waarbij fysieke toegang een probleem is:

Diversificatie en herroepbaarheid. Om de impact van gecompromitteerde geheimen te beperken, moeten ze tijdens de provisioning voor elk apparaat gediversifieerd worden, zodat de compromittering van een enkel apparaat niet naar de hele vloot wordt uitgebreid in de stijl van pwn-once, misbruiken everywhere. Bovendien moeten authenticatiegeheimen herroepbaar zijn, zodat defensieve telemetrie relevant wordt.

Bestandheid tegen manipulatie. Aangezien TPM's niet de mogelijkheid hebben om rechtstreeks op externe sabotageschakelaars aangesloten te worden, moeten ze geïntegreerd worden in een beschermd subsysteem waar activering van de sabotageschakelaar onmiddellijk leidt tot het wissen van het TPM-geheim. Idealiter zorgt de activering van de sabotageschakelaar ook voor waarschuwingen in de backend, zodat herroepingsprocessen in gang gezet kunnen worden.

Overwegingen voor Red Teams

Het uitvoeren van een TPM sniffing aanval in de praktijk is niet helemaal hetzelfde als onder laboratoriumomstandigheden. TPM sniffing-aanvallen tegen FDE-oplossingen kunnen een krachtig hulpmiddel zijn in het arsenaal van een red team en passen in een breed scala aan bedreigingsmodellen, zoals fysieke aanvallers met toegang op locatie, onbeheerde/gestolen laptops, kwaadwillende insiders en interdictie van de toeleveringsketen. Toch hebben al deze scenario's gemeen dat het venster waarbinnen red teamoperators hun aanval kunnen uitvoeren beperkt is. Enige mate van heimelijkheid is vereist - als u dus volledig blind naar binnen gaat en een half uur aan het rommelen bent terwijl u van plan was minuten te maken en een haastig in elkaar gezette laptop achterlaat, kan dit alles in de praktijk moeilijker uitvoerbaar zijn dan op puur technische gronden.

Ten eerste kan de toegankelijkheid van TPM buscommunicatie sterk variëren. In het meeste eerdere werk kozen onderzoekers ervoor om SOIC8-testklemmen of grabbersondes aan een chip te bevestigen die toevallig op dezelfde bus zat als de TPM. U kunt echter moederbordontwerpen tegenkomen waarbij geen van de chips op de TPM-bus een gemakkelijk te bereiken chipverpakkingstype heeft. Buspennen op een TQFP, QFN of BGA-chip aftappen is heel wat lastiger dan op mooie en gemakkelijke SOIC-chips. Soms hebt u geluk en zijn er grote pads of nabijgelegen testpunten, maar in andere gevallen zult u naaldprobes of soldeervaardigheden met zeer dunne draad moeten gebruiken. En dan kan blijken dat u SPI-communicatie verwachtte terwijl de TPM op deze revisie van het moederbord nog steeds LPC gebruikte...

In andere gevallen zijn chips en/of testpunten gewoon moeilijk bereikbaar. Ze kunnen verborgen zitten onder lagen plastic en coating, vastgeklemd onder ventilatorarmen, of aan de andere kant van het moederbord, waardoor ze helemaal uit elkaar gehaald en omgedraaid moeten worden. En al dat spul moet onopvallend en werkend weer in elkaar worden gezet voordat u betrapt wordt.

Om verrassingen en onnodig geklungel te voorkomen, moeten red team operators de volgende voorbereidingen treffen bij het uitvoeren van een TPM snuffelaanval:

Verzamel informatie over de ingezette FDE-oplossing en de configuratie ervan (gebruikte PIN?), en zorg ervoor dat er analysetooling voor beschikbaar is.
Verzamel informatie over de gebruikte laptopmodellen, verkrijg schema's, zorg ervoor dat de tooling het bustype in kwestie aankan en oefen ten minste een paar keer op het model in kwestie.
Verzamel informatie over eventuele manipulatiebeveiligingen (beveiligingslabels, schakelaars, enz.) en bereid u hierop voor.
Zorg ervoor dat u een snelle oplossing voor het klonen van schijven meeneemt om cijfertekst van de schijf te kopiëren voor latere ontcijfering, u wilt dit niet ter plekke doen en u wilt ook niet uren hoeven wachten.

Een extra factor in de praktijk verslaan zal niet triviaal zijn. Toch zijn er twee mogelijke wegen: bootkit-gebaseerde tamper-and-revert-aanvallen en het achterlaten van een klein hardware-implantaat met bus-sniffing-mogelijkheden op het moederbord. Na het invoeren van de extra factor en het ontzegelen van het TPM-geheim, zou het implantaat het kunnen opslaan om het later fysiek terug te halen of het mogelijk kunnen exfiltreren via een geïntegreerde communicatiemogelijkheid (RF, 4G, enz.), afhankelijk van de beschikbare ruimte en de miniaturisatiemogelijkheden. Trammell Hudson gaf een geweldige presentatie over dit onderwerp voor een gerelateerde use case op 35C3.

Defensieve aanbevelingen

Er is veel degelijk defensief advies over dit onderwerp beschikbaar, onder andere van Microsoft[1],[2], maar over het algemeen komt het harden van TPM-gebaseerde FDE-oplossingen neer op de volgende principes:

Gebruik een extra factor zoals een PIN, wachtwoord of TOTP om de ontzegeling van de TPM te regelen.
Gebruik indien mogelijk een fTPM in plaats van een dTPM.
Configureer de TPM voor gemeten bootintegratie in de FDE-configuratie om te beschermen tegen firmwarebedreigingen.
Gebruik verzegelingen op gevoelige apparaten (hoewel de mate waarin dit helpt sterk varieert).