Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 24/01/2016, à 11:36

mandeb

[résolu] laisser les lieux en partant aussi propres qu'en entrant

Bonjour à tous,

Passionné de chiffrement je me suis fait une petite implémentation du 'One Time Pad' en python + wx.python. Pas de souci tout fonctionne convenablement.
La question qui me préoccupe concerne le 'nettoyage' à faire en fin de traitement sur le PC qui a été utilisé. Comment s'assurer qu'il ne reste aucune trace du travail en terme de buffers fichiers, fichiers tmp, dans la ram, etc..., de tout éléments éventuellement exploitables par un éventuel attaquant ? Un reboot doit naturellement déjà en supprimer pas mal mais quid des disques ?

Pour le traitement de petits fichiers il ne doit pas y avoir grand chose à nettoyer mais je dois protéger des gros fichiers (Go) qui eux doivent sans doute nécessiter l'usage temporaires de certaines zones disque.

Que faut-il vérifier et existe-t-il des fonctions de nettoyage en python ? f.close() vide-t-il les buffers fichiers ?

bref, comment être le plus "furtif" possible ?

merci et bon we.

Dernière modification par mandeb (Le 26/01/2016, à 14:52)

Hors ligne

#2 Le 25/01/2016, à 09:42

claudius01

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

Bonjour,

Je ne pense pas qu'il y ait de solution "miracle" pour tout nettoyer hormis le reformatage (et encore, j'ai lu que nos services de renseignement pouvaient retrouver les données les plus récentes après un formatage d'un disque, mais j'espère que tu n'es pas aussi paranoïaque ... ;-).

Sinon moins béton, une solution pourrait être de travailler dans un chroot et après le détruire ou encore de travailler dans un ramdisk et le détruire (à confirmer / infirmer par des spécialistes)...

NB: Même un rm laisse des traces car cette action n'opère que sur la table d'accès aux fichiers. Il faudrait réécrire le même fichier avec des patterns aléatoires et ensuite le détruire pour ne laisser aucune trace mais la difficulté est identifier ces fichiers. Là encore ce n'est pas sûr car Linux peut décider entre temps de réorganiser le fichier pour le défragmenter, chose à laquelle je lui ai été toujours très reconnaissant @ Windows ;-)).

Dernière modification par claudius01 (Le 25/01/2016, à 10:26)

Hors ligne

#3 Le 25/01/2016, à 12:17

mandeb

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

Merci pour votre réponse, je vais explorer le ramdisk avec un petit bémol : l'appli y perdra en portabilité mais ce n'est pas forcément grave.
La littérature crypto décrit abondamment de nombreux algo de chiffrement divers et variés avec tous leurs avantages et inconvénients. Quelques unes font remarquer que l'implémentation logicielle elle-même est plus souvent source de failles, sans jamais donner de détails pratiques sur ce qu'il faut protéger vraiment et comment faire, d'où ma démarche.
Par ailleurs c'est simplement une démarche de curiosité et de cohérence technique : à quoi servirait-il de chiffrer solidement un document dont tout ou partie du clair resterait à traîner quelque part dans un fichier tmp ou autre ?

Sur le plan pure "parano" il est clair qu'un attaquant réellement motivé dispose de multiples moyens (chantage, pressions, coercition, gégène...) pour obtenir un texte en clair ou une clé s'il le veut vraiment (mais là on s'écarte du sujet du post wink)!
C'est donc juste le souci d'un travail (amateur wink ) le plus propre possible.

bonne journée.

Dernière modification par mandeb (Le 25/01/2016, à 12:18)

Hors ligne

#4 Le 25/01/2016, à 12:19

Nasman

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

shred doit permettre d'effacer proprement les fichiers créés.


PC fixe sous Bionic 64 bits et portable avec Focal 64 bits

Hors ligne

#5 Le 25/01/2016, à 12:32

mandeb

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

Oui c'est exactement ce qu'il faudrait faire, mais cela suppose avoir la connaissance du/des fichiers concernés.
C'est précisément ce que je cherche à savoir : y-a-t-il eu intervention de fichiers intermédiaires de la part du système ou de python lors du traitement et si oui comment les localiser pour éventuellement y appliquer une commande shred ?

Hors ligne

#6 Le 25/01/2016, à 12:35

claudius01

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

Je ne connaissais pas shred, mais sauf erreur de ma part, le problème réside effectivement dans l'identification de tous les fichiers ouverts / écrits / clôturés par le(s) processus de cet excellent cryptage One Time Pad qui plus est "attaqué" depuis Python ;-)...

Edit: mandeb a écrit: "si oui comment les localiser pour éventuellement y appliquer une commande shred ?". Je ne vois qu'une chose, intercepter tous les open / read / write / close de l'application de cryptage et/ou utiliser truss.

Dernière modification par claudius01 (Le 25/01/2016, à 12:44)

Hors ligne

#7 Le 26/01/2016, à 11:48

grim7reaper

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

En Python je doute que tu aies suffisement de contrôle pour tout nettoyer, tes données vont etre copiées un peu partout en RAM…
Et puis une des ses pages de RAM peut être swappé (et donc se retrouver sur le disque).

Meme en C ce n'est pas si évident : si tu utilises stdio tu as perdu car rien ne garanti que les buffers intermédiaires sont mis à zéro avant réutilisation.
D’ailleurs le dernier moyen d'avoir une fuite de clef peut venir de là, cf la dernière faille SSH :

https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt a écrit :

1. If a private SSH key is loaded from disk into memory by fopen() (or
fdopen()), fgets(), and fclose(), a partial or complete copy of this
private key may remain uncleansed in memory. Indeed, these functions
manage their own internal buffers, and whether these buffers are
cleansed or not depends on the OpenSSH client's libc (stdio)
implementation, but not on OpenSSH itself.

- In all vulnerable OpenSSH versions, SSH's main() function calls
  load_public_identity_files(), which loads the client's public keys
  with fopen(), fgets(), and fclose(). Unfortunately, the private keys
  (without the ".pub" suffix) are loaded first and then discarded, but
  nonetheless buffered in memory by the stdio functions.

- In OpenSSH versions <= 5.6, the load_identity_file() function (called
  by the client's public-key authentication method) loads a private key
  with fdopen() and PEM_read_PrivateKey(), an OpenSSL function that uses
  fgets() and hence internal stdio buffering.

Internal stdio buffering is the most severe of the three problems
discussed in this section, although GNU/Linux is not affected because
the glibc mmap()s and munmap()s (and therefore cleanses) stdio buffers.
BSD-based systems, on the other hand, are severely affected because they
simply malloc()ate and free() stdio buffers. For interesting comments on
this issue:

https://www.securecoding.cert.org/confl … ut+to+disk

On peut aussi citer qu’utiliser memset pour mettre un buffer à zéro peut-être viré par le compilateur car il voit que tu ne relis pas le buffer par la suite (il faut utiliser memset_s).

mandeb a écrit :

Quelques unes font remarquer que l'implémentation logicielle elle-même est plus souvent source de failles, sans jamais donner de détails pratiques sur ce qu'il faut protéger vraiment et comment faire, d'où ma démarche.

Parce que c‘est très très large.

Pour des conseils de bases:
- n’utilise pas les I/O bufferisés.
- verrouille ta RAM pour éviter qu'elle se retrouve sur disques.
- fait attention aux optimisations de ton code, ça peut se retourner contre toi (timing attack).

Ça fait déjà beaucoup de choses à prendre en compte, beaucoup d’occasions de se planter. Et ça ne suffit pas (et sans même aller jusqu'aux attaques physiques sur la machine).
Il y a tellement de moyen de se planter que tu vas te planter…
Tu ne fais pas du code crypto quand tu n'as pas une excellente connaissance sur le sujet (déjà que ceux qui s’y connaissent ont des bugs de sécu, imagine le programmeur lambda :S).

En conclusion, tu peux faire ce genre de code pour t'amuser/pratiquer/apprendre (c’est très intéressant), mais ne l'utilise pas sérieusement.

claudius01 a écrit :

utiliser truss.

Sous Linux il me semble que l’on utilise strace tout simplement.

Dernière modification par grim7reaper (Le 26/01/2016, à 14:58)

Hors ligne

#8 Le 26/01/2016, à 11:57

erresse

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

Une solution simple, quoiqu'un peu onéreuse peut-être...
Créer tout ce que tu veux sur un PC, copier le résultat final sur une clé USB que tu rangeras dans un coffre-fort, puis passer le PC à la broyeuse !!!
OK, je sors...
lol


Plus de 50 ans d'informatique, ça en fait des lignes de commandes en console, mais on n'avait pas le choix...
Excellente raison pour, aujourd'hui qu'on le peut, utiliser au maximum les INTERFACES GRAPHIQUES !
Important : Une fois résolu, pensez à clore votre sujet en ajoutant [Résolu] devant le titre du 1er message, et un bref récapitulatif de la solution à la fin de celui-ci. Merci.

Hors ligne

#9 Le 26/01/2016, à 13:19

claudius01

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

Bonjour,

grim7reaper a écrit :
claudius01 a écrit :

... utiliser truss.

... Sous Linux il me semble que l’on utilise strace tout simplement.

Effectivement, je te le concède grim7reaper, mais 20 ans d'Unix ne s'effacent pas comme cela.

Oh non pas la broyeuse ;-)

Plus sérieusement, pourquoi ne pas utiliser justement un Raspberry Pi sous Raspbian ou autre Nano-ordinateur (le résultat ne va sortir dans le même laps de temps, je vous l'accorde) pour faire tous les calculs et ensuite reformater sa carte SD, voire la détruire pour vraiment être sûr ...

Hors ligne

#10 Le 26/01/2016, à 13:37

grim7reaper

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

claudius01 a écrit :

reformater sa carte SD

Supprimer les fichiers avec shred risque de ne pas suffire sur une carte SD (à cause du phénomène de write amplification).
Et même si ça fonctionne, tu ne pourras potentiellement pas réécrire tous les fichiers, même avec l’aide de strace : un fichier temporaire qui est supprimé dès sa création (comme ça se fait traditionnellement), tu ne pourras pas y accéder après coup meme si strace te donne son chemin.

Reformater ne suffit pas (tu détruis seulement le système de fichier, pas son contenu).
Et pour réecrire sur toute la carte, il faut prendre des précautions car certaines fonctionnalités peuvent jouer contre toi : par exemple faire un dd de /dev/zero ça peut possiblement ne rien faire à s’il y a de la compression à la volée.

Cette section du wiki Archlinux parle un peu de ce genre de problématique.

Encore une fois, rien n'est trivial dans ce domaine hmm

Hors ligne

#11 Le 26/01/2016, à 13:45

Babdu89

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

Bonjour.
Une idée peut-être. Elle vaut ce qu'elle vaut.
Utiliser la machine sans disque dur branché.
Deux clés usb.
Une clé live Ubuntu, persistant ou pas. Et une clé de travail/stockage des données.
Pour ce qui est de la RAM?... Je ne sais pas.

Normalement il ne devrait rien y avoir à glaner sur le disque dur, après l'avoir rebranché...

ÉDIT
Ou dans le même sens.
Utiliser un Ubuntu installé sur un petit hdd usb. Disque dur de la machine débranché...

@+.   Babdu89  .

Dernière modification par Babdu89 (Le 26/01/2016, à 13:49)


J'ai découvert Ubuntu avec la 07.10.... Et alors?!...  Depuis je regarde de temps en temps si Windows marche toujours....

Hors ligne

#12 Le 26/01/2016, à 13:47

claudius01

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

grim7reaper a écrit :

... Reformater ne suffit pas (tu détruis seulement le système de fichier, pas son contenu).
... Supprimer les fichiers avec shred risque de ne pas suffire sur une carte SD (à cause du phénomène de write amplification).

Donc, vu le prix d'une carte SD [négociable en grande quantité], je propose purement et simplement de la détruire...

Reste à savoir si le processus de génération de clés avec One Time Pad et son exploitation est réalisable avec un Nano-Ordinateur et en particulier avec un Raspberry Pi ...

Dernière modification par claudius01 (Le 26/01/2016, à 14:46)

Hors ligne

#13 Le 26/01/2016, à 14:53

mandeb

Re : [résolu] laisser les lieux en partant aussi propres qu'en entrant

Hum ! je m'aperçois que je j'étais au pied d'une montagne bien plus élevée que prévue ! hmm
J'en retiens quand même 2 choses :
* les fichiers créés restent incorruptibles et peuvent voyager sans problèmes dès lors que la machine qui les a traités reste inaccessible aux attaquants (avec toute les réserves évoquées précédement !).

* Il est amusant de constater que très vite des solutions évoquant la destruction physique de tout ou partie du matériel utilisé soient apparues, ce qui n'est pas sans rappeler la traduction en français du "One Time Pad" : "Masque jetable". wink

merci à tous de vos lumières, j'ai de quoi "fouiner" un moment...
(je passe en [résolu])

Dernière modification par mandeb (Le 26/01/2016, à 18:56)

Hors ligne