Comment "cacher" une clé dans un programme ?

Comment "cacher" une clé dans un programme ? - C++ - Programmation

Marsh Posté le 01-08-2005 à 11:06:30    

Bon alors voilà :  
mon programme client doit avoir en local une clé privée. Pour lui transmettre de manière sûre, pas de problème c'est ok. Maintenant je voudrai pouvoir la garder sur le client en permanence de manière relativement sûre : je veux pas qu'un gros malin me reverse tout ça et retrouve la clé [:kiki]
 
Comment faire ? Je pense qu'il existe des solutions classiques vu que Steam&Co sont obligés de stocker qqpart deux ou trois secrets.
 
Merci de me file vos tuyaux :)
 
:hello:


Message édité par daneel17fr le 01-08-2005 à 11:06:43
Reply

Marsh Posté le 01-08-2005 à 11:06:30   

Reply

Marsh Posté le 01-08-2005 à 11:09:31    

ce n'est pas possible. si le client veut voir sa clef privée, il pourra la voir de toutes façons...

Reply

Marsh Posté le 01-08-2005 à 11:11:17    

Non mais le client je veux qu'il ai connaissance de sa propore clé (Qd je dis client, je parle de mon programme). Ce que je veux, c'est cacher ma clé dans mon programme, de manière à ce qu'il soit difficile de la retrouver en faisant du reverse ingineering ou un truc du genre.

Reply

Marsh Posté le 01-08-2005 à 11:11:39    

mcjoedassin a écrit :

ce n'est pas possible. si le client veut voir sa clef privée, il pourra la voir de toutes façons...


je veux la protéger de qq1 extérieur, pas de mon propre client.

Reply

Marsh Posté le 01-08-2005 à 11:16:08    

tu ne peux pas mettre ça dans un fichier avec les droits adéquats ?
 
"difficile de la retrouver en faisant du reverse ingineering" > je vois ce que tu veux dire, mais je ne pense pas que ce soit implémentable efficacement ... en tout cas je ne peux t'aider sur ce point ...


Message édité par mcjoedassin le 01-08-2005 à 11:17:28
Reply

Marsh Posté le 01-08-2005 à 11:52:31    

les droits sur les fichiers, ça pourrait être une idée. Les OS sont propriétaires, faut voir ce qu'ils proposent de ce point de vue.
 
Merci !

Reply

Marsh Posté le 01-08-2005 à 11:57:05    

okidoki ...
par ailleurs sur les UNIX, les passwords/clefs privées ssh/gpg sont porprement écrites dans des fichiers/répertoires ayant les bonnes permissions ...
De toutes façon pour un logiciel libre, une protection anti reverse engineering n'est pas concevable ...

Reply

Marsh Posté le 01-08-2005 à 12:27:31    

daneel17fr a écrit :

les droits sur les fichiers, ça pourrait être une idée. Les OS sont propriétaires, faut voir ce qu'ils proposent de ce point de vue.
 
Merci !


 
Bon si j'ai bien compris ce que tu veux j'ai une solution : tu chiffres la clé privée avec une passphrase choisie par le client (je crois que c'est ce que font les logiciels de cryptage, enfin ça me paraît une sécurité évidente). Après tu peux rajouter une couche de sécurité en jouant sur les droits du fichier où est stockée la clé.
 
Edit: ah j'avais toujours pas pigé. Ce que tu appelles ton "client" c'est un programme ? :heink:  
Ben dans ce cas il n'y a que les droits sur les fichiers qui peuvent t'aider... mais j'ai dû mal à comprendre le sens de tout ça. [:petrus75]


Message édité par Profil supprimé le 01-08-2005 à 12:31:22
Reply

Marsh Posté le 01-08-2005 à 12:31:59    

oui, gpg fait celà effectivement. respect !

Reply

Marsh Posté le 01-08-2005 à 12:36:55    

mcjoedassin a écrit :

okidoki ...
par ailleurs sur les UNIX, les passwords/clefs privées ssh/gpg sont porprement écrites dans des fichiers/répertoires ayant les bonnes permissions ...
De toutes façon pour un logiciel libre, une protection anti reverse engineering n'est pas concevable ...


oui mon "client" c'est un programme client.
 
pourquoi stocker une clé en local sur le client ? Pour lui permettre de s'authentifier auprès du serveur ensuite. Il faut un secret partager nan ?

Reply

Marsh Posté le 01-08-2005 à 12:36:55   

Reply

Marsh Posté le 01-08-2005 à 12:42:16    

euh, ton secret partagé, ce n'est pas la clef privée rassure moi ;)
                ^^^^^^^


Message édité par mcjoedassin le 01-08-2005 à 12:42:56
Reply

Marsh Posté le 01-08-2005 à 12:42:48    

daneel17fr a écrit :

oui mon "client" c'est un programme client.
 
pourquoi stocker une clé en local sur le client ? Pour lui permettre de s'authentifier auprès du serveur ensuite. Il faut un secret partager nan ?


 
Tout à fait. Mais pour ce genre de choses il doit exister des bibliothèques éprouvées genre OpenSSL/OpenSSH, non ?

Reply

Marsh Posté le 01-08-2005 à 12:45:02    

mcjoedassin a écrit :

euh, ton secret partagé, ce n'est pas la clef privée rassure moi ;)
                ^^^^^^^


 
ahah t'inquiète.  
 
le serveur envoie un message chiffré avec la clé publique du client
le client déchiffre avec sa clé secrète et renvoie le resultat au serveur
du coup le serveur a la preuve que le client est bien le vrai (possesseur de la bonne clé).
 
tu as raison, ce n'est pas vraiment un secret partagé ;)

Reply

Marsh Posté le 01-08-2005 à 12:46:57    


mmmmmh... je vais voir, bonne idée merci :)
en fait j'ai pas encore regardé pasque j'ai supposé que ces lib utilisaient des certificats etc... il ya aussi le fait que je doive mentionner l'utilisation des ces solutions dans mon programme qui me gêne (license GPL). M'enfin ça peut donner des idées.

Reply

Marsh Posté le 01-08-2005 à 12:51:00    

daneel17fr a écrit :

mmmmmh... je vais voir, bonne idée merci :)
en fait j'ai pas encore regardé pasque j'ai supposé que ces lib utilisaient des certificats etc... il ya aussi le fait que je doive mentionner l'utilisation des ces solutions dans mon programme qui me gêne (license GPL). M'enfin ça peut donner des idées.


 
Ces bibliothèques ne sont pas sous licence GPL mais sous des licences moins restrictives qui peuvent être utilisées dans des logiciels propriétaires (à vérifier, tu DOIS de toutes manières lire la licence avant d'utiliser ces bibliothèques ;)).

Reply

Marsh Posté le 01-08-2005 à 12:52:37    

daneel17fr, si tu essayes de créer ton protocole cryptographique...  
ca ressemble à du Needham Schroeder ... y à pas une attaque "man in the middle" là ?


Message édité par mcjoedassin le 01-08-2005 à 12:53:10
Reply

Marsh Posté le 01-08-2005 à 13:12:45    

oh je n'ai pas prétention de ré-inventer la crypto ;)
je ne sais pas encore quelle methode je vais vraiment utiliser, mais dans tous les cas (je pense) je vais retomber sur une problématique genre : "ça marche si je garde bien secret mon secret partagé sur mon prog client" ou "il faut que mon client ai une clé secrète... et qu'elle le reste".
 
dans tous les cas faut que je trouve comment "cacher" une info en local dans mon programme.
 
pour NS, effectivement tu peux utiliser de vieilles clés de session pour mettre la merde. Une solution, introduite par Kerberos, est d'utiliser des durées de vie pour les clé de session.
 
Mais comme je te l'ai dit, j'ai pas encore vraiment arrêter mes choix. Surtout que je vais dépendre fortement des devices qui accueilleront le client à terme (smartphone, pda, pc portable... les puissances sont différentes, et certains embarquent des solutions de chiffrement/dechiffrement hardwares que j'aurai intérêt à utiliser).
 
 
Pour openSSL : ça marche tout seul l'authentification ? Pas besoin de se réferrer à une CA ou un truc du genre ? Dans ton client tu mets "authentifie-toi" et hop ça marche ?

Reply

Marsh Posté le 01-08-2005 à 13:29:39    

Bon alors il semblerait que ce que je cherche à faire ai un nom (bonne nouvelle, ça veut dire que des gens ont déjà bien bosser dessus et que je vais pouvoir méchamment leaker comme un vandale [:itm]) : ofuscation (en anglais dans le texte).
 
Je cours me renseigner plus avant, et je tiens à jour le topic, des fois que ça puisse servir à d'autres :)
 
Merci pour vos contributions, et continuer à poster si vous avez d'autre idées :) :)
:hello:

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed