Effacement du pré-chiffrement, pourquoi?


25

Je voulais savoir pourquoi, avant de crypter et de s'installer sur le disque, Kali:

  1. effacé tout le lecteur
  2. rempli le lecteur avec 0s
  3. rempli le lecteur avec 1s
  4. rempli le lecteur avec des données aléatoires
  5. effacé à nouveau le lecteur

Je sais que Kali n'est pas destiné à être installé, mais ce n'est pas le but ici.

Alors, comment est-ce utile avant l'installation, par exemple sur un tout nouveau disque dur? Je suis habitué à voir que lors de la suppression du disque dur, pas à installer.


Les étapes 1 à 3 sonnent de la même manière que badblockspour vérifier les secteurs défectueux, écrire et vérifier les 0, 1, 01 et 10. Pour le chiffrement du disque entier, il est courant de recommander un remplissage nul chiffré (pour écrire des données chiffrées partout) pour les raisons de la réponse de frostschultz (+1), mais faire tout cela avant le chiffrement est inhabituel, après le chiffrement puis l'exécution badblocksou mkfs -ccaccomplirait la même chose, plus identifier les blocs défectueux. Peut-être que quelqu'un chez Kali est un peu paranoïaque à propos de la mémoire flash (USB, SSD) n'écrivant pas toujours le même secteur au même endroit et échangeant des secteurs vers / à partir de sauvegardes
Xen2050

Réponses:


36

Il est inutile de faire plusieurs passes. Une fois est assez.

Remplir un disque à chiffrer avec des données aléatoires a principalement deux utilisations:

  • se débarrasser des anciennes données non chiffrées
  • rendre l'espace libre indiscernable des données chiffrées

Habituellement, si vous cryptez, vous ne voulez pas que quiconque voit vos données. Donc, si vous aviez de vieilles données non chiffrées sur ce disque, vous voulez aussi vous en débarrasser. Un SSD peut s'en occuper plus facilement et plus rapidement blkdiscard. En fait, Linux mkfsTRIMs toutes les données sans même vous demander de confirmation, ce qui rend impossible toute récupération de données. Il y a trop de TRIM sous Linux.

L'espace libre est un peu une zone grise. Si vous ne pré-remplissez pas avec des données aléatoires, sur un tout nouveau disque dur, les secteurs qui n'ont jamais été écrits seront des zéros. Sur un SSD, si vous autorisez la suppression / TRIM, l'espace libre sera également nul.

Bien que cela n'affecte en aucune façon vos données (elles sont toujours cryptées), cela révèle la quantité d'espace libre / données réelles dont vous disposez, et où cet espace / données libres est situé. Par exemple, un hexdump -CSSD chiffré et coupé ressemblera à ceci:

# hexdump -C /dev/ssd | grep -C 2 '^\*'
...
--
b3eabff0  dc c9 c7 89 16 ca d3 4f  a3 27 d6 df a0 10 c3 4f  |.......O.'.....O|
b3eac000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
b3f70000  5a 99 44 b5 9c 6b 1e 9c  81 cf 9a 43 b6 23 e9 0f  |Z.D..k.....C.#..|
b3f70010  2c e6 9a 5d 59 9b 46 5f  21 3f 4d 5f 44 5b 0a 6b  |,..]Y.F_!?M_D[.k|
--
b3f70ff0  5f 63 8d e8 c4 10 fd b1  a6 17 b5 7d 4a 57 09 68  |_c.........}JW.h|
b3f71000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
b3f72000  5d 1c 09 dd c9 6b 57 18  db 67 e1 35 81 57 45 8e  |]....kW..g.5.WE.|
b3f72010  0f a8 be 39 ae e5 5f cf  cf e3 8b a7 c1 25 1a a3  |...9.._......%..|
--
...

De cela , vous pouvez dire que j'ai des segments d'espace libre à l' adresse 0xb3eac000 .. 0xb3f70000, b3f71000 .. b3f72000... et l'inverse qui est des segments de données de cours comme 0xb3f70000 .. b3f71000.

Que pouvez-vous en faire? Eh bien, rien (*).

(*) c'est ce que j'aimerais dire. Mais les gens deviennent créatifs . Les modèles d'espace libre peuvent être utilisés pour dériver le type de système de fichiers que vous utilisez (en raison de la façon / où ils stockent les métadonnées - s'il y a de l'espace libre où ext4stocker l'une de ses sauvegardes de métadonnées, ce n'est probablement pas le cas ext4, etc.). Parfois, il révèle même la distribution que vous utilisez (si votre programme d'installation Linux remplit le système de fichiers de manière déterministe, les fichiers peuvent toujours se retrouver aux mêmes adresses physiques). À ce stade, quelqu'un pourrait savoir où se trouve un fichier système spécifique et pourrait le modifier / l'endommager d'une manière ou d'une autre. (Les installateurs doivent randomiser la façon dont ils remplissent les systèmes de fichiers pour éviter cela.)

Cependant, ces considérations sont très théoriques et présentent un risque très faible par rapport à la vulnérabilité des installations les plus cryptées pour d'autres raisons. Dans la plupart des installations prêtes à l'emploi, il est plus probable / plus simple de simplement altérer les initramfs, ou d'installer un enregistreur de frappe, ou d'exploiter le système en cours d'exécution, que d'obtenir en quelque sorte un accès brut et d'analyser les données chiffrées et d'espérer réaliser quoi que ce soit de cette façon.

Vous devez d'abord vous en préoccuper avant de vous soucier de révéler de l'espace libre.

Avec SSD, il est tout à fait normal d'activer TRIM et d'avoir ainsi de l'espace libre révélé à tout moment. C'est également le cas pour les solutions de chiffrement qui fonctionnent sur une couche de fichiers plutôt que sur une couche de blocs.

Avec le disque dur, vous effectuez principalement l'effacement aléatoire même sur un nouveau disque parce que vous le pouvez, et il n'y a aucune raison de ne pas le faire, car cela n'implique aucun coût (à part une première configuration) et aucun inconvénient.


1
Le découpage n'efface pas nécessairement tous les flash NAND découpés, car certains peuvent être dans le même bloc d'effacement que certains secteurs non découpés. (les blocs d'effacement sont plus grands que les blocs d'écriture). Même si mkfs coupe une partition entière avant d'écrire les nouvelles métadonnées, les données d'autres partitions (comme la partition système EFI) sont toujours actives et le micrologiciel SSD ne connaît pas les partitions.
Peter Cordes

Un lien vers en.wikipedia.org/wiki/Trim_(computing) pourrait être utile dans votre réponse!
Gaurav
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.