PS3

Le
ptilou
Bonjour et Bonne année,

Je viens de lire un article ou l'on parle d'avoir trouvé une clés
privé par le biais d'un algorithme, y aurait il d'autre solution que
la force brute ?
http://www.gamepro.fr/2010/12/31/playstation/la-ps3-vraiment-hackee/510049/

Merci pour tous retour d'info

Ptilou
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
A. Caspis
Le #23000841
ptilou wrote:
Je viens de lire un article ou l'on parle d'avoir trouvé une clés
privé par le biais d'un algorithme, y aurait il d'autre solution que
la force brute ?
http://www.gamepro.fr/2010/12/31/playstation/la-ps3-vraiment-hackee/510049/



Une maladresse dans l'implémentation de ECDSA. C'est expliqué ici:
http://www.youtube.com/watch?vêg0VyRTld8#t30s

AC
Jean-Marc Desperrier
Le #23028471
ptilou wrote:
Je viens de lire un article ou l'on parle d'avoir trouvé une clés
privé par le biais d'un algorithme, y aurait il d'autre solution que
la force brute ?
http://www.gamepro.fr/2010/12/31/playstation/la-ps3-vraiment-hackee/510049/



Pas n'importe quelle privée, une clé privée de courbe elliptique, ce qui
signifie que l'algorithme crypto sous-jacent est DSA.

Et DSA a un point faible, il utilise un générateur aléatoire, qui doit
être *parfaitement* sûr, sinon la clé privée peut être retrouvée.
C'est décrit brièvement ici :
http://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Sensitivity

Il y a une description plus détaillée du problème ici, qui aborde le cas
PS3 :
http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/

Il vient d'y avoir une discussion sur le sujet sur sci.crypt initiée par
François Grieu, et Thomas Pornin est en train d'y proposer une solution
astucieuse au problème :
C'est, au lieu d'utiliser un générateur aléatoire, de se servir d'un
hachage initialisée avec la clé privée et le contenu du message.
- La fonction de hash ne permet pas de revenir au données de départ
sinon l'algo est très fortement cassé (beaucoup plus que MD5 ne l'est
aujourd'hui), donc on ne révèle rien sur la clé privée en faisant cela.
- Comme la clé privée est totalement inconnue de l'attaquant (sinon de
toute façon, c'est déjà cassé), le résultat du hashage est absolument
imprévisible pour lui, et indistinguable d'une valeur aléatoire (encore
une propriété que toute fonction de hachage un tant soit peu raisonnable
vérifie très bien, y compris MD5 d'ailleurs).

Il faut éviter de se précipiter et laisser mûrir l'idée, afin d'avoir le
temps de vérifier qu'il n'y a pas un piège caché. Cependant la logique
qui montre que ça devrait être solide n'est pas très compliquée, donc ça
semble assez robuste.

Le problème c'est que les gens suffisamment mal informés pour ne pas
utiliser DSA proprement, avec un vrai générateur aléatoire, ne le seront
jamais assez pour utiliser cette alternative à la place. L'avantage
serait surtout sur une plate-forme où l'on doute d'avoir un générateur
aléatoire sérieux disponible, et on pourra éviter complétement de se
poser la question en faisant cela. A condition que cet algo soit bien
validé comme étant vraiment sûr.
Mehdi Tibouchi
Le #23028981
Jean-Marc Desperrier wrote in message

Il vient d'y avoir une discussion sur le sujet sur sci.crypt initiée par
François Grieu, et Thomas Pornin est en train d'y proposer une solution
astucieuse au problème :
C'est, au lieu d'utiliser un générateur aléatoire, de se servir d'un
hachage initialisée avec la clé privée et le contenu du message.



C'est une technique classique. Voir par exemple le papier de Louis
Granboulan à SCN'02 :

http://www.di.ens.fr/~granboul/recherche/publications/abs-2002-ESIGN.html

(qui parlait de ESIGN plutôt que DSA mais ça ne change pas grand-chose;
d'ailleurs Louis à aussi une discussion de l'extension à ce cas dans son
papier sur PECDSA).
Thomas Pornin
Le #23029331
According to Mehdi Tibouchi
C'est une technique classique.



Oui, je n'en suis certainement pas l'inventeur. La méthode usuelle
consiste à adjoindre à la clé privée une autre valeur secrète qui,
combinée avec le message à signer, sert de graine à un PRNG. Ce que
j'essaye de faire consiste en deux points :

1. Spécifier une méthode au format "RFC", c'est-à-dire en faisant
attention aux détails d'implémentation. Il ne s'agit pas d'innover
académiquement mais d'amener la technique à un point où elle est
implémentable (et donc, par exemple, publier des vecteurs de test).

2. Réutiliser la clé privée elle-même comme graine pour le PRNG (afin
d'être compatible avec des clés déjà générées, et les générateurs
de clés existants, sans besoins en stockage supplémentaire).

Le point 2 complique certainement les preuves de sécurité. Dans (EC)DSA,
on utilise k (la valeur aléatoire) et x (la clé secrète) dans l'équation
suivante :

s = (H(m) + xr) / k mod q

Intuitivement, on "sent" que ça ne pose pas de problème de sécurité si k
est généré à partir de H(m) et x, parce que k et x sont séparés par le
PRNG. Cela impose que le PRNG ait quelques bonnes proppriétés qu'a
priori HMAC_DRBG possède. Mais idéalement il faudrait rédiger la preuve
de sécurité proprement (c'est-à-dire adapter les preuves de sécurité
existantes pour prendre en compte ce montage). Le format RFC n'est pas
très pratique pour ça ; ça m'arrangerait si quelqu'un l'avait déjà fait
et publié quelque part...


Voir par exemple le papier de Louis Granboulan à SCN'02 :

http://www.di.ens.fr/~granboul/recherche/publications/abs-2002-ESIGN.html

(qui parlait de ESIGN plutôt que DSA mais ça ne change pas grand-chose;
d'ailleurs Louis à aussi une discussion de l'extension à ce cas dans son
papier sur PECDSA).



Je le note : demander son avis à Louis. Je vais faire ça.


--Thomas Pornin
Publicité
Poster une réponse
Anonyme