Sur le disque dur de ma machine perso, qui est sous
Debian Wheezy, j'utilise la commande « mcrypt » (issue
du paquet éponyme) pour chiffrer/déchiffrer un fichier
texte un peu sensible (c'est un fichier qui contient
des identifiants/mots des passe car je n'ai pas une bonne
mémoire ;)). La commande « mcrypt » permet donc de
chiffrer/déchiffrer un fichier via un mot de passe :
* avec « mcrypt secret.txt », je dois saisir deux fois à
l'identique un mot de passe et cela me génère une version
chiffrée de mon fichier qui s'appelle « secret.txt.nc ».
* avec « mcrypt -d secret.txt.nc », je dois saisir le mot
de passe précédent et alors la version en clair du fichier
est générée (ie le fichier « secret.txt »).
Je me suis fait un petit script shell qui me permet de
modifier ou consulter ce fichier (entre autres choses
le script supprime par exemple le fichier en clair une
fois que je l'ai consulté pour éviter que j'oublie un
jour etc).
Bref, d'un point de vue « ergonomie » ma solution bricolée
me convient très bien, pas de souci. Mais ma question porte
ici sur la « fiabilité » du chiffrement de la commande. En
effet, j'ai bien tenté de consulter la page man de « mcrypt »,
ça parle d'algorithmes etc. mais je dois avouer qu'en crypto
je n'y connais rien du tout.
La chiffrement de « mcrypt » sur Debian Wheezy (version 2.6.8)
est-il fiable ? Est-ce que, si un jour (en 2015/2016) quelqu'un
tombe sur la version chiffrée du fichier, fichier chiffré avec
un mot de passe d'une douzaine de caractères du genre celui-là
« El3;p@Nt3+14 » (rien à voir avec mon mot de passe mais c'est
pour donner une idée), est-ce que je peux avoir la garantie que
ce quelqu'un ne pourra pas déchiffrer le fichier en un temps
raisonnable ?
Parce que si on me dit qu'avec « mcrypt », le petit hacker du
dimanche peut me cracker mon fichier en 30 minutes, ça
m'embêterait un peu. ;)
Ci-dessous, voici du coup mon script pour consulter/éditer mon fichier secret.txt. Le script suppose que le fichier chiffré secret.txt.nc a été créé manuellement une première fois et ensuite, on appelle le script ainsi :
Hélas ! je ne peux pas t'aider pour valider le script, tu es visiblement bien plus compétent que moi ! mais il y a sûrement ici des barbus du script ...
Ci-dessous, voici du coup mon script pour consulter/éditer
mon fichier secret.txt. Le script suppose que le fichier
chiffré secret.txt.nc a été créé manuellement une première
fois et ensuite, on appelle le script ainsi :
Hélas ! je ne peux pas t'aider pour valider le script, tu es visiblement
bien plus compétent que moi ! mais il y a sûrement ici des barbus du
script ...
Ci-dessous, voici du coup mon script pour consulter/éditer mon fichier secret.txt. Le script suppose que le fichier chiffré secret.txt.nc a été créé manuellement une première fois et ensuite, on appelle le script ainsi :
Hélas ! je ne peux pas t'aider pour valider le script, tu es visiblement bien plus compétent que moi ! mais il y a sûrement ici des barbus du script ...
Paul Aubrin
On Fri, 28 Aug 2015 23:58:16 +0200, Francois Lafont wrote:
Sur le disque dur de ma machine perso, qui est sous Debian Wheezy, j'utilise la commande « mcrypt » (issue du paquet éponyme) pour chiffrer/déchiffrer un fichier texte un peu sensible (c'est un fichier qui contient des identifiants/mots des passe car je n'ai pas une bonne mémoire ;)). La commande « mcrypt » permet donc de chiffrer/déchiffrer un fichier via un mot de passe :
Pour les mots de passes, le mieux est d'utiliser un outil comme keepass. Pour des données plus volumineuses, on peut utiliser un système fichier chiffré tel que truecrypt. Sinon, le couteau suisse du chiffrement est l'option enc d'openssl (man enc). L'algorithme aes a été retenu après que sa solidité ait été validée par des cryptanalystes indépendants réputés.
On Fri, 28 Aug 2015 23:58:16 +0200, Francois Lafont wrote:
Sur le disque dur de ma machine perso, qui est sous Debian Wheezy,
j'utilise la commande « mcrypt » (issue du paquet éponyme) pour
chiffrer/déchiffrer un fichier texte un peu sensible (c'est un fichier
qui contient des identifiants/mots des passe car je n'ai pas une bonne
mémoire ;)). La commande « mcrypt » permet donc de chiffrer/déchiffrer
un fichier via un mot de passe :
Pour les mots de passes, le mieux est d'utiliser un outil comme keepass.
Pour des données plus volumineuses, on peut utiliser un système fichier
chiffré tel que truecrypt.
Sinon, le couteau suisse du chiffrement est l'option enc d'openssl (man
enc). L'algorithme aes a été retenu après que sa solidité ait été validée
par des cryptanalystes indépendants réputés.
On Fri, 28 Aug 2015 23:58:16 +0200, Francois Lafont wrote:
Sur le disque dur de ma machine perso, qui est sous Debian Wheezy, j'utilise la commande « mcrypt » (issue du paquet éponyme) pour chiffrer/déchiffrer un fichier texte un peu sensible (c'est un fichier qui contient des identifiants/mots des passe car je n'ai pas une bonne mémoire ;)). La commande « mcrypt » permet donc de chiffrer/déchiffrer un fichier via un mot de passe :
Pour les mots de passes, le mieux est d'utiliser un outil comme keepass. Pour des données plus volumineuses, on peut utiliser un système fichier chiffré tel que truecrypt. Sinon, le couteau suisse du chiffrement est l'option enc d'openssl (man enc). L'algorithme aes a été retenu après que sa solidité ait été validée par des cryptanalystes indépendants réputés.
Kevin Denis
Le 28-08-2015, Francois Lafont a écrit :
Ah oui, merci bien, je ne connaissais pas. Une fois de plus sur ce groupe de discussion, j'ai appris quelque chose. Après une consultation rapide de la page man de shred, il me semble que je peux remplacer mon « rm -f secret.txt » par ça :
shred --remove --verbose --zero secret.txt
Est-ce que c'est suffisant pour empêcher définitivement la récupération du fichier en clair secret.txt ?
un simple rm détruit la référence vers le fihier mais ne le supprime pas réellement. Un petit exemple: $ dd if=/dev/zero of=disk bs24k count 10+0 enregistrements lus 10+0 enregistrements écrits 10485760 octets (10 MB) copiés, 0,0149484 s, 701 MB/s $ sudo mke2fs disk [sudo] password for kevin: mke2fs 1.42.12 (29-Aug-2014) Rejet des blocs de périphérique : complété En train de créer un système de fichiers avec 10240 1k blocs et 2560 i-noeuds. UUID de système de fichiers5fcd75-c163-4c1d-906c-166b593c9b2c Superblocs de secours stockés sur les blocs : 8193
Allocation des tables de groupe : complété Écriture des tables d'i-noeuds : complété Écriture des superblocs et de l'information de comptabilité du système de fichiers : complété
$ sudo mount -t ext2 -o loop disk /mnt/hd $ ls /mnt/hd lost+found
-> j'ai créé un disque rempli de zéros. Plaçons y un fichier secret: $ sudo chmod 777 /mnt/hd/ $ echo "mot de passe secret" > /mnt/hd/secret $ sync $ rm -f /mnt/hd/secret
Donc suite au rm -f, le fichier a disparu, on est d'accord?
$ sudo umount /mnt/hd $ strings disk | grep pass mot de passe secret
Donc même si le fichier n'existe plus, les données sont encore présente. La référence au fichier a disparu, mais les données sont encore là.
qu'avec shred désormais ça ira mieux. ;) (même si on est d'accord j'ai sûrement des traces du fichier en clair qui traîneront encore quelques temps.)
Voilà. -- Kevin
Le 28-08-2015, Francois Lafont <francois.lafont@nospam.invalid> a écrit :
Ah oui, merci bien, je ne connaissais pas. Une fois de plus
sur ce groupe de discussion, j'ai appris quelque chose. Après
une consultation rapide de la page man de shred, il me semble
que je peux remplacer mon « rm -f secret.txt » par ça :
shred --remove --verbose --zero secret.txt
Est-ce que c'est suffisant pour empêcher définitivement la
récupération du fichier en clair secret.txt ?
un simple rm détruit la référence vers le fihier mais ne le supprime
pas réellement. Un petit exemple:
$ dd if=/dev/zero of=disk bs24k count
10+0 enregistrements lus
10+0 enregistrements écrits
10485760 octets (10 MB) copiés, 0,0149484 s, 701 MB/s
$ sudo mke2fs disk
[sudo] password for kevin:
mke2fs 1.42.12 (29-Aug-2014)
Rejet des blocs de périphérique : complété
En train de créer un système de fichiers avec 10240 1k blocs et 2560 i-noeuds.
UUID de système de fichiers5fcd75-c163-4c1d-906c-166b593c9b2c
Superblocs de secours stockés sur les blocs :
8193
Allocation des tables de groupe : complété
Écriture des tables d'i-noeuds : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété
$ sudo mount -t ext2 -o loop disk /mnt/hd
$ ls /mnt/hd
lost+found
-> j'ai créé un disque rempli de zéros. Plaçons y un fichier secret:
$ sudo chmod 777 /mnt/hd/
$ echo "mot de passe secret" > /mnt/hd/secret
$ sync
$ rm -f /mnt/hd/secret
Donc suite au rm -f, le fichier a disparu, on est d'accord?
$ sudo umount /mnt/hd
$ strings disk | grep pass
mot de passe secret
Donc même si le fichier n'existe plus, les données sont encore présente.
La référence au fichier a disparu, mais les données sont encore là.
qu'avec shred désormais ça ira mieux. ;) (même si on est d'accord j'ai
sûrement des traces du fichier en clair qui traîneront encore quelques
temps.)
Ah oui, merci bien, je ne connaissais pas. Une fois de plus sur ce groupe de discussion, j'ai appris quelque chose. Après une consultation rapide de la page man de shred, il me semble que je peux remplacer mon « rm -f secret.txt » par ça :
shred --remove --verbose --zero secret.txt
Est-ce que c'est suffisant pour empêcher définitivement la récupération du fichier en clair secret.txt ?
un simple rm détruit la référence vers le fihier mais ne le supprime pas réellement. Un petit exemple: $ dd if=/dev/zero of=disk bs24k count 10+0 enregistrements lus 10+0 enregistrements écrits 10485760 octets (10 MB) copiés, 0,0149484 s, 701 MB/s $ sudo mke2fs disk [sudo] password for kevin: mke2fs 1.42.12 (29-Aug-2014) Rejet des blocs de périphérique : complété En train de créer un système de fichiers avec 10240 1k blocs et 2560 i-noeuds. UUID de système de fichiers5fcd75-c163-4c1d-906c-166b593c9b2c Superblocs de secours stockés sur les blocs : 8193
Allocation des tables de groupe : complété Écriture des tables d'i-noeuds : complété Écriture des superblocs et de l'information de comptabilité du système de fichiers : complété
$ sudo mount -t ext2 -o loop disk /mnt/hd $ ls /mnt/hd lost+found
-> j'ai créé un disque rempli de zéros. Plaçons y un fichier secret: $ sudo chmod 777 /mnt/hd/ $ echo "mot de passe secret" > /mnt/hd/secret $ sync $ rm -f /mnt/hd/secret
Donc suite au rm -f, le fichier a disparu, on est d'accord?
$ sudo umount /mnt/hd $ strings disk | grep pass mot de passe secret
Donc même si le fichier n'existe plus, les données sont encore présente. La référence au fichier a disparu, mais les données sont encore là.
qu'avec shred désormais ça ira mieux. ;) (même si on est d'accord j'ai sûrement des traces du fichier en clair qui traîneront encore quelques temps.)
Voilà. -- Kevin
Benoit Izac
Bonjour,
Le 29/08/2015 à 01:39, Francois Lafont a écrit dans le message <55e0f128$0$3380$ :
Pour ce genre d'usage, à échelle du particulier, on utilise plutot des softs dans le genre de KeePass: http://doc.ubuntu-fr.org/keepassx http://sourceforge.net/p/keepass/discussion/329220/thread/17d1bd26/ https://packages.debian.org/sid/keepass2
Ça semble sans doute un programme très bien mais il s'utilise via une interface graphique, non ? J'avoue que je suis assez attaché à l'idée de pouvoir tout faire en console et aussi en utilisant mon petit vim que j'aime beaucoup. ;)
J'utilise pwsafe depuis quelques années et j'en suis très satisfait. <http://sourceforge.net/projects/pwsafe/>
-- Benoit Izac
Bonjour,
Le 29/08/2015 à 01:39, Francois Lafont a écrit dans le message
<55e0f128$0$3380$426a74cc@news.free.fr> :
Pour ce genre d'usage, à échelle du particulier, on utilise plutot
des softs dans le genre de KeePass:
http://doc.ubuntu-fr.org/keepassx
http://sourceforge.net/p/keepass/discussion/329220/thread/17d1bd26/
https://packages.debian.org/sid/keepass2
Ça semble sans doute un programme très bien mais il s'utilise
via une interface graphique, non ? J'avoue que je suis assez
attaché à l'idée de pouvoir tout faire en console et aussi en
utilisant mon petit vim que j'aime beaucoup. ;)
J'utilise pwsafe depuis quelques années et j'en suis très satisfait.
<http://sourceforge.net/projects/pwsafe/>
Le 29/08/2015 à 01:39, Francois Lafont a écrit dans le message <55e0f128$0$3380$ :
Pour ce genre d'usage, à échelle du particulier, on utilise plutot des softs dans le genre de KeePass: http://doc.ubuntu-fr.org/keepassx http://sourceforge.net/p/keepass/discussion/329220/thread/17d1bd26/ https://packages.debian.org/sid/keepass2
Ça semble sans doute un programme très bien mais il s'utilise via une interface graphique, non ? J'avoue que je suis assez attaché à l'idée de pouvoir tout faire en console et aussi en utilisant mon petit vim que j'aime beaucoup. ;)
J'utilise pwsafe depuis quelques années et j'en suis très satisfait. <http://sourceforge.net/projects/pwsafe/>
-- Benoit Izac
Francois Lafont
Hello,
On 29/08/2015 21:30, Kevin Denis wrote:
un simple rm détruit la référence vers le fihier mais ne le supprime pas réellement.
Oui, je pense que c'était déjà clair pour moi que rm supprime toute référence[*] au fichier dans les métadata du fs (dans la table des inodes notamment et peut-être ailleurs je ne sais pas) mais n'efface pas les données elles-mêmes (la zone est juste considérée comme disponible désormais).
[*] à condition que le fichier ne possède plus le moindre hardlink qui pointe vers lui.
Un petit exemple: $ dd if=/dev/zero of=disk bs24k count 10+0 enregistrements lus 10+0 enregistrements écrits 10485760 octets (10 MB) copiés, 0,0149484 s, 701 MB/s $ sudo mke2fs disk [sudo] password for kevin: mke2fs 1.42.12 (29-Aug-2014) Rejet des blocs de périphérique : complété En train de créer un système de fichiers avec 10240 1k blocs et 2560 i-noeuds. UUID de système de fichiers5fcd75-c163-4c1d-906c-166b593c9b2c Superblocs de secours stockés sur les blocs : 8193
Allocation des tables de groupe : complété Écriture des tables d'i-noeuds : complété Écriture des superblocs et de l'information de comptabilité du système de fichiers : complété
$ sudo mount -t ext2 -o loop disk /mnt/hd $ ls /mnt/hd lost+found
-> j'ai créé un disque rempli de zéros. Plaçons y un fichier secret: $ sudo chmod 777 /mnt/hd/ $ echo "mot de passe secret" > /mnt/hd/secret $ sync $ rm -f /mnt/hd/secret
Donc suite au rm -f, le fichier a disparu, on est d'accord?
$ sudo umount /mnt/hd $ strings disk | grep pass mot de passe secret
Donc même si le fichier n'existe plus, les données sont encore présente. La référence au fichier a disparu, mais les données sont encore là.
Ah, merci beaucoup pour l'exemple super rapide et peu coûteux pour tester les choses et voir de ses propres yeux. J'ai profité de ton exemple pour faire le test aussi avec un « shred --remove --zero » et j'ai pu constater effectivement que le rm laisse bien la donnée intacte (tant que le fs n'a pas réécrit par dessus évidemment) et qu'avec le shred plus aucune trace des données.
Voilà qui finit de me rassurer complètement. ;) Merci pour cet exemple très pédagogique Kevin.
-- François Lafont
Hello,
On 29/08/2015 21:30, Kevin Denis wrote:
un simple rm détruit la référence vers le fihier mais ne le supprime
pas réellement.
Oui, je pense que c'était déjà clair pour moi que rm supprime
toute référence[*] au fichier dans les métadata du fs (dans
la table des inodes notamment et peut-être ailleurs je ne
sais pas) mais n'efface pas les données elles-mêmes (la zone
est juste considérée comme disponible désormais).
[*] à condition que le fichier ne possède plus le moindre
hardlink qui pointe vers lui.
Un petit exemple:
$ dd if=/dev/zero of=disk bs24k count
10+0 enregistrements lus
10+0 enregistrements écrits
10485760 octets (10 MB) copiés, 0,0149484 s, 701 MB/s
$ sudo mke2fs disk
[sudo] password for kevin:
mke2fs 1.42.12 (29-Aug-2014)
Rejet des blocs de périphérique : complété
En train de créer un système de fichiers avec 10240 1k blocs et 2560 i-noeuds.
UUID de système de fichiers5fcd75-c163-4c1d-906c-166b593c9b2c
Superblocs de secours stockés sur les blocs :
8193
Allocation des tables de groupe : complété
Écriture des tables d'i-noeuds : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété
$ sudo mount -t ext2 -o loop disk /mnt/hd
$ ls /mnt/hd
lost+found
-> j'ai créé un disque rempli de zéros. Plaçons y un fichier secret:
$ sudo chmod 777 /mnt/hd/
$ echo "mot de passe secret" > /mnt/hd/secret
$ sync
$ rm -f /mnt/hd/secret
Donc suite au rm -f, le fichier a disparu, on est d'accord?
$ sudo umount /mnt/hd
$ strings disk | grep pass
mot de passe secret
Donc même si le fichier n'existe plus, les données sont encore présente.
La référence au fichier a disparu, mais les données sont encore là.
Ah, merci beaucoup pour l'exemple super rapide et peu coûteux
pour tester les choses et voir de ses propres yeux. J'ai profité
de ton exemple pour faire le test aussi avec un « shred --remove
--zero » et j'ai pu constater effectivement que le rm laisse bien
la donnée intacte (tant que le fs n'a pas réécrit par dessus
évidemment) et qu'avec le shred plus aucune trace des données.
Voilà qui finit de me rassurer complètement. ;)
Merci pour cet exemple très pédagogique Kevin.
un simple rm détruit la référence vers le fihier mais ne le supprime pas réellement.
Oui, je pense que c'était déjà clair pour moi que rm supprime toute référence[*] au fichier dans les métadata du fs (dans la table des inodes notamment et peut-être ailleurs je ne sais pas) mais n'efface pas les données elles-mêmes (la zone est juste considérée comme disponible désormais).
[*] à condition que le fichier ne possède plus le moindre hardlink qui pointe vers lui.
Un petit exemple: $ dd if=/dev/zero of=disk bs24k count 10+0 enregistrements lus 10+0 enregistrements écrits 10485760 octets (10 MB) copiés, 0,0149484 s, 701 MB/s $ sudo mke2fs disk [sudo] password for kevin: mke2fs 1.42.12 (29-Aug-2014) Rejet des blocs de périphérique : complété En train de créer un système de fichiers avec 10240 1k blocs et 2560 i-noeuds. UUID de système de fichiers5fcd75-c163-4c1d-906c-166b593c9b2c Superblocs de secours stockés sur les blocs : 8193
Allocation des tables de groupe : complété Écriture des tables d'i-noeuds : complété Écriture des superblocs et de l'information de comptabilité du système de fichiers : complété
$ sudo mount -t ext2 -o loop disk /mnt/hd $ ls /mnt/hd lost+found
-> j'ai créé un disque rempli de zéros. Plaçons y un fichier secret: $ sudo chmod 777 /mnt/hd/ $ echo "mot de passe secret" > /mnt/hd/secret $ sync $ rm -f /mnt/hd/secret
Donc suite au rm -f, le fichier a disparu, on est d'accord?
$ sudo umount /mnt/hd $ strings disk | grep pass mot de passe secret
Donc même si le fichier n'existe plus, les données sont encore présente. La référence au fichier a disparu, mais les données sont encore là.
Ah, merci beaucoup pour l'exemple super rapide et peu coûteux pour tester les choses et voir de ses propres yeux. J'ai profité de ton exemple pour faire le test aussi avec un « shred --remove --zero » et j'ai pu constater effectivement que le rm laisse bien la donnée intacte (tant que le fs n'a pas réécrit par dessus évidemment) et qu'avec le shred plus aucune trace des données.
Voilà qui finit de me rassurer complètement. ;) Merci pour cet exemple très pédagogique Kevin.
-- François Lafont
Kevin Denis
Le 30-08-2015, Francois Lafont a écrit :
Ah, merci beaucoup pour l'exemple super rapide et peu coûteux pour tester les choses et voir de ses propres yeux. J'ai profité de ton exemple pour faire le test aussi avec un « shred --remove --zero » et j'ai pu constater effectivement que le rm laisse bien la donnée intacte (tant que le fs n'a pas réécrit par dessus évidemment) et qu'avec le shred plus aucune trace des données.
Bon. Maintenant, imaginons que tu aies un SSD. Les opérations d'écriture ne sont pas faites sur place, mais regroupées et réordonnées. Ca se passe à un niveau plus bas que le filesystem. Afin d'étaler l'usure des cellules, une opération d'écriture peut se faire sur la cellule suivante. On imagine des cellules contigues ABCDEF et un fichier placé sur A: Si tu réécris le fichier, la cellule A est marquée comme vide, et le fichier est réécrit sur B. Et ainsi de suite. Un outil comme shred qui réécrit 5 fois des données aléatoire va en fait écrire 5 cellules du SSD.
Donc si un analyste démonte le SSD et lis les cellules une à une, il retrouvera le fichier écrit sur A.
Tu peux lire la partie 5.19 de la FAQ de LUKS https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions -- Kevin
Le 30-08-2015, Francois Lafont <francois.lafont@nospam.invalid> a écrit :
Ah, merci beaucoup pour l'exemple super rapide et peu coûteux
pour tester les choses et voir de ses propres yeux. J'ai profité
de ton exemple pour faire le test aussi avec un « shred --remove
--zero » et j'ai pu constater effectivement que le rm laisse bien
la donnée intacte (tant que le fs n'a pas réécrit par dessus
évidemment) et qu'avec le shred plus aucune trace des données.
Bon. Maintenant, imaginons que tu aies un SSD. Les opérations d'écriture
ne sont pas faites sur place, mais regroupées et réordonnées. Ca se passe
à un niveau plus bas que le filesystem.
Afin d'étaler l'usure des cellules, une opération d'écriture peut se faire
sur la cellule suivante.
On imagine des cellules contigues ABCDEF et un fichier placé sur A:
Si tu réécris le fichier, la cellule A est marquée comme vide, et le fichier
est réécrit sur B. Et ainsi de suite. Un outil comme shred qui réécrit
5 fois des données aléatoire va en fait écrire 5 cellules du SSD.
Donc si un analyste démonte le SSD et lis les cellules une à une, il
retrouvera le fichier écrit sur A.
Tu peux lire la partie 5.19 de la FAQ de LUKS
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
--
Kevin
Ah, merci beaucoup pour l'exemple super rapide et peu coûteux pour tester les choses et voir de ses propres yeux. J'ai profité de ton exemple pour faire le test aussi avec un « shred --remove --zero » et j'ai pu constater effectivement que le rm laisse bien la donnée intacte (tant que le fs n'a pas réécrit par dessus évidemment) et qu'avec le shred plus aucune trace des données.
Bon. Maintenant, imaginons que tu aies un SSD. Les opérations d'écriture ne sont pas faites sur place, mais regroupées et réordonnées. Ca se passe à un niveau plus bas que le filesystem. Afin d'étaler l'usure des cellules, une opération d'écriture peut se faire sur la cellule suivante. On imagine des cellules contigues ABCDEF et un fichier placé sur A: Si tu réécris le fichier, la cellule A est marquée comme vide, et le fichier est réécrit sur B. Et ainsi de suite. Un outil comme shred qui réécrit 5 fois des données aléatoire va en fait écrire 5 cellules du SSD.
Donc si un analyste démonte le SSD et lis les cellules une à une, il retrouvera le fichier écrit sur A.
Tu peux lire la partie 5.19 de la FAQ de LUKS https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions -- Kevin
Francois Lafont
On 30/08/2015 22:29, Kevin Denis wrote:
Bon. Maintenant, imaginons que tu aies un SSD. Les opérations d'écriture ne sont pas faites sur place, mais regroupées et réordonnées. Ca se passe à un niveau plus bas que le filesystem. Afin d'étaler l'usure des cellules, une opération d'écriture peut se faire sur la cellule suivante. On imagine des cellules contigues ABCDEF et un fichier placé sur A: Si tu réécris le fichier, la cellule A est marquée comme vide, et le fichier est réécrit sur B. Et ainsi de suite. Un outil comme shred qui réécrit 5 fois des données aléatoire va en fait écrire 5 cellules du SSD.
Donc si un analyste démonte le SSD et lis les cellules une à une, il retrouvera le fichier écrit sur A.
Ok, compris, merci bien.
Tu peux lire la partie 5.19 de la FAQ de LUKS https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
Mais il n'y a aucun moyen d'effacer véritablement et de manière certaine une donnée d'un disque SSD ? Je ne suis pas concerné par ce problème vu que je n'ai pas de SSD mais juste par curiosité. Parce que dans ton lien, j'ai pas l'impression qu'ils proposent de solutions (juste des contournements).
-- François Lafont
On 30/08/2015 22:29, Kevin Denis wrote:
Bon. Maintenant, imaginons que tu aies un SSD. Les opérations d'écriture
ne sont pas faites sur place, mais regroupées et réordonnées. Ca se passe
à un niveau plus bas que le filesystem.
Afin d'étaler l'usure des cellules, une opération d'écriture peut se faire
sur la cellule suivante.
On imagine des cellules contigues ABCDEF et un fichier placé sur A:
Si tu réécris le fichier, la cellule A est marquée comme vide, et le fichier
est réécrit sur B. Et ainsi de suite. Un outil comme shred qui réécrit
5 fois des données aléatoire va en fait écrire 5 cellules du SSD.
Donc si un analyste démonte le SSD et lis les cellules une à une, il
retrouvera le fichier écrit sur A.
Ok, compris, merci bien.
Tu peux lire la partie 5.19 de la FAQ de LUKS
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
Mais il n'y a aucun moyen d'effacer véritablement et
de manière certaine une donnée d'un disque SSD ? Je ne
suis pas concerné par ce problème vu que je n'ai pas
de SSD mais juste par curiosité. Parce que dans ton
lien, j'ai pas l'impression qu'ils proposent de
solutions (juste des contournements).
Bon. Maintenant, imaginons que tu aies un SSD. Les opérations d'écriture ne sont pas faites sur place, mais regroupées et réordonnées. Ca se passe à un niveau plus bas que le filesystem. Afin d'étaler l'usure des cellules, une opération d'écriture peut se faire sur la cellule suivante. On imagine des cellules contigues ABCDEF et un fichier placé sur A: Si tu réécris le fichier, la cellule A est marquée comme vide, et le fichier est réécrit sur B. Et ainsi de suite. Un outil comme shred qui réécrit 5 fois des données aléatoire va en fait écrire 5 cellules du SSD.
Donc si un analyste démonte le SSD et lis les cellules une à une, il retrouvera le fichier écrit sur A.
Ok, compris, merci bien.
Tu peux lire la partie 5.19 de la FAQ de LUKS https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
Mais il n'y a aucun moyen d'effacer véritablement et de manière certaine une donnée d'un disque SSD ? Je ne suis pas concerné par ce problème vu que je n'ai pas de SSD mais juste par curiosité. Parce que dans ton lien, j'ai pas l'impression qu'ils proposent de solutions (juste des contournements).
-- François Lafont
Ascadix
Le 30/08/2015, Francois Lafont a supposé :
On 30/08/2015 22:29, Kevin Denis wrote:
Bon. Maintenant, imaginons que tu aies un SSD. Les opérations d'écriture ne sont pas faites sur place, mais regroupées et réordonnées. Ca se passe à un niveau plus bas que le filesystem. Afin d'étaler l'usure des cellules, une opération d'écriture peut se faire sur la cellule suivante. On imagine des cellules contigues ABCDEF et un fichier placé sur A: Si tu réécris le fichier, la cellule A est marquée comme vide, et le fichier est réécrit sur B. Et ainsi de suite. Un outil comme shred qui réécrit 5 fois des données aléatoire va en fait écrire 5 cellules du SSD.
Donc si un analyste démonte le SSD et lis les cellules une à une, il retrouvera le fichier écrit sur A.
Ok, compris, merci bien.
Tu peux lire la partie 5.19 de la FAQ de LUKS https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
Mais il n'y a aucun moyen d'effacer véritablement et de manière certaine une donnée d'un disque SSD ? Je ne suis pas concerné par ce problème vu que je n'ai pas de SSD mais juste par curiosité. Parce que dans ton lien, j'ai pas l'impression qu'ils proposent de solutions (juste des contournements).
Backup des données, pas un dd raw hein, une copie des fichiers + le nécessaire pour le systéme (MBR, etc...) éventuellement, un coup de clonezilla par ex ferait l'affaire.
puis un sécure erase du SSD
puis restore des données
:-) Oui, c'est sacrément lourd
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Le 30/08/2015, Francois Lafont a supposé :
On 30/08/2015 22:29, Kevin Denis wrote:
Bon. Maintenant, imaginons que tu aies un SSD. Les opérations d'écriture
ne sont pas faites sur place, mais regroupées et réordonnées. Ca se passe
à un niveau plus bas que le filesystem.
Afin d'étaler l'usure des cellules, une opération d'écriture peut se faire
sur la cellule suivante.
On imagine des cellules contigues ABCDEF et un fichier placé sur A:
Si tu réécris le fichier, la cellule A est marquée comme vide, et le fichier
est réécrit sur B. Et ainsi de suite. Un outil comme shred qui réécrit
5 fois des données aléatoire va en fait écrire 5 cellules du SSD.
Donc si un analyste démonte le SSD et lis les cellules une à une, il
retrouvera le fichier écrit sur A.
Ok, compris, merci bien.
Tu peux lire la partie 5.19 de la FAQ de LUKS
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
Mais il n'y a aucun moyen d'effacer véritablement et
de manière certaine une donnée d'un disque SSD ? Je ne
suis pas concerné par ce problème vu que je n'ai pas
de SSD mais juste par curiosité. Parce que dans ton
lien, j'ai pas l'impression qu'ils proposent de
solutions (juste des contournements).
Backup des données, pas un dd raw hein, une copie des fichiers + le
nécessaire pour le systéme (MBR, etc...) éventuellement, un coup de
clonezilla par ex ferait l'affaire.
puis un sécure erase du SSD
puis restore des données
:-)
Oui, c'est sacrément lourd
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Bon. Maintenant, imaginons que tu aies un SSD. Les opérations d'écriture ne sont pas faites sur place, mais regroupées et réordonnées. Ca se passe à un niveau plus bas que le filesystem. Afin d'étaler l'usure des cellules, une opération d'écriture peut se faire sur la cellule suivante. On imagine des cellules contigues ABCDEF et un fichier placé sur A: Si tu réécris le fichier, la cellule A est marquée comme vide, et le fichier est réécrit sur B. Et ainsi de suite. Un outil comme shred qui réécrit 5 fois des données aléatoire va en fait écrire 5 cellules du SSD.
Donc si un analyste démonte le SSD et lis les cellules une à une, il retrouvera le fichier écrit sur A.
Ok, compris, merci bien.
Tu peux lire la partie 5.19 de la FAQ de LUKS https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
Mais il n'y a aucun moyen d'effacer véritablement et de manière certaine une donnée d'un disque SSD ? Je ne suis pas concerné par ce problème vu que je n'ai pas de SSD mais juste par curiosité. Parce que dans ton lien, j'ai pas l'impression qu'ils proposent de solutions (juste des contournements).
Backup des données, pas un dd raw hein, une copie des fichiers + le nécessaire pour le systéme (MBR, etc...) éventuellement, un coup de clonezilla par ex ferait l'affaire.
puis un sécure erase du SSD
puis restore des données
:-) Oui, c'est sacrément lourd
-- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Francois Lafont
On 31/08/2015 01:00, Ascadix wrote:
Backup des données, pas un dd raw hein, une copie des fichiers + le nécessaire pour le systéme (MBR, etc...) éventuellement, un coup de clonezilla par ex ferait l'affaire.
puis un sécure erase du SSD
D'après le lien donné par Kevin, même un "secure erase" n'est pas forcément fiable à tous les coups.
puis restore des données
:-) Oui, c'est sacrément lourd
Oui en effet. ;)
Bon, le jour où j'ai un SSD, je change mon script pour que le fichier en clair soit écrit sur un tmpfs et puis voilà. :p
-- François Lafont
On 31/08/2015 01:00, Ascadix wrote:
Backup des données, pas un dd raw hein, une copie des fichiers + le nécessaire pour le systéme (MBR, etc...) éventuellement, un coup de clonezilla par ex ferait l'affaire.
puis un sécure erase du SSD
D'après le lien donné par Kevin, même un "secure erase"
n'est pas forcément fiable à tous les coups.
puis restore des données
:-)
Oui, c'est sacrément lourd
Oui en effet. ;)
Bon, le jour où j'ai un SSD, je change mon script pour
que le fichier en clair soit écrit sur un tmpfs et puis
voilà. :p
Backup des données, pas un dd raw hein, une copie des fichiers + le nécessaire pour le systéme (MBR, etc...) éventuellement, un coup de clonezilla par ex ferait l'affaire.
puis un sécure erase du SSD
D'après le lien donné par Kevin, même un "secure erase" n'est pas forcément fiable à tous les coups.
puis restore des données
:-) Oui, c'est sacrément lourd
Oui en effet. ;)
Bon, le jour où j'ai un SSD, je change mon script pour que le fichier en clair soit écrit sur un tmpfs et puis voilà. :p
-- François Lafont
gump
Bon, le jour où j'ai un SSD, je change mon script pour que le fichier en clair soit écrit sur un tmpfs et puis voilà. :p
Oui, un RAMdisk est la bonne solution.
D'une manière générale, la confidentialité des données ne fait pas bon ménage avec les SSD et les systèmes de fichiers journalisés ( donc NTFS sous Windows, et ext3, ext4, Reiser, etc. sous Linux ) Le mieux : pour des données sensibles, une partition en fat32 ( lisible et inscriptible sous Linux ) ou ext2. Plus un tmpfs comme cache volatile. Et ne pas oublier le swap : tu dis qu'il ne sert pas mais ...qui sait ? Sous windows, supprimer carrément la mémoire virtuelle, ça fait plus de dix ans que je le fais et aucun prog ne s'en est jamais plaint !
Bon, ça c'est si on a des secrets d'Etat, hein ! sinon on peut quand même être moins parano.
Bon, le jour où j'ai un SSD, je change mon script pour
que le fichier en clair soit écrit sur un tmpfs et puis
voilà. :p
Oui, un RAMdisk est la bonne solution.
D'une manière générale, la confidentialité des données ne fait pas bon
ménage avec les SSD et les systèmes de fichiers journalisés ( donc NTFS
sous Windows, et ext3, ext4, Reiser, etc. sous Linux )
Le mieux : pour des données sensibles, une partition en fat32 ( lisible
et inscriptible sous Linux ) ou ext2. Plus un tmpfs comme cache volatile.
Et ne pas oublier le swap : tu dis qu'il ne sert pas mais ...qui sait ?
Sous windows, supprimer carrément la mémoire virtuelle, ça fait plus de
dix ans que je le fais et aucun prog ne s'en est jamais plaint !
Bon, ça c'est si on a des secrets d'Etat, hein ! sinon on peut quand
même être moins parano.
Bon, le jour où j'ai un SSD, je change mon script pour que le fichier en clair soit écrit sur un tmpfs et puis voilà. :p
Oui, un RAMdisk est la bonne solution.
D'une manière générale, la confidentialité des données ne fait pas bon ménage avec les SSD et les systèmes de fichiers journalisés ( donc NTFS sous Windows, et ext3, ext4, Reiser, etc. sous Linux ) Le mieux : pour des données sensibles, une partition en fat32 ( lisible et inscriptible sous Linux ) ou ext2. Plus un tmpfs comme cache volatile. Et ne pas oublier le swap : tu dis qu'il ne sert pas mais ...qui sait ? Sous windows, supprimer carrément la mémoire virtuelle, ça fait plus de dix ans que je le fais et aucun prog ne s'en est jamais plaint !
Bon, ça c'est si on a des secrets d'Etat, hein ! sinon on peut quand même être moins parano.
