Re: Sicurezza dei dati su disco.

>   Stando a quanto dichiarato dal produttore e confermato dall'articolo
>   di Pc Prof. (mero copia e incolla dalla cartella stampa?)

Sulle riviste consumer il copia e incolla e' garantito :)

> il sistema
>   dovrebbe cifrare e decifrare i file on the fly senza praticamente
>   abbattere le prestazioni del controller (supporta sia ata100 sia
>   ata133).

IN LINEA DI PRINCIPIO non vedo perche' no, il throughput di DES su hardware
anche relativamente economico puo' aggirarsi sui 400 Mbit/s senza nessuno
sforzo, e ATA100 e 133 dovrebbero stare sugli 800/1000 Mbit/sec massimi
(peraltro, dal momento che il throughput dipende dall'elemento piu' lento,
non e' nemmeno detto che questo sia il controller, ma vabbe').

Quindi con un po' di impegno si potrebbe senza dubbio fare un chip per il
DES, economico, a quella velocita'. Ci sono core commerciali che superano il
Gb/sec e sicuramente non sono limitati a chiavi da 40 bit (uno trovato
proprio al volo: http://www.ocean-logic.com/des.htm)

Semmai il punto e':

>   Utilizza una chiave DES a 40 bit contenuta su due token usb.

Ora, se il token fosse USB 2.0, dubito che il transfer rate possa essere
quello di un hard disk ATA133. Ad occhio, dato che su burst mi pare che USB2
arrivi a 480 Mbit/s, e dato che qui parliamo di trasferimento bidirezionale,
direi che quantomeno ci si puo' aspettare di non andare oltre i 240 Mbit/s
di velocita'.

Alternativamente, il token viene usato per criptare una chiave generata a
caso e poi questa chiave viene usata, sull'hardware interno, per il DES. In
quel caso, boh, si puo' fare, pero' vorrei ben capire come vengono fatte
girare le chiavi tra i vari dispositivi, perche' gli schemi piu' ovvii hanno
dei bei punti deboli, altro che token.

>   Stando sempre alle dichiarazioni del produttore il db delle chiavi
>   viene sistematicamente eliminato

Il DB delle chiavi NON DEVE ESISTERE. Non ha senso che esista. Gia' il fatto
che ne parlino (se ne parlano, sto a quello che dici tu perche' il sito abit
non funziona al momento) mi inquieta.

> garantendo la sicurezza degli
>   utenti che, solamente presentando uno dei due token possono richiedere
>   un duplicato.

La sicurezza, se esiste la possibilita' di duplicare i token, e' pari a
zero, IMNSHO.

>   1) la scelta di una chiave tutto sommato debole e' dettata
>   esclusivamente dalla necessità di non abbattere le prestazioni su un
>   prodotto di fascia economica?

Sni'. Nel senso, ti posso dire che garantisce costi ridotti, non che sia
l'unico motivo per usare chiavi deboli. L'altro motivo, per esempio, e'
l'esportazione. Se avessero usato chiavi forti avrebbero avuto sicuramente
problemi.

>   2) come si puo' avere la relativa certezza che non ci siano key
>   escrow?

Se i token sono duplicabili, hai la certezza che CI SIA key escrow.

>   3) come e' possibile la duplicazione del token? non dovrebbero
>   essere fatti in modo da non essere duplicabili?

Vedi sopra.

Stefano "Raistlin" Zanero
System Administrator Gioco.Net
public PGP key block at http://gioco.net/pgpkeys



________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List