Cher journal,
Il semblerait que, dans le cardre de l'affaire Fortis¹, les avocats de la banque ait transmis des données sur une clef USB à la police. Cependant, afin de ne pas être trop transparent et d'éviter que des informations qui pourraient être compromettantes circule n'importe, les avocats du service juridique ont supprimer certains fichiers. La police a cependant fait une analyse un peu poussée du support et a découvert ces fichiers qui avaient été supprimé (et pas réécrit).
Tout ça pour te dire qu'il y a encore du chemin à faire avant que les gens comprenne ce qu'il est possible de faire avec l'outil qu'ils manipulent. Et que même si les gens savent utiliser Windows, une formation ne ferrait pas de mal.
¹: l'affaire Fortis concerne une banque belge qui a failli faire faillite et qui a été sauvée in-extremis par l'état belge. Ceci aurait fait perdre beaucoup d'argent aux actionnaires essayent de prouver que la banque ne les a pas suffisamment informé comme elle l'aurait dû.
# Et vous ?
Posté par barmic . Évalué à 6.
Comment auriez-vous fait ?
Perso, je pense à la première méthode, mais ça aurait retardé d'une journée l'envoie des fichiers. Franchement quand tu vois les enjeux là j'aurais acheté une nouvelle clef USB (je présume qu'éviter la prison vaut bien une poignée d'euros en contrepartie).
Là pour le coup il y a moyen que les fichiers soient dans un dossier caché "trash" de la clef....
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et vous ?
Posté par Zenitram (site web personnel) . Évalué à 9.
Filer une clé USB qui n'a jamais contenu les fichiers qu'on ne veut pas filer. Bref, une clé neuve, "spéciale police", sur laquelle on n'écrit que ce qu'on veut filer, le plus sûr moyen de ne pas filer une chose est de ne l'avoir jamais écrit sur la clé.
Toutes tes méthodes peuvent être déjouées si on y met les moyens ("effet mémoire" des puces) + possibilité d'erreur humaine (oubli etc...).
[^] # Re: Et vous ?
Posté par nicolas . Évalué à 3.
Le flash posséderait un effet mémoire ? Par quel mécanisme ?
[^] # Re: Et vous ?
Posté par Zenitram (site web personnel) . Évalué à 3.
La, comme ça, je n'ai pas les liens, d'autres ici sont plus au courant que moi, mais de tête j'ai lu qu'en étudiant de près les cellules et leur état électrique suivi d'un algo pour tester les "possibilités viables" (ce qui aurait du sens, on écarte les erreurs), on peut retrouver leur état précédent voire quelques uns avant. Après, il faut avoir le matos et les compétences pour...
Après, si tu écrit 10x /dev/random, je pense que même la CIA aurait du mal, mais le principe de plus de sécurité (ne pas filer ce qui est écrit) est dans tous les cas plus viable. : on ne connait jamais les avancées techniques du mec en face.
[^] # Re: Et vous ?
Posté par beagf (site web personnel) . Évalué à 7.
Cette technique c'est pour les disques magnétiques style les disque durs, je n'ait pas entendu parler du même genre d'attaque contre les mémoires flash.
Si quelqu'un à des infos je suis intéressé.
[^] # Re: Et vous ?
Posté par cosmocat . Évalué à 7.
Un article paru récemment où justement les chercheurs s'alarment que sur un disque SSD, les données sont TRÈS vite supprimées. Là où ils pensaient qu'il faudrait 30 à 60 minutes pour supprimer les données (de façon statistiques), en 3 minutes, la majorités des fichiers sont inretrouvables.
http://news.techworld.com/security/3263093/ssd-fimware-destroys-digital-evidence-researchers-find/
PS : y'a le lien vers l'étude de 21 pages dans l'article pour ceux qui veulent creuser la question...
[^] # Re: Et vous ?
Posté par pasScott pasForstall . Évalué à 3.
Si tu penses a une depeche/journal poste par ici ya qq mois, c'etait tres loin d'etre applicable.
En gros, tu retrouvais le contenu si le disque etait ridiculement petit et si tu savais plus ou moins ce qu'il contenait avant. C'est pratique pour retrouver ses donnees a soi, pas trop pour espionner.
Des fichiers effaces mais pas reecrit par contre, la c'est zezette, tu recuperes presque tout sans forcer.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Et vous ?
Posté par GnunuX (site web personnel) . Évalué à 1.
Le plus simple reste "wipe" ... non ?
[^] # Re: Et vous ?
Posté par François Nautré . Évalué à 10.
Déjà j'aurais transmis un CD plutôt qu'une clé USB.
[^] # Re: Et vous ?
Posté par téthis . Évalué à 7.
Les supports de stockage ayant eu des données confidentielles ne doivent jamais sortir intacts du cercle de confidence. Mon choix se serait donc porté sur une clef USB neuve ou des CD gravés.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Et vous ?
Posté par claudex . Évalué à 4.
Ils auraient peut-être utilisé des CD réinscriptibles :)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et vous ?
Posté par yellowiscool . Évalué à 9.
J'aurais acheté une nouvelle clef, pour ensuite la remplir de plein de petites images de chats (ou pr0n au choix). Après avoir supprimé les images, j'aurais enfin mis les documents importants.
Envoyé depuis mon lapin.
[^] # /dev/frandom ?
Posté par solsTiCe (site web personnel) . Évalué à 1.
y'a /dev/frandom aussi par le bien d'un module, qui est plus rapide et qui ne perd pas trop en élément aléatoire. A priviligier sur disque dur.
[^] # Re: Et vous ?
Posté par Maclag . Évalué à 3.
J'aurais été encore plus subtil:
Mais ça fait trop longtemps que je suis en Chine, et maintenant j'ai beaucoup d'idées un peu tordues...
Du reste, je viens de lire que remplir la clé de 0 (ou de random) aurait retardé l'expédition de la clé d'une journée.
Je ne sais pas ce que les avocats utilisent comme clés USB ou comme ordinateur, mais chez moi (TM), formatter une clé en bas niveau prend vachement moins d'une journée...
Non, en fait la bonne réponse c'était de ne rien effacer parce que c'est pas bien d'essayer de gruger la police, qu'il y a de bonnes chances qu'ils s'en rendent compte tôt ou tard, et que finalement ils vont probablement mal le prendre et à la fin ça va être pire...
[^] # Re: Et vous ?
Posté par Xavier Teyssier (site web personnel) . Évalué à 3.
chez moi (TM), formatter une clé en bas niveau prend vachement moins d'une journée
Certes. Et générer un fichier de plusieurs Giga à partir de /dev/random ? Je pense que le facteur limitant auquel se référait la personne en question se situe là...
Après, on peut utiliser urandom, qui est bien plus rapide, mais théoriquement moins sûr...
[^] # Re: Et vous ?
Posté par Sébastien B. . Évalué à 8.
Mais en même temps, tu t'en fiche là que ça soit pas vraiment aléatoire, ce qui compte c'est d'écraser ce qu'il y a dessus, tu génère pas une clef RSA non plus quoi. Même si la séquence est prévisible, ben, c'est pas grave, ta clef est quand même "écrasée".
[^] # Re: Et vous ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Une fois la clef prête, il suffit d'écrire dessus et remplier le clef avec des fichiers sans intérêt, même pas besoin d'utiliser random ou /dev/null.
Ensuite, on efface ses fichiers supplémentaires et le tour est joué.
"La première sécurité est la liberté"
[^] # Re: Et vous ?
Posté par Thibault (site web personnel) . Évalué à 0.
Tu peux aussi utiliser /dev/urandom, qui est bien plus rapide pour générer beaucoup de données aléatoires :
[^] # Re: Et vous ?
Posté par Thibault (site web personnel) . Évalué à 1.
J'ai loupé la dernière ligne de ton commentaire, milles excuses...
[^] # Re: Et vous ?
Posté par emabc . Évalué à 1.
Il y a secure-delete sous Debian (la commande s'appelle srm)
# Cas des SSD
Posté par JGO . Évalué à 10.
Plus généralement, concernant les mémoires de masse flash (pas les simples clef usb), la situation est plus complexe. Le contrôleur fait un peu ce qu'il veut (compresser les données, répartir l'usure, effacer seulement s'il en a l'envie). Il y a aussi des zones où on ne peut pas écrire même en faisant un dd sur le disque complet. Bref, jamais de fichier confidentiel en clair sur un SSD.
http://hardware.slashdot.org/story/11/02/17/1911217/Confidential-Data-Not-Safe-On-Solid-State-Disks
Mais également, les SSD sont plus difficiles à analyser par la police. Faire un dd pour récupérer le contenu d'un disque magnétique (ou d'une clef usb) pour analyse est facile, mais pour les mêmes raisons que plus haut, faire un dd sur un ssd peut ne pas renvoyer le contenu effacé. Le seul moyen de savoir ce qu'il y a octet à octet est de lire les données au niveau du microcontrôleur, ce qui est à la fois plus difficile techniquement et juridiquement (il faut justifier de devoir détruire l'appareil et copier subrepticement le contenu sans qu'un suspect le sache n'est plus possible).
http://hardware.slashdot.org/story/11/03/01/1740240/SSDs-Cause-Crisis-For-Digital-Forensics
# Suppression exhaustive
Posté par Christophe HENRY (site web personnel) . Évalué à 2.
J'écris un gros fichier sur tout le disque, puis un shred dessus.
De cette manière, et à moins que le disque en garde sous le coude, la totalité des blocs devient atteignable avec un seul gros fichier.
[^] # Re: Suppression exhaustive
Posté par JGO . Évalué à 2.
Ta technique (remplir avec 1 seul fichier) devrait bien fonctionner, mais j'en profite pour présenter srm (secure rm) http://sourceforge.net/projects/srm/
Après les passes aléatoires, srm renomme et tronque les fichiers, faisant disparaitre aussi les métadonnées (nom, taille) de la table de fichiers.
L'algorithme d'effacement est plus complet que shred, il cumule les passes avec des zéros, des passes avec des 1, certaines avec /dev/urandom. L'algorithme est optimisé pour les médias magnétiques et il n'existe encore rien d'optimisé pour les mémoires flash.
Attention cependant que les systèmes de fichiers journalisés (donc, presque tous) peuvent de leur propore initiative rendre inopérantes ces mesures, en gardant des morceaux de données sensibles dans le journal, ou en y écrivant tous les effacements.
[^] # Re: Suppression exhaustive
Posté par JGO . Évalué à 2.
Le papier d'origine (1996) du spécialiste. Lire aussi les épilogues en bas pour les développements récents (techniques pour les SSD) et les mises en garde sur les limitations.
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
[^] # Re: Suppression exhaustive
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
L'algorithme d'effacement est plus complet que shred, il cumule les passes avec des z
zéros, des passes avec des 1, certaines avec /dev/urandom.
Toutes ces passes n'ont pas d'intérêt. A priori, avec un AFM (microscope à force atomique), on peut scanner en quelques heures la surface équivalente ~10ko. Par contre, on ne sait pas quels 10ko, sur un disque de plusieurs centaine de Go mais en plus, il faut retraiter un fichier de scan de plusieurs centaines de Go pour retrouver les donnés.
Donc bon...
"La première sécurité est la liberté"
[^] # Re: Suppression exhaustive
Posté par JGO . Évalué à 4.
Dans l'hypothèse où tu as donc démonté le disque, tu peux le monter sur un spin-stand (système de rotation et de têtes de disque dur utilisé pour les tests en salle blanche). Ensuite tu passes un bon moment à aligner l'axe de rotation du spin-stand avec celui du qui a écrit les données. Une fois que c'est fait, tu peux lire le signal brut, non pas 1/0 mais une courbe du signal. Éventuellement mets le disque en rotation plus lente pour acquérir le signal avec une plus grande résolution spatiale. Là, tu as accès à deux choses :
Si tu fais une seule passe d'effacement, y'a ds chances que l'état antérieur soit encore lisible d'un côté ou de l'autre des bits. La procédure décrite est automatisable.
[^] # Re: Suppression exhaustive
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
A moins que la technologie a été modifié, il est impossible de ré-aligner les têtes de lectures. Les têtes sont calibré en usines avec des paramètres en mémoires flash. Si ses paramètres sont perdus, les données le serait aussi.
"La première sécurité est la liberté"
[^] # Re: Suppression exhaustive
Posté par JGO . Évalué à 2.
J'ai vu passer un papier sur récupérer un alignement il y a quelques années. Maintenant les pistes on beaucoup réduit en taille, c'est peut-être plus possible sans les paramètres d'usine... Mais sans enlever le disque de son axe, tu peux essayer de prendre le contrôle du bras et de la tête de lecture au niveau du contrôleur, et récupérer les signaux de bas niveau.
[^] # Re: Suppression exhaustive
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
A priori, c'est ce qu'ils font en laboratoire pour lire un disque abimé, mais si la flash des données de calibration est morte, il ne peuvent rien faire.
"La première sécurité est la liberté"
[^] # Re: Suppression exhaustive
Posté par claudex . Évalué à 2.
Sauf qu'on parle de clef USB, c'est-à-dire de la mémoire Flash, il se peut donc que des secteurs ne soient plus inscriptible et donc la méthode ne fonctionne pas. Sauf si la clef est neuve mais il y a toujours un risque.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Suppression exhaustive
Posté par luten . Évalué à 1.
Oui à cause du wear-leveling on efface les secteurs logiques, non les secteurs physiques qui suivant les types d'algo utilisés par le controleur peuvent très bien conserver les data ( un effacement d'un secteur n'est qu'une réallocation d'un secteur vierge le plus souvant).
Comme mentionné plus haut même en ayant accès à la mémoire en bypassant le controleur et en connaissant l'algo utilisé cela ne doit pas être évidant de retrouvé ses petits.
[^] # Re: Suppression exhaustive
Posté par Christophe HENRY (site web personnel) . Évalué à 2.
Avec le Wear_levelling, les secteurs peuvent être mis en repos. Mais si un seul gros fichier occupe tout l'espace, tous les secteurs sont forcément mobilisés à la fin. Cette méthode ne marche pas pour les metadonnées, comme ça a été pointé plus haut, et pour les secteurs jugés défectueux.
Rien n'empêche de faire ce que j'ai indiqué, puis de refaire un bon dd/shred sur toute la clé. En principe, tous les secteurs sont parcourus, non ?
[^] # Re: Suppression exhaustive
Posté par claudex . Évalué à 3.
Sauf les secteurs défectueux. Ce qui arrive assez « rapidement » sur une clef usb.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Suppression exhaustive
Posté par J Avd . Évalué à 5.
Hou lallalalalala
JAMAIS faire un rm -rf /PATH/.* !!!
L'option f a des propriétés trop forte, le risque de remonter dans la racine est trop grand
Toujours rm -r uniquement et si ça pose des questions :
CTRL-C
unalias rm; puis rm -r
ou
/bin/rm -r
L'option f doit être utilisé avec la plus grande précaution...
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
[^] # Re: Suppression exhaustive
Posté par barmic . Évalué à 5.
À la place de :
tu peut faire :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Suppression exhaustive
Posté par calandoa . Évalué à 5.
Les bons shells ne transorment pas
.*en.et..; les bons rm refusent les argument.et..mais il est vrai qu'on n'est jamais trop prudent avec unrm -r...[^] # Re: Suppression exhaustive
Posté par steph1978 . Évalué à 1.
Pourquoi pas directement /dev/sdX ?
Au moins aucun FS ne sera suceptible de rendre certaines zones inaccessibles ou de conserver des journaux.
# Editeur de texte?
Posté par Nitchevo (site web personnel) . Évalué à 3.
Je n'ai pas ouvert un .doc depuis des années avec un éditeur de texte mais je me souviens que vers les années 2000, il était possible de trouver de cette manière des fragments des anciennes versions du document.
Si tel est toujours le cas alors, outre les mesures relatives au système de fichier, je transmettrai une version nouvelle du document réalisée par copier coller.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.