TCFS - Transparent Cryptographic File System -, un filesystem cifrato per Linux.

Introduzione.

Al giorno d'oggi, tenuto conto del notevole progresso della tecnologia di rete, è realmente fattibile condividere risorse in rete. Non solo in rete locale (LAN) ma anche su rete globale (WAN o Internet). Con l'avvento sul mercato di strumenti wireless (quali PDA o notebook) è sempre maggiore la richiesta di repository accessibili da qualunque punto della rete e attraverso diversi tipi di rete. In questa ottica, i file system di rete, uno dei primi servizi ad esser stato distribuito in rete, assume un ruolo sempre più necessario.

Il distribuire in rete servizi, risorse e applicazioni, se da un lato offre notevoli vantaggi, dall'altro crea notevoli problemi di sicurezza: utenti non autorizzati possono ottenere accesso a servizi ristretti. Nell'esempio di file system distribuiti in rete, due sono le entità in gioco: da un lato il server che ha accesso diretto al file system locale, dall'altro il client che richiede accesso al file system. Uno dei più diffusi file system di rete è NFS (Network File System). A dispetto della sua notevole diffusione, l'NFS non si pone affatto il problema della sicurezza. Nessun tentativo di proteggere i dati in rete, nessun tentativo di identificazione del client da parte del server, nessun tentativo di identificazione del server da parte del client. In questo contesto, niente proibisce ad un malintenzionato accesso all'intero file system che il server condivide.

In questo articolo verrà introdotto TCFS (Transparent Cryptographic File System), un file system di rete che affronta e risolve il problema di proteggere i dati in un file system di rete. Il progetto nacque nel 1995 ed ha subito, nel corso degli anni, notevoli migliorie con l'aggiunta di nuove uniche caratteristiche (come la condivisione di file cifrati in gruppo).

Scopi di TCFS.

Durante la progettazione di TCFS si cercò di trovare un sistema capace di fornire un robusto meccanismo di sicurezza che implicasse quanto meno coinvolgimento possibile da parte dell'utente finale. Questo meccanismo doveva garantire:

1. un modello di fiducia minimo;
   
2. impatto minimo sull'amministrazione del sistema;
   
3. impatto minimo sulle applicazioni client;
   
4. impatto minimo sull'utente finale.

L'architettura di TCFS è stata progettata per rispettare i punti appena esposti, pur rimanendo semplice nella sua essenza: ogni qualvolta una applicazione, in esecuzione sul client, richiede un blocco di dati, il kernel del client effettua una richiesta al server. Il server invia i dati al client in maniera cifrata. Il kernel del client decifra i dati e li passa alla applicazione che li ha richiesti.
Il processo di scrittura funziona in maniera analoga: l'applicazione in esecuzione sul client desidera salvare dati sul file system di rete. Il kernel del client riceve i dati dall'applicazione, li cifra e li invia (cifrati) al server. Quest'ultimo salva i dati sul file system senza minimanente toccarli.

L'utente ha il solo onere di passare la chiave al kernel all'inizio della sessione di lavoro. Non deve nemmeno ricordare altre password all'infuori della propria password di login (a meno che non voglia usare una passphrase).

Questa semplice architettura rispetta i quattro punti sopra esposti:

1. modello di fiducia minimo:
   i dati compaiono in chiaro (sia quelli letti che quelli da scrivere) solo sul client. Il server riceve solo dati cifrati e non ha alcun modo per decifrarli. In rete i dati viaggiano sempre cifrati (sia in lettura che in scrittura). Inoltre, poich&ecute; il processo di cifratura e decifratura dei dati avviene solo sul client, la chiave stessa non verrà mai spedita attraverso la rete. L'unica macchina fidata è, quindi, il client.
   
   
2. impatto minimo sull'amministrazione del sistema:
   il server funge da normale server NFS. L'amministratore di sistema della macchina server può del tutto ignorare il fatto che il file system esportato sia in realtà un file system TCFS. Per lui è un normale file system NFS.
   
   
3. impatto minimo sulle applicazioni client:
   nessuna modifica ai sorgenti e nessuna ricompilazione delle applicazioni installate sul client è necessaria. Le usuali funzioni di gestione di file sono rimaste inalterate. Non è nemmeno richiesto che le applicazioni abbiano a conoscere come gestire le chiavi. Tutto ciò è gestito, trasparentemente, da TCFS. Le applicazioni client ignorano del tutto il fatto di lavorare su file salvati su TCFS. Così come NFS viene visto dalle applicazioni come un normale file system locale, così accade anche per TCFS.
   
   
4. impatto minimo sull'utente finale:
   TCFS ha un impatto minino sull'utente finale. In alcuni casi addirittura nullo. Utenti sulla macchina client (nel caso questa sia condivisa da più di un utente) possono accedere ai loro file ignorando del tutto che essi siano conservati su TCFS. Ciò non vieta, però, la possibilità, ad utenti che lo richiedano, di un maggiore controllo sulle regole di accesso ai file. TCFS fornisce a questo tipo di utenti completa gestione delle chiavi di accesso e l'abilità di controllare quali file debbano essere cifrati e quali no.

Panoramica delle caratteristiche di TCFS.

L'ultima versione di TCFS (la 3.0 attualmente non ancora completa ed in versione beta) implementa le seguenti funzionalità:

1. data integrity check:
   ad ogni blocco di un file cifrato con TCFS viene aggiungo un piccolo check (un hash). Questo hash viene controllato ad ogni lettura del blocco. Se il controllo ritorna errore, allora il blocco è stato modificato sul server o durante il viaggio in rete. In questo caso TCFS
   Per ogni file viene generata una chiave diversa. Questa chiave viene cifrata con la chiave di sessione dell'utente e conservata all'interno dell'header del file. Per ogni blocco dati alla file key viene aggiunto il numero del blocco. In questo modo ogni blocco viene cifrato usando una chiave differente. Blocchi uguali daranno quindi output diverso, sia in file diversi che all'interno dello stesso file.
   ritorna un errore all'applicazione richiedente.
   
2. dynamic encryption modules:
   È possibile scegliere, per ogni singolo file o directory, il motore di cifratura da usare per cifrarlo. Nel caso delle directory questo significa scegliere con che motore di cifratura cifrare i nomi dei file e che motore usare per cifrare i nuovi file appena creati. È comunque possibile cambiare il motore di cifratura ogni volta che si vuole.
   È possibile inserire o rimuovere motori di cifratura a runtime, senza bisogno di far ripartire il sistema, senza bisogno di rilanciare TCFS e addirittura mentre TCFS stesso sta lavorando per altri utenti.
   Questo è stato ottenuto sfruttando appieno il caricamento di codice dinamico (i moduli) presente in Linux. Il motore di cifratura usato per cifrare un file (o directory) è salvato nel suo header. Quando viene effettuata una lettura/scrittura in quel file, viene caricato il modulo corrispondente in memoria. Il modulo, una volta caricato, provvederà a registrare le proprie funzioni di cifratura/decifratura. In questo modo TCFS potrà usarle per cifrare/decifrare il file.
   
   
3. group sharing of files:
   È possibile condividere file o directory tra gruppi di utenti. Per ogni gruppo viene generata una chiave (all'atto della creazione del gruppo stesso). Ad ogni membro del gruppo viene data una share (un pezzo di chiave). Quando una certa soglia (threshold, definibile per ogni gruppo) di utenti è connessa al sistema ed ogni utente ha immesso la propria share, allora, e solo allora, la chiave diventa disponibile al sistema ed è possibile cifrare/decifrare i file del gruppo.
   È matematicamente impossibile ricuperare la chiave (non conservata in nessun database, al contrario della chiave utente) se un numero di utenti inferiori alla soglia combina le proprie share.
   
   
4. Kerberos support:
   Ancora non disponibile in TCFS 3.0 beta, dovrebbe essere disponibile nella sua versione finale. Sarà possibile autenticare un utente, e quindi ottenere la chiave di sessione, utilizzando Kerberos.
   La gestione delle chiavi in TCFS è totalmente svincolata dal core di TCFS stesso. Tutta la gestione delle chiavi è affidata ad una libreria esterna chiamata tcfslib. Al momento la tcfslib fornisce un sistema base (Basic Key Management System) per la gestione delle chiavi (cifrando la chiave di sessione di TCFS con la password di login dell'utente).
   Nella versione finale stabile di TCFS 3.0 sarà possibile gestire le chiavi appoggiandosi al sistema di autenticazione di Kerberos.
   
   
5. TCFS-aware application support:
   Anch'esso ancora in fase di sviluppo, sarà disponibile nella versione finale stabile di TCFS 3.0.
   Grazie all'uso di un header TCFS è possibile salvare, in maniera sicura, informazioniTCFS e sfruttare l'header del file cifrato per salvare flag o dati aggiuntivi (metadata).
   Sarà sviluppato un intero set di funzioni di libreria (API) per la gestione dei metadata utente. aggiuntive riguardanti un file cifrato. È possibile sviluppare una qualsiasi applicazione

Links utili

Maggiori informazioni su TCFS possono essere reperite dalla home page del progetto

• http://www.tcfs.it

Documentazione più dettagliata su TCFS è scaricabile in formato Postscript o PDF cliccando su questo link:

• http://www.tcfs.it/index.php?pc=2

Archivi della mailing list di TCFS sono, invece, reperibili seguendo questo link:s

• http://www.tcfs.it/pipermail/tcfsml

fonte: Pluto

Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog: