Attaque sur AES. disque préalablement rempli de zéros.
Le
Kevin Denis
Bonjour,
linux permet de chiffrer un disque à l'aide de cryptsetup. Le chiffrement
par défaut utilisé est AES.
Imaginons un disque préalablement rempli de zéros. Le chiffrement utilisé
est AES à l'aide d'une clé non triviale. Imaginons un attaquant root sur
la machine qui ne dispose pas de la clé.
Il a donc a dispositions de très grandes quantités de données (plusieurs
giga au vu des disques actuels) dont le chiffré est une suite de zéros.
Ceci constitue t'il une faiblesse?
Merci
linux permet de chiffrer un disque à l'aide de cryptsetup. Le chiffrement
par défaut utilisé est AES.
Imaginons un disque préalablement rempli de zéros. Le chiffrement utilisé
est AES à l'aide d'une clé non triviale. Imaginons un attaquant root sur
la machine qui ne dispose pas de la clé.
Il a donc a dispositions de très grandes quantités de données (plusieurs
giga au vu des disques actuels) dont le chiffré est une suite de zéros.
Ceci constitue t'il une faiblesse?
Merci
Poser une question
Comme tout le monde va proposer:
# dmsetup table --showkeys
on peut imaginer de plus que le dispositif de chiffrement est
du genre FIPS 140-2 niveau 3 (c'est à dire avec une interface
séparée pour la gestion des clés).
AC
je suppose que tu parle d'un disque plein de clair zéro, écrits sous
forme de chiffré, qui ressemblera a de l'aléatoire.
je connais pas cryptsetup, mais:
si cryptsetup chiffre chaque bloc indépendemment sans ajouter de donnée
variable, alors tout les bloc a zéro auront la même valeur.
ce sera simple a détecter, et ca permettra de faire une analyse du
remplissage du disque.
l'analyse de remplissage est très utile pour détecter si une chose
importante est stockée dessus, si une opération est en cours...
par contre le chiffrement du bloc zero ne donne qu'un seul couple
clair-chiffré. mais comme ce bloc zéro est commun a tout les disque, un
groupe peut se faire un dictionnaire de toutes les manières de chiffrer
zéro (est-ce les rainbow table). ca suppose que la clé est pas trop
grande. 56 est a la portée de gens puissants (512milliers de To), 64
bits est a la portée peut être de la NSA (128 millions de To, ie de
disques), quoique... 128 bits, n'y pensons même pas...
tout ca si les algo sont solides (attaquables uniquement par force
brute, ce qui est probable car la NSA sais bien que tout secret fini par
fuiter ou être redécouvert avec le temps, et a du faire de son mieux,
comme avec le DES)
ensuite si on ajoute une donnée déterministes (numéro de bloc par
exemple) au bloc, on obtient les versions chiffrées de pas mal de bloc
connus... moins utiles
si c'est du bruit que l'on rajoute, on n'a plus trop de trucs prévisible
sur lesquels se reposer...
bref, a mon avis ajouter au bon endroit un bloc de 128 bits aléatoires ,
au début de chainage de bloc du bloc disque (eh oui il y a deux niveaux
de bloc ici, bloc chiffrement et bloc disque), ca neutralise l'attaque a
clair connu ...
reste a attaquer le générateur aléatoire.
si le générateur est bon, par exemple en étant couplé à un système de
chiffrement en boucle et a un bon hash en sortie, afin d'étaler les
éventuels faiblesse du générateur... enfin je dis ca, mais il doit y
avoir des gens qui ont étudié le soucis (lire la doc de cryptsetup, de
dev/random, et les grans bouquins genre applied cryptography de bruce
schneier)
Tu voulais dire le clair, là ?
--
Q. What kind of moron includes Arabic symbols that can't be displayed in most
fonts in the From: header just because they look nice on his/her own screen?
A. A Google-Groping kind of moron.
Al
Non, le chiffré est une suite de 0.
On prend un disque rempli de 0. On demande au système de le chiffrer
avec une clef X. Le système ne fait absolument rien, il considère que le
disque est chiffré avec la clef X. On obtient donc un chiffré rempli de
0.
--
IT'S POTATO, NOT POTATOE
IT'S POTATO, NOT POTATOE
IT'S POTATO, NOT POTATOE
-+- Bart Simpson on chalkboard in episode 7F01