Salut à tous,
Je me pose une question toute simple :
"Comment stocker une clé privée dans mon programme Java pour éviter qu'elle soit retrouvé par une simple "décompilation" du .jar ?"
Merci à vous!
Bonne soirée et bon week-end!
++
Version imprimable
Salut à tous,
Je me pose une question toute simple :
"Comment stocker une clé privée dans mon programme Java pour éviter qu'elle soit retrouvé par une simple "décompilation" du .jar ?"
Merci à vous!
Bonne soirée et bon week-end!
++
Salut,
je pense que ce n'est pas possible, au pire tu pourras rendre cela plus difficile à retrouver mais pas impossible.
Il faudrait peut être la demander à chaque démarrage de l'appli.
ca dépend a quoi te sert cette clé.
Hello,
A quoi sert la clé n'est pas le problème, il s'agit d'une clé secrète servant dans un algorithme de cryptage symétrique qui donc doit être préservée de l'extérieur. Sinon l'ensemble du système se trouve compromis.
Par contre, je suis surpris qu'il ne soit pas possible de la protéger par un quelconque moyen.
Merci quand même ,
Bonne journée
Salut,
Si c'est possible de le faire. Stocker la clef encryptée, et protégée par un mot de passe. Par contre le seul vrai moyen sécurisé est de demander ce mot de passe au démarrage de l'application... Cette solution n'est pas spécifique à Java mais commun à tous les langages : stocker un secret de manière réelement sécurisée ne se fait qu'en protégeant par un mot de passe entré par l'utilisateur...
A plus
Bonjour,
Alors si je comprends bien, l'idée est de crypter la clé secrète avec une autre clé secrète (mot de passe) qui est saisie par un utilisateur.
Je vois deux problèmes :
- dans tous les cas, le maillon faible est l'utilisateur, donc lui confier la clé n'est pas une bonne idée
- dans mon cas, je n'ai pas d'utilisateur, personne pour saisir un mot de passe, il me faut donc vraiment protéger la clé dans le programme
Merci pour vos réponses
Bonne journée
++
tu te rend compte de ce que tu demande? C'est ce que l'industrie des medias n'est toujours pas parvenue à faire malgrès ses moyen 'comment rendre un secret lisible tout en empechant la lecture de ce secret'. Soit tu met un mot de passe (et le user devra le tapper pour débloquer la clé), soit la clé privée n'est pas ou peu protégée, et dans ce cas c'est la machine qu'il va falloirr protéger pour éviter qu'elle soit compromise. Par exemple, les clés privée ssl/tls des serveur web ne sont en général protégées que par le système de sécurité de l'OS qui ne permet qu'à l'administrateur et au user faisant tourner le service d'y avoir accès. Dans tous les cas, à un moment donné, cette clé devra être lisible.Citation:
Envoyé par Harry_Tauper
Salut,
Par curiosité : que veux-tu protéger ?
a++
Ok, et le mot de passe tu le protèges comment ? On tourne donc en rond non ?Citation:
Envoyé par tchize_
Sinon effectivement sécuriser la machine est surement le plus efficace. Sauf que dans mon cas, l'équipement contenant ce programme est déployé à très grande échelle, donc impossible de garantir l'intégrité de l'ensemble des équipements contenant la clé.
Je cherche simplement à empêcher qu'une suite de valeur ne soit pas facilement visible à l'intérieur du .jar, il ne me semble pas que cela soit fou. N'y a-t-il aucun moyen de protéger le contenu d'un .jar (ne serait-ce que de la décompilation) ? Par exemple, l'obfuscation en J2ME n'existe-t-elle pas en J2SE ?
Sinon pour adiGuba, je cherche simplement à sécuriser la communication entre 2 équipements à l'aide d'une clé privée.
En tous cas, merci pour vos réponses.
Bonne après-midi
++
Cela ne fait que rendre la chose un peu plus compliqué... mais pas impossible !Citation:
Envoyé par Harry_Tauper
Si ton application tourne sur un système "hostile" (que tu ne maitrise pas), il y a un grand nombre de moyen pour récupérer l'information...
Pourquoi ne pas utiliser la Cryptographie asymétrique ?Citation:
Envoyé par Harry_Tauper
Ainsi la clef privé connu de l'application ne sert qu'à recevoir des messages, et il devient complètement inutile de la récupérer...
a++
il n'est stocké nulle part, sa protection n'a donc pas de sens. C'est à l'utlisateur de le retenir.Citation:
Envoyé par Harry_Tauper
Je crois que t'as un problème de design là. Si je suis bien ta logique, des centaines d'appareil vont posséder la même clé privée. La logique voudrais que chaque appareil aie sa propre clé, ainsi un appareil / clé compromis peux facilement être désactivé en invalidant sa clé sur le serveur.Citation:
Sinon effectivement sécuriser la machine est surement le plus efficace. Sauf que dans mon cas, l'équipement contenant ce programme est déployé à très grande échelle, donc impossible de garantir l'intégrité de l'ensemble des équipements contenant la clé.
Non mais une obfuscation ne résistera pas à une attaque en règle par quelqu'un décidé à récupérer la clé, ca empechera seulement l'utilisateur lambda sans connaissances d'y avoir accès. Bref un protection très virtuelle.Citation:
Je cherche simplement à empêcher qu'une suite de valeur ne soit pas facilement visible à l'intérieur du .jar, il ne me semble pas que cela soit fou.
Qu'entend tu par "sécuriser"? Empecher un equipement rogue de se connecter? Dans ce cas il faut une clé privée différente sur chaque équipement (qui peut être fournie sous forme de smart card, par exemple) et la clé publique sur l'autre, ou passer par une autorité de certification comme on le fait avec les certificats ssl.Citation:
Sinon pour adiGuba, je cherche simplement à sécuriser la communication entre 2 équipements à l'aide d'une clé privée.
Si tu veux empecher l'interception de la communication, il faut alors passer aussi par l'échange d'une clé asymétrique et utiliser l'ensemble des fonctionnalité de SSL ou TLS (clé d'authentification + négociation d'une clé symétrique jetable à la connection)
Alors on ne parle pas d'un mot de passe mais d'une clé permettant de déchiffrer la clé privée encodée...Citation:
Citation:
Ok, et le mot de passe tu le protèges comment ? On tourne donc en rond non ?
il n'est stocké nulle part, sa protection n'a donc pas de sens. C'est à l'utlisateur de le retenir.
Chaque équipement possèdera une clé privée diversifié à partir d'une clé maitre... mais ça n'est pas le problème, il faut quand même protégé cette clé.Citation:
Je crois que t'as un problème de design là. Si je suis bien ta logique, des centaines d'appareil vont posséder la même clé privée. La logique voudrais que chaque appareil aie sa propre clé, ainsi un appareil / clé compromis peux facilement être désactivé en invalidant sa clé sur le serveur.
Juste pour information, je ne suis pas du tout dans une architecture client/serveur avec un réseau IP derrière. Les équipements ne sont pas connectés à un quelqueconque réseaux, il s'agit de communication point à point.
Par sécuriser, j'entends d'une part une authentification et d'autre part cryptage des données (optionnel pour le moment).
Un des problèmes de l'utilisation d'un algorithme asymétrique et la lourdeur des traitements (et surtout le temps). De plus j'ai du mal à imaginer comment assurer l'authentification puisque la clé publique n'importe qui peut la connaitre... Votre aide est la bienvenue sur ce point.
Merci
Bonne soirée
++
Salut,
Pas forcément non. Quand tu as une clef privée stockée dans un format PKCS#12, tu as bien un clef protégée par mot de passe ;)Citation:
Envoyé par Harry_Tauper
Bon Là c'est tout l'intérêt de SSL : ça fait ce que tu veux, on sait que c'est sûr, c'est éporouvé testé, déjà été attaqué des milliers de fois. Quand tu implémentes ton propre protocole "sécurisé", il y a d'énormes chances que ce ne soit pas si sécurisé que ça mais que ça présente de grosses failles.Citation:
Envoyé par Harry_Tauper
Pour l'authentification des pairs, c'est simple : si c'est une authentification mutuelle chacun possède son couple clef privée/publique. Le fait que la clef publique soit publique permet justement de vérifier les signatures de l'autre composant à qui l'on parle (signatures faites grâce à la clef privée, que donc juste un des composants connait, donc émise par celui ci...). Penche toi sur le concept de PKI.
Pour ce qui est du asymétrique, oui c'est lourd, c'est pour ça que c'est quasi exclusivement utilisé pour échanger une clef symétrique jetable (comme a dit tchize_), et SSL n'échappe pas à la règle... (crypter une clef va plus vite qu'un texte vue la taille des clefs ;))
A plus
L'authentification se fait avec un clé assymétrique dans ces cas là, en général. Les deux cotés du point à point ont leur propre clé privée, ils l'utilisent. L'équipement de l'autre coté utilise la clé publique pour déchiffrer. Le fait de savoir déchiffrer authentifie, de fait, l'expéditeur puisqu'il est le seul a avoir la clé privée et donc le seul à pouvoir envoyer ce message (qui doit changer à chaque fois, bien sur)Citation:
Envoyé par Harry_Tauper
C'est pour ca que le protocoles type SSL/TLS n'utilisent pas la clé assymétrique pour chiffrer tout le message. Ils l'utilisent pour chiffrer un demi clé symétrique (en gros, il y a une procédure bien précise et éprouvée pour négocier les clés assymétriques). Chacun envoie sa "demi-clé" à l'autre en utilisant la clé publique du destinataire. Ainsi seul l'expéditeur et le destinataire ont les deux demi-clé. Un fois ça fait, on utilise cette clé symétrique, jetable, pour le reste de la communication.Citation:
Un des problèmes de l'utilisation d'un algorithme asymétrique et la lourdeur des traitements (et surtout le temps).
Voir en haut, on utilise justement la clé privée pour s'authentifier et la publique, de l'autre coté, pour vérifier cette authentification.Citation:
De plus j'ai du mal à imaginer comment assurer l'authentification puisque la clé publique n'importe qui peut la connaitre... Votre aide est la bienvenue sur ce point.
y a t-il un moyen (simple) en java pour chiffre une connexion TCP ?
en pratique, il faut aller voir dans quelles classes ?
SSLSocketCitation:
Envoyé par PierreD87
il faut passer par les factory ?
parce que je me vois mal implémenter ça (abstract)...
oui
Code:SSLSocketFactory.getDefault().createSocket(.....)