Bonjour à tous,
j'ai une question au sujet du chiffrement de volumes qui me trotte dans la tête depuis un moment:
Pourquoi faut-il remplir un volume de données aléatoires avant de le chiffrer ?
C'est un conseil que j'ai pu trouver dans de nombreux cours et tutoriels sur le web sans qu'il n'y ait la moindre explication…
J'ai cru comprendre, suite à quelques recherches, que s'abstenir de remplir le disque de nombres aléatoires pourrait permettre à d'éventuels cryptanalystes de situer les données sur le volume, leur offrant par la même occasion un angle d'attaque. Je ne comprend pas pourquoi.
Par exemple si je chiffre un volume (avec LUKS) rempli avec /dev/zero au préalable (dans lequel il n'y a qu'un fichier texte contenant 4 caractères), c'est l'intégralité du disque qui est chiffré (et pas uniquement le fichier texte).
Dans ces conditions comment ferait un attaquant pour situer les données sur le disque ? Une faille éventuelle de l'algo de chiffrement (grossièrement, tous les '0' placés dans le volume seraient transformés en 'b') qui pourrait conduire à une analyse fréquentielle ? Il est peu probable qu'une faille semblable passe inaperçue…
Merci d'avance à qui pourra éclairer ma lanterne.
# Tout n'est pas écrit
Posté par chimrod (site web personnel) . Évalué à 3.
Oui et non : l'intégralité du volume est chiffré, mais le disque n'est pas réécrit tant qu'aucune donnée n'y est modifiée.
Dans l'exemple que tu donnes, les 4 caractères seront chiffrés, et le reste du disque ne sera pas modifié.
Tu peux faire le test en montant ton volume non pas depuis un fichier. Tu verras bien ce qui est modifié dans le fichier.
[^] # Re: Tout n'est pas écrit
Posté par medrogan . Évalué à 2.
Comment le disque peut être intégralement chiffré si aucune donnée n'y est modifiée ?
Je n'ai pas saisi le sens de ta dernière phrase. Tu m'invites à essayer avec un volume monté depuis un fichier ? C'est ce que j'ai fait avec losetup. Le contenu du fichier est intégralement chiffré.
[^] # Re: Tout n'est pas écrit
Posté par EauFroide . Évalué à 2.
Insérer des données random a pour but de supprimer les répétitions, répétition qui sont elles-mêmes utilisées pour décrypter des morceaux d'informations.
Mais il me semble que les logiciels comme truecrypt remplissent déjà de données pseudo-aléatoire lors de, la création d'un volume (lorsqu'il demande de faire bouger la souris avec des mouvements non prédictible)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Tout n'est pas écrit
Posté par medrogan . Évalué à 3.
Oui mais une fois le volume chiffré, comment distingue-t-on ces motifs ?
Si l'algo est bien conçu le brouillage mathématique est censé être uniforme, non ?
# L'intégralité du disque n'est pas chiffré
Posté par Olivier (site web personnel) . Évalué à 7.
1) Lorsque tu lances ta commande de création du volume chiffré ("cryptsetup luksFormat …."), tu notes qu'il ne faut que quelques secondes pour que le programme te rende la main. Cela veut dire que "cryptsetup" n'a écrit que quelques octets sur le disque, à savoir les informations de chiffrement. La grande majorité du disque, elle, n'a pas été touchée, donc ton disque est toujours plein de de zéro.
2) Après avoir monté ton volume chiffré, et avant sa première utilisation, tu vas devoir le formater (en ext4 par exemple, mais tu peux aussi mettre du FAT32, NTFS, brtfs, etc …). Dans le cas de l'ext4, cela donnerait "mkfs.ext4 /dev/mapper/xxxxx". La commande en question va alors écrire quelques blocs de donnés sur le disque (ce que l'on appelle des "inodes"), que luks va bien entendu chiffrer.
3) Si on analysé le disque après cela, que voit t'on ? Beaucoup de zero, et éparpillé à des endroits bien précis, des blocs de données chiffrés, mais dont la taille et le nombre peuvent d'identifier que ce sont des blocs d'inodes, et donc, que le volume chiffré est formaté en ext4.
4) Si tu connais des éléments de signatures précis du système de fichiers (la structure des blocs d'inode est quelque chose de donnu), alors tu peux comparer ces signatures aux données chiffrés. Cela peut t'aider à déchiffré le volume complet.
5) Conclusion: remplir le disque dur de données aléatoires permet de rendre plus difficile l'identification des blocs connus du volume chiffré.
[^] # Re: L'intégralité du disque n'est pas chiffré
Posté par medrogan . Évalué à 2.
Ok merci j'ai compris, j'ai fait quelques tests avec "od" et, effectivement, il y a plein de blocs de zéros.
[^] # Re: L'intégralité du disque n'est pas chiffré
Posté par Kerro . Évalué à 2.
Et surtout, ça évite que l'attaquant ait une idée de ce qui est stocké.
Ce n'est pas la même chose d'avoir 30 Mio de données ou 600 Gio.
Dans le premier cas on pense à des documents, dans le second on pense à des vidéos/photos en plus du reste.
# Alerte rootkit !
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
Si tu n'as que 4 caractères dans
/dev/zero, ton système a un gros problème.[^] # Re: Alerte rootkit !
Posté par medrogan . Évalué à 1.
Le texte entre parenthèses est mal positionné, c'est dans mon volume de test qu'il y a un fichier contenant quatre caractères ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.