Original-URL des Artikels: https://www.golem.de/news/tls-gcm-gefahr-durch-doppelte-nonces-1605-121005.html    Veröffentlicht: 20.05.2016 08:05    Kurz-URL: https://glm.io/121005

TLS/GCM

Gefahr durch doppelte Nonces

Moderne TLS-Verbindungen nutzen üblicherweise das AES-GCM-Verschlüsselungsverfahren. Das benötigt einen sogenannten Nonce-Wert, der sich nicht wiederholen darf. Ansonsten ist die Sicherheit dahin.

Die AES-Verschlüsselung im sogenannten Galois/Counter-Mode (GCM) hat sich für TLS-Verbindungen weitgehend durchgesetzt. Der Grund dafür ist, dass alle anderen Verschlüsselungsmodi, die von TLS unterstützt werden, in der Vergangenheit zahlreiche Sicherheitslücken hatten. Doch auch GCM ist nicht frei von Problemen. In einem Forschungsprojekt, an dem auch der Autor dieses Artikels beteiligt war, wurden Probleme bei der Generierung des sogenannten Nonce-Wertes untersucht. Eine Reihe von Webservern nutzt sich wiederholende Nonce-Werte, eine gravierende Sicherheitslücke. Betroffen sind unter anderem Webseiten des Kreditkartenkonzerns Visa.

Nonce-Wert muss einmalig sein

Eine Verschlüsselung mit dem GCM-Verfahren nutzt einen sogenannten Initialisierungsvektor, der zwölf Bytes lang ist. Vier Bytes davon sind durch das Protokoll vorgegeben, die übrigen acht Bytes muss die jeweilige TLS-Implementierung setzen. Wichtig dabei: Es handelt sich um einen sogenannten Nonce-Wert. Das bedeutet, dass dieser Wert für jede Verschlüsselungsoperation einmalig sein muss. Werden zwei Verschlüsselungsoperationen mit demselben Key und demselben Nonce durchgeführt, ist die Sicherheit des GCM-Verfahrens nicht mehr gewährleistet.

Die TLS-Spezifikation gibt leider keinerlei Hinweise, wie ein Nonce sicher generiert werden soll. Auf diesen Mangel der Spezifikation hat 2014 der Google-Entwickler Adam Langley hingewiesen. Langleys Blogpost war der Anlass für dieses Forschungsprojekt.

Im Grunde ist es kein Problem, einen sicheren Nonce zu erstellen: Am einfachsten ist es, einen Zähler zu verwenden. Sprich: Bei jeder weiteren Verschlüsselung wird der vorherige Nonce-Wert um eins erhöht. Ob man dabei mit einem zufälligen Wert oder mit Null anfängt, ist egal - beides ist sicher.

Wie sich allerdings herausstellte, gibt es einige TLS-Implementierungen, bei denen die Nonce-Generierung fehlerhaft implementiert ist. Mittels eines internetweiten Scans fanden sich 184 HTTPS-Server, bei denen der Nonce nach wenigen Verschlüsselungen bereits wiederholt wird. Einige Server nutzten dabei permanent einen Nullwert als Nonce, andere schickten zwei identische Werte und zählten anschließend hoch, wieder andere nutzten zuerst eine Zufallszahl und für alle weiteren Verschlüsselungen einen Nullwert.

Visa-Server verwundbar

Zwar ist die Zahl der betroffenen Server nicht besonders hoch, doch darunter fanden sich einige prominente Namen. Betroffen waren und sind etwa eine Reihe von Webseiten des Kreditkartenkonzerns Visa. Im Januar wurde Visa über diese Sicherheitslücke informiert, es gab jedoch keine Reaktion.

Es gestaltete sich als schwierig, herauszufinden, welche Hersteller für die fehlerhaften TLS-Implementierungen verantwortlich sind. Viele betroffene Serverbetreiber beantworteten Mailanfragen nicht. Über Kontakte, die das österreichische Cert herstellte, konnten wir jedoch herausfinden, dass ein Serverbetreiber Geräte des Herstellers Radware nutzte. Radware hat inzwischen ein Firmwareupdate bereitgestellt.



Forbidden Attack



Neben den Servern, die den Nonce-Wert direkt wiederholen, fanden sich etwa 70.000 Server, die den Nonce-Wert zufällig setzen. Das ist riskant. Aufgrund des Geburtstagsparadoxons steigt dabei die Wahrscheinlichkeit, einen doppelten Nonce-Wert zu erzeugen, wenn eine große Zahl von Verschlüsselungen mit demselben Schlüssel durchgeführt wird. Allerdings müssen dafür mehrere Giga- oder gar Terabytes an Daten über eine einzige TLS-Verbindung übertragen werden. Betroffen von dieser schwächeren Form der Sicherheitslücke sind unter anderem Geräte von A10 und Sangfor sowie IBM Lotus Domino.

Der verbotene Angriff von Joux

Wenn sich ein Nonce-Wert wiederholt, kann ein Angreifer daraus mit hoher Wahrscheinlichkeit den Authentifizierungsschlüssel des GCM-Verfahrens berechnen. Diesen Angriff hatte der Kryptograph Antoine Joux bereits während des Standardisierungsprozesses von GCM vorgestellt. Joux bezeichnete diesen Angriff damals als "Forbidden Attack", also als verbotenen Angriff. Verboten deshalb, weil korrekte Implementierungen den Nonce niemals wiederholen sollten.

Hat ein Angreifer den Authentifizierungsschlüssel mittels dieses verbotenen Angriffs erfahren, kann er damit Pakete manipulieren. Im Fall von HTTPS etwa könnte der Angreifer Javascript-Code in eine Webseite einfügen. Es gelang uns, den Angriff praktisch umzusetzen und auf verwundbaren Webseiten - beispielsweise der dänischen Webseite von Visa (www.visa.dk) - anzuwenden.

Zukünftige Protokolle robuster

Im Entwurf für das zukünftige Protokoll TLS 1.3 wurde das Problem fehlerhafter Nonces grundlegend behoben. Statt es der Implementierung zu überlassen, wie der Nonce-Wert gewählt wird, gibt der Standard diesen direkt vor. Auch die kurz vor ihrer Verabschiedung stehende Spezifikation für das Verschlüsselungsverfahren ChaCha20/Poly1305 in TLS sieht einen ähnlichen Mechanismus vor. Eine Implementierung, die den Nonce fehlerhaft implementiert, würde damit sofort auffallen, da mit korrekt arbeitenden Implementierungen keine Verbindung zustande käme.

Auch auf der grundlegenden Ebene der Algorithmen gibt es Ansätze, die Wahl der Nonces sicherer zu gestalten. Verschlüsselungsmodi mit sogenannten Synthetic IVs (SIV) generieren den Initialisierungsvektor selbst, er muss nicht durch die Implementierung oder das Protokoll gesetzt werden. Im Rahmen des Caesar-Wettbewerbs sind mehrere Verfahren vorgeschlagen worden, die dies umsetzen, auch wird zur Zeit eine Variante des GCM-Verfahrens namens AES-GCM-SIV in der IETF diskutiert.

Die entdeckten Sicherheitslücken mit fehlerhaften Nonces sind keine Schwäche des TLS-Protokolls selbst, es handelt sich um Fehler in der Implementierung. Doch einmal mehr zeigt sich, welche Tücken es bei der korrekten Implementierung von TLS gibt. Es scheint, dass fast jeder Fehler, den man bei der Implementierung von TLS machen kann, auch von irgendwem gemacht wird.

Der Code, der für den Scan verwendet wurde, sowie der Code für den Angriff wurden auf Github veröffentlicht.  (hab)


Verwandte Artikel:
Quantencomputer: Erste Empfehlungen für Post-Quanten-Kryptographie   
(07.09.2015, https://glm.io/116166 )
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )
Librem 5: Purism-Smartphone bekommt Smartcard für Verschlüsselung   
(09.03.2018, https://glm.io/133248 )
Trustico/Digicert: Chaos um 23.000 Zertifikate und private Schlüssel   
(01.03.2018, https://glm.io/133077 )
Windows 10: Microsoft sagt Passwörtern auf Wiedersehen   
(28.09.2017, https://glm.io/130342 )

© 1997–2019 Golem.de, https://www.golem.de/