jump to navigation

Deaglio indagato? November 28, 2006

Posted by laspinanelfianco in Trusted Computing.
3 comments

Francamente, sono piuttosto perplesso.

Il DVD di Deaglio contiene un film che riguarda la famosa “notte dei misteri” e, di conseguenza è difficile accusarlo di diffondere delle notizie, buone o cattive che siano. Semmai, lo si può accusare di diffondere delle opinioni.

A parte questo, non mi è chiaro come si possa affermare che il tipo di broglio ipotizzato da Deaglio sia impossibile. Anche se ciò che conta sono i dati ufficiali su carta, ciò che è effettivamente trattato durante l’elaborazione, sono i dati di tipo informatico, facilmente manipolabili da (quasi) chiunque sia in possesso delle chiavi di accesso necessarie.

A questo punto, si impone una attenta sorveglianza su questo tema. Che i sistemi elettorali delle democrazie occidentali siano, come minimo, “a rischio”, lo hanno già dimostrato le ultime due elezioni presidenziali americane e le ultime elezioni italiane. Non mi sembra proprio che si possano liquidare certe ipotesi come pura fantasia, soprattutto dopo che il Governo Berlusconi ha messo in atto una riforma elettorale che viene considerata da tutti, persino da coloro che l’hanno voluta, un vero obbrobrio.

Creare una (quasi) Trusted Platform con un LiveCD ed una Smart Card August 22, 2006

Posted by laspinanelfianco in Trusted Computing.
add a comment

In altre occasioni ho già spiegato che quasi tutte le funzioni interessanti di una Trusted Platform possono essere ottenute anche da una semplice Smart Card. Più esattamente, si possono ottenere da una Smart Card tutte le funzionalità che sono realmente utili all’utente del PC, mentre si possono lasciare non implementate quelle che sarebbero utili solo ai suoi fornitori e che, molto probabilmente, verrebbero usate solo per controllare l’utente e limitare la sua libertà di azione. In questo articolo vedremo come sia teoricamente (e praticamente) possibile creare una piattaforma di calcolo quasi completamente affidabile, e quindi quasi completamente equivalente ad una Trusted Platform “tradizionale”, usando un LiveCD di Linux, una chiave di memoria USB ed una Smart Card. Chiariamo subito che si tratta di una esposizione teorica: per creare una piattaforma di questo tipo sarebbe necessario sviluppare diversi componenti software che ora non esistono. Questa peraltro è anche la situazione corrente delle “vere” Trusted Platform che, in questo momento, non dispongono ancora del software necessario per sfruttare la presenza del TPM e di altri elementi.

Le funzionalità della Trusted Platform che vogliamo replicare

Le funzionalità di una TP che potrebbero essere realmente utili ad un utente e che quindi vorremmo poter replicare sono le seguenti.

  1. La possibilità di verificare la integrità e quindi la affidabilità della nostra piattaforma HW+SW (PC, BIOS, Sistema Operativo e programmi) prima dell’uso. In buona sostanza, ci interessa replicare le funzionalità di Secure Boot e di Software Integrity Checking.
  2. La possibilità di cifrare i nostri dati sul disco. Ci interessa quindi replicare sia le funzionalità di cifratura “simmatrica” delle TP che, se possibile, la funzionalità di Sealed Storage.
  3. La possibilità di cifrare le nostre comunicazioni con altre macchine collegate in rete.

Le funzionalità che non vogliamo replicare

Non ci interessa replicare alcune funzionalità che non ci sarebbero realmente utili o che, peggio, sarebbero utili solo ai nostri “avversari”, come le seguenti.

  1. La possibilità di verificare quale sia la configurazione SW della nostra macchina e di verificare l’integrità del nostro SW da una postazione remota, cioè la famigerata “Remote Attestation”. Questa funzionalità è del tutto inutile per noi che abbiamo accesso fisico alla nostra macchina e consentirebbe invece ai nostri fornitori di discriminarci sulla base del software che usiamo.
  2. La protezione delle aree di memoria usate dai singoli programmi, cioè la funzionalità di Memory Curtaining. Dato che il software che andremo ad usare sarà sotto il nostro diretto e quasi assoluto controllo, non avremo bisogno di questa funzionalità per garantire la sicurezza e la affidabilità del nostro sistema.
  3. La protezione dei canali di I/O (Display, Mouse, Tastiera, Casse audio, Microfono, etc.). Anche in questo caso, dato che il software che andremo ad usare sarà sotto il nostro controllo diretto, non avremo bisogno della funzionalità di Secure I/O per garantire la sicurezza e l’affidabilità del nostro sistema.

Le funzionalità che non si possono replicare

Alcune delle funzionalità di una Trusted Platform dipendono strettamente dalla sua struttura HW e non possono essere replicate da un sistema come quello che noi ipotizziamo. Queste funzionalità sono (almeno) le seguenti.

  1. La certificazione della identità della piattaforma (Attestation). Dato che le chiavi di identificazione e di autenticazione che andremo ad usare risiedono su una Smart Card rimovibile, e non su un TPM saldato alla MB, queste chiavi possono certificare solo l’identità della Smart Card e, di conseguenza, del suo detentore (l’utente), non quella della piattaforma HW. Francamente, è difficile pensare che questo sia un difetto.
  2. La protezione delle aree di memoria (Memory Curtaining) richiedono un apposito supporto HW e non possono essere replicate da questo sistema. Per fortuna, possiamo rinunciare a questa funzionalità senza grandi rimpianti perchè abbiamo il controllo diretto del software che andremo ad usare. Si noti però che sfugge al nostro controllo il BIOS del PC ospite.
  3. La protezione dei canali di I/O (Secure I/O) richiede un apposito supporto HW e non può essere replicata. Anche un questo caso, ne possiamo fare a meno, in gran parte dei casi, perchè abbiamo il controllo diretto del SW usato. Tuttavia, l’assenza di questa funzionalità rende il nostro ipotetico sistema vulnerabile all’azione dei key logger e degli screen logger di tipo hardware.

Si noti che le Trusted Platform tradizionali non possono ipotizzare di avere il controllo diretto e quasi assoluto del software che viene installato ed usato sulla macchina. Per questo motivo, esse non possono rinunciare, come noi facciamo, alle funzionalità di Secure I/O e Memory Curtaining.

Le funzionalità della Smart Card

Le funzionalità che la Smart Card è in grado di offrire e che noi utilizzeremo sono le seguenti.

  1. Una chiave crittografica in grado di identificare univocamente la Smart Card. Questa funzionalità è analoga alla Attestation di un TPM ma non è del tutto sovrapponibile ad essa a causa del fatto che la SC è rimovibile mentre il TPM non lo è.
  2. Una o più chiavi crittografiche in grado di identificare in modo univoco una o più identità dell’utente. Questa funzionalità è del tutto equivalente alle Attestation Identity Key del TPM.
  3. Delle modeste funzionalità di cifra secondo un algoritmo asimmetrico a chiave pubblica, come RSA. Questa funzionalità è del tutto equivalente a quella del TPM. Si noti che nè la SC nè il TPM vengono usati come co-processore crittografico per cifrare grandi quantità di dati sul disco o interi flussi di comunicazione. Le loro funzionalità vengono usate solo per cifrare le chiavi usate a loro volta da normali programmi di cifra, come GPG.
  4. Delle funzionalità di firma digitale e di creazione di certificati digitali del tutto analoghe a quelle del TPM. Queste funzionalità possono essere usate, tra l’altro, per verificare e garantire l’integrità del software e della configurazione, esattamente come avviene sulle Trusted Platform tradizionali. Nel nostro caso, tuttavia, questo tipo di certificazione spesso non è necessaria perchè il software è comunque sotto il nostro controllo diretto (proviene da un CD non riscrivibile).
  5. La possibilità di conservare piccole quantità di dati all’interno della SC (di solito, le chiavi di cifra usate dai programmi crittografici residenti sul PC).

FSFE Smart Card

Figura 1. La Smart Card crittografica della Free Software Foundation. Un gadget irresistibile.

La nostra Trusted Platform artigianale

La nostra TP artigianale sarà composta dai seguenti elementi.

  1. Un LiveCD di Linux (andrebbe bene anche un altro S.O., come BSD), debitamente personalizzato.
  2. Una Smart Card (quasi di qualunque tipo) ed il relativo reader
  3. Una flash memory (una chiave USB), non strettamente necessaria
  4. Alcuni programmi ausiliari, memorizzati sul CD
  5. Alcuni elementi di configurazione memorizzati sul CD
  6. Alcuni dati “sensibili” memorizzati sulla SC

Le personalizzazioni del LiveCD

Come è noto, un LiveCD (o LiveDVD) di Linux è una versione i Linux che risiede su un CD e che può essere lanciata dal CD stesso, senza procedere ad una installazione del Sistema Operativo e dei programmi sul disco fisso dell’utente. Una volta lanciato Linux, i dati della configurazione del sistema (ad esempio la configurazione della connessione ad Internet e del client di posta) ed i dati prodotti dall’utente (ad esempio i documenti creati con OpenOffice) possono essere salvati su un’area del disco fisso del sistema ospite (anche in formato cifrato) o su una memoria flash (chiave USB).

Knoppix

Figura 2: La mitica Knoppix in versione DVD. Quasi tutto l’universo Linux su un singolo disco.

La caratteristica saliente del CD è che tutto il software che noi andremo ad usare, dal kernel di Linux ad OpenOffice, può essere considerato affidabile perchè proviene da questo CD non riscrivibile. L’unico modo di modificare questo software è quello di creare un nuovo CD e sostituirlo a quello esistente. Questa è una operazione che certamente non sfuggirebbe alla nostra attenzione. Basterebbe un’occhiata al CD per capire che non è più quello che siamo abituati ad usare. Basta una firma manuale con un pennarello sul lato scrivibile del CD per rendere molto difficile la sua sostituzione a nostra insaputa. Una volta lanciata una copia affidabile di Linux, un eventuale malintenzionato non avrebbe più occasione di inserirsi nel processo a nostra insaputa.

Solo l’installazione di nuovo software, scaricato da Internet, fornirebbe al malintenzionato una occasione di intrusione ma è facile premunirsi anche nei confronti di questa minaccia: basta controllare le firme digitali (i checksum) del software che si desidera installare prima di installarlo o, in modo ancora più sicuro, installare solo sofware che proviene dal CD stesso.

Nella nostra esposizione possiamo supporre che l’utente abbia provveduto a personalizzare la sua copia del LiveCD e che quindi i dati di configurazione “fissi”, come la configurazione del client di posta, siano già stati “incisi” nel CD.

I dati creati dall’utente ed i dati di configurazione che dipendono dalla postazione usata (come la configurazione della connessione alla rete) verranno memorizzati in un un file del sistema ospite o su una chiave USB (cifrata, anche se questo non sarebbe obbligatorio). I documenti possono anche essere conservati (in formato cifrato) su dischi di rete (GMail/GSpace).

Per poter servire al nostro scopo, il LiveCD deve essere configurato in questo modo.

  1. Deve essere presente del software in grado di cifrare file e canali di comunicazione, cioè qualcosa come GPG e/o SSH. Può essere utile anche un sistema in grado di cifrare al volo i file o interi file sistem, come TrueCrypt o simili. Le funzionalità di questo software vengono usate per garantire l’integrità del sistema e la protezione di dati e canli di comunicazione.
  2. Sarebbe utile che fosse presente un sistema di Integrity Checking come quelli usati da molti sistemi IDS (Intrusion Detection System), come Tripwire o AIDE. Questo sistema può essere usato per garantire l’integrità del sistema (anche se, in realtà, non sarebbe necessario).
  3. Deve essere presente il supporto per la SC ed il relativo reader
  4. Sul CD deve essere presente un file cifrato (od una partizione cifrata) che contiene i checksum di tutti i programmi disponibili sul CD, generati da AIDE o da altri programmi. Le chiavi di accesso a questa partizione cifrata sono memorizzate nella SC. Questo accorgimento serve solo ad impedire ad un marpione, tecnicamente molto abile, di sostituire il nostro LiveCD con uno molto simile ma pieno di software “taroccato”. In realtà, probabilmente è più semplice firmare a mano il CD sul lato scrivibile.

L’identificazione dell’utente

Per evitare che tutto il nostro sistema diventi una facile preda di un eventuale ladro che riuscisse ad impossessarsi sia del LiveCd che della SC, è necessario che tutto il sistema si assicuri di avere a che fare proprio con noi al momento del lancio, e non con un estraneo. A questo provvede, senza nessuna personalizzazione, la SC. Al momento del lancio del LiveCD, il programma di login deve chiedere di vedere la nostra SC per permetterci di accedere alla sessione. La SC, a sua volta, chiederà il nostro PIN per abilitare il login. Si può trovare la documentazione necessaria a questa URL: http://www.strongsec.com/smartcards/howto/html/SmartCard-Login-HOWTO.html . Linux dispone già di tutti gli strumento necessari a questo scopo ed il livello di sicurezza che è in grado di garantire è “military-grade”.

L’identificazione della piattaforma ed il secure boot

A nostra volta, noi utenti dobbiamo essere in grado di verificare che il LiveCD che stiamo per usare sia proprio il nostro e che contenga solo software che noi riteniamo affidabile e sicuro. A questo scopo si usa la partizione che contiene i checksum (SHA-1, MD5, CRC32 o quello che vi pare) di tutti programmi presenti sul CD.

Al momento del lancio, un apposito programma (uno script di init, probabilmente un “wrapper” di Tripwire o qualcosa di simile) deve eseguire questa sequenza di operazioni:

  1. Deve chiedere alla SC le chiavi di accesso alla partizione cifrata sul CD. La SC probabilmente ci chiederà di inserire il nostro PIN per autorizzare l’operazione.
  2. Deve aprire la partizione cifrata, leggere i singoli checksum, ricalcolare i checksum per i programmi interessati e confrontare i due risultati. Se i risultati coincidono, abbiamo a che fare con un CD integro ed affidabile. In realtà, è probabile che in questa fase si faccia uso di “digest di digest”, esattamente come fa una normale TP, e che si limitino le verifiche al minimo indispensabile (driver, kernel, etc.).
  3. Se tutto quadra, deve lanciare i vari programmi (kernel, X11, desktop manager, etc.)

Questa sequenza ricalca quella che viene eseguita da una normale TP e svolge le stesse funzioni (Secure Boot). Alcuni sistemi IDS (Intrusion Detection System) possono essere installati sul CD e configurati per eseguire questa verifica all’avviamento.

Tuttavia, dato che noi possiamo garantirci l’identità, la integrità e la affidabilità del CD-ROM in altro modo, ad esempio firmandolo a mano con un pennarello, non è realmente necessario usare questo sistema. Noi possiamo contare sul fatto che il CD-ROM debba essere sostituito per poter alterare il software che esso contiene (si tratta di un dispositivo non riscrivibile) mentre la TP tradizionale non può fare la stessa ipotesi riguardo al software che risiede su un hard disk.

Il controllo di integrità del software applicativo

Naturalmente, anche il software applicativo può essere verificato nello stesso modo che abbiamo appena esposto e che riguarda solitamente il sistema operativo. Nel caso di sofware scaricato da Internet, ed installato su una partizione scrivibile del disco fisso (o su un chiave USB), è necessario verificare personalmente, a mano, che il programma non sia stato alterato. A questo scopo quasi tutti i produttori mettono a disposizione i checksum dei file scaricabili.

La cifratura dei canali di comunicazione esterni

La cifratura dei canali di comunicazione che esistono tra il nostro PC ed altre macchine della rete è affidata ai soliti programmi: OpenSSH, Firefox con SSL e via dicendo. Le chiavi di cifra usate da SSH possono essere conservate sulla SC od all’interno di una apposita partizione cifrata del CD (più probabilmente un file cifrato).

La cifratura dei file

La cifratura di file, e persino di interi file system, può essere affidata ai programmi disponibili abitualmente su Linux, come GPG, TrueCrypt e via dicendo. Le chiavi di cifra usate possono (e dovrebbero) essere conservate all’interno della SC. Tra i dati presenti in queste partizioni cifrate saranno quasi certamente presenti anche le chiavi di cifra usate da OpenSSH ed altri programmi crittografici. Legando un file cifrato ad un digest della configuazione corrente del sistema è possibile ricreare la funzionalità di Sealed Storage delle Trusted Platform.

La firma digitale

La firma digitale necessaria per certificare l’origine e la integrità dei documenti verrà apposta dalla nostra SC, su nostra richiesta. Questa è una delle sue normali funzionalità e ricalca fedelmente le funzionalità offerte da un TPM. Funzioni analoghe della Smart Card possono essere usate per creare dei certificati digitali con cui garantire l’autenticità e la integrità dei documenti o della configurazione del sistema (una funzionalità equivalente alla Attestation delle Trusted Platform).

Vantaggi

Un sistema LiveCD+Smart Card come questo può sostituire una vera Trusted Platform in quasi tutte le sue applicazioni. Ad esempio, usando questo sistema potrebbe diventare ragionevolmente sicuro usare una postazione pubblica (da un Internet cafè) per accedere alla propria posta riservata.

I veri vantaggi di questa implementazione “artigianale” sono però di carattere “politico”:

  1. Non esiste una chiave di identificazione univoca della nostra piattaforma
  2. Non esiste e non può essere usata (contro di noi) la Remote Attestation
  3. Siamo noi a decidere ogni minimo aspetto della piattaforma, della sua configurazione, del suo uso e del suo aspetto.
  4. Abbiamo a che fare con degli oggetti fisici (Smart Card, LiveCD, chiave USB). Basta un’occhiata per capire se qualcosa è cambiato. Basta cambiare uno qualunque di questi oggetti per cambiare ciò che non ci va più a genio.

Svantaggi

Questo sistema ha alcuni grossi limiti tecnici rispetto ad una vera Trusted Platform:

  1. Non è in grado di proteggere l’utente dallo spionaggio condotto con dei key logger o degli screen logger. Ciò che appare sullo schermo e ciò che viene digitato sulla tastiera può essere intercettato e registrato, all’insaputa dell’utente, da appositi dispositivi hardware che questo sistema non potrebbe rilevare.
  2. Non è in grado di proteggere l’utente dagli effetti di un BIOS malvagio

Links

http://www.knoppix.org/

http://en.wikipedia.org/wiki/LiveCD

http://www.fsfe.org/en/card

http://en.wikipedia.org/wiki/Smart_Card

http://sourceforge.net/projects/aide

http://sourceforge.net/projects/tripwire/

http://www.gnupg.org/

http://www.openssh.com/

http://www.truecrypt.org/

http://encfs.sourceforge.net/

http://en.wikipedia.org/wiki/Key_logger

http://www.surfpack.com/software/keycapture/

Trusted Computing e-book Release 2.0 Beta 1 July 3, 2006

Posted by laspinanelfianco in Trusted Computing.
4 comments

Sul mio sito di appoggio, trovate la nuova versione del mio e-book sul Trusted Computing.

http://alessandrobottoni.interfree.it/

(sezione “pubblicazioni”)

o, direttamente:

http://alessandrobottoni.interfree.it/download/trusted_computing_2.0_beta_1.pdf

Questa nuova versione è completamente diversa dalla precedente e contiene una ampia raccolta di articoli apparsi su queste pagine. Per i lettori più affezionati sarà quindi una lettura inutile e noiosa. La mia speranza è che sia invece un modo semplice e veloce di avvicinarsi a questo tema per coloro che iniziano ad occuparsene ora.

Fatemi sapere cosa ne pensate.