Crypto asymétrique

On 16 Nov 2004 14:00:35 GMT
Marco <mm_delthis@sistech.fr> wrote:

Bonjour,

J'arrive en phase terminale de réalisation d'un projet, mais j'ai un do ute

sur l'utilisation de la crypto asymétrique dans mon cas.
En effet au lieu de voir une clé publique et une clé privé, je cons idère
plutot que j'ai 2 clé (K1,K2) qui chiffre/déchiffre ce qu'a fait l'au tre.
En partant de cela, j'ai établi un petit protocole :
- Un serveur crypte un code avec K1 et il est le seul à connaitre ce
code.- Un logiciel décrypte ceci avec K2.
K2 est écrit en dur dans le logiciel. Et le logiciel est éparpillé un peu
partout dans le monde.
Donc ma grande question est supposons qu'une personne arrive à partir d u
logiciel (en faisant du reverse engenering) trouve K2. Est-ce que K1 est
compromis?

On peut voir ceci comme une signature presque, le logiciel doit pouvoir
decrypter le message et s'assurer qu'il provient bien du serveur.
Maintenant si K2 est découvert ce n'est pas trop grave tant que personne
ne peut se faire passer pour le serveur.

Expliqué comme ca, j'ai impression qu'on a donc bien à faire à une simple
signature donc la crypto asymétrique résoud mon problème.
Mais comme j'ai des doutes, je voudrais vos avis avant d'implementer ceci.

Effectivement, ce la ressemble à du chiffrement asymétrique. Maintenant,
quant à savoir si la compromission de K1 est possible uniquement en trouv ant
K2, tout dépend de l'algorithme choisi. Théoriquement une clef publique (K2)
peut être diffusée (c'est le principe du chiffrement asymétrique), ma is ce
n'est pas facile d'inventer de type d'algo...



--
shen
"You know what, I'm happy..."
Droopy

Marco wrote:

[...]
En partant de cela, j'ai établi un petit protocole :
- Un serveur crypte un code avec K1 et il est le seul à connaitre ce code.
- Un logiciel décrypte ceci avec K2.
[...]
Donc ma grande question est supposons qu'une personne arrive à partir du
logiciel (en faisant du reverse engenering) trouve K2. Est-ce que K1 est
compromis?

C'est la propriété de base des algo asymétriques qu'il ne l'est pas.

On peut voir ceci comme une signature presque, le logiciel doit pouvoir
decrypter le message et s'assurer qu'il provient bien du serveur.

En effet.

Maintenant si K2 est découvert ce n'est pas trop grave tant que personne ne
peut se faire passer pour le serveur.

Je ne connais pas l'application, mais en général si quelqu'un peut
utiliser le reverse engineering pour trouver K2, il ne lui est pas plus
difficile de patcher le logiciel pour qu'il attende une autre clé, ou
lui faire accepter même un code non-signé, etc ...

Tout dépend contre quoi exactement tu veux te protéger.

Jean-Marc Desperrier <jmdesp@alussinan.org> wrote in
news:cndbi1$946$1@reader1.imaginet.fr:

Donc ma grande question est supposons qu'une personne arrive à partir
du logiciel (en faisant du reverse engenering) trouve K2. Est-ce que
K1 est compromis?

C'est la propriété de base des algo asymétriques qu'il ne l'est pas.

Pourtant j'ai lu il y a quelques jours ici ceci :
"En revanche, dans certains algorithmes, on peut facilement retrouver la
cl‚ publique … partir de la cl‚ priv‚e, et ce n'est pas un problŠme."
C'est en faite la lecture de cette phrase qui m'a poussé à poster mon
message afin d'avoir confirmation de ceci ou nan.

Je ne connais pas l'application, mais en général si quelqu'un peut
utiliser le reverse engineering pour trouver K2, il ne lui est pas
plus difficile de patcher le logiciel pour qu'il attende une autre
clé, ou lui faire accepter même un code non-signé, etc ...

Tout dépend contre quoi exactement tu veux te protéger.

C'est surtout pour lutter contre les keygens. Je ne sais pas trop comment
ils sont trouvés. Pour le fait de trafiquer l'application, quoiqu'on fasse,
quelqu'un arrivera a patcher je pense, c'est juste histoire de compliqué un
peu plus le travail du cracker.

Marco wrote:

Jean-Marc Desperrier <jmdesp@alussinan.org> wrote in

Donc ma grande question est supposons qu'une personne arrive à partir
du logiciel (en faisant du reverse engenering) trouve K2. Est-ce que
K1 est compromis?

C'est la propriété de base des algo asymétriques qu'il ne l'est pas.

Pourtant j'ai lu il y a quelques jours ici ceci :
"En revanche, dans certains algorithmes, on peut facilement retrouver la
cl‚ publique … partir de la cl‚ priv‚e, et ce n'est pas un problŠme."
C'est en faite la lecture de cette phrase qui m'a poussé à poster mon
message afin d'avoir confirmation de ceci ou nan.

Désolé, mais j'ai mal interprété ta question alors.
Oui, pour la majorité des algo, on obtient très facilement la clé public
à partir de la clé privée.

C'est pour cela que le serveur doit chiffrer avec la clé privée (ce que
l'on appelle signer), et le client déchiffrer avec la clé public (ce que
l'on appelle vérifier la signature).

Il est hors de question de diffuser la clé privée dans le client.

Après déchiffrement, le fait que le résultat contient un padding correct
assure qu'on a utilisé la bonne clé publique pour déchiffrer, et que
donc l'émetteur a forcément utilisé *la* clé privée qui lui correspond
pour chiffrer. Donc qu'il connait cette clé privée, et donc qu'il est
bien la personne que l'on pense.

Je ne connais pas l'application, mais en général si quelqu'un peut
utiliser le reverse engineering pour trouver K2, il ne lui est pas
plus difficile de patcher le logiciel pour qu'il attende une autre
clé, ou lui faire accepter même un code non-signé, etc ...

Tout dépend contre quoi exactement tu veux te protéger.

C'est surtout pour lutter contre les keygens. Je ne sais pas trop comment
ils sont trouvés. Pour le fait de trafiquer l'application, quoiqu'on fasse,
quelqu'un arrivera a patcher je pense, c'est juste histoire de compliqué un
peu plus le travail du cracker.

La solution plus haut sera efficace contre les keygen, les attaquants
seront donc obligés d'utiliser plutôt un patch, ce qui ne leur
représentera pas une difficulté supplémentaire sérieuse.

Une exemple de logicile qui se protégeait ainsi est Netscape 4, et la
réponse a été ceci : Fortify
http://www.fortify.net/intro_main.html

Marco <mm_delthis@sistech.fr> wrote in message news:<Xns95A39842337Bmmdelthissistechfr@212.198.2.12>...

Bonjour,

Bonjour !

[...]

Donc ma grande question est supposons qu'une personne arrive à partir du
logiciel (en faisant du reverse engenering) trouve K2. Est-ce que K1 est
compromis?

c'est tres fortement dependant de la methode utilisee pour generer K1 et K2,
il n'y a pas de reponse universelle a cette question.

On peut voir ceci comme une signature presque, le logiciel doit pouvoir
decrypter le message et s'assurer qu'il provient bien du serveur.
Maintenant si K2 est découvert ce n'est pas trop grave tant que personne ne
peut se faire passer pour le serveur.

Expliqué comme ca, j'ai impression qu'on a donc bien à faire à une simple
signature donc la crypto asymétrique résoud mon problème.

Mais comme j'ai des doutes, je voudrais vos avis avant d'implementer ceci.

Merci

Voui c'est bel et bien le principe de la signature, probleme resolu par la
crypto a clef publique, mais encore une fois la resistance depends de la
facon dont tu generes K1 et K2, si tu deduis K1 de K2 alors il y a des chances
pour qu'un reverse engineering permette a quelqu'un d'obtenir la clef utilisee
par le serveur pour signer.

C'est surtout pour lutter contre les keygens. Je ne sais pas trop comment
ils sont trouvés. Pour le fait de trafiquer l'application, quoiqu'on
fasse,
quelqu'un arrivera a patcher je pense, c'est juste histoire de compliqué
un
peu plus le travail du cracker.

Inutile d'utiliser la cryptographie (ou une autre techno compliquée) pour
contrer le travail des hackers.
En effet qu'elle que soit la methode utilisée pour verifier la clef du
logiciel, la facon la plus simple pour le hacker de deproteger le logiciel
est de la patcher. Il s'agit par exemple de 'simplement' supprimer du
logiciel la partie du code qui va faire la verification de la clef.
Du genre:

Soft initiale: if verifclef(...) = true then run(...)
Une fois patché: if true then run(...)

la fct verifclef(...) peut etre aussi compliqué que tu le veux....la seule
personne qui va passer un peu plus de temps a travailler, c toi !

Jean-Marc Desperrier <jmdesp@alussinan.org> wrote in
news:cndg6l$a0q$1@reader1.imaginet.fr:

Désolé, mais j'ai mal interprété ta question alors.
Oui, pour la majorité des algo, on obtient très facilement la clé
public à partir de la clé privée.

C'est ce point que j'ai du mal à comprendre, il faut donc bien voir une
notion de clé public et clé privé , et non pas un couple de clés (k1,k2)
qui sont liés.
Une clé a donc plus d'importance qu'une autre.
Je compte réaliser cela en utilisant les fonction openssl (pour php) car
je n'ai rien trouvé d'autre en crypto asymétrique pour du php.
Il faut donc que je fasse bien attention pour crypter avec la clé privé.

Pour mon information pourrait-tu me dire quels sont les algo qui
permettent de ne pas obtenir la clé public à partir de la privée.
Ceci pourrait m'être utile plus tard peut être.

C'est pour cela que le serveur doit chiffrer avec la clé privée (ce
que l'on appelle signer), et le client déchiffrer avec la clé public
(ce que l'on appelle vérifier la signature).

Il est hors de question de diffuser la clé privée dans le client.

Après déchiffrement, le fait que le résultat contient un padding
correct assure qu'on a utilisé la bonne clé publique pour déchiffrer,
et que donc l'émetteur a forcément utilisé *la* clé privée qui lui
correspond pour chiffrer. Donc qu'il connait cette clé privée, et donc
qu'il est bien la personne que l'on pense.

Oui j'ai bien compris le principe de la signature, ca c'est bon.

La solution plus haut sera efficace contre les keygen, les attaquants
seront donc obligés d'utiliser plutôt un patch, ce qui ne leur
représentera pas une difficulté supplémentaire sérieuse.

Une exemple de logicile qui se protégeait ainsi est Netscape 4, et la
réponse a été ceci : Fortify
http://www.fortify.net/intro_main.html

Oui je sais pour les patchs, mais contre les patchs j'ai presque envie de
dire que c'est plus mon problème.. enfin en terme de programation. Pour
se prémunir des patchs je pense qu'il faut plutot avoir une aproche type
"carte à puce" pour modifier le code afin qu'il soit le moins exploitable
(rajout d'instrucion, mélanger la verification du code avec d'autre
instrucions utiles) histoire de compliqué le reverse engeenering.
Enfin la, je dis tout ceci, mais je n'ai pas du tout reflechit à ca et
donc mieux vaut se taire et ne pas dire de bêtisses :)

Encore merci pour tes réponses (ainsi que celles des autres).

Marco wrote:

Jean-Marc Desperrier <jmdesp@alussinan.org> wrote in
Pour mon information pourrait-tu me dire quels sont les algo qui
permettent de ne pas obtenir la clé public à partir de la privée.
Ceci pourrait m'être utile plus tard peut être.

En réglèe générale, les librairies de crypto ont des fonctions pour
générer une paire de clé, et ensuite pour obtenir clé privée et publique
de là, donc ce n'est pas très nécessaire.
Cela dit en réalité dans le cas de RSA, la clé publique est une
sous-partie de la clé privé.
Pour DSA, d'après l'algo, si les paramètres p, q et g sont connus, une
formule simple donne la clé publique y à partir de la clé privée x (y =
g^x mod p). Cf http://www.itl.nist.gov/fipspubs/fip186.htm

Marco <mm_delthis@sistech.fr> wrote in message news:<Xns95A3BBB69ABC2mmdelthissistechfr@212.198.2.12>...

Jean-Marc Desperrier <jmdesp@alussinan.org> wrote in
news:cndbi1$946$1@reader1.imaginet.fr:

Donc ma grande question est supposons qu'une personne arrive à partir
du logiciel (en faisant du reverse engenering) trouve K2. Est-ce que
K1 est compromis?

C'est la propriété de base des algo asymétriques qu'il ne l'est pas.

Pourtant j'ai lu il y a quelques jours ici ceci :
"En revanche, dans certains algorithmes, on peut facilement retrouver la
cl? publique ? partir de la cl? priv?e, et ce n'est pas un probl?me."
C'est en faite la lecture de cette phrase qui m'a poussé à poster mon
message afin d'avoir confirmation de ceci ou nan.

vi effectivement, pour schematiser tu as une clef privee (donc confidentielle
que tu gardes cote serveur) qui est generee et une clef publique (que tu peux
diffuser dans ton soft) qui en est derivee. obtenir la clef publique a partir
de la clef privee est simple mais cela ne pose pas de probleme puisque cette
derniere reste sur le serveur, en revanche l'operation inverse qui consiste a
calculer la clef privee a partir de la clef publique est difficile (vraiment
tres difficile selon l'algo. ;).

Je ne connais pas l'application, mais en général si quelqu'un peut
utiliser le reverse engineering pour trouver K2, il ne lui est pas
plus difficile de patcher le logiciel pour qu'il attende une autre
clé, ou lui faire accepter même un code non-signé, etc ...

Tout dépend contre quoi exactement tu veux te protéger.

C'est surtout pour lutter contre les keygens. Je ne sais pas trop comment
ils sont trouvés. Pour le fait de trafiquer l'application, quoiqu'on fasse,
quelqu'un arrivera a patcher je pense, c'est juste histoire de compliqué un
peu plus le travail du cracker.

hm, je vois pas trop comment tu comptes te proteger des keygen, j'imagine bien
deux methodes utilisant des clefs publiques, mais dans les deux il est trivial
de mettre en echec la verification. tu peux en dire plus ou bien c'est
confidentiel ?

"bart s." <gachna_annti_spam@laposte.net> wrote in message news:<419a8cb0$0$1867$626a14ce@news.free.fr>...

C'est surtout pour lutter contre les keygens. Je ne sais pas trop comment
ils sont trouvés. Pour le fait de trafiquer l'application, quoiqu'on
fasse,
quelqu'un arrivera a patcher je pense, c'est juste histoire de compliqué
un
peu plus le travail du cracker.

Inutile d'utiliser la cryptographie (ou une autre techno compliquée) pour
contrer le travail des hackers.
En effet qu'elle que soit la methode utilisée pour verifier la clef du
logiciel, la facon la plus simple pour le hacker de deproteger le logiciel
est de la patcher. Il s'agit par exemple de 'simplement' supprimer du
logiciel la partie du code qui va faire la verification de la clef.
Du genre:

Soft initiale: if verifclef(...) = true then run(...)
Une fois patché: if true then run(...)

la fct verifclef(...) peut etre aussi compliqué que tu le veux....la seule
personne qui va passer un peu plus de temps a travailler, c toi !

c'est vrai, mais d'un autre cote le soft peut etre construit de facon a ce que
cette tache soit assez compliquee (de nombreuses dependences avec la verif) et
requiert un temps enorme de "patchage". et d'autre part, le nombre de personnes
ayant les capacites de faire ce genre de chose est infime compare au nombre des
utilisateurs potentiels du soft.

Pour la distribution, j'avais imagine un petit protocole permettant de limiter
(sans pour autant mettre en defaut) la diffusion de versions piratees, je vais
continuer a bosser un peu dessus parceque c'est pas trop au point encore :-)