Attacchi di sniffing TPM contro obiettivi non-Bitlocker

L'anno scorso, durante l'aumento dell'attenzione dei media per la sicurezza del Trusted Platform Module (TPM), innescato da un post sul blog del Dolos Group che descriveva un attacco di sniffing a Windows Bitlocker che si basava su un TPM, un cliente ci ha chiesto di indagare sul suo set up di Full Disk Encryption (FDE) basato su TPM alla luce di questo tipo di attacco. La ricerca correlata e i commenti che ne sono seguiti, come il post di Dolos Group, sembrano essersi concentrati sui TPM utilizzati da Windows Bitlocker [1], [2], [3], [4]. Per questo motivo, abbiamo pensato che sarebbe stato interessante approfondire questo scenario applicato ad altri casi di utilizzo del TPM.

In questo blog post, imparerà a conoscere:

1. Il background del modulo di piattaforma affidabile (TPM)
2. Il nostro modello di minaccia
3. Indagine
4. IoT e TPM
5. Considerazioni per i Red Teaming
6. Raccomandazioni difensive

Contesto

Un Trusted Platform Module (TPM) si riferisce tipicamente a un crittoprocessore sicuro dedicato, conforme allo standard ISO/IEC 11889 del Trusted Computing Group (TCG). I TPM possono essere utilizzati per vari scopi, che vanno dall'integrità della piattaforma e dal supporto FDE all'archiviazione di materiale chiave e credenziali (come per l'autenticazione SSH). I TPM possono essere utilizzati in varie piattaforme, dai server e i computer portatili ai dispositivi IoT connessi al cloud.

Esistono due versioni principali dello standard, TPM 1.2 e TPM 2.0, con la seconda che non è retrocompatibile con la prima. I TPM possono essere implementati in vari modi (i più comuni sono i dTPM e gli fTPM):

• TPM discreti (dTPM): si presentano sotto forma di un chip dedicato, resistente alle manomissioni.
• TPM integrati: che sono implementati come sottosistema hardware all'interno di un altro chip.
• TPM firmware (fTPM): sono basati sul firmware e in genere vengono eseguiti nel Trusted Execution Environment (TEE) di una CPU.
• TPM Hypervisor (vTPM): che sono segmentati rispetto a una macchina virtuale e funzionano in cima a un hypervisor.
• TPM software: sono basati esclusivamente sul software e rappresentano l'implementazione meno sicura.

Per l'integrità della piattaforma, i TPM forniscono meccanismi per supportare l'avvio misurato. Partendo da un Core Root of Trust for Measurement (CRTM) (ad esempio, la ROM di avvio di alcuni SoC), vengono calcolati gli hash di vari componenti della piattaforma (ad esempio, BIOS/UEFI, bootloader, firmware del controller integrato, ecc.) e memorizzati negli slot del Platform Configuration Register (PCR). Queste informazioni possono essere incorporate nel processo di avvio sicuro (eventualmente come parte del FDE) per garantire che questi vari componenti non siano stati manomessi.

I TPM forniscono anche meccanismi per supportare soluzioni di crittografia per fornire garanzie di riservatezza e di autenticazione dell'integrità. Questi meccanismi includono la generazione di chiavi, la possibilità di crittografare il materiale chiave con una chiave specifica del TPM e le funzioni antimanomissione per far sì che il TPM funzioni come un archivio sicuro per i segreti. L'uso di una chiave protetta dal TPM di per sé è tipicamente indicato come binding, mentre l'aggiunta di valori PCR di avvio misurati nel mix crittografico è tipicamente indicata come sealing.

Negli scenari di crittografia, i TPM possono essere configurati in una delle diverse modalità:

• Solo TPM: in questo caso, il TPM fornisce automaticamente la chiave alla soluzione di crittografia su richiesta (ad esempio, all'avvio).
• TPM + PIN: in questo caso, il TPM necessita di un segreto fornito dal sistema (in genere un PIN inserito dall'utente) prima di sbloccare la chiave.
• TPM + PIN + MFA: in questo caso, è richiesto un fattore aggiuntivo, come una chiave USB con un segreto o un TOTP.

Nel caso di FDE, devono essere forniti segreti aggiuntivi prima dell'avvio. Le funzioni antimanomissione sul TPM (dovrebbero) impedire il brute-forcing dei PIN, l'estrazione delle chiavi private e il glitching per bypassare queste funzioni.

Sebbene in passato ci siano stati attacchi invasivi di probing, vari canali laterali, interposer e attacchi di progettazione e implementazione ai TPM, in questo post ci concentreremo solo sugli attacchi di sniffing contro i dTPM negli scenari di supporto FDE, poiché questi tipi di attacchi sono inerenti al design dei dTPM.

Poiché i dTPM sono chip dedicati e separati dalla CPU principale e dagli altri controller di un dispositivo, hanno bisogno di un modo per comunicare con loro. Lo standard specifica i bus LPC, I2C e SPI per questo scopo, e il dTPM dovrà essere inserito in un bus insieme a qualsiasi dispositivo che potrebbe avere bisogno di parlare con lui (a seconda che ci siano ruoli single o multi-master).

Per dirla in modo un po' semplificato, durante la configurazione della crittografia, la CPU assume la proprietà del TPM, lo configura e invia una chiave al TPM per il binding o il sigillo. Il TPM cripta questa chiave utilizzando i dati di autenticazione, la propria chiave segreta e le misurazioni PCR opzionali e invia il blob della chiave crittografata. Questo blob viene poi memorizzato da qualche parte (in genere come parte dell'intestazione di un volume crittografato). Durante la decodifica, la CPU invia il blob della chiave crittografata al TPM, e i dati di autenticazione e le misurazioni opzionali vengono ottenuti dal TPM e utilizzati insieme alla sua chiave segreta per decifrare il blob. La chiave in chiaro viene rinviata alla CPU per essere utilizzata.

Pertanto, a un certo punto del processo di decriptazione, la chiave in chiaro può essere inviata sul bus alla CPU in chiaro . Sebbene lo standard TPM 2.0 consenta la cosiddetta'crittografia dei parametri', questa funzione è raramente implementata dalle soluzioni di crittografia e, come sottolineato da Trammell Hudson, comporta il problema della fiducia senza la possibilità di memorizzare i segreti sulla CPU principale.

Modello di minaccia

Il nostro modello di minaccia si basava sull'ipotesi di un aggressore con accesso fisico per un tempo limitato a un dispositivo che utilizza una soluzione FDE supportata da dTPM. Questo presuppone che sia stato effettuato il provisioning/commissioning e che i dati in questione siano stati crittografati. Sebbene tutta una serie di altre minacce rientrino in questo ambito, ci siamo concentrati specificamente sullo sniffing del bus TPM, poiché le misurazioni PCR sono irrilevanti per questo scenario.

Indagine

Durante la nostra indagine, abbiamo confrontato Windows 10 Bitlocker con TPM con diverse implementazioni FDE basate su Linux, ovvero: systemd-cryptsetup, clevis, luks-tpm2, safeboot e coreboot. Il TPM in questione era un modulo Infineon OPTIGA SLB 9670 TPM 2.0 con un'interfaccia SPI (anche se ovviamente questo scenario funziona contro I2C e LPC, come è stato dimostrato in precedenza).

Come possiamo vedere, la crittografia dei parametri semplicemente non viene utilizzata nella pratica e, ad eccezione di safeboot, nessuna delle soluzioni applica il PIN/MFA per impostazione predefinita. Anche se non abbiamo analizzato in dettaglio pureboot, U-Boot, tboot e TrustedGRUB2, sospettiamo che anche in questo caso si applichino risultati simili.

Per aiutare gli altri a valutare e dimostrare la fattibilità degli attacchi di sniffing TPM contro le implementazioni FDE basate su Linux, ho sviluppato due plugin di Saleae Logic 2, come mostrato di seguito. Sono disponibili su Github.

Tutte le soluzioni che abbiamo analizzato si basano sul Linux Unified Key Setup (LUKS). I volumi LUKS2 hanno un'intestazione con un'area keyslot che contiene diversi keyslot per diverse password o file chiave che possono essere utilizzati per decriptare il volume. Queste voci di keyslot specificano le informazioni sulla derivazione della chiave, come la priorità, la funzione di derivazione della chiave, i parametri, il sale e l'algoritmo di crittografia. Una chiave master crittografata (MK), memorizzata nelle strisce anti-forensics (AF), viene poi decrittografata utilizzando la chiave derivata.

Per utilizzare LUKS insieme a un TPM, la maggior parte delle soluzioni (system-cryptsetup, safeboot, luks_tpm2) utilizza tpm2-tools, una sorta di toolkit simile a BusyBox per interagire con il TPM2 Software Stack (TSS) del Trusted Computing Group (TCG).

In systemd-cryptsetup, un token TPM viene registrato e collegato a un keyslot LUKS2. Con un comando `cryptsetup luksDump /dev/sda1 --debug-json`, possiamo vedere che il token contiene una voce tpm2-blob codificata in base64 che viene inviata al TPM per l'unsealing. Il traffico di unsealing è abbastanza facile da individuare su un bus SPI e consiste in un'operazione TPM_READ su TPM_DATA_FIFO_0 (d40024) con una struttura dati composta da una DWORD con valore 00000022 seguita da un campo di lunghezza di dimensioni WORD (in genere valore 0020) e dalla successiva chiave a 256 bit.

Il mio plugin Saleae Logic formatta la chiave per l'output del file chiave LUKS:

Il montaggio di un volume può essere eseguito con `cryptsetup open ./sda1-luks myvolumename --key-slot 1 --key-file ./mykey --keyfile-size 44`.

Mentre luks-tpm2 funziona in modo leggermente diverso, può memorizzare le chiavi in un file sigillato sul disco o nella NVRAM del TPM e ha il supporto della passphrase per l'unsealing. La sua operazione di unsealing sembra la stessa sul bus SPI e il plugin funziona anche in questo caso. Safeboot sembra la soluzione più robusta tra quelle studiate, in quanto costringe gli utenti a utilizzare il PIN per impostazione predefinita, e funziona in modo leggermente diverso sotto il cofano, ma il plugin tpm2-tools funziona anche in questo caso.

Clevis è un framework di decodifica automatica collegabile con una serie di 'pin' (da non confondere con un PIN), dove ogni pin implementa il supporto crittografico utilizzando un backend diverso. Per la crittografia, Clevis prende alcuni dati e una configurazione JSON per produrre un oggetto JSON Web Encryption (JWE) che contiene dati crittografati con una JSON Web KEY (JWK) e alcuni metadati. Al momento della decifrazione, Clevis ottiene la chiave dalla JWK e dai metadati e decifra il testo cifrato dalla JWE.

Il 'pin' Clevis tpm2 genera un JWK, crea un oggetto nel TPM con il JWK come dati segreti e lo lega o sigilla al TPM. Il JWE risultante (associato a uno slot chiave LUKS2) contiene sia le porzioni sensibili pubbliche e sigillate dell'oggetto creato, sia i metadati relativi al sigillo. Al momento della decifrazione, il 'pin' tpm2 prende il JWE, lo carica nel TPM, disincrosta il JWK e decifra il testo cifrato nel JWE.

Come risultato di questo approccio, il traffico SPI del TPM ha un aspetto leggermente diverso. Quello che stiamo cercando è un'operazione TPM_READ su TPM_DATA_FIFO_0 (d40024) con una struttura di dati composta da un DWORD con valore 00000072, seguito da un campo di lunghezza variabile di tipo WORD, seguito da un gruppo di dati JSON.

Il mio plugin Saleae Logic convalida il JSON ed estrae la chiave e i metadati rilevanti:

IoT e TPM

I dispositivi IoT rientrano spesso nel tipico modello di minaccia 'accesso fisico da parte di un avversario', soprattutto per quei dispositivi distribuiti in luoghi pubblici o dove l'utente è un potenziale avversario. Diversi casi d'uso correlati richiedono una sorta di funzionalità del sottosistema di sicurezza fidata, come l'autenticazione del dispositivo, l'identificazione, la manutenzione sicura, l'attestazione remota e la protezione dei dati a riposo e in transito.

Mentre molti dispositivi IoT utilizzano coprocessori sicuri non conformi allo standard TPM, entrambe le piattaforme AWS e Azure possono essere utilizzate per il provisioning sicuro dei dispositivi e la protezione dei token/credenziali.

Come illustrato di seguito, l'approccio Azure per Windows 10 IoT Core è piuttosto tipico per questo caso d'uso. Qui viene stabilita una chiave di accesso condivisa (SAK) tra il dispositivo IoT e il cloud durante il processo di provisioning, fornendo al cloud le parti pubbliche della Endorsement Key (EK) e della Storage Root Key (SRK) del TPM. La SAK è impressa nel TPM sul lato del dispositivo, mentre sul lato del cloud, il dispositivo fisico è associato a un ID dispositivo nell'hub del dispositivo del cloud. Successivamente, viene generato un token SAS (Shared Access Signature), che specifica una richiesta di accesso associata a determinate politiche. Questo token viene firmato dal TPM utilizzando una chiave HMAC con il SAK.

Anche l'implementazione del TPM di Windows 10 IoT Core non utilizza la crittografia dei parametri. Pertanto, il SAK potrebbe essere sniffato durante il provisioning (che non è uno scenario molto preoccupante) e i token SAS potrebbero essere sniffati durante le operazioni. A seconda del modello di minaccia del dispositivo, quest'ultimo problema potrebbe essere un problema. Inoltre, un aggressore con accesso fisico al dispositivo IoT potrebbe semplicemente richiedere al TPM di firmare dati arbitrari, interponendosi sul bus o rimuovendo del tutto il TPM.

La difesa contro questo tipo di minacce nei dispositivi IoT è complicata dal fatto che il controllo dell'accesso al TPM, sotto forma di PIN, è complicato dalla necessità tipica di un'interazione zero con l'utente durante le operazioni (o di utenti non fidati). Inoltre, la semplice memorizzazione del PIN per l'inserimento automatico da parte della CPU principale produce un problema di "uovo e gallina". Per questo motivo, vengono in mente due linee di difesa complementari per i dispositivi IoT protetti da TPM in cui l'accesso fisico è un problema:

• Diversificazione e revocabilità. Per limitare l'impatto dei segreti compromessi, questi dovrebbero essere diversificati per ogni dispositivo durante il provisioning, in modo che la compromissione di un singolo dispositivo non si estenda all'intera flotta in stile pwn-once, exploit everywhere. Inoltre, i segreti di autenticazione dovrebbero essere revocabili, in modo che la telemetria difensiva diventi perseguibile.

• Resistenza alle manomissioni. Poiché i TPM non hanno la possibilità di essere collegati direttamente a interruttori antimanomissione esterni, dovrebbero essere integrati in un sottosistema protetto in cui l'attivazione dell'interruttore antimanomissione innesca immediatamente la cancellazione del segreto TPM. Idealmente, l'attivazione dell'interruttore di manomissione genera anche degli avvisi di backend, in modo da poter avviare i processi di revoca.

Considerazioni per il Red Teaming

Eseguire un attacco di sniffing TPM nella pratica non è proprio come farlo in condizioni di laboratorio. Gli attacchi di sniffing del TPM contro le soluzioni FDE possono essere uno strumento potente nell'arsenale di un Red Team e si inseriscono in un'ampia gamma di modelli di minaccia, come gli aggressori fisici con accesso in sede, i laptop incustoditi/rubati, gli insider disonesti e l'interdizione della catena di approvvigionamento. Tuttavia, tutti questi scenari hanno in comune il fatto che la finestra entro la quale gli operatori del Red Teaming possono eseguire il loro attacco è limitata. È necessaria una certa dose di furtività; per questo motivo, entrare completamente alla cieca e armeggiare per mezz'ora mentre si pianificavano i minuti e lasciarsi alle spalle un computer portatile assemblato in fretta può rendere tutto questo più difficile da realizzare nella pratica che non su basi puramente tecniche.

Sconfiggere un fattore aggiuntivo nella pratica non sarà banale. Tuttavia, due possibili strade potrebbero essere gli attacchi tamper-and-revert basati su bootkit e l'inserimento di un piccolo impianto hardware con capacità di bus-sniffing sulla scheda madre. Una volta inserito il fattore aggiuntivo e svelato il segreto TPM, l'impianto potrebbe memorizzarlo per un successivo recupero fisico o eventualmente esfiltrare il segreto attraverso una capacità di comunicazione integrata (RF, 4G, ecc.), a seconda dello spazio disponibile e delle capacità di miniaturizzazione. Trammell Hudson ha presentato un ottimo discorso su questo argomento per un caso d'uso correlato alla 35C3.

Raccomandazioni difensive

Sono disponibili molti consigli difensivi solidi su questo tema, anche da parte di Microsoft[1],[2], ma in generale, l'indurimento delle soluzioni FDE basate su TPM si riduce ai seguenti principi:

• Impiegare un fattore aggiuntivo come un PIN, una password o un TOTP per regolare l'unsealing del TPM.
• Utilizzare un fTPM invece di un dTPM, se possibile.
• Configurare il TPM per l'integrazione dell'avvio misurato nella configurazione FDE per proteggere dalle minacce del firmware.
• Impiegare sigilli di sicurezza antimanomissione sui dispositivi sensibili (anche se il grado di aiuto varia notevolmente).

E adesso?

Vuole saperne di più sul nostro Red Teaming o sulle valutazioni di sicurezza dopo aver letto questo blog? Ci contatti pure.