Ce billet contient deux parties : la première explique succinctement les solutions et commandes pour pouvoir effacer toutes les données d’un disque (ou d’une partition). La deuxième approfondit les commandes et outils utilisés dans la première — Je me rend bien compte, après relecture du fait que j’ai pas mal dérivé dans l’écriture de cet article, il faut croire que j’avais beaucoup à dire.. donc si vous avez le temps, servez vous un café et profitez en bien.

Update le 6 Mai 2009: Correction des fautes d’orthographe…

ATTENTION: Toutes les procédures ci-dessous sont définitives et non réversibles. Après avoir exécuté ces commandes, vous (ou un tiers) ne pourrez JAMAIS récupérer les informations qui y étaient stockées.

Info: Dans ce billet j’utiliserais comme chemin pour mon disque dur a effacer : /dev/sdX, il vous faudra naturellement le remplacer par le vôtre. Vérifiez toujours d’abord vôtre table de partition avec « df » (utilitaire sans risques, il permet simplement de lister les disques montés sur vôtre système – NDLR : fstab)
Suivant la distribution *nix que vous utiliserez vous ne pourrez sûrement pas directement réinitialiser le disque système : il vous faudra utiliser un « live CD » ou booter sur un autre disque dur.

1. L’utilitaire « dd »:

L’utilitaire « dd » fourni avec tous les *nix et dérivés, permet de faire de nombreuses manipulations sur des fichiers ou des systèmes de fichiers comme (liste non exhaustive): Formatter une disquette à partir d’une image, découper un fichier en plusieurs morceaux, faire une image d’un DVD ou encore — et c’est ce qui nous intéresse ici — détruire les données d’un disque dur en le remplissant de zéros ou de données aléatoires.

Il faut toujours faire attention lorsqu’on utilise dd. Le simple fait d’oublier une option ou d’échanger les arguments aura des conséquences désastreuses.

1.1 Méthode rapide et peu sûre :

La première méthode consiste à écrire des 0 sur tous les secteurs du disque en une seule passe :

L’argument « conv=notrunc » permet de ne pas limiter la taille du fichier de sortie.

1.2 Méthode lente et moyennement sûre :

La seconde méthode, un peu plus sûre que la précédente consiste en l’utilisation du périphérique générateur d’aléatoires du noyau. Ce qui aura pour effet d’écrire des données aléatoires sur tous les secteurs du disque :

1.3 Méthode très lente et sûre:

Ici nous allons utiliser la première méthode, mais avec 32 passe.. De quoi vraiment tout effacer.

Notez qu’ici j’ai défini le paramètre « BS » qui correspond au nombre d’octets spécifié écrit en une seule fois. Ce qui permet de raccourcir considérablement le temps de chaque passe.

1.4 Méthode vraiment très lente et très sûre:

Pour cette dernière solution, vous l’aurez déduit par vous même, 16 passes de random, de quoi effacer définitivement n’importe quel octet sensible ! Suivant la taille du disque/partition, cette solution peut prendre énormément de temps…

Approfondissements :

Temps des opérations — Optimisations

Voyons comment se comporte dd pour un fichier test de 100Mb avec notre solution n°1 et un Block size de 1:

1 * 102400000 = 100Mb, dd a mis environ 7 minutes 38 secondes, pitoyable, pourquoi ?!

Petites précisions indispensables au sujet des secteurs (ou blocs):
Un secteur (ou bloc) est une subdivision d’une piste de votre disque dur. Chaque secteur peut stocker un nombre bien défini de données — les disques magnétiques fournissent généralement un espace de 512 octets (ce n’est pas le cas des SSD). La notion de bloc a été utilisée au début de l’informatique pour ce petit morceau de données, mais le terme secteur est devenu beaucoup plus courant. Puis peu à peu, « bloc » est devenu plus employé pour définir un certain nombre de données (variable) utilisé par un processus. Par exemple, le programme dd qui permet de définir la taille de bloc à utiliser lors de l’exécution avec le paramètre BS (= octets). En réalité, ça ne change pas la taille du secteur d’un support, seule la taille des données qui seront manipulées.

Notez que pour un CD, la taille d’un secteur est de 2.048 bytes (par exemple, si vous avez besoin de créer une image iso, tapez : dd if=/dev/hdc of=/tmp/mycd.iso bs=2048 conv=notrunc).

Reprenons — comment puis-je vérifier la taille des blocs sur un BSD ?

Et sur un GNU/Linux ?

Notez que sur le deuxième exemple, le système de fichier est en fait monté sur un RAID, d’où la réponse de BS de 4k.

Bien, maintenant que nous savons, essayons en spécifiant un BS de 512:

512 * 200000 = 100Mb, dd a mis à peine plus d’une 2,4s (contre 7m38) — la différence est énorme, pourquoi ?

En fait, l’explication est simple, c’est la synchronisation entre les données envoyées et les données écrites. Des blocs de 512 octets sont envoyés au disque et sont directement écrits sur les secteurs correspondants ; inutile de mettre en cache 512 fois 1 octet pour pouvoir écrire notre bloc. Et si on spécifie un BS supérieur, me direz-vous ? Essayons.

En effet, cela ne nous apporte rien ! notez que j’ai spécifié bs=512, mais en fait dd utilise par défaut le block size de 512.

/dev/zero, /dev/random ou /dev/urandom ?

Pour cette partie, je me suis largement inspiré des manpages de random que j’ai agrémentée d’exemples et quelques précisions.

Les fichiers spéciaux /dev/random et /dev/urandom existents depuis Linux 1.3.30 et ils fournissent une interface avec le générateur de nombres aléatoires du noyau. Il faut savoir que le noyau identifie chaque périphérique au moyen de deux numéros, le majeur (à gauche) et le mineur (à droite), ex:

Le fichier /dev/random a un numéro de périphérique majeur égal à 1, et un numéro mineur égal à 8. Les numéros du périphérique /dev/urandom sont 1 pour le majeur, et 9 pour le mineur et pour zero ils sont respectivement de 1 et 5. Ils sont de type c (Character), ils communiquent octet par octet (comme un port série) à l’inverse des disques durs qui sont de type b (Blocks) et qui – donc – communiquent par blocs de données.

Ce que l’on peut lire dans la documentation de noyau Linux a leurs propos :

1 char Memory device
    ...
    5 = /dev/zero        Null byte source
    ...
    8 = /dev/random   Nondeterministic random number gen.
    9 = /dev/urandom Faster, less secure random number gen.
    ...

En réalité, le générateur de nombres aléatoires récupère les séquences aléatoires en fonction du « bruit » généré par l’environnement : mouvement de la souris, frappe au clavier, etc.. Le générateur mémorise également une estimation du nombre de bits de bruit dans son réservoir d’entropie, et utilise son contenu pour créer des nombres aléatoires.
En effet, lors d’une lecture, le périphérique /dev/random sera limité au nombre de bits de bruit qu’il contient.
/dev/random est particulièrement adapté pour des cas où l’on a ponctuellement besoin de nombres hautement aléatoires (création de clés par exemple). Lorsque le réservoir d’entropie est vide, les lectures du périphérique /dev/random seront bloquantes jusqu’à l’obtention de suffisamment de bruits en provenance de l’environnement. Dans notre cas – ou l’on a besoin d’une très grande quantité de données —, nous risquons d’être très rapidement limité ! Heureusement, /dev/urandom renverra autant d’octets qu’on en demande. Toutefois, s’il n’y a plus assez de bits disponibles dans le réservoir d’entropie, les valeurs renvoyées pourraient être théoriquement vulnérables à une cryptanalyse basée sur l’algorithme employé par le pilote. Il n’existe pas de documentation sur ce type d’attaque dans la littérature publique actuelle, mais cela n’élimine pas le risque théorique.

Le fichier de périphérique /dev/zero quand a lui, se comporte comme s’il contenait une infinité d’octets à ~0. Quelle que soit la quantité de données que vous essayez de lire à partir de /dev/zero, il générera suffisamment d’octets nuls.

En résumé, nous allons plutôt utiliser /dev/urandom ou /dev/zero, sinon ça va prendre un temps fou. /dev/random donne de l’entropie « forte » (liée au matériel) et ne donne donc que quelques octets par seconde. /dev/urandom complète cette entropie forte avec du PRNG et génère donc les données aussi vite que nécessaire, ou presque..

Dans le cas d’un effacement de disque dur, ce risque nous importe peu, mais je trouvais intéressant d’en parler.

Petites précisions pour les BSD Users:
1) Le générateur de bruit random a été remplacé par un générateur cryptographique nommé « Yarrow algorithm » ;
2) /dev/urandom est un lien symbolique sur /dev/random.
3) Les numéros mineurs et majeurs ne sont pas les mêmes, ex:

Vérifications

Pour vérifier l’oeuvre de la commande dd couplée à random, nous allons utiliser « hexdump » (sur un fichier de 64b, pour une question de lisibilité).

Utilisons « zero » comme générateur:

Quand à utiliser « random », voici le résultat :

Vous pourrez, naturellement vérifier le résultat en situation « réelle » grace a la commande suivante :

Note finale

Il existe des logiciels comme « Shred » qui offrent des solutions « clés en main », mais qui au final ne font que ce que vous auriez très bien pu faire avec « dd » (un nombre X de passes random puis finir sur une « zero »), ex:

Les deux lignes suivantes font la même chose:

sachant que – pour un disque de 500Go – dd a été le plus rapide chez moi.

Il existe un ensemble d’outils nommé « secure_deletion toolkit », mais il n’est pas encore porté sur toutes les plates-formes. Par exemple, l’outil « sfill » pousse l’effacement sécurisé des fichiers à son paroxysme :

* Une passe avec 0xff
* 5 passes aléatoires avec la source /dev/urandom
* 27 passes avec des valeurs spéciales définies par Peter Gutmann. (Je vous invite d’ailleurs a lire son article très complet si vous voulez en savoir plus.)
* A nouveau 5 passes aléatoires.
* Une passe avec 0×00.

Il est peu être possible de lire « à côté des pistes », des résidus magnétisés et de retrouver ainsi des données écrites préalablement en décalant les têtes et peut être existe’il d’autres méthodes dont nous n’avons pas connaissance alors il reste une solution universelle et radicale : La destruction physique. C’est la seule solution réellement viable et irrécupérable : Perceuse, Masse, Acide et j’en passe..

Le générateur random et l’utilitaire dd sont disponibles sur énormément de distributions : Solaris, Mac OS X, FreeBSD, HP-UX, Tru64, AIX et j’en passe.

Explications

Exemple concret

Rien ne vous empêche, par exemple, de faire un cron qui lancerais la sauvegarde tous les dimanches a 6h du mat’.