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:

TPMArchitecture (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:

PCR Uso
0 CRTM, BIOS and Platform Extensions
1 Platform Configuration
2 Option ROM Code
3 Option ROM Configuration and Data
4 IPL Code (MBR)
5 IPL Code Configuration and Data
6 State Transition and Wake Events
7 Reserved for future usage

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:

ChainTrust (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

Technorati tags: ,

Pubblicato mercoledì 5 dicembre 2007 alle 4:43 PM - 4 commenti so far
Archiviato in: Security, Trusted Computing

Paranoie vere

In questo post, che segue quello sulla definizione di integrità e Paranoiaquello sulla definizione di chain of trust, mi interessa presentare i quattro scenari che rappresentano le paranoie vere, quelle che hanno portato alla definizione del TPM così com'è oggi nella versione 1.2. In un certo senso tali scenari pre-datano l'invenzione del TPM e quindi esistono a priori. L'individuazione di tale scenari  porterà (spero) a chiarire due ruoli distinti ma spesso maliziosamente confusi nel tentativo di confutare la bontà di alcuni approcci (tornando all'esempio dei passaporti, qualcuno spesso confonde il ruolo del ministro degli interni con quello del titolare del passaporto). Uno dei quattro scenari l'ho già visto "implementato" (senza TPM e quindi con lacune importanti) nell'ultimo viaggio di lavoro quasi a garanzia che la paranoia è un linguaggio universale e universalmente riconosciuto.

Joe il paranoico (risk management)
La preoccupazione di Joe è il furto del portatile o la violazione dell'integrità del suo sistema. Joe non è un genio dell'informatica e qualsiasi mezzo che possa ridurre tali rischi è ben accetto, in quanto in possesso di informazioni di altissimo valore. In questo scenario proprietario ed utente sono la stessa entità.

Gestione dell'hardware
Il dipartimento IT della Vip&Vip Inc. è molto paranoico per quanto riguarda l'accesso alla rete interna. La soluzione perfetta sarebbe quella di garantire l'accesso alla rete solo a PC di proprietà dell'azienda opportunamente configurati. In questo caso invece proprietario (l'IT di Vip&Vip) e l'utente sono entità disgiunte.

E-commerce
Jeannie lavora con l'azienda Quartz&Tempus che gestisce contrattazioni di titoli in borsa. Sia Jeannie che Q&T sono molto paranoici riguardo la legittimità e la non repudiabilità delle transazioni e per protezione reciproca stanno cercando un protocollo che possa garantire entrambi. In questo scenario proprietario ed utente sono la stessa entità.

Gestione della sicurezza e risposta alle emergenze
Un net-worm imperversa nella rete interna di Vip&Vip e il dipartimento IT vuole dirottare tutti i PC infetti in una subnet con sandbox dove permettere di scaricare le patch necessarie. Il worm è abbastanza evoluto ed in grado di ingannare anche i più sofisticati engine di scansione. In questo caso invece proprietario (l'IT di Vip&Vip) e l'utente sono entità disgiunte.

Due note:

  1. Altri scenari sono ovviamente possibili, come pure anti-scenari (questa forse l'ho inventata io, ma mi piace la definizione di anti-pattern). Seguirà un post su qualcuno di questi.
  2. Ho volutamente evitato di spiegare come risolvere i vari problemi con un TPM.

Nel prossimo post finalmente si parla "in codice": ovvero di registri, di algoritmi e protocolli. Cominciando da come implementare il secure boot.

-quack

Technorati Tags:

Pubblicato martedì 23 ottobre 2007 alle 4:10 PM - 20 commenti so far
Archiviato in: Trusted Computing

Integrita' ed identita'

Uno degli argomenti più ostici da affrontare quando si parla di Trusted Computing è la differenza tra i concetti di identità e di integrità. Sebbene strettamente correlati tra loro, non sono la stessa cosa. Prima di addentrarcisi su come funziona tecnicamente il famoso chip Fritz, è necessario chiarire tale distinzione. Lo faccio con una metafora spero banale.pass-elettr

Per viaggiare all'estero verso paesi extra-europei c'è bisogno del passaporto. La foto con i dati anagrafici sul passaporto dicono all'addetto alla frontiera chi siamo. Chi siamo corrisponde alla nostra identità che viene verificata appunto attraverso il matching con la foto sul nostro passaporto. Il fatto che il passaporto sia impossibile da modificare, ossia che sia tamper-proof, rende perfettamente il concetto di integrità del passaporto. Se scopriamo che il passaporto ha la pellicola trasparente manipolata, possiamo essere certi che l'integrità del passaporto è stata violata, anche se la foto sul passaporto (identità) è la stessa. Il guaio è - a voler dare retta a qualcuno - che l'addetto alla frontiera è estremamente interessato all'integrità del passaporto in misura maggiore o uguale all'identità. Anche se io sono certo di essere io al 100%, l'ufficiale alla frontiera non può più avere tale certezza in quanto l'identità senza integrità non serve a molto in una relazione tra entità sconosciute. A completare l'esempio, calzante quasi come un guanto, il fatto che la pellicola trasparente sul passaporto protegge solo una parte sebbene alquanto importante del passaporto stesso: nessuno ci vieta di pasticciare con ghirigori degni di Mirò tutte le restanti pagine del passaporto.

Trasponendo l'esempio nel mondo del trusted computing, la foto (identità) coincide con la password, la smartcard o l'impronta digitale (o meglio ancora una combinazione delle tre); la pellicola trasparente con il secure boot via TPM. Le due cose sono complementari[1] ma purtroppo anche strumenti di identità abbastanza complessi come una smart card o un'impronta digitale sono totalmente inutili per garantire l'integrità. A peggiorare le "cose del software" ed aumentare la paranoia dei tecnofili, un'ulteriore differenza tra l'esempio del passaporto e il mondo software: la scalabilità degli attacchi nel mondo del computing. Se manipolare mille passaporti (entrare nella casa di qualcuno, manipolare, usare e restituire) è mille volte più difficile che manipolarne uno solo, portare a termine un milione di attacchi usando una vulnerabilità 0-day combinata è facile quasi quanto portare a termine un singolo attacco basato sulla stessa vulnerabilità (se la vulnerabilità è "abbastanza buona"). Nella trasposizione dell'esempio, il fatto che possiamo usare le pagine non sigillate del passaporto come vogliamo corrisponde con il fatto che possiamo più o meno lanciare, su una macchina integra, tutti sistemi operativi che vogliamo con tutti i processi che vogliamo, compresi virus e altre schifezze (i menzionati ghirigori): l'unica cosa che non può accadere è che qualcuno modifichi la foto o i dati anagrafici gli elementi importanti per l'integrità del sistema (e questo lo decide il paese che rilascia il passaporto sistema operativo/utente) senza che il titolare se ne possa accorgere.

Un'ulteriore nota sul concetto di integrità. L'integrità è un valore booleano (vero/falso) e non un floating point; non ci sono valori intermedi di integrità (esempio: il sistema è integro al 99.999%). Quanto questo valore interessi il proprietario del sistema è un altro paio di maniche che dipende anche dalla paranoia ma non solo del propetario: se il propetario del sistema è il povero IT manager che deve gestire decine di migliaia di desktop qualsiasi valore inferiore alla certezza matematica potrebbe non avere nessun significato.

Infine un'ultima osservazione: il passaporto tamper-proof è una tecnologia moderna interessante. Come avviene per tutte le tecnologie si possono teoricamente verificare degli abusi. La critica che più va di moda è cosa succederebbe se tutte le pasticcerie del mondo decidessero di vendere bigné solo a cittadini nati in anni dispari che presentano un passaporto tamper-proof alla cassa. È per questo che il gruppo promotore "Mondo senza passaporti", in virtù del fatto che alcuni paesi che rilasciano passaporti sono delle "sanguinarie" dittature, nell'interesse "eventuale futuro" dei diritti dei compratori di bigné ha fatto richiesta presso il "ministero dei passaporti mondiali" che - in base alla pura discrezione del titolare del passaporto - la pellicola trasparente, e quindi anche i dati relativi all'identità, sia facilmente falsificabile; la motivazione ufficiale è "non si sa mai". Non sto scherzando. E pensare che basterebbe smettere di comprare bigné!

Nel prossimo post intendo analizzare quelle che sono le vere paranoie ed entrare nei dettagli tecnici di come il TPM intende risolverle; il secure boot via chain of trust è solo una di quelle.

-quack

[1] Nella realtà è possibile usare - ma è sconsigliato - una delle feature del TPM anche per scopi di identità ma non viceversa (usare la smart card per garantire l'identità)

Technorati tags:

Pubblicato domenica 21 ottobre 2007 alle 5:00 PM - 37 commenti so far
Archiviato in: Trusted Computing

Chain of trust

Sabato scorso avevo proposto un quiz sul tanto odiato TPM. La domanda era cosa offre un TPM che una Smart Card non può offrire. La risposta è riassunta nel titolo di questo post, la chain of trust.

Il TPM - essendo un dispositivo riconosciuto e supportato da BIOS - permette di validare il Sistema  Operativo prima che quest'ultimo venga caricato in memoria, cominciando appunto dal boot loader: in parole povere iTPMChip l TPM è in grado di garantire l'integrità del boot loader _AL_ sistema operativo; l'unico modo safe in cui questo può avvenire è via hardware e necessariamente prima che il sistema operativo venga caricato. Perché non ci si può fidare del boot loader solamente via software? Perché il boot loader potrebbe venire facilmente aggirato e programmato per mentire (i rootkit sono solo una via). Il TPM, per come è costruito, garantisce l'integrità fisica delle chiavi private in esso contenute: modificarle dall'esterno è impossibile, come può avvenire con una chiave memorizzata su una chiavetta USB.

Per far funzionare una Smart Card, o un dispositivo SD, c'è bisogno di driver e di un sistema operativo. Per questo motivo una Smart Card, laddove non supportata a livello di BIOS[1], non può essere usata come dispositivo per garantire la chain of trust.

Nota importante: il compito principale del secure boot non è quello di impedire di far partire software "non firmato" ma è quello di dare al software interessato la risposta «certa» alla domanda «ma io sono veramente io?». La reazione a tale risposta dipende quindi solamente da «chi» fa la domanda e non dal TPM stesso.

C'è infine un aspetto pratico: se si usasse una Smart Card per memorizzare le chiavi di cifratura di bitlocker, il trafugamento fisico dei dati sarebbe un pelino più semplice.

Questo da parte mia è il primo post sull'argomento Trusted Platform. Cercherò di evitare accuratamente «false» paranoie; quelle vere vanno prese in considerazione in quanto alla base dei requirements per creare una Trusted Platform.

-quack

Technorati Tags: ,

[1] Ad oggi, non sono a conoscenza di sistemi in vendita che supportino il secure boot via smartcard.

Pubblicato martedì 16 ottobre 2007 alle 6:38 PM - 31 commenti so far
Archiviato in: Security, Trusted Computing