OpenSSH forciert Alternativen zu NIST-Krypto-Standards
Als erstes groĂźes Projekt unterstĂĽtzt OpenSSH jetzt Verfahren fĂĽr sicheren SchlĂĽsselaustausch und digitale Signaturen, die von den NIST-Standards fĂĽr Elliptische Kurven abweichen. Basis dafĂĽr ist Dan Bernsteins Curve25519.
Kryptographie auf der Basis von Elliptischen Kurven ist durch die Enthüllung der NSA-Aktivitäten ins Gerede gekommen; nicht wenige Kryptologen betrachten die aktuellen, von der NIST spezifizierten Standards durch den Einfluss der NSA als kompromittiert. Andererseits führt schon mittelfristig kaum ein Weg am Einsatz von EC-Verfahren vorbei. Das OpenSSH-Projekt zeigt mit seiner Unterstützung der vom renommierten Kryptologen Dan Bernstein vorgeschlagenen Curve25519 einen Ausweg aus dem Dilemma auf.
Im Zentrum der aktuellen Diskussionen stehen die fĂĽr Authentifizierung und Digitale Signaturen verantwortlichen Verfahren RSA und Diffie Hellman. Bei beiden mĂĽsste man schon heute eigentlich mit SchlĂĽsseln mit mehr als 3000 Bit arbeiten, um ein Sicherheitsniveau zu erreichen, das dem eines symmetrischen 128-Bit-SchlĂĽssels etwa fĂĽr AES entspricht. Die eigentlich schon mittelfristig wĂĽnschenswerte Sicherheit von 256-Bit bieten erst RSA-SchlĂĽssel mit ĂĽber 15000 Bit. Die Situation eskaliert also dramatisch. Da sich solche ĂĽberlangen SchlĂĽssel stark auf die Geschwindigkeit der Berechnungen auswirken, braucht man Alternativen.
Langsamer Logarithmus
Die bietet die Kryptografie auf Basis von Elliptischen Kurven. Das dem Diffie-Hellman-Verfahren zu Grunde liegende Problem des diskreten Logarithmus – Computer können sehr schnell potenzieren, aber das Berechnen des Logarithmus ist laaaaangsam – lässt sich direkt darauf übertragen; ECDH kann DH quasi nahtlos ersetzen. Der Vorteil: bei ECDH genügen bereits 256-Bit-Schlüssel für ein Sicherheitsniveau von 128-Bit; und die doppelt so langen 512-Bit-Schlüssel liefern auch die doppelte Sicherheit von 256 Bit. ECDH ist somit deutlich schneller und effizienter als DH. Die Mathematik dazu ist ebenfalls ausreichend gut erforscht, und auch die europäische Krypto-Elite ist sich weitgehend einig, dass in der Zukunft kein Weg an EC-Verfahren vorbei führt. Aber ...
Die aktuellen Standards für EC-Verfahren wurden von der amerikanischen NIST unter aktiver Mithilfe der NSA entwickelt. Sie enthalten einige frei wählbare Parameter, die irgendwie "vom Himmel fallen" – also ohne nachvollziehbare Begründung in die Standards eingeflossen sind. Nun kann es natürlich sein, dass die NSA wie schon in den 70ern bei DES das Top-Secret-Knowhow ihrer Mathematiker eingebracht hat, um den Standard zu verbessern. Doch die mittlerweile auf die NSA zurückgeführte Hintertür im Pseudo-Zufallszahlen-Generators Dual EC DRBG wirkt nach. Für wahrscheinlicher halten es deshalb viele Experten, dass sie sich wie auch da einen wie auch immer gearteten Vorsprung gesichert haben, der ihnen bei Angriffen auf EC-Verfahren zu Gute kommen wird.
Alternative Curve25519
Der renommierte und streitbare Kryptologe Dan Bernstein hat mit Curve25519 eine Alternative vorgeschlagen, die ebenfalls Diffie Hellman auf einer elliptischen Kurve umsetzt, aber dazu andere Parameter nutzt. Die hat allerdings bislang Mangels Standardisierung keine große Verbreitung gefunden. Das könnte sich jetzt ändern. Mit der soeben veröffentlichten OpenSSH-Version 6.5 unterstützt ein prominenter und viel genutzter Eckpfeiler für kryptografisch gesicherte Verbindungen Curve25519. Sowohl OpenSSH-Server als auch Clients werden Diffie Hellman auf Basis von Curve25519 für den Austausch des geheimen Sizungsschlüssels nutzen (Keyexchange). Darüber hinaus steht mit Ed25519 auch eine Alternative zu DSA und ECDSA für digitale Signaturen und somit für Authentifizierung zur Verfügung; die müssten dann allerdings Anwender und Admins aktiv für ihre Schlüssel auswählen.
OpenSSH war schon häufig Vorreiter was den professionellen und soliden Einsatz von Kryptografie für gesicherte Verbindungen angeht. So war etwa Forward Secrecy durch den Einsatz von Diffie Hellman für den Schlüsselaustausch bei OpenSSH schon viele Jahre lang selbstverständlich – also lange bevor es letztes Jahr für SSL beziehungsweise HTTPS zum Thema wurde. Man darf gespannt sein, ob die OpenSSH-Entwickler auch hier ihrer Zeit voraus sind – und um wie viele Jahre.
Immerhin hat es Curve25519 for Transport Layer Security (TLS) bereits in den Status eines Internet-Drafts der IETF geschafft; angesichts der Geschwindigkeit, mit der sich TLS-Standards ausbreiten – TLS v1.2 wurde 2008 verabschiedet und ist noch nicht sonderlich weit verbreitet – besagt das aber leider nicht viel. Mehr Hoffnung gibt vielleicht, dass Googles Adam Langley, der bereits dafür gesorgt hatte, dass der Suchmaschinenriese Jahre vor der Konkurrenz PFS umgesetzt hat, derzeit offenbar mit Curve25519 experimentiert. (ju)
