Timing-Angriffe und der zeitkonstante Vergleich von Geheimnissen

Worum es geht

Ein Timing-Seitenkanal besteht, wenn die Dauer einer Operation von geheimen Daten abhängt. Der klassische Fall ist der Vergleich eines übermittelten Werts mit einem gespeicherten Geheimnis per gewöhnlicher Gleichheit: Der Vergleich kehrt zurück, sobald ein Byte abweicht, sodass ein Versuch mit korrektem ersten Byte etwas länger dauert als einer mit falschem. Wiederholte Messungen mitteln das Rauschen heraus und erlauben es einer angreifenden Partei, den Wert Byte für Byte zu rekonstruieren. Standardbibliotheken stellen Vergleiche bereit, deren Dauer nicht vom Inhalt abhängt: Pythons hmac.compare_digest verwendet „einen Ansatz, der Timing-Analyse verhindern soll, indem inhaltsbasiertes Short-Circuiting vermieden wird“; Nodes crypto.timingSafeEqual vergleicht die zugrunde liegenden Bytes mit einem zeitkonstanten Algorithmus und ist als geeignet für HMAC-Digests, Authentifizierungs-Cookies und Capability-URLs dokumentiert; Gos subtle.ConstantTimeCompare benötigt eine Zeit, die von den Längen abhängt und unabhängig vom Inhalt ist.

Warum es wichtig ist

Alles, was ein Server gegen ein Geheimnis vergleicht, ist betroffen: Webhook-Signaturen, API-Schlüssel, Passwort-Reset-Tokens, Session-Kennungen, CSRF-Tokens, HMAC-Tags auf signierten Cookies. Ob das Leck über ein verrauschtes Netzwerk ausnutzbar ist, ist eine Frage der Stichprobenzahl, nicht des Prinzips; die zeitkonstante Funktion ist günstig und erübrigt die Frage.

So wird es angewendet

• Jeden geheimnistragenden Wert mit der zeitkonstanten Funktion der Plattform vergleichen, nie mit == oder Stringgleichheit, und den Datensatz nicht über den Klartext-Token nachschlagen (WHERE token = ?), da ein Datenbankvergleich kein zeitkonstanter Vergleich ist; stattdessen über eine nicht geheime ID oder einen Hash des Tokens nachschlagen und dann zeitkonstant vergleichen.
• Die Längenregel beachten. Alle drei Funktionen behandeln abweichende Längen gesondert: Pythons Hinweis besagt, dass eine Längenabweichung die Längen offenlegen kann, aber nicht die Werte; Node wirft eine Ausnahme; Go liefert sofort 0 zurück. Digests fester Länge oder Hashes der Eingaben vergleichen, damit die Längen stets übereinstimmen.
• Den gesamten Pfad konstant halten, nicht nur den Vergleich: Existiert ein Benutzername nicht, das Passwort dennoch gegen einen Dummy-Hash prüfen, damit „unbekannter Benutzername“ und „falsches Passwort“ dieselbe Zeit brauchen.
• Serverseitige Bearer-Tokens als Hashes speichern und die Hashes vergleichen; eine geleakte Tabelle enthält dann ebenfalls keine verwendbaren Tokens.

Stolpersteine

Ein zeitkonstanter Vergleich behebt keinen vorgelagerten Schritt mit variabler Dauer, etwa eine Verzweigung nach dem Präfix des Geheimnisses oder einen Decoder, der frühzeitig ablehnt; Nodes Dokumentation hält fest, dass die Verwendung von timingSafeEqual nicht garantiert, dass der umgebende Code zeitsicher ist. Rate Limiting verringert die Stichprobenzahl der angreifenden Partei, ist aber eine zweite Verteidigungslinie, kein Ersatz. Eine handgeschriebene Vergleichsschleife kann von einem Compiler oder einer Laufzeitumgebung so umgeformt werden, dass datenabhängiges Timing wieder entsteht; die Bibliotheksfunktion verwenden.