[e-privacy] Dubbi di backdoor NSA su Vista SP1 eccoci

vecna vecna at s0ftpj.org
Wed Dec 19 11:25:03 CET 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

simone at winstonsmith.info wrote:

> il nuovo random number generator di Vista è denominato Dual_EC-DRBG, ed è
> lo stesso in cui lo scorso mese alcuni esperti di sicurezza, tra cui lo
> stesso Schneier, hanno identificato quella che molti sospettano si tratti
> di una chiave d'accesso segreta

Taroccare il sistema di generazione di dati random e' un attacco non
molto noto, ma pur sempre efficace.

all'utente la generazione appare random, ma non lo e'.

Ma a dir il vero, non mi aspettavo un attacco simile...

nel senso, il vantaggio strategico di un governo e' di poter imporre del
proprio codice all'interno di un OS. tutto chiaro. ma c'e' la
consapevolezza che tutto il mondo fara' audit su di te, e le
vulnerabilita' verranno trovate.

una backdoor potevo crederla in windows 98, ma dopo gli anni 2000-2007
non credo sia piu' plausibile.

D'altro canto, il comportamento della NSA e' sempre pero' stato "avanti"
in qualche modo. quando il DES, da IBM andro' in mano all'NSA e lei rese
la chiave di 56 bit anziche' di 64, (e al tempo 40 bit erano sufficenti)
sembrava lo stesse facendo per avere una chiave piu' piccola e maggiori
possibilita' di cracking. (
http://it.wikipedia.org/wiki/Data_Encryption_Standard )

puo' anche essere vero, eh

ma dopo un po' di anni scoprirono che le modifiche portate dall'NSA
rendevano il DES invulnerabile alla crittanalisi differenziale, che
l'NSA gia' conosceva.

per cui mi preoccuperei di piu' di qualcosa fatto in casa, o rivisto,
che non viene trovato vulnerabile dai comuni cittadini.

E questo invece e' un bug di generazione numeri random, che sono gia'
stati trovati vulnerabili in vari modi. Il problema delle collisioni lo
si e' visto legato a MD5 ad esempio (anche se non sembra, le cose sono
fin troppo simili), lo si e' visto quando si e' implementato in gnupg il
sistema di raccoglimento entropia, e lo si e' visto con la generazione
dei sequence number (li' si che era importante, 32 bit che dovevano
essere di puro random, e l'applicazione di funzioni matematiche non
perfettamente studiate faceva restringere il campo di generazione):

http://lcamtuf.coredump.cx/newtcp/

E' qui che sta l'attacco: il numero di chiavi che possono essere
generate non e' piu' tutto quello possibile previsto dall'algoritmo (i
256 bit classici) ma sono una quantita' finita. quindi le possibili
chiavi non sono 2^256, ma di meno.

piu' il sistema di generazione random sara' prevedibile e minore sara'
il numero di chiavi possibile.

(ad esempio, qui trovate un modulo kernel per linux che rende
/dev/urandom sorgente di soli byte 'v': generare una chiave con questa
sorgente darebbe sempre la solita chiave):

http://www.s0ftpj.org/bfi/dev/BFi11-dev-02

(ci trovate anche la spiegazione, anche se forse e' un po' offuscata)

Questi tipi di backdoor, di errori o di limitazioni della chiave, ci
mettono davanti a due tipi di attacchi dei quali possiamo essere target:


1) il numero di chiavi generato e' "finito", e' un numero gia'
probabilmente precomputato dall'NSA o da chi per esso, tipo rainbow
table, si cerca di generare tutte le chiavi possibili cosi' da poterle
testare in modo serializzato durante un bruteforce. Il bruteforce
concettualmente potrebbe sembrare un approccio insensato e limitato,
invece avendo le chiavi e potendo (se si tratta di traffico di rete, o
di settori del disco) di attacchi di tipo know-plaintext, il cracking e'
quasi immediato

2) il numero di chiavi generabile e' infinito, ma buona parte sono
ricostruibili. ad esempio, il 20%. Pensate ad avere sott'occhio il
traffico di tutt'America e poter crackare il 20% delle sessioni cifrate.
 Ogni computer con Vista fara', plausibilmente, piu' di 5 sessioni
cifrate nella sua vita ? si ? 5 * 20% = 100%. Ok d'accordo, la
stastistica ci dice che e' possibile per un utente non caderci mai in
quel 20%, ma e' questione di grandi numeri.

ciao ciao,
v
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaPF/FvCb6mAu76URAu1/AJ4u+iRwhVeTF+Dd6ytToiVS02ZLmACeJYNI
y8Dwrog3UjhdjSldB+RTeuA=
=z18w
-----END PGP SIGNATURE-----



More information about the E-privacy mailing list