Come funziona il secure boot

Nell'ultimo post dedicato al trusted computing mi ero ripromesso di spiegare come funziona praticamente un dispositivo TPM.

L'architettura tipica di un dispositivo TPM 1.2 come quello di Infineon è descritta dalla seguente figura:

(fonte)

Come si può vedere un chip TPM fornisce diverse svariate funzionalità: è infatti possibile ad esempio di usare il TPM come generatore di numeri casuali (RNG), oppure come memoria (limitata) non volatile, ecc. Ogni funzionalità può essere usata in maniera più o meno indipendente dalle altre.

Per quanto riguarda il secure boot la funzionalità associata è quella dei platform configuration register (PCR). Ogni TPM viene fornito con un numero svariato di PCR: le specifiche richiedono che ne siano forniti almeno 24, i primi sedici dei quali (PCR0-PCR15) devono essere non resettabili. Per semplificare d'ora in poi mi riferirò con il termine PCR ai PCR non resettabili. Un PCR è un registro schermato e come tale protetto da interferenze e occhi indiscreti. Il PCR permette solo due tipi di operazioni 'semplici': lettura ed estensione.

• la lettura restituisce al chiamante il valore contenuto nel PCR
• l'estensione prende come input un valore di 160 bit e scrive nel PCR l'hash (comunemente si usa SHA-1 e quindi i PCR stessi sono grandi 160 bit) della concatenazione tra il valore del PCR e il valore in ingresso. In parole povere esegue la seguente operazione:
  PCR = SHA-1(PCR && input-value)
  il valore in ingresso rappresenta l'evento che si va a "misurare". Non è possibile sovrascrivere direttamente il valore dei vari PCR

Le specifiche del TCG per PC definiscono anche l'uso che si va a fare di ogni PCR:

e cioé per esempio nel PCR4 sarà caricato il valore finale di tutte le misurazioni del MBR (nella maggior parte dei casi una sola).

Altra nota importante: durante l'accensione tutti i PCR vengono resettati (e cioé conterranno 0).

Per comprendere come funziona il secure boot, bisogna introdurre un altro elemento della piattaforma, il Core Root of Trust Module (CRTM). Per banalizzare il concetto, il CRTM è il pezzo di codice IMMUTABILE che su una piattaforma TC viene eseguito per primo e che si occuperà di misurare se stesso ed il BIOS per poi passarvi il controllo. Questo avviene con il seguente pseudocodice:

Extend( PCR0, SHA1 (CRTM))
Extend( PCR0, SHA1 (BIOS))

Dopo di che il controllo viene passato al "BIOS" che procederà alla misurazione degli altri componenti (opzioni del BIOS, MBR, ecc.) e alle normali operazioni di boot. La fase di esecuzione del CRTM e del BIOS, che termina con il passaggio del controllo al MBR, è sempre la stessa e l'unico elemento variabile in gioco è il contenuto finale dei valori dei PCR. Questo significa che il codice contenuto nel MBR verrà eseguito comunque e sarà compito di tale codice prendere in considerazione o meno quanto registrato nei PCR.

A questo punto dovrebbe essere chiaro come funziona il secure boot, almeno in linee generali: si installa un SO che supporta il secure boot su una macchina da zero, il sistema operativo "prende nota" dei valori del PCR considerati da questo interessanti dopodiché se i valori non coincidono vuol dire che qualcosa è cambiato e sta al sistema operativo decidere come notificare l'utente e cosa fare.

I più curiosi invece si chiederanno come è possibile memorizzare tali valori da qualche parte senza che il malintenzionato di turno possa sostituirli e vanificare la protezione offerta dal secure boot. La piattaforma viene in aiuto degli sviluppatori di OS con due API simmetriche, TPM_Seal e TPM_Unseal. La prima prende in input una bitmask (rappresentante i PCR da usare) e un array di byte: l'array viene criptato e "firmato" usando come chiave i valori dei PCR specificati nella bitmask. La seconda fa esattamente l'opposto ma in più restituisce errore se i valori dei PCR, usati per firmare, non coincidono. Il compito del sistema operativo, una volta effettuato il primo boot, è quello di sigillare dei dati (volendo anche casuali) e memorizzarne il risultato sul disco. Nei boot successivi, se si riesce a desigillare il file, vuol dire che il sistema è integro altrimenti qualcosa è cambiato.

La sequenza di misurazioni/esecuzioni è rappresentata da questa figura:

(fonte)

dove in cima alla chain of trust c'è il CRTM. Il CRTM quindi, insieme al chip TPM, è di fondamentale importanza per l'integrità di una trusted computing platform. Un sistema che rispetta le specifiche TCG deve garantire una protezione "assoluta" contro attacchi software contro il TPM e CRTM. Per quanto riguarda la protezione da eventuali attacchi hardware cito da Trusted Computing Platforms:

The TCPA specification requires a limited but specified amount of physical protection for the TPM and CRTM. This reflects reality. In many cases it is impractical to provide a high level of physical protection, and in any case, it is impossible to provide absolute physical protection. If someone wants to physically interfere with a TPM and CRTM, they can (given enough time and money), and there is nothing that can be done to stop them.

Nella maggior parte dei sistemi TCP odierni (come il mio Vaio di lavoro) il CRTM è memorizzato in una parte non modificabile via software del BIOS. Le specifiche prevedono che - laddove il CRTM sia in qualche modo aggiornabile - possa essere aggiornato solo dal vendor del sistema (nel mio caso Sony). Le specifiche tuttavia non prescrivono in nessuna maniera come e dove implementare il CRTM, infatti in questo paper viene preso in considerazione un approccio diverso e proposta una soluzione con il CRTM embedded nello stesso TPM su cui non esprimo nessun parere personale. Nel prossimo post ho intenzione di entrare nei dettagli implementativi della funzionalità bitlocker di Vista che fa uso del TPM laddove presente.

Linko-bibliografia:

Trusted Computing Platforms
TCG Architecture Overview
TCG specifications for PC
How To Build Hardware Support For Secure Startup
A New Approach of TPM Construction Based on J2810
Trusted Computing for Linux
TCPA Misinformation Rebuttal
Trusted Computing Platform
The CRTM and authenticated boot process

-enjoy