Il modo giusto per utilizzare il TPM per la crittografia completa del disco

Question

Il modo giusto per utilizzare il TPM per la crittografia completa del disco

#1 da (11 voti)

20

Attualmente sto configurando un equivalente BitLocker utilizzando TPM e LUKS. Ho le nozioni di base giuste e sono in grado di misurare il processo di avvio e sigillare la chiave FDE usando il TPM.

Ogni volta che le parti sensibili (firmware, bootloader, kernel) vengono aggiornate, il seguente comando viene utilizzato per sigillare la chiave di crittografia nel nuovo stato del sistema:

tpm_sealdata -p 0 -p 1 ... -p 11 -p 13 -i <keyfile> -o <sealed keyfile>

Quando il sistema si avvia, viene utilizzato quanto segue per annullare la chiusura della chiave, che viene poi passata a LUKS per montare il volume crittografato:

tpm_unsealdata -i <sealed keyfile> -o <temporary keyfile stored in RAM>

Funziona e ha il comportamento desiderato - se il processo di avvio è stato manomesso (diciamo aggiungendo init=/bin/sh alla riga di comando del kernel per bypassare una password di root) il TPM si rifiuta di annullare la chiave e il sistema è così sicuro .

Tuttavia, ho alcune domande:

Innanzitutto, il TPM richiede la password SRK ogni volta che viene eseguita un'operazione di chiusura / apertura. Mi piacerebbe evitarlo e comportarmi come BitLocker che è trasparente e non richiede nulla. Ho pensato di utilizzare una password SRK predefinita ma a quanto pare è insicuro , tuttavia le risposte non riescono a stabilire se un utente malintenzionato che conosce la password può annullare la chiusura di una chiave se i PCR non corrispondono allo stato in cui si trovavano quando la chiave è stata sigillata.

Un'altra domanda è quale modo dovrei usare per sigillare le chiavi - il mio modo riguarda tpm_sealdata / tpm_unsealdata ma un altro progetto tpm -luks utilizza tpm-nvread / tpm-nvwrite . Mi piacerebbe conoscere le differenze e se un modo è più sicuro dell'altro.

disk-encryption luks tpm bitlocker

posta André Borie 27.05.2016 - 08:40

fonte

1 risposta

Leggi altre domande sui tag disk-encryption luks tpm bitlocker

Consigli per il software honeypot C'è un posto dove posso caricare i miei log di honeypot?

score 11 · Accepted Answer

Prima di tutto: nessun sistema è sicuro al 100%, ma l'utilizzo del TPM è migliore di nessun TPM. Il TPM Chip è solo una sorta di archivio crittografato, che risiede sulla scheda madre dei computer che supportano Trusted Platform Environment, e ha i BIOS pronti a gestirlo.

PCR sono registri con funzioni specifiche gestite tramite l'operazione TPM_Extend . Non possono essere "impostati", solo estesi (new_hash = [old_hash || new_measurement]).

TPM ha Root statico di fiducia per le misurazioni (SRTM) e Root dinamico di fiducia per le misurazioni (DRTM) e la combinazione di entrambi crea l'ambiente protetto. Questo tizio spiega molto bene come è fatto. È una catena di fiducia tra elementi fissi e dinamici.

Torna alle PCR, sono registri indipendenti dalla piattaforma e quelli più comuni sono:

PCR 0 to 3 for the BIOS, ROMS...
PCR 4 - MBR information and stage1
PCR 8 - bootloader information stage2 part1
PCR 9 - bootloader information stage2 part2
PCR 12 - all commandline arguments from menu.lst and those entered in the shell
PCR 13 - all files checked via the checkfile-routine
PCR 14 - all files which are actually loaded (e.g., Linux kernel, initramfs, modules...)
PCR 15 to 23 are not used

I notebook basati su Intel utilizzano comunemente i primi 16 registri, ma potrebbero essere estesi ad altri software / usi.

Durante la scrittura di informazioni (sigillatura) su TPM, è possibile aggiungere una chiave di archiviazione (SRK) che è in qualche modo una "chiave di gestione" e viene utilizzata per aggiungere altre chiavi a questo archivio. Come per manpage , l'utilizzo di -z imposterà TSS_WELL_KNOWN_SECRET (20 zero bytes) .

-z, --well-known
    Use TSS_WELL_KNOWN_SECRET (20 zero bytes) as the SRK password. 
    You will not be prompted for the SRK password with this option.

Quindi, avere questo SRK impostato sul segreto predefinito ( TSS_WELL_KNOWN_SECRET ) non sarà sufficiente per attaccare qualcuno poiché TPM può essere aperto solo se le PCR correnti corrispondono a quelle usate per sigillare i dati. Inoltre, parte della gestione della PCR avviene al momento dell'avvio (BIOS) ed è molto difficile manipolarli e quindi creare PCR "falsi". Il BIOS è l'unico posto in cui le PCR vengono viste come zeri prima che avvenga il resto del processo.

L'unico attacco FEASABLE è quello che punta alle comunicazioni MITM tra BIOS e PCR per azzerare la PCR senza riavviare la macchina per mettere il sistema in stato "attendibile". Questo attacco è noto come TPM Reset Attack .

The Attack

So, given everything we've seen above, it should be very difficult to fake a trusted boot process, as long as the BIOS takes the first few measurements. The critical assumption here is that the PCRs cannot be easily reset without restarting the whole platform that the TPM resides on. If an attacker is capable of monitoring the measurements sent to the PCRs by the BIOS (with, for instance a logic analyzer, see this paper), and capable of zeroing out the PCRs without restarting the machine, then she could take a platform in any configuration and put it into a 'trusted' state. So, the difficult part is getting the TPM to reset without bringing down the whole machine. It is worth mentioning that we've also looked at interposing memory and other such things to change the running system after its been measured, but due to the speed of the busses that memory and hard drives sit on, this is a tricky endeavor. Attacking a slower bus is much easier.

TPMs typically reside on the Low Pin Count (LPC) bus. The LPC bus supports a ground driven reset line. This means that when this particular line on the bus is driven to ground every device on this bus is supposed to reset. Other devices attached to this bus include the BIOS, and legacy keyboard and mouse controllers. The video below demonstrates that driving this line is indeed possible, and fairly easy to do. Please note that in the video, we are accessing the computer in question via a remote ssh session. This is because the keyboard and mouse controller get reset when we drive the reset pin, but the network card does not. More details of this attack (and others!) can be seen in my senior honors thesis: A Security Assessment of Trusted Platform Modules, Dartmouth College Computer Science Technical Report TR2007-597.

Tieni presente che questa è una versione semplificata di TUTTE LE COSE che coinvolgono Trusted Computing . Si prega di dare un'occhiata al Documento di architettura di TPMv2 per ottenere maggiori informazioni su tutte le operazioni che avvengono tra bios, hardware e software durante l'installazione di un ambiente attendibile.

tl; dr : l'uso della chiave di archiviazione di default (20 byte zero) non è sufficiente per creare un sistema non sicuro.

Argomenti correlati: