Dans un projet que je fais, je veux donner aux utilisateurs la possibilité de supprimer de manière sécurisée de supprimer un fichier - comme dans, écraser-le avec des bits aléatoires ou des 0. Y a-t-il une façon facile-ish de faire cela en C # .NET? Et à quel point cela serait-il efficace?
5 Réponses :
Vous ne pouvez pas supprimer en toute sécurité un fichier sur un système de fichiers de journalisation. Le seul système de non-journalisation toujours à une utilisation intensive est FAT32. Sur tout autre système, le seul moyen de supprimer en toute sécurité est de déchiqueter tout le disque dur.
La raison en mode Secure Ne fonctionne pas, c'est que les données utilisées pour écraser un fichier peuvent ne pas être stockées au même endroit que les données qu'il écrasent.
Il semble que Microsoft fournit un outil de suppression sécurisé, mais il ne semble pas être quelque chose que vous pouvez utiliser comme une chute de remplacement.
Le seul bon moyen d'empêcher la récupération de fichier supprimée, le manque de déchiquetage du disque, serait de chiffrer le fichier avant qu'il ne soit écrit sur le disque.
Merci pour la réponse, j'ai reproché une question un peu. Peu importe si le fichier est totalement effacé, tout ce qui compte, c'est que j'utilise des méthodes similaires pour un programme d'effacement des fichiers standard de tourbière
@Andrey, je ne comprends pas ce que tu veux dire
Si le fichier est, dites une taille de 100 Mo, il est totalement impraticable de garder les fichiers cryptés et originaux entiers en RAM ...
Vous pouvez invoquer Sysinternals sdelete pour le faire pour vous. Cela utilise l'API de défragmentation pour gérer tous ces cas de bord difficiles.
Utilisation de l'API de défragmentation, SDelete peut déterminer avec précision les clusters sur un disque sont occupés par des données appartenant à compressé, clairsemé et Fichiers cryptés.
Si vous souhaitez reconditionner cette logique sous une forme plus pratique, l'API est décrit ici .
J'essaierais d'abord simplement ouvrir le fichier et écraser son contenu car je le ferais normalement. Jolie triviale en C #, je ne prends même pas la peine de l'écrire. Cependant, je ne sais pas à quel point cela serait sécurisé. D'une part, je suis tout à fait sûr que cela ne fonctionnerait pas sur des lecteurs flash et des SSD qui utilisent des algorithmes sophistiqués pour fournir un nivellement de l'usure. Je ne sais pas ce qui fonctionnerait là-bas, il faudrait peut-être être fait au niveau du conducteur, peut-être que ce serait impossible du tout. Sur des lecteurs normaux, je ne sais tout simplement pas ce que Windows ferait. Peut-être qu'il conserverait également de vieilles données.
Cela ne fonctionnera pas sur aucun système de fichiers de journalisation, quel que soit le type de lecteur (voir ma réponse pour une explication).
@Mikerobi - Je sais, mais en dehors de cela - c'est la prochaine meilleure chose. Au moins, les utilitaires typiques de Lelete seront dupes.
Une solution serait de chiffrer le contenu du fichier de données. Une nouvelle clé serait utilisée chaque fois que le fichier est mis à jour. Lorsque vous souhaitez "supprimer de manière sécurisée", les données "perdent" la clé de cryptage et supprimez le fichier. Le fichier sera toujours sur le disque physiquement mais sans la récupération de la clé de cryptage serait impossible.
Voici une explication plus détaillée quant à pourquoi "Secure" Les écrasements de fichiers sont médiocres Sécurité:
sans outil de niveau bas (en dehors de .NET Runtime), vous n'avez accès à l'emplacement du disque physique. Prenez un filtream sur NTFS, lorsque vous «Ouvrez un fichier d'accès à l'écriture», vous n'avez aucune garantie que la copie «mise à jour» (dans ce cas aléatoire version 101010) sera stockée au même endroit (écrasant ainsi le fichier d'origine). En fait, la plupart du temps, c'est ce qui se passe:
1) fichier x.dat est stocké à partir de Cluster 8493489
2) Vous ouvrez fichier x.dat pour l'accès à l'écriture. Ce qui vous est retourné par le système d'exploitation est simplement un pointeur sur le flux de fichiers extraité par non seulement le système d'exploitation, mais le système de fichiers sous-jacents et les pilotes de périphérique sous-jacents (matériels RAID par exemple) et parfois le disque physique lui-même (SSD). Vous mettez à jour le contenu du fichier avec des 1 & 0 aléatoires et fermez le feuilleam.
3) Le système d'exploitation peut probablement (et probablement) écrire le nouveau fichier à un autre cluster (par exemple, cluster 4384939). Il ne fera ensuite que mettre à jour le fichier X MFT indiquant X est maintenant stocké au 4384939.
à l'utilisateur final, il ne semble que une copie du fichier existe et il a maintenant des données aléatoires. Toutefois, les données d'origine existent toujours sur le disque.
Le fichier ne peut pas être récupéré sans la clé, donc il est essentiellement perdu droit? tort. La clé est également récupérable de la même manière que le dossier aurait à moins que l'on sait exactement ce qu'il fait
Dupliqué possible de Fichiers de déchiquetage dans .NET
Vous avez complètement manqué le point de ma réponse, il n'ya aucun moyen de vous assurer que les données que vous essayez d'écrire dans un fichier occuperont réellement le même emplacement sur le disque que les données qu'il remplacent. Vous ne pouvez donc pas faire ce que vous êtes. Demander.
Voulez-vous supprimer en toute sécurité le contenu ou voulez-vous écraser-le avec des bits aléatoires? Ils ne sont pas les mêmes. Il suffit de écraser le fichier ne va pas faire ce que vous voulez, je pense.
@Mikerobi - C'est extrêmement difficile (en particulier de C #), mais pas impossible.
Dupliquer possible de [C # - Suppression d'un fichier de manière permanente] ()