Newsgroup: it.comp.os.linux.iniziare
Titolo: Una cosa un po' difficile: accedere ad hd criptato con smart card infocamere...

Ciao,
su Linux c'ï¿œ la possibilitï¿œ di criptare l'intero
HD per poi accederci inserendo una password all'avvio
del sistema operativo.
Vorrei sapere se ï¿œ possibile, invece di usare una password,
utilizzare per l'accesso una smart card (o un token USB).
Attualmente, ho con me un token USB di InfoCamere, ma
non ï¿œ attivato. Potrei sfruttarlo per accedere all'HD criptato
ed autenticarmi su Linux?
Il token USB ï¿œ prodotto da bit4id, Key4 vers. 100G.

 Il token USB è prodotto da bit4id, Key4 vers. 100G.
Questo pero' e' un altro sistema rispetto a cryptsetup. Lo ignoro.

 Il token USB ï¿œ prodotto da bit4id, Key4 vers. 100G.
Non ho trovato info su questo modello che non pare esistere. AFAICT i 
prodotti di bit4id sono supportati da Linux. ï¿œ forse questo?
http://www.bit4id.com/italiano/Download/download_file/spec_ACR38T.pdf
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 
http://www.bit4id.com/italiano/Download/download_file/spec_ACR38T.pdf
No, come faccio per sapere se posso utilizzare questo token?
Ciï¿œ che mi interessa ï¿œ soprattutto poter criptare l'intero hd, in modo 
che risulti illeggibile se rubato.

 che risulti illeggibile se rubato.
Questo lo puoi fare a prescindere dall'uso di token. Peraltro io sconsiglio 
tendenzialmente la crittografia dell'intero disco perchï¿œ ï¿œ normalmente 
inutile. La cosa importante ï¿œ crittografare la home dell'utente che contiene 
i dati; crittografare il resto generalmente serve solo a perdere 
performance. L'unico altro posto in cui potrebbe esserci qualcosa di 
pregiato sono la /etc, dove comunque basta fare attenzione a non mettere 
nulla di sensibile o eventualmente mettere link che puntino nella home 
utente, la swap che puoi crittografare oppure semplicemente cancellare ad 
ogni shutdown in base al livello di sicurezza che desideri, la /tmp che puoi 
configurare come tmpfs, la /var/log e /var/tmp che puoi crittografare o 
pulire o montare in bind al login, ecc.ecc.


 performance.
Dissento ancora. Sto scrivendo da un vecchio pc con processore AMD
Athlon da 1 GHz con full disk encryption e la perdita di performance
è trascurabile (leggasi "era così lento anche prima"). Se non devi
fare video editing, a stento ti accorgerai che su un pc recente c'è
LUKS.
Rossi, se non trovi la quadra col token USB, vai di semplice LUKS.
Con una passphrase seria, la sicurezza è uguale. Anzi imho meglio,
perché la passphrase, al contrario del token, non te la ruba nessuno.

 Per poi magari fare altre acrobazie per ripristinarle quando servono.
Cosa dovresti ripristinare di grazia?
 > Dissento ancora. Sto scrivendo da un vecchio pc con processore AMD
 > Athlon da 1 GHz con full disk encryption e la perdita di performance
 > è trascurabile (leggasi "era così lento anche prima"). Se non devi
 > fare video editing, a stento ti accorgerai che su un pc recente c'è
 > LUKS.
Definisci *trascurabile*. Io uso un portatile con CPU dual core e la perdita 
di performance per me è *importante*. Certo che se con il PC non ci fai 
null'altro che navigare un po' in Internet o leggere la posta probabilmente 
il disco lo usi poco e la perdita di performance è ridotta.
Prova invece a dover fare qualche compilazione o anche solo usare programmi 
che accedano al disco in modo significativo (anche un semplice aggiornamento 
di sistema) e poi vediamo se la perdita di performance è ancora trascurabile 
o se si fa sentire.
 > Rossi, se non trovi la quadra col token USB, vai di semplice LUKS.
 > Con una passphrase seria, la sicurezza è uguale.
Autenticazione a doppio fattore, questa sconosciuta...
 > Anzi imho meglio,
 > perché la passphrase, al contrario del token, non te la ruba nessuno.
Quindi 1 > 2 ... interessante.


Il 25/05/10 22:46, rossi ha scritto:

Soluzione complessa e rischiosa se il token si danneggia perdi il 
certificato contenuto e non puoi piï¿œ accedere ai dati, inoltre 
difficilmente serve crittare tutto l'HD, generalmente basta uno 
spazietto in cui infilare i dati sensibili, la soluzione + semplice 
credo sia utilizzare TrueCrypt.
Comunque se devi proprio portarti dietro dati sensibili moolto meglio 
spendere qualche dollaro e comprarsi un IronKey serie D200

 serve solo a perdere performance.
Non la metterei in termini di performance; in questo specifico caso 
forse è più vantaggioso criptare solo la /home per il semplice fatto che 
l'intero sistema operativo è completamente in piedi al momento di 
accedere alla smart card.
Diversamente, criptando l'intero disco, l'accesso alla smart card deve 
avvenire sfruttando le limitate possibilità offerte unicamente dal 
contenuto della /boot (kernel+initrd) e non è proprio banale.
Per esempio ho un lettore Athena al quale si accede semplicemente 
caricando libasedrive-{serial,usb} e pcscd; usarlo quindi da uno script 
d'avvio associandolo a cryptsetup è semplice.
In ultimo, raccomanderei all'OP di fare sempre attenzione al rischio 
dell'attacco "evil maid", il falso senso di sicurezza assoluta delle 
partizioni criptate è quasi più pericoloso di una partizione in chiaro...
Leggasi: ad un ladro che interessano i tuoi dati non è detto che debba 
rubarti il disco con una sola visita (ne bastano due).
Ciao.

 riferisce alla cretinata di Gutmann altrimenti siamo a posto.
Premessa: io in generale son d'accordissimo con te, eh.
Ma, nello stretto dettaglio dell'"irrecuperabile"...
Non credo si riferisca a Gutmann. Credo si riferisca a questo:
lem@lappybaby:~$ touch indelebile
lem@lappybaby:~$ echo se mi leggi sei nei guai > indelebile
lem@lappybaby:~$ cat indelebile
se mi leggi sei nei guai
lem@lappybaby:~$ sudo stat -f indelebile  
  File: "indelebile"
    ID: 43cf5f8eb59608f5 Namelen: 255     Type: ext2/ext3
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 25703614   Free: 10497690   Available: 9192021
Inodes: Total: 6529024    Free: 6430734
lem@lappybaby:~$ sudo stat -c %i indelebile
2766867
lem@lappybaby:~$ sudo debugfs /dev/mapper/CRYPTOHOME
debugfs 1.41.11 (14-Mar-2010)
stat <2766867>
debugfs:  stat <2766867>
Inode: 2766867   Type: regular    Mode:  0644   Flags: 0x0
Generation: 674537629    Version: 0x00000000
User:  1000   Group:  1000   Size: 25
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x4bfd1b40 -- Wed May 26 14:59:44 2010
atime: 0x4bfd1b25 -- Wed May 26 14:59:17 2010
mtime: 0x4bfd1b40 -- Wed May 26 14:59:44 2010
Size of extra inode fields: 4
BLOCKS:
(0):11105002
TOTAL: 1
(END) 
q
debugfs:  quit
lem@lappybaby:~$ sudo dd if=/dev/mapper/CRYPTOHOME bs=4096 skip=11105002 count=1
se mi leggi sei nei guai
1+0 record dentro
1+0 record fuori
4096 byte (4,1 kB) copiati, 6,6235e-05 s, 61,8 MB/s
Ora usiamo un tool di rimozione sicura:
lem@lappybaby:~$ srm indelebile
Per sicurezza:
lem@lappybaby:~$ sync
Vediamo se ha funzionato:
lem@lappybaby:~$ cat indelebile
cat: indelebile: Nessun file o directory
lem@lappybaby:~$ sudo debugfs /dev/mapper/CRYPTOHOME
debugfs 1.41.11 (14-Mar-2010)
stat <2766867>
debugfs:  stat <2766867>
Inode: 2766867   Type: regular    Mode:  0644   Flags: 0x0
Generation: 674537629    Version: 0x00000000
User:  1000   Group:  1000   Size: 0
File ACL: 0    Directory ACL: 0
Links: 0   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x4bfd1ecd -- Wed May 26 15:14:53 2010
atime: 0x4bfd1b25 -- Wed May 26 14:59:17 2010
mtime: 0x4bfd1ecd -- Wed May 26 15:14:53 2010
dtime: 0x4bfd1ecd -- Wed May 26 15:14:53 2010
Size of extra inode fields: 4
BLOCKS:
(END)
q
debugfs:  quit
***EPPURE:***
lem@lappybaby:~$ sudo dd if=/dev/mapper/CRYPTOHOME bs=4096 skip=11105002 count=1
se mi leggi sei nei guai
1+0 record dentro
1+0 record fuori
4096 byte (4,1 kB) copiati, 6,4001e-05 s, 64,0 MB/s
Quindi non ha funzionato affatto: srm chissà dove ha scritto e riscritto.
I dati sono ancora lì, e sono recuperabilissimi.
Nemmeno una passata con sfill, dato che il fs su cui ho operato è
journaled, potrebbe *assicurare* la cancellazione dei dati.
E, anche se il fs non fosse stato journaled, quel blocco avrebbe potuto
nel frattempo essere occupato, ma non ancora riscritto, da un altro file.
Insomma: se si vuole essere paranoici, se ne ha ben donde. Anche senza
Gutmann. ;)
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________________
Non sprecare i cicli idle della tua CPU: 
http://boinc.berkeley.edu/index.php

 Quindi 1 > 2 ... interessante.
No, al più irrilevante. Quanto ci vuole a fare bruteforce di una
passphrase LUKS di 20 caratteri? Se le informazioni in quel pc
valgono così tanto, fanno prima a mandarti i due strafatti di crack
con la saldatrice (cit.) a cui darai molto volentieri password,
dongle e telefono di tua sorella. :-)
http://www.mguhlin.org/2009/02/crypto-nerds-dream.html

 Quindi 1 > 2 ... interessante.
Dimenticavo, anche il token viene rubato/smarrito, allora sì che
apprezzerai le meraviglie del doppio fattore. :-) Imho, non ne vale
proprio la pena.

 senza Gutmann. ;)
Avrei voluto essere in grado di spiegarlo come hai fatto tu! :-)


Se il token viene smarrito non c'è alcun problema. Con la sola smartcard non
ci fanno nulla, a meno che uno non sia stato così fesso da scriverci sopra o
allegarci il pin.
IMHO tu stai confondendo il memorizzare una chiave su un dispositivo
rimovibile (cosa fondamentalmente poco utile) con l'utilizzare una
smartcard; quest'ultima è *quasi* [0] inattaccabile.
[0]
https://www.ccs.uky.edu/Events/AccessGrid/Seminars/Archives/PPT_Slides/Mar03.ppt


 fesso da scriverci sopra o allegarci il pin.
Mi sono spiegato male. In caso di smarrimento/danneggiamento etc.
rimani TU senza i tuoi dati, quindi aggiungi un rischio in più, in
cambio del vantaggio che i tuoi dati sono craccabili forse in 1000
anni anziché in 100 (sparo a caso), il che è a mio modesto avviso un
vantaggio del tutto irrilevante ai fini pratici.


In questo caso però puoi avere delle chiavi secondarie, 
p.es
. mantenute su
un CD in cassaforte o se il PC è aziendale su un sistema aziendale.
LUKS supporta fino a 10 slot.
