Criptare partizioni e directory

Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Set language to:en it | Login/Register

Aiuto! Mi rubano i dati!

Come ho detto in un altro articolo, una buona password di root non è, purtroppo, sufficiente a garantirsi l'inviolabilità del Server.
Può capitare il caso in cui un Server o semplicemente il disco venga rubato, oppure molto più prosaicamente, nel caso in cui il disco renda l'anima e occorra cestinarlo senza che qualcuno possa leggerne i dati con vari sistemi (si, come ha dimostrato qualcuno, un buon magnete, o all'occorrenza un buon trapano a percussione sono sistemi altamente validi nel caso il disco sia da distruggere).

In questo articolo tratterò il primo caso, ovvero il disco funziona perfettamente e si vuole semplicemente pararsi la schiena nel caso in cui il Server o il disco venga rubato.

La soluzione, come si può immaginare, consiste semplicemente nel criptare i dati presenti su disco.
Per fare questo ci sono due sistemi: criptare le partizioni o criptare semplicemente i dati.

Per criptare i dati si possono usare programmi come GPG/PGP, oppure crearsi una directory criptata con EncFS.
Questo sistema è utile nel caso in cui alla macchina ci siano accessi anche da altre persone e si vogliano proteggere pochi dati personali (per esempio, le chiavi SSH e GPG, oppure i files nei quali i Browser salvano le varie passwords o in cui si salvano i dati di connessione del MailAgent o di ICQ).
EncFS ha anche l'innegabile vantaggio di impedire perfino a root di accedere alla directory con i dati criptati (anche se, ovviamente, nessuno impedisce a root di usare su e diventare immediatamente l'utente che ha accesso alla directory...)!

Nel caso invece in cui si abbiano parecchi dati da criptare, e questi debbano poter essere accessibili ad altri utenti, EncFS non è una buona soluzione. In questi casi è molto meglio criptare direttamente le partizioni e quindi (dopo averle sbloccate) montarle e accederci normalmente, come qualsiasi altra partizione.
Per questi casi conviene usare lo standard LUKS (Linux Unified Key Setup), in quanto è molto rapida la modifica al volo della passphrase.

Criptiamo una directory

Per prima cosa, ovviamente, è necessario installare il programma. Varie distribuzioni lo chiameranno in vari modi, ma non dovrebbe essere difficile trovare il pacchetto EncFS.
Sulle distribuzioni basate su Debian, questo pacchetto si chiama proprio encfs e si installa semplicemente con apt-get. Assieme a questo pacchetto è necessario installare anche fuse-utils, altrimenti manca il comando fusemount. Essendo quest'ultimo pacchetto una dipendenza, verrà (si spera) installato automaticamente.

A questo punto è sufficiente lanciare il programma e crearsi una directory criptata. Questo esempio crea la directory .crypt nella Home dell'utente corrente contenente i dati criptati e la monta nella directory crypt.

encfs ~/.crypt ~/crypt

Occorre rispondere a un paio di domande (per esempio, se le directories non esistono e occorre crearle). Quindi si può scegliere tra l'exptert mode e il paranoia mode già predefinito.
Quasi sempre si usa tranquillamente il modo predefinito.
L'ultima cosa da inserire, a questo punto, è la passphrase. Una volta fatto questo la directory ~/crypt è pronta per essere usata.
Per smontare questa directory basta lanciare il comando:

fusermount -u ~/crypt

E i dati non sono più disponibili finchè non si rimonta la directory, usando lo stesso comando usato per crearla.

Personalmente ho creato due scripts che vengono lanciati rispettivamente al logon e al logout che provvedono a montare e smontare la directory nella quale ho i miei dati riservati.

Criptiamo una partizione

Vediamo ora invece come si può criptare un'intera partizione, che poi verrà usata in maniera del tutto trasparente per gli utenti.

Anche in questo caso occorre ovviamente installare il programma che, nelle distribuzioni basate su Debian si chiama cryptsetup.
Debian, addirittura, durante l'installazione, consente di creare le partizioni criptate, cosa questa estremamente comoda in quanto si può fare l'installazione di un sistema criptando da subito i dischi e lasciando "a libero accesso" solo / e /boot.

Nel caso, invece, si abbia un sistema già installato e si voglia semplicemente creare una nuova partizione criptata, è necessario fare tutto a mano.
Per prima cosa occorre modificare il file /etc/crypttab. Questo file contiene la descrizione delle directory criptate, nel formato:

#<target device> <source device> <key file> <options>

Per esempio:

system-data_crypt /dev/mapper/system-data none luks
system-home_crypt /dev/mapper/system-home /data/conf/luks/key luks

In questo caso, visto che son pigro, instruisco il sistema per chiedermi la passphrase per la prima partizione, e gli dico che la passphrase per la seconda la trova in un file contenuto nella prima partizione.
Questa cosa è molto comoda nel caso in cui un Server abbia parecchie partizioni, tutte criptate (come sono tutti i Servers che ho in ufficio).

Ovviamente la prima partizione (/dev/mapper/system-data_crypt) dev'essere montata prima che il sistema possa sbloccare e quindi montare la seconda.
Questo non è un problema nel momento in cui si montano a mano le partizioni, ma nel caso in cui tutte le partizioni del disco siano criptate, occorre che lo faccia il sistema durante il Boot.
Per fare questo occorre istruire il sistema per montare una partizione prima di sbloccare le altre. Questo si ottiene inserendo nel file /etc/default/cryptdisks un valore per la chiave CRYPTDISKS_MOUNT (per i sistemi Debian. Per gli altri occorre guardare dove viene messo questo file):

CRYPTDISKS_MOUNT="/data"

Ovviamente /data è configurato in /etc/fstab! Nell'esempio, avremo:

/dev/mapper/system-data_crypt /data ext3 defaults 0 1
/dev/mapper/system-home_crypt /home reiserfs defaults 0 2

A questo punto occorre semplicemente formattare le partizioni:

cryptsetup luksFormat /dev/mapper/system-data
cryptsetup luksFormat /dev/mapper/system-home

Durante questo processo il sistema chiederà una passphrase che, per quanto riguarda la partizione /dev/mapper/system-home_crypt deve essere la stessa inserita nel file /data/conf/luks/key.

MOLTO IMPORTANTE! Questo file deve contenere SOLO ED ESCLUSIVAMENTE la passphrase! Anche un CRLF è vietato, in quanto verrebbe considerato parte della passphrase!! L'ideale è generare il file con questo sistema:

echo -n "<passphrase>" > /data/conf/luks/key

Una volta create le partizioni occorre sbloccarle, creare il FileSystem e infine montarle e usarle:

cryptsetup luksOpen /dev/mapper/system-data system-data_crypt
mkfs -t ext3 /dev/mapper/system-data_crypt
mount /data
cryptsetup luksOpen /dev/mapper/system-home system-home_crypt
mkfs -t reiserfs /dev/mapper/system-home_crypt
mount /home

FINITO! Durante il Boot, il sistema si bloccherà e non partirà finchè la passphrase per la partizione /data non verrà inserita, quindi, a meno che uno non sia così idiota da scrivere la passphrase su un PostIT attaccato al Server, i dati saranno al sicuro anche in caso di furto!
Certo, occorre anche installare un buon sistema di Backup, altrimenti i dati non saranno sicuramente usabili dai ladri, ma anche noi li avremo persi...

Devo cambiare la passphrase!!

Può essere necessario cambiare la passphrase, sia per EncFS, sia per le partizioni LUKS.
Questo è facile e molto rapido.

Nel caso di EncFS, basta dare il comando:

encfsctl passwd <directory contenente i dati in forma criptata (nell'esempio ~/.crypt)>

Il sistema chiederà l'attuale passphrase e la nuova (due volte!), quindi la passphrase verrà modificata.

Nel caso di LUKS, occorre inserire una seconda passphrase e quindi cancellare la prima.
Questo si ottiene in questo modo:

cryptsetup luksAddKey <device (nell'esempio /dev/mapper/system-data o /dev/mapper/system-home)>
cryptsetup luksDelKey <device> 0

Il sistema chiederà una nuova passphrase (per il primo comando) in modo da poterla aggiungere alla lista delle passphrases, e l'attuale passphrase per il secondo, quindi la prima passphrase verrà cancellata.
Ovviamente occorre modificare la passphrase anche nel file usato per montare automaticamente le partizioni al Boot, altrimenti al prossimo Boot del sistema non sarà possibile il mount automatico.

Bello! Installo subito LUKS sui Servers in sala macchine!

Ecco, questo è il miglior modo per correre in giro per il mondo ad ogni avvio del Server...
Come ho detto prima, al Boot il sistema si blocca finchè la passphrase non viene inserita, quindi o avete a disposizione un KVM via TCP o andate in Sala Macchine ogni volta che c'e' da riavviare la macchina!

Tenetelo presente, quando installate il Server! Personalmente uso le partizioni LUKS solo per le macchine che ho in ufficio (e che sono relativamente facili da rubare). I Server in sala macchine hanno partizioni non criptate, in quanto non mi è permesso entrarci in sala macchine (che si trova dal Provider e non è nemmeno tanto vicina).

Comments

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

22 messages  this document does not accept new posts
Motosauro

subject By Motosauro posted 04/03/2009 12:10

Ottima guida :-\)

Grazie

-- Motosauro

mk66

desktop By mk66 posted 09/03/2009 14:22

Si parla di server, ma immagino che si possa attuare anche su un desktop?

Nel mio caso potrebbe essere utile per criptare la directory (o addirittura la partizione completa) dove salvo i lavori in corso.

Sommato al backup, garantirebbe una maggior sicurezza, che non fa mai male.

-- mk66

Luca Bertoncello

-AT- mk66 By Luca Bertoncello posted 10/03/2009 07:34

> Si parla di server, ma immagino che si possa attuare anche su un desktop?

Si parla di macchine con sistema operativo Linux. Che siano Server, Workstation, Firewall o quel che e', non cambia niente dal punto di vista della criptazione...

> Nel mio caso potrebbe essere utile per criptare la directory (o addirittura la partizione completa) dove salvo i lavori in corso.

E' quel che facciamo in ufficio... :-\)

Ricorda che LUKS e' molto piu' veloce di EncFS, quindi se hai parecchi files, usa LUKS (che funziona solo con una partizione).

> Sommato al backup, garantirebbe una maggior sicurezza, che non fa mai male.

Quello mai! :-\)

Ciao

Luca

-- Luca Bertoncello

miniBill

-AT- mk66 By miniBill posted 16/03/2009 19:08

ti diré di pié, nel mio sistema anche la root é criptata, anche se in quel caso ci vuole qualche magheggio aggiuntivo

io ho seguito questo:

http://en.gentoo-wiki.com/wiki/Root_filesystem_over_LVM2,_DM-Crypt_and_RAID

-- miniBill

mk66

Grazie By mk66 posted 18/03/2009 23:07

Grazie a Luca per i chiarimenti e le spiegazioni dettagliate :-\) (appena avro' un poco di tempo, quindi non prima di maggio, ci studiero' bene sopra e procedero')

Grazie anche a MiniBill per il link, ma nella mia situazione mi sembra un pochino eccessivo criptare anche la root: quello che mi importa particolarmente e' salvaguardare il piu' possibile la mia partizione di lavoro: root e home eventualmente ci metto niente a reinstallarle, ma la partizione di lavoro mi manda in paranoia e cerco di fare di tutto e di piu' per proteggerla/proteggermi

-- mk66

Luca Bertoncello

-AT- mk66 By Luca Bertoncello posted 19/03/2009 07:39

> Grazie a Luca per i chiarimenti e le spiegazioni dettagliate (appena avro' un poco di tempo, quindi non prima di maggio, ci studiero' bene sopra e procedero')

Prego, buon lavoro!

Ciao

Luca

-- Luca Bertoncello

Andrea Del Priore

Proprio ieri... By Andrea Del Priore posted 23/03/2009 13:09

E proprio ieri un cl-collega(mac dotato) ha letto un howto su un qualche sito(della serie "prodotto x e' uscito dopo prodotto Y quindi e' piu' sicuro e figo") ha deciso di creare, seduta stante, una immagine sparse con cifratura 256 AES da usare come disco "sicuro".

La password e' stata generata in modo sicuro tramite il relativo "tool" di firefox.

Ed e' stata copiaincollata nel modulo per la generazione della pass.

E tutti i dati di sviluppo del suo ultimo progetto spostati in quel drive.

Poi ha iniziato a cazz... navigare sul web, e al primo copia-incolla la password e' andata a donnine di facili costumi.

Ovviamente il giorno dopo, dopo il boot, a chi e' venuto a chiedere la password?

E chi si e' dovuto smazzare il restore dalla settimana prima?

-- Andrea Del Priore

Luca Bertoncello

-AT- Andrea Del Priore By Luca Bertoncello posted 23/03/2009 21:46

> Poi ha iniziato a cazz... navigare sul web, e al primo copia-incolla la password e' andata a donnine di facili costumi.

Intelligente il tipo, niente da dire...

Comunque cio' non toglie niente al fatto che la criptazione dei dati sia sicura.

Certo, se si dimentica la passphrase... Ma li il problema e' dell'idiota di turno, non dell'algoritmo.

Ciao

Luca

-- Luca Bertoncello

Anonymous coward

Criptare partizioni e directory By Anonymous coward posted 02/01/2010 23:13

Mi sembra di aver capito che con LUKS ci siano delle limitazioni alla lunghezza della chiave ( 256 bits ) e sui cifrari usabili. cryptoloop ( configurati con losetup ) + aes + chiave di 512 bits è una soluzione più adatta al mio grado di paranoia :-\)

Aggiungerei truecrypt alla lista dato che è anche multipiattaforma. -- Anonymous coward

Luca Bertoncello

@ Anonymous coward By Luca Bertoncello posted 03/01/2010 08:44

> Mi sembra di aver capito che con LUKS ci siano delle limitazioni alla lunghezza della chiave ( 256 bits ) e sui cifrari usabili. cryptoloop ( configurati con losetup ) + aes + chiave di 512 bits è una soluzione più adatta al mio grado di paranoia :-\)

>

> Aggiungerei truecrypt alla lista dato che è anche multipiattaforma.

Dal man di cryptsetup:

--key-size, -s

set key size in bits. Has to be a multiple of 8 bits. The key size is limited by the used cipher. See output of /proc/crypto for more information. Can be used for create or luksFormat, all other LUKS actions will ignore this flag, as the key-size is specified by the partition header. Default is 128 for luksFormat and 256 for create.

Non direi quindi che c'e' SEMPRE una limitazione di 256 bit...

In ogni caso, cryptoloop ha le sue belle limitazioni e, da quel che ne so, e' lento. E poi voglio vederti usarlo per partizioni usate dal sistema (/usr, /var/, etc.).

Cryptoloop lo userei solo per i miei dati personali (da smontare ogni volta).

Ciao -- Luca Bertoncello

The same Anonymous coward

@ Luca Bertoncello By The same Anonymous coward posted 12/01/2010 17:37

> Non direi quindi che c'e' SEMPRE una limitazione di 256 bit...

In fase di installazione da netboot c'è :/

> In ogni caso, cryptoloop ha le sue belle limitazioni e, da quel che ne so, e' lento.

E' lento e non si sposa bene con i filesystem journaled ( tutti oramai ) , ma è ancora valido : https://wiki.torproject.org/noreply/TheOnionRouter/OperationalSecurity

esiste comunque loop-aes che risolve i problemi di performance ( http://loop-aes.sourceforge.net/ )

> E poi voglio vederti usarlo per partizioni usate dal sistema (/usr, /var/, etc.).

Uhm ... ma che senso ha criptare /usr ? Posso capire /var , /tmp ... :/

> Cryptoloop lo userei solo per i miei dati personali (da smontare ogni volta).

Esatto ; stesso dicasi per truecrypt. -- The same Anonymous coward

Luca Bertoncello

@ The same Anonymous coward By Luca Bertoncello posted 13/01/2010 08:10

> > Non direi quindi che c'e' SEMPRE una limitazione di 256 bit...

>

> In fase di installazione da netboot c'è :/

Ma non SEMPRE! :\)

> E' lento e non si sposa bene con i filesystem journaled ( tutti oramai ) , ma è ancora valido : https://wiki.torproject.org/noreply/TheOnionRouter/OperationalSecurity

Niente da dire, ma rimane lento! Se lo usi solo tu per pochi dati, va bene, ma prova a farci lavorare un'intera ditta, poi mi dici!

> > E poi voglio vederti usarlo per partizioni usate dal sistema (/usr, /var/, etc.).

>

> Uhm ... ma che senso ha criptare /usr ? Posso capire /var , /tmp ... :/

Ha senso, credimi! Se ti ciulano l'Hard-Disk, e' meglio fare in modo che nessuno possa leggere NIENTE...

Ciao -- Luca Bertoncello

The same Anonymous coward

@ Luca Bertoncello By The same Anonymous coward posted 13/01/2010 15:43

> > Uhm ... ma che senso ha criptare /usr ? Posso capire /var , /tmp ... :/

>

> Ha senso, credimi! Se ti ciulano l'Hard-Disk, e' meglio fare in modo che nessuno possa leggere NIENTE...

Uhm ... ho capito : se anche la /usr è criptata , nessuno può andare a verificare che tipo di programmi erano installati sul quel sistema ( server di posta , server web , etc ...) e quindi avere informazioni sul tipo di dati eventualmente presenti nel resto del disco.

Innanzitutto , grazie per le risposte e la pazienza :D ... ancora una domanda : la tabella delle partizioni e le caratteristiche/il tipo delle singole partizioni sono ancora visibili , distinguibili , in chiaro con LUKS ? In caso affermativo , esiste una soluzione che non richieda meccanismi hardware tipo TPM per avere qualcosa di simile a una full disk encryption ? -- The same Anonymous coward

Luca Bertoncello

@ The same Anonymous coward By Luca Bertoncello posted 14/01/2010 08:32

> Innanzitutto , grazie per le risposte e la pazienza :D ... ancora una domanda : la tabella delle partizioni e le caratteristiche/il tipo delle singole partizioni sono ancora visibili , distinguibili , in chiaro con LUKS ? In caso affermativo , esiste una soluzione che non richieda meccanismi hardware tipo TPM per avere qualcosa di simile a una full disk encryption ?

Come e' scritto chiaramente nell'articolo, le partizioni sono state create normalmente con LVM. Quindi si! Le partizioni sono visibili e puoi vederne la dimensione e capire che sono poi trattate con LUKS.

NON puoi vedere, ovviamente, il FileSystem installato, perche' questo e' stato creato sopra LUKS.

Ciao -- Luca Bertoncello

jojo-QUE

LUKS ... By jojo-QUE posted 21/01/2010 16:28

LUKS è vulnerabile a certi tipi di attacchi poichè le chiavi sono memorizzate in chiaro da qualche parte e comunque residenti in chiaro nella memoria.

Un fdp certificato potrebbe preventivamente ottenere queste chiavi o trovando il modo di leggere fisicamente il file delle password ( un po' come si faceva in passato con /etc/passwd ) oppure leggendo le stesse dalla memoria ( con un exploit , un dump forzato , un cold boot attack ... ) ; la VM non implementa infatti alcuna tecnica di scrubbing per i dati residenti.

L'fdp certificato potrebbe solo successivamente - ammesso che non abbia già avuto accesso alle informazioni che interessavano lui o i suoi comittenti - preoccuparsi di mettere le mani fisicamente sui dispositivi.

Gli altri sistemi ( cryptoloop , encfs , truecrypt ... ) sono vulnerabili almeno al secondo tipo di attacco.

Discorso a parte per loop-aes che risolve in parte due tipi di problemi : le prestazioni ( routines ottimizzate in assembler ) e la lettura forzata della chiave dalla memoria ( scrubbing delle chiavi ).

-- jojo-QUE

Luca Bertoncello

@ jojo-QUE By Luca Bertoncello posted 22/01/2010 08:14

> LUKS è vulnerabile a certi tipi di attacchi poichè le chiavi sono memorizzate in chiaro da qualche parte e comunque residenti in chiaro nella memoria.

Sono memorizzate IN CHIARO?!? Scusa, ma questa mi giunge veramente nuova...

Puoi citare un qualche articolo/HowTo/altro che spieghi 'sta roba (che a me sembra una cazzata assurda)?

> Un fdp certificato potrebbe preventivamente ottenere queste chiavi o trovando il modo di leggere fisicamente il file delle password ( un po' come si faceva in passato con /etc/passwd ) oppure leggendo le stesse dalla memoria ( con un exploit , un dump forzato , un cold boot attack ... ) ; la VM non implementa infatti alcuna tecnica di scrubbing per i dati residenti.

Guarda, se la chiave e' messa in un file (e il sistema e' "in piedi") e esiste un qualche exploit per entrare nella macchina (da remoto o da locale non importa), quel file lo puoi leggere e quindi hai tutte le password che vuoi.

LUKS e' **UN** sistema per proteggersi. **NON** deve essere l'unico...

Ciao -- Luca Bertoncello

jojo-QUE

@ Luca Bertoncello By jojo-QUE posted 22/01/2010 22:08

> Sono memorizzate IN CHIARO?!? Scusa, ma questa mi giunge veramente nuova...

> Puoi citare un qualche articolo/HowTo/altro che spieghi 'sta roba (che a me sembra una cazzata assurda)?

http://tinyurl.com/yb2vnqw

http://www.saout.de/tikiwiki/tiki-index.php?page=LUKSFaq ( How can I backup my partition header/my metadata? )

http://lwn.net/Articles/358220/

http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html

http://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html

Loop-aes non è vulnerabile al memory dump attack poichè prevede un meccanismo interno per lo scrubbing delle chiavi. Altri sistemi , come (Open)Solaris , implementano meccanismi simili nativamente e direttamente sulla VM ...

non sono riuscito a raccattare il thread di gmame con la patch che implementa lo scrubbing sulla VM del kernel linux e la relativa discussione :\( ... ma comunque ho trovato altri threads interessanti su loop-aes e sull'introduzione del relativo supporto in dm-crypt

http://news.gmane.org/gmane.linux.kernel.cryptoapi/cutoff=3820

http://news.gmane.org/gmane.linux.cryptography

Ovviamente la base di partenza per il mio punto è che l'attaccante sia un fdp certificato e abbastanza determinato.

-- jojo-QUE

Luca Bertoncello

@ jojo-QUE By Luca Bertoncello posted 23/01/2010 08:39

>

> > Sono memorizzate IN CHIARO?!? Scusa, ma questa mi giunge veramente nuova...

> > Puoi citare un qualche articolo/HowTo/altro che spieghi 'sta roba (che a me sembra una cazzata assurda)?

>

> http://tinyurl.com/yb2vnqw

Che da quel che si capisce, direi che puoi vedere la chiave CRIPTATA (e fin li non mi faccio grandi problemi).

Se poi usi un algoritmo debole per criptarla e' un altro discorso.

E comunque, ripeto, per poter leggere la chiave devi avere il sistema gia' funzionante (e quindi essere entrato in qualche altro modo).

Con il sistema in piedi (ed essendo root, che altrimenti la password non la leggi lo stesso), non hai bisogno di chissa' che! rsync e ti copi l'HD da qualche altra parte.

Sinceramente non vedo il problema (di LUKS).

ciao -- Luca Bertoncello

Anonymous coward

@ Luca Bertoncello By Anonymous coward posted 18/04/2010 16:52

>

> Sinceramente non vedo il problema (di LUKS).

>

Per fortuna c'è qualcuno che invece lo vede : http://www.hermann-uwe.de/blog/lest-we-remember--cold-boot-attacks-on-encryption-keys -- Anonymous coward

gianni

@ Luca Bertoncello By gianni posted 27/05/2010 17:30

>

> Sinceramente non vedo il problema (di LUKS).

>

Il problema non è tanto di LUKS che è piuttosto robusto come sistema , ma di come il sistema funzioni a regime. Al momento la chiave viene caricata IN CHIARO in memoria e per certi sistemi come ad esempio i portatili, questo è un problema serio : per quanto riguarda il metodo del cold boot attack , esso deve essere portato o mentre il sistema è in funzione o nei minuti immediatamente successivi allo spegnimento , ma se il riferimento diventa l'immagine dell'ibernazione , l'arco temporale di azione diventa notevolmente più lungo.

Il programma di installazione di debian avverte l'utente quando si tenta di installare il sistema con LUKS e il file di swap non viene criptato.

D'altro canto di solito si usa /dev/urandom per generare la chiave ( che di fatto è una chiave di sessione ) per crittare il file di swap e quindi l'ibernazione non funziona.

La panacea di tutti i mali sembra essere il criptaggio di tutti i dati o solo di quelli sensibili , prima che il sistemi entri in ibernazione ( http://lkml.org/lkml/2009/7/1/42 ) o ancora meglio ( come fa loop-aes per le sue chiavi ) criptare in maniera permanente tutti i dati caricati in memoria con una "chiave di sessione" : diversi sistemi di tipo enterprise come ad esempio (Open)Solaris , operano in questo modo. Questa modifica della VM di linux potrebbe contribuire a rendere vani i cold boot attacks et simila.

Tuttavia , dopo aver letto la notizia del cracking di RSA 1024 ( http://www.ns.umich.edu/htdocs/releases/story.php?id=7551 ) mediante un attacco di tipo non-bruteforce e portato a termine in circa 100 ore, credo che nessun sistema classico di crittografia possa essere considerato completamente sicuro.

Ad oggi i sistemi come TrueCrypt o sistemi steganografici che offrono la "Deniable Encryption" ( http://en.wikipedia.org/wiki/Deniable_encryption ) sono gli unici ad essere considerati "abbastanza" sicuri. -- gianni

jojo-QUE

accesso da remoto By jojo-QUE posted 03/02/2010 01:01

Un metodo per poter avviare un sistema LUKS da remoto senza avere accesso fisico al server : http://gpl.coulmann.de/ssh_luks_unlock.html

-- jojo-QUE

Luca Bertoncello

@ jojo-QUE By Luca Bertoncello posted 03/02/2010 07:34

> Un metodo per poter avviare un sistema LUKS da remoto senza avere accesso fisico al server : http://gpl.coulmann.de/ssh_luks_unlock.html

Che pero' non sempre funziona...

Nel caso che abbiamo un ufficio (con un Modem comandato dal Server stesso), avrei qualche problema...

Comunque sempre buono a sapersi!

Ciao -- Luca Bertoncello

22 messages  this document does not accept new posts

Previous Next

The Author

Luca Bertoncello ha lavorato come responsabile del MailCluster per un Internet Service Provider in Dresden (Germania), specializzandosi nella configurazione di Exim, SpamAssassin e Clam e nella gestione di Clusters basati su Heartbeat e DRBD.
Attualmente lavora per una ditta che gestisce campagne pubblicitarie su Internet (no, non e' uno spammer :D) come programmatore e sistemista.
E' completamente paranoico... :)
Maggiori informazioni sul suo sito: http://www.lucabert.de/

Contribute

Do you want to contribute? read how.  
 

Copyright

This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.

This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project Powered By Gigan