SSH, Linux und die stetige Veränderung von Sicherheit – II

In dieser Miniserie von Blog-Beiträgen (s. auch SSH, Linux und die stetige Veränderung von Sicherheit - I/) befasse ich mich ein wenig mit SSH.

Für mich liefert dieses Protokoll im Zeichen der letztjährigen Entwicklungen ein Beispiel dafür, unter welchen Aspekten ein Systemadministrator heute Sicherheitsvorkehrungen einordnen und gestalten muss. Es liefert aber auch ein Beispiel dafür, in welche Schieflage die Diskussion von Sicherheit in der IT insgesamt geraten ist und wie notwendig es wäre, eine grundsätzliche Debatte über die Rolle aller daran Beteiligten, inklusive staatlicher Organe, zu führen. Aber ein Schritt nach dem anderen.

Eine unruhe-weckende Publikation aus dem Jahr 2015

Nach ersten veröffentlichten Ergebnissen im Mai letzten Jahres erschien im Oktober 2015 eine Publikation, die klar und deutlich vermittelte, dass zumindest damalige Implementierungen von TLS, SSH aber auch IPsec/IKE einen gemeinsamen Schwachpunkt aufwiesen. Wer sich regelmäßig um Sicherheitsthemen kümmert, kennt das entsprechende Paper unter dem Titel "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" von Adrian et al., 2015, vermutlich schon. Es kann unter folgendem Link eingesehen werden:
https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf.

Das Paper weist auf Schwächen in bestimmten Varianten des grundlegenden "Diffie-Hellman-Merkle"-Verfahrens [DHM] zur initialen Vereinbarung kryptographischer Schlüssel hin. Das asymmetrische DHM-Verfahren kommt in einer Reihe von Protokollen zur Verschlüsselung von Kommunikationskanälen zwischen Computern zum Einsatz. Passende Übersichtsartikel finden sich unter
https://weakdh.org/
https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html
https://www.schneier.com/blog/archives/2015/10/breaking_diffie.html
https://threatpost.com/prime-diffie-hellman-weakness-may-be-key-to-breaking-crypto/115069/
http://thehackernews.com/2015/10/nsa-crack-encryption.html

Das Interessante an der genannten Veröffentlichung war für mich Folgendes:

  • Sie zeigt auf, dass die Schwäche eines einzelnen grundlegenden kryptographischen Verfahrens Auswirkungen auf mehrere Standardprotokolle für den sicheren Datenaustausch in Netzwerken und im Internet haben kann.
  • Sie verdeutlicht, dass man bzgl. potentieller Angriffsszenarien immer alle Voraussetzungen, Phasen und Umsetzungsebenen der eingesetzten Protokolle im Blick haben muss. Und das schließt letztlich auch die benutzten mathematischen Algorithmen und daraus abzuleitende Konsequenzen ein.

Worum ging es?

Sichere Verbindungen zwischen Computern orientieren sich meist an dem Prinzip, dass das Brechen einer verschlüsselten Sitzung nicht zur Dekryptierung anderer bereits aufgezeichneter Datenströme führen darf. Man spricht auch von sog. "Forward Secrecy".

Ein Ansatz dazu ist die sitzungsspezifische Vereinbarung von Schlüsseln hinreichender Stärke für die anschließende eigentliche Kommunikationsverschlüsselung. Die Computer tauschen hierzu in einer initialen Kommunikationsphase öffentlich zugängliche Informationen und Parameter aus, die dann u.a. zur Berechnung eines gemeinsam genutzten (symmetrischer) Krypto-Schlüssels herangezogen werden. Natürlich muss das sog. "Key-Exchange-Verfahren" [KEX] so sicher sein, dass der Schlüssel aus den ausgetauschten öffentlich zugänglichen Informationen für Dritte NICHT ableitbar ist. Wie man das grundsätzlich erreicht, bespreche ich in einem Nachfolge-Artikel.

An dieser Stelle sind für das Verständnis zunächst nur drei Dinge wichtig, wobei wir uns im Moment mehr um das Wording und nicht um Details kümmern:

  • Das DHM-Verfahren wird von SSH in verschiedenen Ausprägungen genutzt. Darunter gibt es eine sog. FFC-Variante ("Finite Field Cryptography"), in deren Rahmen Gruppen von Parametern als Grundlage des konkreten KEX-Verfahrens ausgetauscht werden. Basis der FFC-Verfahren sind u.a. große Primzahlen und bestimmte multiplikative Operationen auf endlichen Zahlengruppen, die sich durch Modulo-Operationen zyklisch reproduzieren lassen. Die Publikation von Adrian et al. bezog sich auf FFC-Verfahren. Daneben gibt es Verfahren, die Operationen auf sog. "elliptischen Kurven" über definierten Zahlengruppen nutzen (EC : Elliptic Curve; ECC: Elliptic Curve Cryptography). Auch in EC basierten DHM-Verfahren spielen Primzahlen eine große Rolle.
  • In DHM-basierten KEX-Verfahren vom Typ FFC ist u.a. die Größe der Primzahlen (genauer deren Länge in Bits) entscheidend für die Sicherheit des gesamten Verfahrens. Diese Primzahlen und weitere Parameter müssen bestimmte Eigenschaften erfüllen. Sie sind in der Praxis daher Teil sog. vordefinierter Parametergruppen. Ein bestimmtes definiertes DHM-KEX-Verfahren vom Typ FFC nutzt also eine ganz bestimmte Parametergruppe und wird in der Regel auch nach dieser Gruppe bezeichnet. Welche Parametergruppen bereitstehen, hängt u.a. von der Implementierung des Protokolls ab - und nicht zuletzt auch davon, wer aus welchen Gründen solche Parametergruppen erzeugt und empfohlen hat.
  • Die konkrete KEX-Variante, die das SSH-Protokoll über den DHM-Prozess zur Schlüsselvereinbarung für eine bestimmte neue Computer-Verbindung nutzt, ist das Ergebnis eines initialen Verhandlungsprozesses: Das KEX-Verfahren wird von den beiden betroffenen Computer-Systemen nach bestimmten Regeln aus einer Menge möglicher und verfügbarer Verfahren ausgewählt. Die verfügbaren Verfahren können vom Systemadministrator festgelegt oder eingeschränkt werden. Die Auswahl eines konkreten FFC-Verfahrens bedeutet u.a. auch die Auswahl einer bestimmten vordefinierten Parametergruppe.

Bei DHM-KEX-Verfahren geht es also um Methoden, wie zwei Systeme im Vorfeld einer z.B. unter SSH verschlüsselten Kommunikation aus ausgetauschten Parametern einen konkreten gemeinsamen und für Dritte nicht reproduzierbaren Schlüssel für die Kryptierung des nachfolgenden Informationsstroms berechnen können. Das ernüchternde Ergebnis der genannten Untersuchung war, dass es zumindest mit den Ressourcen eines Staates möglich ist, bestimmte FFC-Varianten von DHM-KEX-Verfahren, die 2015 noch in der Praxis benutzt und von Servern angeboten wurden, zu brechen. Nämlich dann, wenn die verwendeten Primzahlen eine bis dato als sicher eingeschätzte Länge von 1024Bit oder weniger hatten. Dies betraf ganz bestimmte, im Einsatz befindliche vordefinierte Parametergruppen.

Ein potentieller Angriff würde sich also nicht gegen das eigentliche Verschlüsselungsverfahren von SSH, sondern auf das initiale KEX-Verfahren richten - mit dem Ziel, den Schlüssel des später eingesetzten, an sich sicheren Verschlüsselungsverfahrens in Erfahrung zu bringen. Bei dieser Attacke lohnt es sich übrigens durchaus, sowohl die initial öffentliche als auch die nachfolgende verschlüsselte Kommunikation für einen spätere Auswertung aufzuzeichnen.

Wer war zur Behebung der erkannten Schwächen zu addressieren?

Nach der Untersuchung von Adrian et al. steht und fällt die Sicherheit sowohl von SSH als auch anderen Protokollen damit, ob die von ihnen kritisierten FFC-Parametergruppen durch das DHM-Verfahren de facto herangezogen werden oder nicht. Hierauf hat u.a. der Systemadministrator durch Konfigurationseinstellungen Einfluss - wenn auch begrenzt. Er muss aber natürlich wissen, dass und wo es da ein Problem gibt und was konkret bei der Konfiguration seines Sicherheitsprotokolls zu tun ist.

Die genannte Untersuchung konnte im Zuge experimenteller Analysen aber auch belegen, dass die im Internet vorfindbaren Implementierungen von SSL/TLS bzw. SSH noch weitere Schwächen bis Fehler aufwiesen. Insgesamt wurde eine Lücke zwischen Erkenntnissen der Kryptographie und der algorithmischen Umsetzung bzw. Implementierung in konkreten SW-Paketen beklagt. Ein wichtiger Nachweis wurde im SSL/TLS-Umfeld durch die sog. "Logjam"-Attacke geführt. Neben Systemadministratoren sind also auch SW-Hersteller - und im Fall von Linux ggf. auch Distributoren anzusprechen. Im Falle von SSH sollten u.a. als schwach erkannte DHM-KEX-Verfahren standardmäßig aus der Implementierung für das jeweilige Betriebssystem ausgeschlossen werden.

Eine erste Reaktion des BSI

Wie ernst wurden nun die Ergebnisse der Untersuchung von offizieller Seite genommen? Man sollte meinen, dass die oben diskutierten Erkenntnisse eine dedizierte, klare und umfassende Warnung auch deutscher Bundesbehörden an Systemadministratoren zur Folge hätten haben müssen. Man würde nach Studium der verfügbaren Unterlagen zudem meinen, dass eine solche Warnung konkrete Hinweise zur Konfiguration u.a. von (Open-) SSH hätte beinhalten sollen.

Nun schielt man bei solchen Fragen in Deutschland auch als Open-Source-Anhänger fast zwangsläufig auf das BSI, das sich jährlich zur Sicherheitslage äußerst und dankenswerter Weise regelmäßig technische Richtlinien für sicherheitsrelevante Verfahren veröffentlicht bzw. aktualisiert. Ich möchte an dieser Stelle einzelne Empfehlungen des BSI gar nicht in Frage stellen. Mir geht es im Moment nur darum, ob die Themen der oben genannten Veröffentlichung in hinreichender Weise aufgegriffen wurden.

In seinem jährlichen Bericht "Die Lage der IT-Sicherheit in Deutschland 2015" vom November 2015 taucht auf S. 16 der Hinweis auf die sog. Logjam-Attake im TLS-Umfeld auf; nachgeordnet wird auch das allgemeinere und aus meiner Sicht wichtigere Thema der generellen Schwäche von KEX-Verfahren zur Festlegung von Kryptierungsschlüsseln unter DHM kurz angesprochen. Zitat: ..." Sie konnten dadurch die beim TLS-Verbindungsaufbau ausgetauschten geheimen Schlüssel nahezu in Echtzeit berechnen. Die Ergebnisse sind auch auf andere Einsatzbereiche dieses Schlüsselaustauschverfahrens übertragbar. Mit einem höheren Aufwand für die Vorberechnungen lassen sich zudem potenziell auch DLP-Fälle lösen, die eher dem Stand der Technik entsprechen. Die französischen Forscher geben beispielsweise Argumente dafür, dass die NSA in der Lage sei, das DLP auf ausgewählten Gruppen zu 1.024 Bit Primzahlen schnell zu lösen." Auf die Publikation von Adrian et. al. wird explizit hingewiesen.

Benannt werden die "anderen Einsatzbereiche" (u.a. SSH, IPSec) aber leider nicht konkret. Vor allem aber Hinweise/Links zu weiteren Informationen bzgl. konkret zu treffenden Maßnahmen bzgl. der Konfiguration dieser Protokolle werden im BSI-Papier unverständlicherweise nicht gegeben.

Die im Februar 2016 erschienene technische Richtlinie BSI TR-02102-1 zum Thema "Kryptographische Verfahren: Empfehlungen und Schlüssellängen" und die Richtlinie TR-02102-4 für SSH sprechen das Thema hinreichender Primzahl- und Schlüssellängen natürlich an und die empfohlenen Längen sind sehr wohl hinreichend. Die Publikation von Adrian et al. wird dort aber leider überhaupt nicht erwähnt. Immerhin drängt die TR-02102-4 darauf, bestimmte KEX-Algorithmen unter SSH nicht mehr zu nutzen oder zumindest in der Priorität herabzusetzen.

Die Richtlinien arbeiten jedoch nicht klar heraus, wer eigentlich einen Einfluss auf die Liste bereitgestellter KEX-Verfahren sowie zugehöriger Parametergruppen und Primzahllängen in bestimmten SSH-Implementierungen hat und wer diese Liste wie begrenzen bzw. wie beeinflussen kann: der Hersteller und/oder der System-Administrator?

Ich finde, solche für die Praxis wichtigen Punkte sollten in einer technischen Richtlinie eigentlich klar und unmissverständlich behandelt werden. Ferner würde ich mir neben grundsätzlichen Empfehlungen auch ein Eingehen auf die wichtigsten am Markt vertretenen Implementierungen wünschen.

Zur anderen Empfehlungen des BSI - im Besonderen zum Einsatz bestimmter sog. "Elliptischer Kurven" als Grundlage von DHM unter SSH später mehr.

Die späte, aber richtige Reaktion des CERT-EU

Das offizielle Europa reagierte mit erheblicher Zeitverzögerung. Das CERT-EU Security Whitepaper 16-002, "Weaknesses in Diffie-Hellman Key Exchange Protocol" vom Juli 2016 (!)
http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_16-002_Weaknesses%20in%20Diffie-Hellman%20Key%20v1_0.pdf
nimmt aber explizit Bezug auf die Ergebnisse der Studie von Adrian et. al.. Deren große Bedeutung auch für SSH, IKE/IPSec etc. wird klar herausgearbeitet.

Die Einordnung des DHM-Verfahrens als kritische und grundlegende Technologie verschiedener sicherheitsrelevanter Protokolle erfolgt aus meiner Sicht klar und deutlich; Zahlen aus der Studie für die verschiedenen betroffenen Sicherheitsprotokolle wurden zitiert. Die Logjam-Attake wurde als TLS-Besonderheit diskutiert. Im Rahmen der weitergehenden Empfehlungen (z.B. zum Einsatz "Elliptischer Kurven-Algorithmen" im Rahmen von DHM) wird explizit auf weitere kritische und aktuelle Untersuchungen hingewiesen. Danach wendet sich das CERT-EU-Papier explizit an Systemadministratoren und gibt Hinweise bzgl. verschiedener betroffene Systeme und Protokoll-Implementierungen - auch und vor allem im Open-Source-Umfeld. U.a. OpenSSH wird ein eigenes Kapitel gewidmet, in dem (relativ) klare Vorgaben enthalten sind.

Einschätzungen

In jedem Fall signalisierte die Veröffentlichung des CERT-EU White Papers eindrücklich, dass man das durch Adrian et al. aufgeworfene Problem ernst zu nehmen hatte - auch und vor allem als normaler Systemadministrator. Die Art der in der Untersuchung von Adrian et al. besprochenen Schwächen der KEX-Verfahren ist zudem nicht geeignet, allein auf Updates zu vertrauen. Man muss sich als Administrator schon um die konkrete Konfiguration von SSH bzw. OpenSSH kümmern. Daran lässt das Cert-EU-Paper kaum Zweifel.

Nach meiner Einschätzung kamen die Bedeutung und die Reichweite der Ergebnisse von Adrian et al. für die Praxis von Systemadministratoren in den BSI-Papieren dagegen leider nicht so recht zur Geltung. In den später aktualisierten technischen Richtlinien TR-02102-1 bzw. -4 kam die Studie gar nicht vor - auch wenn die Vorgaben für FFC-Verfahren (im BSI-Papier unter DLIES-Verfahren zu finden) selbst den Anforderungen aus der Studie Genüge leisten. So blieb der Handlungsbedarf für Administratoren eher unklar. Man hätte als Leser der BSI-Publikationen auch darauf vertrauen können, dass sich die notwendigen Maßnahmen über Updates der SW-Hersteller erledigen würden.

Das White Paper des CERT-EU hingegen zeichnete sich dadurch aus, dass es sich gezielt mit dem Thema DHM befasste (Titel: "Weaknesses in Diffie-Hellman Key Exchange Protocol"). Als Administrator wurde man sozusagen geordnet in Unruhe und danach in Aktivität versetzt. Die Hinweise zu den betroffenen Protokollen und notwendigen Änderungen waren hinlänglich, um sich dann im Detail um die etwa für OpenSSH vorhandenen Konfigurationsmöglichkeiten zu kümmern. Aus den Informationen zu OpenSSH in der damaligen Version ging zudem klar hervor, dass man als Administrator bestimmte KEX-Verfahren explizit ausschließen sollte. Ehrlich gesagt, hätte ich mir eine ähnlich prägnante Publikation von Seiten des BSI gewünscht.

Das Thema Sicherheit umfassend adressieren

Für Administratoren ist die wichtigste Erkenntnis aus der Untersuchung von Adrian et al. die, dass sie gefordert sind, bei der konkreten Implementierung und Konfiguration von SSH entweder bestimmte KEX-Verfahren explizit auszuschließen oder mit eigenen, speziell generierten Parametergruppen zu unterfüttern. Mindestens für letzteres MUSS man sich aber um Vor- und Nachteile kryptographischer Verfahren kümmern. SW-Pakete einzuspielen allein reicht in keinem Fall !

Ich habe das Paper insgesamt jedoch sehr viel weitergehenden Appell verstanden: Die ganze Kette der Herstellung, Bereitstellung, Installation und Konfiguration der heutigen zentralen, sicherheitsrelevanten Protokolle und Verfahren sowie die zugehörige Informationspolitik ist eigentlich einem Review zu unterziehen.

Protokolle wie TLS oder eben SSH erfordern grundsätzlich den Einsatz verschiedener kryptographischer Verfahren, die in unterschiedlichen Phasen der Computerinteraktion für spezifische Zwecke zum Einsatz kommen. Angriffe auf die Sicherheit und Manipulationen sind in allen Phasen der Protokollabwicklung und auf alle Ebenen der eingesetzten Verfahren möglich. Deshalb sind auch zugrundeliegende mathematische Algorithmen zu hinterfragen. Konsequenzen bzgl. deren Implementierung bzw. die konkrete Konfiguration durch den Systemadministrator sind regelmäßig ins Verhältnis zu neuen Möglichkeiten der Kryptoanalyse zu setzen. Die Veröffentlichung von Adrian et al. adressierte letztlich all diese Ebenen; die einleitenden Ausführungen der Autoren stellten für mich auch eine Art Appell dar:

Wenn es um Sicherheit in der IT geht, ist das Zusammenwirken vieler Glieder einer Kette zu betrachten. Und welches das schwächste Glied und an welcher Stelle es zu Manipulationen kommt, ist nicht immer offenkundig. Hinzu kommt: Die Informationsverbreitung zu erkannten Schwächen muss sich in adäquater und expliziter Weise an alle wenden, die etwas zu tun haben, um die Schwächen in der Praxis zu beheben.