[Pluto-journal] Articolo su TCFS (.txt e .body)

[Aniello 'Il' Del Sorbo]

Salve ecco il mio articolo.
In allegato trovate la versione .txt e .body
Sostato bravo eh?
Merito un bacino?

Anidel.
-------------- parte successiva --------------
È stato filtrato un testo allegato il cui set di caratteri non era
indicato...
Nome: tcfs.txt
URL: <http://lists.pluto.it/pipermail/pluto-journal/attachments/20010803/f816cdee/attachment.txt>
-------------- parte successiva --------------
<center>
<b>TCFS - Transparent Cryptographic File System.
<br>
Un filesystem cifrato per Linux.
<br>
<br>
<a href="http://www.dia.unisa.it" alt="DIA">DIA - Dipartimento di Informatica
ed Applicazioni</a>
<br>
<a href="http://www.unisa.it" alt="unisa">Università degli Studi di
Salerno</a>.
<br>
<br>
http://www.tcfs.it
</b>
</center>
<p align=left>
<font size=3><b>Introduzione.</b></font>
<p>
Al giorno d'oggi, tenuto conto del notevole progresso della tecnologia di rete,
è realmente fattibile condividere risorse in rete. Non solo in rete locale
(<i>LAN</i>) ma anche su rete globale (<i>WAN</i> o <i>Internet</i>).
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.
<p>
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 è <b>NFS</b> (<i>Network
File System</i>). A dispetto della sua notevole diffusione, l'<b>NFS</b> non si
pone affatto il problema della sicurezza. Nessun tentativo di progettere 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.
<p>
In questo articolo verrà introdotto <b>TCFS</b> (<i>Transparent
Cryptographic File System</i>), 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).
<br>
<br>
<font size=3><b>Scopi di <b>TCFS</b>.</b></font>
<p>
Durante la progettazione di <b>TCFS</b> 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:
<br>
<ol>
<li>un modello di <i>fiducia</i> minimo;
<br>
<li>impatto minimo sull'amministrazione del sistema;
<br>
<li>impatto minimo sulle applicazioni client;
<br>
<li>impatto minimo sull'utente finale.
</ol>
l'architettura di <b>TCFS</b> è 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.
<br>
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.
<br>
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).
<p>
Questa semplice architettura rispetta i quattro punti sopra esposti:
<br>
<ol>
<li><b>modello di <i>fiducia</i> minimo</b>:
<br>
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è 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 <i>fidata</i> è, quindi, il client.
<br>
<br>
<li><b>impatto minimo sull'amministrazione del sistema</b>:
<br>
il server funge da normale server <b>NFS</b>.
L'amministratore di sistema della macchina server può del tutto
ignorare il fatto che il file system esportato sia in realtà un file
system <b>TCFS</b>. Per lui è un normale file system <b>NFS</b>.
<br>
<br>
<li><b>impatto minimo sulle applicazioni client</b>:
<br>
nessuna modifica ai sorgenti e nessuna ricompilazione delle applicazioni
installate sul client è necessaria. Le usuali funzioni di gestione di
files sono rimaste inalterate.
Non è nemmeno richiesto che le applicazioni abbiano a conoscere come
gestire le chiavi. Tutto ciò è gestito, trasparentemente,
da <b>TCFS</b>.
Le applicazioni client ignorano del tutto il fatto di lavorare su file
salvati su <b>TCFS</b>. Così come <b>NFS</b> viene visto dalle
applicazioni come un normale file system locale, così accade anche per
<b>TCFS</b>.
<br>
<br>
<li><b>impatto minimo sull'utente finale</b>:
<br>
<b>TCFS</b> 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 <b>TCFS</b>. Ciò non
vieta, però, la possibilità, ad utenti che lo richiedano,
di un maggiore controllo sulle regole di accesso ai file.
<b>TCFS</b> 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.
</ol>
<font size=3><b>Panoramica delle caratteristiche di TCFS.</font>
<p>
L'ultima versione di <b>TCFS</b> (la 3.0 attualmente non ancora completa ed in
versione beta) implementa le seguenti funzionalità:
<br>
<ol>
<li><b>data integrity check</b>:
<br>
ad ogni blocco di un file cifrato con <b>TCFS</b> viene aggiungo un piccolo
check (un <b>hash</b>).
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 <b>TCFS</b> ritorna un errore all'applicazione richiedente.
<br>
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.
<br>
<br>
<li><b>dynamic encryption modules</b>:
<br>
È 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.
<br>
È possibile inserire o rimuovere motori di cifratura a runtime, senza
bisogno di far ripartire il sistema, senza bisogno di rilanciare <b>TCFS</b> e
addiritura mentre <b>TCFS</b> stesso sta lavorando per altri utenti.
<br>
Questo è stato ottenuto sfruttando appieno il caricamento di codice
dinamico (i <b>moduli</b>) presente in <b>Linux</b>.
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
<b>TCFS</b> potrà usarle per cifrare/decifrare il file.
<br>
<br>
<li><b>group sharing of files</b>:
<br>
È 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 <b>share</b> (un pezzo
di chiave). Quando una certa soglia (<b>threshold</b>, 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.
<br>
È 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.
<br>
<br>
<li><b><i>Kerberos</i> support</b>:
<br>
Ancora non disponibile in <b>TCFS 3.0</b> beta, dovrebbe essere disponibile
nella sua versione finale.
Sarà possibile autenticare un utente, e quindi ottenere la chiave di
sessione, utilizzando Kerberos.
<br>
La gestione delle chiavi in <b>TCFS</b> è totalmente svincolata dal
core di <b>TCFS</b> stesso.
Tutta la gestione delle chiavi è affidata ad una libreria esterna
chiamata <b>tcfslib</b>. Al momento la tcfslib fornisce un sistema base
(<i>Basic Key Management System</i>) per la gestione delle chiavi (cifrando la
chiave di sessione di <b>TCFS</b> con la password di login dell'utente).
<br>
Nella versione finale stabile di <b>TCFS 3.0</b> sarà possibile gestire
le chiavi appoggiandosi al sistema di autenticazione di Kerberos.
<br>
<br>
<li><b><i>TCFS-aware</i> application support</b>:
<br>
Anch'esso ancora in fase di sviluppo, sarà disponibile nella versione
finale stabile di <b>TCFS 3.0</b>.
<br>
Grazie all'uso di un header <b>TCFS</b> è possibile salvare, in maniera
sicura, <b>informazioni</b> aggiuntive riguardanti un file cifrato.
È possibile sviluppare una qualsiasi applicazione <b>TCFS</b> e
sfruttare l'header del file cifrato per salvare flag o dati aggiuntivi
(<b>metadata</b>).
<br>
Sarà sviluppato un intero set di funzioni di libreria (<i>API</i>) per
la gestione dei metadata utente.
</ol>
<font size=3><b>Links utili</b></font>
<p>
Maggiori informazioni su <b>TCFS</b> possono essere reperite dalla home page del
progetto
<ul>
<li><a href="http://www.tcfs.it" alt="TCFS Home Page">http://www.tcfs.it</a>
</ul>
Documentazione più dettagliata su <b>TCFS</b> è scaricabile in
formato Postscript o PDF cliccando su questo link:
<ul>
<li><a href="http://www.tcfs.it/index.php?pc=2" alt="TCFS doc">
http://www.tcfs.it/index.php?pc=2</a>
</ul>
Archivi della mailing list di <b>TCFS</b> sono, invece, reperibili seguendo
questo link:
<ul>
<li><a href="http://www.tcfs.it/pipermail/tcfsml" alt="Mailing list archives">
http://www.tcfs.it/pipermail/tcfsml</a>
</ul>
<p align=right>
<a href="mailto:anidel a tcfs.unisa.it">Aniello Del Sorbo</a>.