Original-URL des Artikels: https://www.golem.de/news/rsa-crt-rsa-angriff-aus-dem-jahr-1996-wiederentdeckt-1509-116134.html    Veröffentlicht: 04.09.2015 14:13    Kurz-URL: https://glm.io/116134

RSA-CRT

RSA-Angriff aus dem Jahr 1996 wiederentdeckt

Eine Optimierung von RSA-Signaturen kann bei fehlerhaften Berechnungen den privaten Schlüssel verraten. Bekannt ist dieser Angriff schon seit 1996, ein Red-Hat-Entwickler hat jetzt herausgefunden, dass es immer noch verwundbare Hard- und Software gibt.

Im Jahr 1996 hat der Kryptograph Arjen Lenstra einen Angriff auf RSA-Signaturen beschrieben, der bei fehlerhaften Implementierungen den privaten Schlüssel verraten kann. Der Red-Hat-Entwickler Florian Weimer hat sich aktuelle RSA-Implementierungen angesehen und im Netz nach Systemen gesucht, die dieses Problem aufweisen. Dabei hat er zahlreiche Geräte gefunden, die nach wie vor für diese Lücke anfällig sind.

Optimierung mit Chinesischem Restsatz

Die Rechenoperationen beim RSA-Algorithmus werden mit Hilfe eines Modulus durchgeführt, der das Produkt zweier Primzahlen ist. Mittels einer Technik, die auf dem sogenannten Chinesischen Restsatz (Chinese Remainder Theorem, CRT) basiert, ist es für den Inhaber des privaten Schlüssels möglich, diese Berechnungen jeweils mit jeder Primzahl einzeln durchzuführen. Eine derartige Berechnung ist schneller, daher verwenden fast alle RSA-Implementierungen dieses Verfahren.

Wie Lenstra 1996 herausfand, kann diese CRT-Optimierung ein großes Sicherheitsrisiko darstellen. Wenn bei einer der beiden Berechnungen ein Fehler auftritt, kann ein Angreifer anschließend den privaten Schlüssel berechnen. Bei einer immer korrekt arbeitenden Implementierung ist das natürlich erstmal kein Problem, da dort keine Rechenfehler auftreten sollten. Aber Bugs in der Software oder Hardwaredefekte können zu derartigen Fehlern führen.

Ein zusätzlicher Check ist ratsam

Um diese Probleme zu vermeiden, ist es empfehlenswert, bei RSA-Signaturen einen zusätzlichen Check einzubauen. Nach dem Erstellen der Signatur sollte diese schlicht nochmal von der Implementierung selbst geprüft werden. Nur wenn die Signatur korrekt ist, darf sie auch preisgegeben werden.

Weimer versuchte, herauszufinden, ob bei heutigen TLS-Implementierungen entsprechende Lücken ganz praktisch ausnutzbar sind. Damit der Angriff funktioniert, muss die RSA-Signatur mit deterministischen Eingaben arbeiten. Das ist nur beim alten RSA-Signaturverfahren nach dem Standard PKCS #1 1.5 der Fall. Eine nichtdeterministische Variante von RSA, die als deutlich sicherer gilt, ist RSA-PSS. Diese ist in PKCS #1 2.1 standardisiert. Allerdings: TLS unterstützt bis heute RSA-PSS nicht, es wird ausschließlich der ältere, deterministische Standard genutzt.

Damit der Angriff auf TLS-Server funktioniert, müssen mehrere Dinge zusammenkommen. Lange Zeit wurde bei TLS und dessen Vorgänger SSL das RSA-Verfahren ausschließlich als Verschlüsselungsalgorithmus genutzt. Nur neue Verschlüsselungsmodi, die mittels eines Diffie-Hellman-Schlüsselaustauschs Forward Secrecy implementieren, nutzen RSA-Signaturen. Damit der Fehler ausnutzbar ist, muss zudem sporadisch ein Fehler bei der RSA-Berechnung auftauchen. Diese Fehler dürfen aber auch nicht zu häufig auftreten, denn nur eine von zwei Berechnungen darf fehlerhaft sein, damit die Schlüsselextraktion möglich ist. Und wie eben erwähnt, kann ein entsprechender Check der Signatur verhindern, dass ein Angreifer überhaupt Zugriff auf die fehlerhaften Berechnungsresultate erhält.

270 Keys gebrochen

Über einen Zeitraum von neun Monaten wurden zahlreiche Scans von bekannten Domainnamen durchgeführt. Dabei ließen sich 270 verschiedene RSA-Keys extrahieren. Nur drei davon gehörten zum Zeitpunkt des Scans zu gültigen Zertifikaten, die von einer von Browsern anerkannten Zertifizierungsstelle signiert waren. Zwei der gültigen Zertifikate gehörten zu einem Netscaler-Gerät von der Firma Citrix. Die für das Gerät verantwortlichen Administratoren konnten kontaktiert werden. Es handelte sich um ein sehr altes Gerät, dessen Austausch sowieso schon vorgesehen war.

Die meisten der extrahierten Keys stammten von Geräten der chinesischen Firma Hillstone. Ein Firmwareupdate für die entsprechenden Geräte steht inzwischen bereit. Weitere betroffene Geräte stammten von den Firmen Viprinet, QNO, Alteon/Nortel, ZyXEL und Fortinet, außerdem betroffen war eine kommerzielle Java-Verschlüsselungsimplementierung namens BEJY.

Spezialprozessor und eigene OpenSSL-Variante

Viele der Fehler haben offenbar eine gemeinsame Ursache: Alle verwendeten Geräte nutzten für die RSA-Operationen einen MIPS-Prozessor der Firma Cavium, der mit einer speziell angepassten OpenSSL-Version zusammen ausgeliefert wird. Laut Cavium wurde ein Update bereitgestellt und die Lücke wird unter der Id CVE-20125-5738 geführt.

Weimer weist darauf hin, dass es sich um eine sehr kleine Zahl von TLS-Handshakes handelt, die von dem Problem betroffen sind. Allerdings treten die entsprechenden Fehler in vielen Fällen nur sehr selten auf. Daher sei es möglich, dass weitere Hard- und Software betroffen ist und durch den Scan nicht gefunden wurde. Durchführen kann man den Angriff auch rein passiv. Man könnte einfach massenhaft die Daten von TLS-Handshakes mitlauschen und nach fehlerhaften Handshakes suchen.

NSS-Schutz gut, OpenSSL-Schutz mit Fragezeichen

Neben dem Scan hat Florian Weimer quelloffene RSA-Implementierungen analysiert, viele davon implementieren keinen Schutz vor derartigen CRT-Fehlern. Ausnahmen sind die beiden wichtigsten TLS-Bibliotheken - OpenSSL und NSS. Bei der von Mozilla genutzten NSS-Bibliothek wird im Fall einer fehlerhaften Signatur schlicht ein Fehler ausgegeben. Das ist laut Weimer die beste Methode, um derartige Fehler zu behandeln. In OpenSSL wird im Falle eines Fehlers die Berechnung der RSA-Signatur ohne die CRT-Optimierung wiederholt. Weimer sieht hier zwar keine unmittelbare Gefahr, aber in sehr speziellen Fällen könnten Fehler in der CPU hier auch dazu führen, dass ein Angreifer, der mehrere Tausend fehlerhafte Signaturen mitlesen kann, den privaten Schlüssel extrahiert. Weimer verweist hierzu auf ein Paper von Forschern der Universität Michigan aus dem Jahr 2010.

Zahlreiche andere Implementierungen hatten überhaupt keinen Schutz gegen derartige Fehler implementiert. Die Entwickler der Java-Implementierung OpenJDK haben, nachdem sie von Weimer kontaktiert wurden, im April eine entsprechende Schutzmaßnahme implementiert. Libgcrypt hat vor wenigen Tagen eine entsprechende Änderung vorgenommen. GnuPG wiederum verwendet zwar Libgcrypt, es hatte aber selbst bereits einen entsprechenden Schutz eingebaut und ist somit nicht betroffen.

Weimer hat auch die Entwickler von Nettle und von Go kontaktiert und um die Implementierung entsprechender Schutzmaßnahmen gebeten. In seinem Hintergrundpaper wird weiterhin erwähnt, dass PolarSSL, Openswan und ocaml-nocrypto ebenfalls den entsprechenden Schutz nicht implementieren, bei Cryptib ist er zwar implementiert, jedoch in der Standardeinstellung ausgeschaltet.

Zombie-Sicherheitslücken als Bedrohung

Dass eine Lücke, die bereits 1996 dokumentiert wurde, nach wie vor ein Problem darstellt, ist bemerkenswert. Im vergangenen Jahr gab es jedoch bereits eine ähnliche Entdeckung: Forscher fanden heraus, dass die RSA-Implementierung von Java und mit Einschränkungen auch die von OpenSSL verwundbar für ein fast ebenso altes Problem waren, die sogenannte Million-Message-Attacke, die der Kryptograph Daniel Bleichenbacher 1998 publiziert hatte.

Die Implementierung von kryptographischen Algorithmen ist komplex und muss zahlreiche mögliche Angriffe berücksichtigen. Offenbar geht das Wissen darüber, wie man entsprechende Angriffe verhindert, über die Jahre verloren und uralte Sicherheitslücken tauchen wieder auf. Wieder einmal zeigt sich hier, dass man die Implementierung entsprechender Algorithmen qualifizierten Fachleuten überlassen sollte. Gerade Enterprise-Produkte werden oft mit zweifelhaften, selbst entwickelten TLS-Implementierungen ausgeliefert, die immer wieder zu Problemen führen.  (hab)


Verwandte Artikel:
Verschlüsselung: Github testet Abschaltung alter Krypto   
(09.02.2018, https://glm.io/132684 )
Hersteller gegen EU-Verbot von Plasmafernsehern   
(15.01.2009, https://glm.io/64630 )
Ron was wrong, Whit is right: RSA-Schlüssel unsicherer als gedacht   
(15.02.2012, https://glm.io/89783 )
Shellshock: Alle Bash-Lücken gepatcht   
(06.10.2014, https://glm.io/109638 )
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )

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