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?
security
ssd
dd
secure-delete
user857990
la source
la source
Réponses:
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.)
la source
L'utilisation
/dev/urandom
devrait 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.la source
/dev/random
, bien sûr, mais plus lent que/dev/zero
, et cela ne vous apporte aucune sécurité./dev/random
gé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/urandom
utilise é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.
la source
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.
la source
/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.urandom
peut prendre des heures. Je suis à peu près sûr que beaucoup de gens apprécieront le frandom pour cette raison.