OVH Cloud OVH Cloud

Crypto asymétrique

16 réponses
Avatar
Marco
Bonjour,

J'arrive en phase terminale de réalisation d'un projet, mais j'ai un doute
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 considère
plutot que j'ai 2 clé (K1,K2) qui chiffre/déchiffre ce qu'a fait l'autre.
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 du
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.

Merci

6 réponses

1 2
Avatar
Francois Grieu
Dans l'article ,
Marco dit:

Il faut donc que je fasse bien attention pour crypter avec
la clé privé.


Il faut dire: **signer** avec la clé privée.
Crypter (on préfère: chiffrer), c'est transformer un message
d'une manière telle qu'une convention (clé) secrète est
nécessaire pour en déduire (de l'information sur) le message
initial.

Pour comprendre la cryptographie à clé publique, il faut se
souvenir des fonctions qu'elle rempli, des actions
correspondantes, et des clés utilisées:
Authenticité
Signer clé privée
Vérifier clé publique
Confidentialité
Chiffrer clé publique
Déchiffrer clé privée

Noter que RSA, combiné à des paddings adaptés, permet de faire
les deux classes de fonction; c'est une des raisons de son succès.
D'autres systèmes assurent seulement l'authenticité (DSA),
d'autres seulement la confidentialité.


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


Je n'en connais pas. Je ne vois pas bien l'utilité: si la clé publique
est publique, à quoi sert il qu'il soit impossible de la retrouver ?
Il y a de algos où il semble difficile de retrouver la clé publique à
partir des signatures (RSA avec petit exposant public n'a pas cette
caractéristique). Mais, par le même raisonnement, est-ce une
proriété utile ?


François Grieu

Avatar
Francois Grieu
Dans l'article ,
Marco dit:

Il faut donc que je fasse bien attention pour crypter avec
la clé privé.


Il faut dire: **signer** avec la clé privée.
Crypter (on préfère: chiffrer), c'est transformer un message
d'une manière telle qu'une convention (clé) secrète est
nécessaire pour en déduire (de l'information sur) le message
initial.

Pour comprendre la cryptographie à clé publique, il faut se
souvenir des fonctions qu'elle rempli, des actions
correspondantes, et des clés utilisées:
Authenticité
Signer clé privée
Vérifier clé publique
Confidentialité
Chiffrer clé publique
Déchiffrer clé privée

Noter que RSA, combiné à des paddings adaptés, permet de faire
les deux classes de fonction; c'est une des raisons de son succès.
D'autres systèmes assurent seulement l'authenticité (DSA),
d'autres seulement la confidentialité.


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


Je n'en connais pas. Je ne vois pas bien l'utilité: si la clé publique
est publique, à quoi sert il qu'il soit impossible de la retrouver ?
Il y a de algos où il semble difficile de retrouver la clé publique à
partir des signatures (au contraire de RSA avec petit exposant public
qui permet de retrouver la clé publique avec quelques signatures).
Mais, par le même raisonnement, est-ce une proriété utile ?


François Grieu

Avatar
Marco
Francois Grieu wrote in news:fgrieu-
:



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


Je n'en connais pas. Je ne vois pas bien l'utilité: si la clé publique
est publique, à quoi sert il qu'il soit impossible de la retrouver ?
Il y a de algos où il semble difficile de retrouver la clé publique à
partir des signatures (RSA avec petit exposant public n'a pas cette
caractéristique). Mais, par le même raisonnement, est-ce une
proriété utile ?




Je n'ai pas d'exemple précis...
mais une idée serait on utilise la clé K1 (public) pour chiffrer un
message.
Ce message comporte un en-tete par exemple ou des propriétés qui permettent
de l'authentifié (c'est peut être la que je fais une grosse erreur de
reflexion). Donc on a les 2 propriété authenticité et chiffrement.
la clé k2 (privé) est en dur ds un logiciel.
Si jamais quelqu'un arrive à avoir k2, il peut décrypter les messages mais
ne peut pas se faire passé pour l'émetteur.
Par contre si il arrive à calculer k1, alors la il peut se faire passé pour
l'émetteur (car il aura eu des message déchiffré et connaitra les propriété
qui authentifie un peu) en chiffrant les messages.

Je sais pas si c'est clair.
Le mieux serait bien sûr d'avoir 2 couples de clé une qui servirait à
authentifié l'autre pour chiffrer.
Mais ds le cadre d'une implementation ds un logiciel il n'ai pas concevable
d'avoir un couple different pour chaque logiciel installé.

Enfin je n'ai pas d'idée précise de l'utilité de ceci mais j'aimerais
plutot un avis sur la qualité de sécurité de ce systeme.


Avatar
Marco
(chaton) wrote in
news::



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 ?


C'est une simple signature de la licence.
le logiciel utilisera la clé public pour verifier l'authenticité de la
licence.
n keygen ne pourra jamais signé la licence sans la clé privé du générateur
de licence.

J'ai oublié un détail?

Avatar
Francois Grieu
Dans l'article ,
Marco propose

d'utiliser la clé K1 (publique) pour chiffrer un message.
Ce message comporte un en-tete par exemple ou des propriétés
qui permettent de l'authentifier.
La clé K2 (privée) est en dur dans un logiciel.


Si je suis bien, dans ce système, la clé publique est gardée
secrète sur le serveur, et la clé privée en dur dans le
logiciel public.

Il me semble qu'en inversant les mots public et privé
dans cette description, et en remplaçant chiffrer par signer,
un système de signature RSA classique variante "à recouvrement
total de message" fait exactement cela. Et je préfère cet usage
des mots.

La signature RSA à recouvrement total de message, c'est:

- tirage des clés RSA, classiquement
- on choisi n = p*q avec p et q grands premiers aléatoires
secrets, et e premier avec p-1 et q-1
- clé K2 = (n,e) dans le logiciel
- clé K1 = (n,d) dans le serveur, d secret, avec
e*d = 1 mod PPCM(p-1,q-1)
donc pour tout x, (x^d)^e = x mod n

- signature d'un message m, qui doit être "nettement" plus
petit que n
- le serveur transforme m en x par une transformation
publique, réversible, ajoutant de la redondance
(exemple: ISO/IEC 9796-2:2002, dont la variante
la plus simple ajoute seulement de la redondance;
quand n fait un nombre de bits multiple de 8 et que
m fait 22 octets de moins que n, on ajoute
le hash SHA-1 de m à droite de m, ajoute $4A à gauche,
et $BC à droite)
- le serveur calcule c = (x^d) mod n et le transmet

- vérification d'un cryptogramme c par le programme
- le programme vérifie 0<=c<n
- il calcule x = (c^e) mod n
- il vérifie la redondance présente dans x, et en
extrait m (exemple correspondant au précédent:
vérifier le $BC à droite, et le $4A à gauche, et
que une fois que l'on les retire, les 20 octets de
droite sont le hash SHA-1 du reste, lequel constitue
alors m)

D'un certain point de vue (celui de Marco), le message
m est "chiffré" quand il est transmis sous la forme de c.
En tout cas sans K2 et avec seulement un exemple de c,
un adversaire ne peut pas remonter à m.

Il n'y a pas à se soucier trop que l'on puisse retrouver
K1 à partir de K2: c'est cryptographiquement impossible si
l'on admet la sécurité de RSA.

Un adversaire pourra probablement retrouver K2; soit
dans le logiciel, c'est le plus simple; soit, si e est
petit, à partir de couples (m,c) s'il en obtient assez.

Si e est choisi grand, aléatoire et secret, on ne sait pas
trouver K2 à partir de couples (m,c), même en choisissant
les messages m, même si n est rendu public, et même si d
est rendu public (ce qui est une catastrophe).


Note: la variante de ISO/IEC 9796-2 que j'ai décrite
(car c'est la plus simple) est théoriquement vulnérable
à une attaque avec de nombreux messages chosis. C'est pour
cela qu'il y a d'autres variantes.


François Grieu

Avatar
Francois Grieu
Dans l'article ,
Marco propose

d'utiliser la clé K1 (publique) pour chiffrer un message.
Ce message comporte un en-tete par exemple ou des propriétés
qui permettent de l'authentifier.
La clé K2 (privée) est en dur dans un logiciel.


Si je suis bien, dans ce système, la clé publique est gardée
secrète sur le serveur, et la clé privée en dur dans le
logiciel public.

Il me semble qu'en inversant les mots publique et privée
dans cette description, et en remplaçant chiffrer par signer,
un système de signature RSA classique variante "à recouvrement
total de message" fait exactement cela. Et je préfère cet usage
habituel des mots.

La signature RSA à recouvrement total de message, c'est:

- tirage des clés RSA, classiquement
- on choisi n = p*q avec p et q grands premiers aléatoires
secrets, et e premier avec p-1 et q-1
- clé K1 = (n,d) "privée" dans le serveur, d secret, avec
e*d = 1 mod PPCM(p-1,q-1)
donc pour tout x, (x^d)^e = x mod n
- clé K2 = (n,e) "publique" dans le logiciel

- signature d'un message m, qui doit être un peu plus
petit que n
- le serveur transforme m en x par une transformation
publique, réversible, ajoutant de la redondance
(exemple: ISO/IEC 9796-2:2002, dont la variante
la plus simple ajoute seulement de la redondance;
quand n fait un nombre de bits multiple de 8 et que
m fait 22 octets de moins que n, on ajoute
le hash SHA-1 de m à droite de m, ajoute $4A à gauche,
et $BC à droite)
- le serveur calcule c = (x^d) mod n et le transmet

- vérification d'un cryptogramme c par le programme
- le programme vérifie 0<=c<n
- le programme calcule x = (c^e) mod n
- le programme vérifie la redondance présente dans x,
et en extrait m (exemple correspondant au précédent:
vérifier le $BC à droite, et le $4A à gauche, et
que une fois que l'on les retire, les 20 octets de
droite sont le hash SHA-1 du reste, lequel constitue
alors m)

D'un certain point de vue (celui de Marco), le message
m est "chiffré" quand il est transmis sous la forme de c.
En tout cas sans K2 et avec seulement un exemple de c,
un adversaire ne peut pas remonter à m.

Il n'y a pas à craindre trop que l'on puisse retrouver
K1 (ou un équivalent) à partir de K2: c'est
cryptographiquement impossible si l'on admet la sécurité
de RSA.

Un adversaire pourra probablement retrouver K2 (ou un
équivalent); soit dans le logiciel, c'est le plus simple;
soit, si e est petit, à partir de couples (m,c) s'il en
obtient assez.

Si e est choisi grand, aléatoire et secret, on ne sait pas
trouver K2 (ni un équivalent), à partir de couples (m,c),
en choisissant les messages m, si n est rendu public,
et même si en plus de tout ceci d est rendu public
(ce dernier point étant une catastrophe).


Note: la variante de ISO/IEC 9796-2 que j'ai décrite
(car c'est la plus simple) est théoriquement vulnérable
à une attaque avec de nombreux messages chosis. C'est pour
cela qu'il y a d'autres variantes.


François Grieu

[désolé pour mes fréquents "Supersedes"]

1 2