L'essuyage est très lent. Trop peu d'entropie?

16

Je dois remettre un ordinateur portable, y compris son disque dur. Puisqu'il n'était pas crypté, je voulais l'essuyer au moins rapidement. Je sais que ce n'est pas optimal sur SSD, mais je pensais mieux que simplement lisible.

Maintenant, je suis en train d'essuyer une clé USB en direct et c'est douloureusement lent. Je me demande pourquoi. Bien sûr, il n'y a pratiquement rien qui se passe sur l'ordinateur en plus d'essuyer cet appareil, donc j'imagine que l'entropie pourrait être faible (entropy_avail dit que c'est à 1220). Serait-il tout aussi bon d'appeler

dd if=/dev/random of=/dev/sda1 bs=1k

quatre fois? Ou existe-t-il un moyen d'appeler quelque chose qui augmentera le caractère aléatoire? Ou le col de la bouteille est-il quelque part complètement différent?

user857990
la source
23
Arrête de faire ça. Vous venez de détruire le SSD.
Michael Hampton
Est-ce la mauvaise utilisation du mot entropie?
user3728501
3
@ user3728501: Il y a vraiment deux facettes à la réponse: "l'entropie" ici est cohérente avec l'utilisation du noyau, donc oui, c'est le bon mot dans ce sens; mais l'utilisation par le noyau de "l'entropie" parle vraiment d' entropie estimée , pas de véritable entropie de Shannon. Il suffit de dire que les détails sont suffisamment subtils pour que personne ne vous reproche d'avoir dit "entropie" dans ce contexte (à moins qu'ils ne soient pédant).
Reid
3
Je ne comprends pas pourquoi quelqu'un utiliserait random / urandom sur un disque moderne de toute façon, SSD ou non - la mise à zéro serait plus rapide et tout aussi efficace.
Chopper3
@Reid Assez bien - J'ai vu la question et j'étais intéressé en raison de mes antécédents en physique.
user3728501

Réponses:

50

N'essayez pas de "nettoyer" un SSD avec des outils conçus pour faire tourner des disques durs magnétiques. Vous ne détruirez pas réellement toutes les données et vous réduirez simplement la durée de vie du SSD.

À la place, utilisez un outil d'effacement spécialement conçu pour les SSD, qui peut utiliser l'effacement flash interne (rejet) du lecteur pour supprimer tous les blocs, y compris ceux auxquels vous ne pouvez pas accéder. Le fournisseur de SSD fournit généralement un tel outil qui est garanti compatible avec les disques de ce fournisseur.

Vous pouvez également essayer de le faire vous-même avec un utilitaire Secure Erase . Les programmes qui effectuent l'effacement sécurisé fonctionnent avec les disques durs et les SSD en rotation. De plus, quelques BIOS système (principalement dans les ordinateurs portables professionnels) ont une fonctionnalité Secure Erase intégrée. Notez qu'un Secure Erase prendra des heures sur un disque dur, mais seulement quelques secondes sur un SSD; sur un disque dur, chaque secteur doit être écrasé, mais sur un SSD, il supprimera tous les blocs à la fois et / ou modifiera la clé de chiffrement interne du lecteur.

(Et notez que l'effacement sécurisé ne fonctionnait pas correctement sur certains des SSD de la première génération; dans ces cas, vous devez simplement jeter le lecteur dans un concasseur.)

Michael Hampton
la source
1
Bravo @Michael pour ne pas avoir laissé la question faire obstacle à la bonne réponse.
poussins
6

L'utilisation /dev/urandomdevrait tout accélérer. Je n'essuierais pas un SSD comme ça. Les SSD ont généralement un niveau d'usure avancé en place. Fondamentalement, au lieu d'écrire sur les données existantes, le lecteur écrit sur les parties inutilisées. Il faudra un peu de temps pour brouiller correctement toutes les données. À ce moment-là, vous auriez déjà porté un SSD, bien que ce ne soit que très peu.

PNDA
la source
2
Plus rapide que /dev/random, bien sûr, mais plus lent que /dev/zero, et cela ne vous apporte aucune sécurité.
Mark
2
@Mark Pourquoi? Bien qu'il ne soit que pseudo-aléatoire, il écrase également les données sur l'appareil avec une merde à haute entropie.
peterh
4
@peterh, vous n'avez pas besoin de conneries à haute entropie. Il n'a pas été possible de récupérer des données à partir d'un disque à effacement nul depuis au moins les 20 dernières années.
Mark
3

/dev/randomgénère des données aléatoires par entropie collectées par votre système (délais entre les raccourcis clavier, synchronisation du réseau en mesurant les arrivées de paquets avec une précision en nanosecondes, etc.). S'il n'y a pas assez d'entropie, cet appareil bloque la sortie pendant qu'il recueille plus d'entropie.

/dev/urandomutilise également l'entropie collectée, mais elle utilise également un générateur pseudo-aléatoire. Donc, son n'a pas beaucoup d'entropie, contrairement à /dev/random, mais il est très rapide. Cependant, sa sortie a une entropie suffisamment élevée, vous pouvez donc l'utiliser partout si vous n'avez pas de restrictions de sécurité très élevées (généralement, la génération de clés).

Si vous écrasez un SSD au niveau du bloc avec de la merde à haute entropie, vous écraserez en fait son ram flash au niveau très bas (et dans la plupart des cas, inaccessible). En effet, le circuit intégré de contrôle SSD n'a aucune possibilité d'enquêter, vos données sont vraiment nulles ou non, de sorte que son mécanisme de déduplication des données est facilement évité.

Mais les béliers flash ont une écriture de bloc maximale et vous l'envoyez avec une telle action plus près de l'expiration de sa durée de vie. Mais un SSD peut être écrasé environ 10000-100000 fois avant qu'il ne commence à mourir, et l'effacement des données n'a pas besoin de se produire si souvent, il est donc encore correct.

peterh - Réintégrer Monica
la source
Je devrais utiliser mon compte serverfault plus souvent.
PNDA
1

En réponse aux commentaires de ma réponse, je dois admettre que l'essuyage n'est généralement pas une bonne idée pour les SSD.

En plus des réponses ci-dessus, je voudrais recommander frandom

C'est encore plus rapide que l'urandom. urandom est beaucoup plus rapide que aléatoire mais pourtant assez lent. Frandom est mon choix pour l'essuyage des disques et uniquement pour l'essuyage des disques. Il ne produit pas la même entropie que aléatoire et urandom, mais pour essuyer le disque, cela devrait suffire. Comme l'a souligné MadHatter, l'algorithme utilisé présente des faiblesses. Mais pour essuyer le disque, vous voulez seulement vous assurer qu'il n'est pas possible de reconstruire les bits restants possibles.

Si vous avez des problèmes pour le lancer, l' ArchWiki a une bonne documentation. L' ArchWiki couvre également beaucoup plus de détails sur la façon d'effacer les disques.

Henrik Pingel
la source
À titre de mise en garde, je note que l'auteur de frandom dit qu '" est basé sur l'algorithme de cryptage RC4, qui est considéré comme sécurisé, et est utilisé par plusieurs applications, y compris SSL ". Ce n'est pas tout à fait vrai; Wikipedia note en juillet 2015 que " RC4 a des faiblesses qui plaident contre son utilisation dans de nouveaux systèmes ... La RFC 7465 interdit l'utilisation de RC4 dans TLS ". J'accorde que frandom est un remplacement pour /dev/urandom, ce qui n'est pas très aléatoire de toute façon, mais toute personne utilisant frandom devrait probablement se rendre compte des problèmes.
MadHatter
Merci pour le commentaire. J'ai modifié ma réponse pour refléter votre point.
Henrik Pingel
Je ne peux pas contester cela - +1 de ma part (même si cette question a déjà reçu une réponse complète).
MadHatter
Merci. essuyer avec urandompeut prendre des heures. Je suis à peu près sûr que beaucoup de gens apprécieront le frandom pour cette raison.
Henrik Pingel
1
Je suis d'accord, mais pas pour les SSD , c'est précisément le sujet de cette question.
MadHatter