In den Staaten sind GOSTs auch so lala. YubiKey FIPS schwerwiegende Sicherheitslücke, die hätte vermieden werden können

Hallo% Benutzername%!

Am 13. Juni 2019 gab Yubico, ein Hersteller von Zwei-Faktor-Authentifizierungsgeräten, einen Sicherheitshinweis heraus, in dem die kritische Sicherheitsanfälligkeit einiger Yubikey FIPS-Geräte angegeben wird. Mal sehen, was diese Sicherheitsanfälligkeit ist und wie sie verhindert werden kann.

Vorwort

Die Staaten haben auch ihre eigenen GOSTs, genannt FIPS - Federal Information Processing Standard. Hardware und Software, mit der der Staat. Strukturen, die zur Einhaltung der FIPS erforderlich sind.

Laut den Kollegen, die wir auf der EuroCrypt 2019 getroffen haben, ist die FIPS-Zertifizierung eine verdammt gute Sache, bis zu dem Punkt, an dem FIPS-Experten zu Ihnen kommen, Ihre Software im Debug-Modus starten, die Werte im Speicher ändern und prüfen, ob sie dort abfällt, wo sie beabsichtigt ist.

Trotzdem ist es real, sich zertifizieren zu lassen und FIPS-konform zu werden. Daher gibt es bei den Produkten und Unternehmen, die Dienstleistungen für den Staat erbringen, um ein Vielfaches mehr als bei uns.

ECDSA

Im USB-Token von Yubico befindet sich ein Speicher für Schlüssel und eine Engine, die Folgendes implementiert ECDSA. Bei der Registrierung wird der öffentliche Schlüssel vom Token auf den Server übertragen und gespeichert.

Beim Anmelden sendet der Server eine zufällige Zeichenfolge an den Client, die er zusammen mit den Metainformationen signiert, z. B. einer Domäne.

Kurz gesagt, wie ECDSA oder die digitale Signatur auf elliptischen Kurven funktionieren. Einige Details sind zur Vereinfachung der Darstellung weggelassen:

1. Wir betrachten den Hash aus der Nachricht und übersetzen ihn in eine Zahl. $$$e = HASH (m)$.
2. Wir erzeugen eine kryptographisch starke Zufallszahl k.
3. Punkt berechnen $$$(x, y) = k * G$Dabei ist G der Basispunkt der Kurve, der als Generator bezeichnet wird (Konstante).
4. Wir berechnen $$$r = x ~ mod ~ n$Dabei ist n die Reihenfolge des Basispunkts (Konstante).
5. Wir berechnen $$$s = k ^ {- 1} (e + r * d) \, \ bmod \, n$Dabei ist d der private Schlüssel
6. Die digitale Signatur besteht aus einem Zahlenpaar r, s

Es ist wichtig, dass die Zahl k nicht nur geheim ist, sondern immer anders. Andernfalls wird es möglich, den privaten Schlüssel zu berechnen.

Zum Beispiel haben wir zwei Signaturen (r, s) und (r1, s1), die für verschiedene Nachrichten m und m1 empfangen werden, aber dasselbe Geheimnis k verwenden. Berechnen wir den privaten Schlüssel.

• Der Angreifer berechnet e und e1.
• Seit $$$s - s1 = k ^ {- 1} (e - e1)$dann können wir herausfinden, k. $$$k = \ frac {e - e1} {s - s1}$
• Seit $$$s = k ^ {- 1} (e + r * d)$dann können wir d berechnen. $$$d = \ frac {s * k - e} {r}$
• d - privater Schlüssel

Wenn die Zahlen k unterschiedlich sind, aber nicht ganz , dann können Sie auch den privaten Schlüssel berechnen, Sie müssen nur ein wenig Brute Force. Übrigens, 2013 habe ich bereits geschrieben, wie der ungeschickt implementierte (EC) DSA in der PlayStation und anderen Produkten kaputt gegangen ist. Ich empfehle dringend, ihn zu lesen.

Yubico

Bei einigen Yubico FIPS-Produkten gab es also einen Fehler, bei dem die Zahlen k unmittelbar nach dem Einschalten des Tokens nicht ganz zufällig waren. Und es gab eine echte Gelegenheit, den darin verdrahteten privaten Schlüssel zu berechnen. Daher haben sie anfällige Geräte zurückgerufen und eine Benachrichtigung ausgegeben.

Was könnte getan werden?

Im Allgemeinen ist das Problem seit langem gelöst. Seit 2013 gibt es RFC 6979 , das eine deterministische ECDSA beschreibt, die durch mehrere einfache Modifikationen aus der üblichen erhalten wird. Darüber hinaus schlug FIPS 2014 bei der Entwicklung des U2F-Standards gerade wegen möglicher Probleme mit dem RPS offen vor , auf deterministisches ECDSA umzusteigen, doch das Angebot wurde abgelehnt. Dies ist einer der Gründe, warum FIPS für F * cked-up, Insecure, Persnickety Standards steht.

Yubico könnte die FIPS-Anforderungen für die Zufälligkeit der Zahl k formal erfüllen, aber eine Problemumgehung verwenden, k deterministisch generieren und sie dann mit der Tatsache XOR-verknüpfen, dass ein RNG ausgegeben wird (oder indem alles über KDF ausgeführt wird). Dies wurde jedoch nicht getan.

Was ist mit uns?

Und wir haben das Gleiche. GOST R 34.10-2012 - im Wesentlichen das gleiche ECDSA, nur mit unterschiedlichen Kurven. Die Anforderungen zur Erzeugung der Zahl k bleiben dieselben wie bei der traditionellen ECDSA. Führt einer der Hersteller unserer Token die oben beschriebene Problemumgehung durch? Verwendet es die deterministische Version von ECDSA? Ich bezweifle es.

Wenn es Vertreter russischer Entwickler gibt, wäre es interessant, ihre Meinung zu diesem Thema zu hören. Oder zumindest, um das zu berücksichtigen.

Vielen Dank für Ihre Aufmerksamkeit.