Aux États-Unis, les GOST sont aussi des moyens. Vulnérabilité fatale YubiKey FIPS qui aurait pu être évitée

Salut% username%!

Le 13 juin 2019, Yubico, un fabricant d'appareils d'authentification à deux facteurs, a publié un avis de sécurité indiquant la vulnérabilité critique de certains appareils Yubikey FIPS. Voyons ce qu'est cette vulnérabilité et comment elle pourrait être évitée.

Préface

Les États ont également leurs propres GOST, appelés FIPS - Federal Information Processing Standard. Matériel et logiciels avec lesquels l'État. structures nécessaires pour se conformer à la FIPS.

Selon les collègues que nous avons rencontrés à EuroCrypt 2019, la certification FIPS est un enfer, même au point que des experts FIPS viennent vous voir, lancent votre logiciel en mode débogage, modifient les valeurs en mémoire et vérifient s'il tombe là où il est prévu.

Malgré cela, obtenir une certification et devenir conforme à la norme FIPS est réel. Par conséquent, les produits et les entreprises qui fournissent des services à l'État sont bien plus nombreux que les nôtres.

ECDSA

À l'intérieur du jeton USB de Yubico, il y a un stockage pour les clés et un moteur qui implémente notamment ECDSA. Lors de l'enregistrement, la clé publique du jeton est transférée sur le serveur et stockée.

Et lors de la connexion, le serveur envoie une chaîne aléatoire au client, qu'il signe avec les méta-informations, comme par exemple un domaine.

En bref sur le fonctionnement de l'ECDSA ou de la signature numérique sur les courbes elliptiques. Certains détails sont omis pour faciliter la présentation:

1. Nous considérons le hachage du message et le traduisons en nombre. $$$e = HASH (m)$.
2. Nous générons un nombre aléatoire cryptographiquement fort k.
3. Calculer le point $$$(x, y) = k * G$où G est le point de base de la courbe appelée générateur (constante)
4. Nous calculons $$$r = x ~ mod ~ n$où n est l'ordre du point de base (constant)
5. Nous calculons $$$s = k ^ {- 1} (e + r * d) \, \ bmod \, n$où d est la clé privée
6. La signature numérique se compose d'une paire de chiffres r, s

Il est essentiel que le nombre k soit non seulement secret, mais toujours différent. Sinon, il devient possible de calculer la clé privée.

Par exemple, nous avons deux signatures (r, s) et (r1, s1), qui ont été reçues pour différents messages m et m1, mais en utilisant le même secret k. Calculons la clé privée.

• L'attaquant calcule e et e1.
• Depuis $$$s - s1 = k ^ {- 1} (e - e1)$alors nous pouvons découvrir k. $$$k = \ frac {e - e1} {s - s1}$
• Depuis $$$s = k ^ {- 1} (e + r * d)$, alors nous pouvons calculer d. $$$d = \ frac {s * k - e} {r}$
• d - clé privée

Si les nombres k sont différents, mais pas tout à fait , vous pouvez également calculer la clé privée, il vous suffit de forcer un peu. Au fait, en 2013, j'ai déjà écrit comment le DSA maladroitement implémenté (EC) s'est cassé sur la PlayStation et d'autres produits, je recommande fortement de le lire.

Yubico

Ainsi, dans un certain nombre de produits Yubico FIPS, il y avait un bogue dans lequel les nombres k immédiatement après avoir allumé le jeton n'étaient pas entièrement aléatoires. Et il y avait une réelle opportunité de calculer la clé privée câblée à l'intérieur. Par conséquent, ils ont rappelé des appareils vulnérables et émis une notification.

Que pourrait-on faire?

D'une manière générale, le problème est depuis longtemps résolu. Depuis 2013, il existe la RFC 6979 , qui décrit un ECDSA déterministe obtenu à partir de l'ordinaire à travers plusieurs modifications simples. De plus, en 2014, lors du développement de la norme U2F, c'est précisément en raison de problèmes potentiels avec le RPS que la FIPS a ouvertement proposé de passer à l'ECDSA déterministe, mais l'offre a été rejetée. C'est l'une des raisons pour lesquelles FIPS signifie F * cked-up, Insecure, Persnickety Standards.

Yubico pourrait officiellement répondre aux exigences FIPS pour le caractère aléatoire du nombre k, mais utiliser une solution de contournement, générant k de manière déterministe, puis le XOR avec le fait qu'il a émis un RNG (ou en exécutant tout via KDF). Mais cela n'a pas été fait.

Et nous?

Et nous avons la même chose. GOST R 34.10-2012 - essentiellement le même ECDSA, juste avec des courbes différentes. Les exigences pour générer le nombre k restent les mêmes que dans l'ECDSA traditionnel. L'un des fabricants de nos jetons effectue-t-il la solution de contournement décrite ci-dessus? Utilise-t-il la version déterministe de l'ECDSA? J'en doute.

S'il y a des représentants de développeurs russes, il serait intéressant d'écouter leur avis à ce sujet. Ou du moins de garder cela à l'esprit.

Merci de votre attention.