[e-privacy] Luks e Tomb era Chip TPM?

[Tommaso Gagliardoni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/14/2012 08:20 PM, ono-sendai wrote:
> Io ne avevo letto in questo [0] (imho splendido) libro di Schneier
> (che fra le altre cose è uno dei designer di twofish). Qui [1] e
> qui [2] ci sono due suoi post a riguardo. Questi attacchi sono solo
> a livello teorico e non hanno (ancora?) applicazioni pratiche da
> quello che ho capito.

Gli attacchi piu' recenti ad AES funzionano sia sulla versione da 128
bit che su quella da 256 bit [6] . Comunque no, niente di praticamente
utilizzabile.


> Anche questo e' vero,ma penso che per un utente poco esperto imho
> sia piu' semplice usare tomb e avere un uguale grado di sicurezza.
> Dopotutto Simone parlava di truecrypt ed a me e' subito venuto in
> mente tomb per la sua semplicita' d'uso (oltre che non ha quegli
> aloni di mistero di cui sopra :P )

Di sicuro truecrypt "puzza", ma tieni conto che TOMB non ha certamente
avuto tutto il review process che gli altri software hanno avuto...
Insomma dipende dal tradeoff tra sicurezza e semplicita' che vuoi
raggiungere, se dici che TOMB e' molto intuitivo da usare ci credo.


> Bhe',anche se la master key non sta mai in chiaro, penso che
> aggiungendo uno strato di protezione non si perda nulla anzi. ... 
> Mmm..su questo non sono daccordo. Una feature non e' mai inutile
> (se non ha effetti collaterali che in questo caso non vedo),

Questo ahime' non e' corretto, come qualsiasi crittografo potrebbe
confermare :) a volte succede che mettendo insieme "pezzi" che di per
se' sono sicuri, si ottiene qualcosa che sicuro non e', a causa di
effetti imprevedibili che spesso non sono evidenti. E' a questo che
servono le dimostrazioni formali di correttezza in crittografia, ma
senza andare troppo in la' pensa alla filosofia "keep it simple,
stupid" della progettazione software: piu' semplice e' il tutto e meno
possibilita' ci sono di bug.


> "This feature lets you keep in mind a certain picture rather than a
> position in a filesystem, much easy to remember. It also helps in
> hiding well the key and eventually communicating it without being
> suspicious, as it is very difficult to detect the presence of a key
> inside an image without knowing the password you used to seal it." 
> ... "When transporting delicate information the risk of
> interception is high: even using encryption, if the courier is
> captured then the key can be found on him and the password can be
> obtained under torture. The solution we propose is that of
> separating keys from storage, so that a courier alone cannot be the
> single point of failure: hence separation between keys and data."

Questo e' un mucchio bullshit :P

 - come mai dovrebbe essere piu' difficile ricordarsi la posizione nel
filesystem di un keyfile piuttosto che di una particolare immagine
(che e' anch'essa un file)?

 - perche' dover comunicare al destinatario dell'informazione SIA
l'immagine SIA la password per sbloccare il keyfile, piuttosto che non
solo una semplice password? E' vero che comunicando solo un'immagine
non si risulta "suspicious", ma poi dovrai comunque comunicare anche
la relativa password!

 - un corriere che trasporti SIA l'immagine che la password e' un
single point of failure, un corriere che NON trasporti l'immagine O
che NON conosca la password non e' un corriere "completo", nel senso
che il destinatario non sapra' comunque come accedere
all'informazione. Se si vuole aumentare la sicurezza diminuendo le
possibilita' di intercettazione del corriere basta usare una singola
password, "spezzarla" tra i corrieri e mandare piu' corrieri, senza
ricorrere alle immagini.

 - la soluzione di separare "keys from storage" non e' neanche ben
posta a livello di definizione: cosa si intende per chiave, una
password o un keyfile? Nel primo caso, la chiave e' GIA' separata
dallo storage, nel secondo caso la cosa e' equivalente a scrivere la
password in un file .txt (e cifrandolo non si ottiene altro che
spostare il problema alla chiave utilizzata per questa seconda
cifratura, oltretutto complicando inutilmente le cose).

Poi questo scenario non e' molto chiaro: lo scopo della cifratura del
filesystem e' di proteggere le MIE informazioni da TUTTI gli altri,
non di COMUNICARLE a un destinatario in maniera sicura. Per quello
c'e' solo una soluzione: la cifratura asimmetrica.

Di nuovo, mi dispiace di dover essere cosi' categorico, ma sul
serio... non ha senso. Non ho dubbi pero' sul fatto che il software in
questione sia davvero ben scritto perche' conosco di fama gli
sviluppatori, e di sicuro si tratta di un esercizio di stile davvero
notevole. Bisogna considerarlo tale pero'.


> Su questa cosa ho trovato questo [4] ... sembra che la cosa sia
> work in progress

Nono, e' una feature presente da tempo [7], io stesso la uso, e'
comoda in diverse situazioni!


> Questo mi interessa molto, anche se non ho ben capito cosa intendi
> :P . Cioe' tu dici di creare al boot un filesystem temporaneo gia'
> cifrato,come faresti? (hai qualche link?).

Allora, l'idea e' che se hai una partizione che usi, ad esempio, come
/tmp (ovvero ci finiscono dati temporanei che non vengono riusati tra
un reboot e l'altro) sarebbe una buona idea fare in modo che quello
che ci finisce dentro venga distrutto ad ogni reboot, cosi' non lasci
tracce della tua attivita'. L'idea banale e' quella di avere uno
script che cancella in modo sicuro ("wipe") la partizione ogni volta
che spegni il pc. Lentissimo. Allora quello che si fa e' questo:

 - all'avvio, il S.O. genera alcuni bit di entropia da /dev/urandom
(dd if=/dev/urandom)

 - poi formatta la partizione in formato LUKS, usando come chiave quei
bit che aveva raccolto (cryptsetup luksFormat)

 - a questo punto si sblocca la partizione usando quella chiave, che
viene mantenuta solo in memoria e mai scritta da nessuna parte
(cryptsetup luksOpen)

 - il device virtuale cosi' creato viene formattato con mkfs.ext2
(perche' e' piu' veloce e non hai bisogno di journaling per un
filesystem temporaneo) e montato su /tmp

Quando il pc viene spento, la chiave in RAM viene persa per sempre:
quei dati non possono piu' essere recuperati! Al prossimo reboot il
S.O. ripete esattamente la stessa sequenza, ottenendo una /tmp del
tutto nuova.

(lo puoi fare anche per lo swap, con mkswap e swapon invece che mkfs e
mount)

Cryptsetup automatizza il processo, basta che metti in /etc/crypttab
/dev/urandom come keyfile e specifichi l'opzione "tmp" o "swap" (man
crypttab). Non usare /dev/random perche' potrebbe rallentare
indefinitamente l'avvio del pc.


> Inoltre,visto che ci siamo...un'idea che mi e' sempre piaciuta,ma
> che non ho mai capito come realizzare, sono le partizioni nascoste 
> di truecrypt,qualcuno conosce un modo per fare questa cosa con
> dmcrypt+luks?

Non esiste ancora che io sappia, e questa e' una cosa che mi fa
letteralmente incazzare, che non esista una soluzione simile nel
ventunesimo secolo :| servirebbe, si', e servirebbe anche una feature
tipo "hidden OS" di truecrypt ma per bootare linux!


> E comunque [5] :D

Sempre e comunque :) ma una discussione paranoica ogni tanto su
e-privacy non fa male :P



[6]
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Known_attacks

[7]
http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#1._General_Questions


- -- 
Tommaso Gagliardoni
GnuPG Key ID: 51D8DEB8
Fingerprint: DC10 0D2F 8F07 238D C5DB  63B8 0AEF 48C5 51D8 DEB8
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPOvxtAAoJEArvSMVR2N6471AQAJjjN8mm1vWASTZA4dUZ4Z8i
BelJn/L4woBv79JpcYcOk037Yq1Py+AORm2wLiwwWqKBrqyBAAGO8OIcOukeSk3Q
NwGiAoZN6wffGBpAEAQnL3sDf8TcDjI7OHi1hM89h3atbshJda/lvXXfNUA+aqF3
7uTJ1eOGzKYU0ZlS/BswxfF8Tjksbj/Sqw/u0qzgqR2i01woVMiIU6r8ET9Z12ik
SdAtSPFwUSHEVgeEcnsxJgn/rFBPMZ2cmS5OkguOVvLNFPPhyEDRyuJxAiV8vR0w
1ZAHG7i51PU4Y4y3EIJA4mgHk6b9PkZkPztVk9y2eD0U44Ji/mRDbGXFhOxqWBV4
p+9Tcg82kdwJO4+nLv/OC1ISUW1iC5Cxs+67ti2sEiwwUu8BOgkHDS6SBoFb7aPO
pVs+x5jHGs1a3T+7oe1oQ77BFYP3oRYPXW8lnT7VJGyh2ydag3DmUL4KhBjCTkrw
IChkShyp0NXqzp1pyCRtYXSEI730qPBdKXBnolqwi8cqdWtOYEo9hhhzWOKxI7pi
HZAj26YZwXPq7sNV8mA2JcLQOsHH//mvlkEVU9YQ1k93yNXY7rWhU1jSctHAFrkX
rGmTcRgb0zJDP6gMJafJzd2M4PjLSJ5QjlayPA14Wc37vTcBUmFgQ2/7W4dAEbLg
tavqhoupZCqtx4dGfRR+
=C0Go
-----END PGP SIGNATURE-----