Discussion :

[laconi87]

Bonjour,

Au cours d'un projet dans un cours de C, nous avons developper un programme de chiffrement par Bloc.

Suite au developpement de ce petit projet plusieurs questions se pose à moi:

- Existe-il des bibliothèques pour sécuriser l'execution du programme ?

- Il y a t-il des informations qui seront recuperables au cours de l'execution du programme et après l'execution du programme ?

- Peut on rendre un programme sur de telle sorte que aucune information ne soit recuperable?

Je peut deja vous informer qu'a la fin de l'execution, je n'ai pas de fuite memoire(valgrind).

merci d'avance.
A disposition pour de plus ample information sur mon probleme.

Nicolas

[souviron34]

décidément c'est la journée !!

A part pour les entrées sorties, les programmes sont sûrs..

Quant aux entrées sorties, elles dépendent de toi.. Plus de la taille du buffer, réglable sur la plupart ses systèmes..

[Melem]

A part pour les entrées sorties, les programmes sont sûrs..

Ici on parle de chiffrement, pas d'entrées/sorties, pour éviter qu'on puisse désassembler facilement le programme.

laconi87, pas très clair ton problème n'empêche.

[laconi87]

Comme la preciser Melem, je souhaite parler de sécurité.

En faite ce que je voudrais réussir à faire c'est qu'un attaquant eventuel qui s'emparerait de la machine qui effectue le chiffrement ne puisse obtenir aucune information pendant l'execution du processus , ni aprés l'execution du processus
Typiquement lorsque je fait appel au programme je fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

./chiffrement fichier_clair fichier_chiffre cle

Alors il y a t-il quelqu'un qui connaisse des bibliothèque en rapport avec la sécurité ou un moyen respectant la norme de le faire.

Nicolas

[Pacorabanix]

ben il *pourrait* y avoir un problème, par exemple si ton système a beaucoup de mémoire vive (ou swap/virtuelle), après le programme certaines infos pourraient être toujours dans la mémoire (bien que désallouée correctement).

Tu pourrais forcer la chaine "fichier en clair" (si tu utilises une chaine...) à se vider en mémoire en réécrivant par dessus.

Et puis attention, quelqu'un qui aurait le système n'aurait qu'a ouvrir la console et faire un petit "fleche haut" pour retrouver la ligne qui crypte et ainsi avoir la clé. Si c'est une clé publique pas de problème, mais sinon aïe....

Enfin c'est surtout des problèmes à résoudre par le système, et non vraiment par le compilateur j'ai l'impression.



Pendant l'exécution, je vois pas trop ce qui empecherai à qq'un de faire des "dumps" mémoire. Si le texte en clair est stocké dans une seule chaine il sera probablement visible, quelque part dans la mémoire... mais faut y aller.

EDIT : la sécruisation d'un cryptage et de traitement d'information nécessite justement la sécurisation *physique* des machines qui s'en occupent!

[laconi87]

Pour précision, fichier_claire et fichier_chif sont des fichiers.

Je suis d'accord que la securité parfaite implique la sécurité des machines.

Il semblerait qu'il existe des bibliothèques permettant de faire de la sécurité de processus mais je ne sais pas si c'est vrai.

Merci pour toute information complementaire a la securite des processus.

[Pacorabanix]

il n'y a pas de forum dédié à la sécurité uniquement sur developpez.net c'est vrai, mais essaye aussi de laisser un message dans le forum "bibliotheques C/C++", peut être que d'autres pourront t'éclairer plus précisément, puisqu'apparemment ta question est spécifique sur les bibliotheques.

[millie]

En faite ce que je voudrais réussir à faire c'est qu'un attaquant eventuel qui s'emparerait de la machine qui effectue le chiffrement ne puisse obtenir aucune information pendant l'execution du processus , ni aprés l'execution du processus


Nicolas

Si une personne a pu prendre le contrôle de ta session quelques secondes avant, il peut récupérer n'importe quel informations du processus (il est possible d'intercepter des fonctions standard très facilement sous UNIX)

Et puis là, tu as ton texte clair appelé directement... donc la faille serait plutôt de ce côté.

[Pouic]

Je remets le message que je t'ai posté sur le forum Linux :

Hm, je n'ai pas dû me faire comprendre.
Il est inutile et naif de croire que tu pourras cacher des informations à quelqu'un qui est root sur ta machine.
Même en prenant des techniques s'apparentant à des rootkits, il y a *toujours* des traces qui restent. Une fois ces traces découvertes, il est enfantin de récupérer la ou les données sensibles.

Je connais plusieurs labo qui travaillent sur des solutions matérielles de ce genre de chose, mais au niveau software, il est quasi-impossible d'empêcher la récupération d'infos.

Donc soit tu pars du principe que ton processus de chiffrement est exécuté dans une sandbox, sur une machine isolée du réseau, et que tu transfères les données à chiffre par clef usb. Soit tu regardes ce qui se fait en hardware

Tu peux toujours penser à modifier ton kernel, mais encore une fois, si l'attaquant est root sur ta bécane, c'est inutile.

[Médinoc]

Je ne vois pas où est le problème.
Un bon algorithme de chiffrement n'a pas besoin d'être protégé, seule la clé doit l'être.
Donc, ce qui est implotant est d'éviter les vecteurs de sortie de la clé, là la discussion peut devenir intéressante.

[Pacorabanix]

Un bon algorithme de chiffrement n'a pas besoin d'être protégé, seule la clé doit l'être.

Il y a meme de bons algorithmes de chiffrement où la clé de chiffrement n'a même pas besoin d'être protégée (systèmes à clé publique, par ex. RSA)

[Médinoc]

La clé privée est toujours protégée. C'est juste qu'on n'en a pas besoin pour chiffrer.

De plus, on utilise rarement la clé publique pour chiffrer toutes les données en RSA: On utilise généralement une clé symétrique (RC5 par exemple) et on chiffre la clé...

[laconi87]

Merci a tous pour vos contibutions.

Je pense que je vais laisser tombé l'idée de sécuriser le processus en lui même car je me demande si cela est vraiment d'une grande utilité etant donné tous vos commentaires.

Merci encore

Nicolas