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 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 macht, 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 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 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 kritisierten FFC-Parametergruppen durch das DHM-Verfahren de facto herangezogen werden oder nicht. Hierauf hat offenbar auch 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 auch 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 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 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 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 als 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 kryptographische Details kümmern. SW-Pakete einzuspielen allein reicht in keinem Fall !

Ich habe das Paper insgesamt jedoch sehr viel weitergehender 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.

Der nächste Beitrag behandelt am Beispiel von Opensuse, dass Systemadministratoren dabei nicht allein auf Updates des Distributors in Standard-Repositories vertrauen sollten.

Die große Passwort-Sammlung … Wi-Fi Sense unter Win 10

Es ist schon interessant, wie unterschiedlich die im Moment im Entstehen befindliche und am Ende wohl recht umfassende Passwort-Sammlung zu Wi-Fi-Geräten dieser Welt wie auch die zugrunde liegenden "Features" eines seit kurzem auf dem Markt erhältlichen PC-Betriebssystems von Sicherheitsexperten beurteilt werden. Ja, Sie erraten es schon: Es geht um "Wi-Fi Sense" unter MS Windows 10/Windows Phone 8.1.

Siehe hierzu auch

https://grahamcluley.com/2015/08/windows-10-wifi/
http://krebsonsecurity.com/2015/07/windows-10-shares-your-wi-fi-with-contacts/
http://www.silicon.de/41615267/windows-10-sicherheitsexperte-kritisiert-wlan-sharing/
http://www.zdnet.de/88242223/windows-10-wlan-sharing-greift-auf-kontakte-zu/
http://www.spiegel.de/netzwelt/web/microsoft-windows-10-ist-die-neue-wlan-teilen-funktion-sicher-a-1041996.html
http://www.extremetech.com/extreme/209208-windows-10s-new-wifi-sense-shares-your-wifi-password-with-facebook-outlook-and-skype-contacts
http://www.pcgameshardware.de/Windows-10-Software-259581/News/FAQ-zur-WLAN-Passwortfreigabe-1166576/
http://reviews.gizmodo.com/why-the-hell-is-windows-10-sharing-my-wi-fi-passwords-1719900675
http://www.rockpapershotgun.com/2015/07/28/windows-10-wifi-sharing/
http://www.computing.co.uk/ctg/news/2415787/windows-10-wi-fi-sense-security-warning-over-automatically-shared-passwords
https://www.404techsupport.com/2015/06/windows10-network-security-wifisense/
http://www.cnet.com/how-to/how-to-kill-wi-fi-password-sharing-in-windows-10/
http://www.geek.com/microsoft/windows-10-wifi-sense-does-not-share-your-passwords-1630014/
http://money.cnn.com/2015/07/30/technology/windows10-wifi-sense/
http://www.networkworld.com/article/2956393/windows/microsoft-windows-10-wi-fi-sense-an-astoundingly-bad-idea.html
http://arstechnica.com/gadgets/2015/07/wi-fi-sense-in-windows-10-yes-it-shares-your-passkeys-no-you-shouldnt-be-scared/
http://www.pcworld.com/article/2943752/wifi-passwordsharing-feature-in-windows-10-raises-security-concerns.html
https://itauditsecurity.wordpress.com/2015/07/30/no-sense-using-win10-wifi-sense/
http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/
http://www.langer.ws/2015/07/sicherheit-nein-danke-windows-10-teilt-wlan-passwoerter-mit-der-welt/
http://www.golem.de/news/it-sicherheit-windows-10-kann-wlan-passwoerter-an-kontakte-verteilen-1507-115107-2.html
http://www.net-security.org/secworld.php?id=18584

 
Die Beurteilungen reichen von "Desaster" bis hin zu "nützlich" und "doch nicht so gefährlich, weil man schließlich ja etwas dagegen tun könne". Auch wenn ich selbst nie Win 10 auf einem Desktop oder Laptop einsetzen würde, ist das Thema aus einer generellen IT-Sicherheitsperspektive hochinteressant und fordert zur Meinungsbildung geradezu auf. Dazu möchte ich einige Überlegungen beisteuern.

Zunächst mal sei gesagt: Als Internet-Nutzer vertraut man auch anderen Organisationen und deren technischer Präsenz Passwörter an. Aber da entscheide in der Regel ich selbst im Rahmen von Anmeldevorgängen, ob ich anonym bleiben will und welches Risiko ich damit verbinde. Ferner ist die Information, die ich z.B. in einem Forum hinterlasse, genau in dem Maße begrenzt wie ich bereit bin, sie preiszugeben.

Viel wichtiger ist aber aus meiner Sicht: Ich bin bei vielen Internet- und Cloud-Diensten von Haus aus nicht der Illusion ausgesetzt, dass ich Herr über die eingesetzte Technik und die Sicherheit meiner Daten wäre. Es handelt sich nicht um eigene, persönliche und physikalisch greifbare technische Systeme in meinem Besitz. Geht es um gehostete Computer-Systeme wie Server, machen sich interessierte fachkundige Anwender denn auch sehr wohl intensiv mit den Sicherheitsvorkehrungen des Hosters und meinen eigenen Einflussmöglichkeiten auf die Sicherheit vertraut.

Im Falle von PCs oder Laptops unterliegen viele normale Nutzer jedoch der Ansicht, dass dort gelagerte Daten von ihnen selbst kontrolliert würden. Auch wenn dies im Fall von Closed Source Betriebssystemen im Kern natürlich als kaum beweisbare Annahme anzusehen ist - zumindest für den heute fast obligatorischen Fall, dass das Gerät regelmäßig ans Internet angeschlossen wird. In Wirklichkeit wussten/wissen wir ohne explizite Prüfung des Datenverkehrs unserer Systeme nach außen nie, wie privat welche unserer Daten wirklich noch waren oder sind. Die Admins des Bundestages können ein Lied hiervon singen ..ö. aber da ging es um Hacking von Passwörtern und nicht um das Betriebssystem als Passwort-Schleuder.

MS öffnet mit WI-FI Sense aus meiner Sicht nun die Büchse der Pandora für private Netze, PC-Systeme und deren Sicherheit. WI-FI-Sense ist aus Sicherheitsperspektive nicht nur wegen der Verbreitung von MS Win als kritisch anzusehen - sondern vor allem deshalb, weil wir es im Falle von Win 10 mit einer bereits recht weitgehenden Verschmelzung von Internet und PC-Betriebssystem zu tun haben. Das eröffnet einen unschönen Blick auf noch kommende, künftige Cloud-Entwicklungen.

Ich führe nachfolgend einige Gründe für meine wachsende Besorgnis an.

Passwörter zu WLAN-Access Points oder WLAN-Routern sind sicherheitsrelevant

Offenbar ist diese Binsenweisheit beim Design von Win 10 unter den Tisch gefallen. Deshalb nochmal im Klartext:

Passwörter für WLAN/Wi-FI Access Points und/oder WLAN-Router sind u.U. hoch sicherheitsrelevant - nicht nur für den Zugang zum Internet über Wi-Fi-Geräte, sondern für alle angeschlossenen Systeme im betroffenen Netzwerk (WLAN, aber auch per Router angeschlossene LANs) und seinen Segmenten insgesamt. Ich will das gar nicht im Detail begründen; wäre die Aussage falsch, dann hätte man weder WPA2 noch andere Netzwerksegemente, noch spezielle Firewalls für WLAN-Router erfinden müssen. Auch die vielen Artikel, in denen Heimanwender zum Einsatz von WPA/WPA2 aus guten Gründen gedrängt wurden, wären überflüssig. Zeil der Schutzmaßnahmen im Wi-FI-Zeitalter - wie u.a. eine verschlüsselte Passwortübertragung über Funk - war immer die Verhinderung einer unfreiwilligen Preisgabe von Passwörtern an unbefugte Dritte

Ein ungeschützter WLAN-Zugang eröffnet Angreifern eine Vielzahl von Angriffsvektoren auf dahinter liegende Systeme. Ein kluger Anwender, der die Passphrase für den Netzwerkzugang kennt, kann im betroffenen Netz beliebig viel Schaden anrichten, wenn er die dortigen Computersysteme erstmal auf Netzwerkebene direkt ansprechen kann. Dies gilt im Besonderen und gerade für MS-Systeme. Wer es nicht glaubt, mache sich mal mit Metasploit und den dort verfügbaren Tools vertraut.

Aber auch jemand der gar keine PC-- oder Server-Systeme im Netz angreifen will, sondern "nur" den Internet-Zugang selbst über den WI-FI-Access Point einer Firma oder Privatperson für illegale Zwecke (wie illegale Downloads oder aber das Übermitteln von bösartigen Nachrichten)nutzen will, kann erheblichen Schaden mit enormen rechtlichen Folgen anrichten.

Das sind - wie gesagt - Binsenweisheiten. Sie gelten in jedem Fall für Heimnetzwerke, aber leider auch für viel kleine Firmen, die für echte Sicherheitsvorkehrungen in ihren Mini-Netzen mit MS PCs kaum Zeit und Geld aufwenden können. Deswegen ist die Verwahrung und Nicht-Zugänglichkeit von Passwörtern ein hochsensibles Thema - daheim wie im Beruf. Die Weitergabe von Passwörtern für WLAN-Zugangspunkte und Router ist schon im privaten Bereich eine sehr persönliche Entscheidung und Vertrauenssache - in kleinen Firmen ist sie in jedem Fall sicherheitskritisch.

MS stellt diese Binsenwahrheiten jedoch mit den Standardeinstellungen von Win 10 auf den Kopf:

Wenn einem Betriebssystem für einen PC ( "Private (!) Computer") in der Standardeinstellung nicht einmal mehr Passwörter heilig sind, die den Zugänge zu offenkundig sicherheitskritischen technischen Systemen, welche sich in meinem Besitz und Zugriff befinden, eröffnen, und wenn solche Passwörter in der Standardeinstellung (!) des Systems in die Cloud verlagert und ggf. sogar durch ganze Gruppen von Dritten "geshared" werden, dann fragt man sich, welches Verständnis von Privatsphäre und Sicherheit die Erfinder eines solchen Systems überhaupt haben.

Jedenfalls ist dieses Verständnis nicht vom elementaren Prinzip "privacy by design" für Software und Betriebssysteme geleitet. Der "Standard" ist in Zukunft bei MS offenbar: Share everything with me and also third parties - ich nutze deine privaten Daten (s.u.) und verwalte zudem auch Passwörter für deine technischen Geräte in der Cloud - genauer auf MS-Servern. Zudem sorge ich dafür, dass auch andere diese Passwörter nutzen können, wenn du oder ein Dritter (s.u.) diese Passwörter an andere verteilen wollen. Ich sage dir aber nicht, was genau ich für die Sicherheit deiner Daten tue.

Die Gefahr durch unbedarfte oder böswillige Dritte

Ein entscheidender Punkt der Kritik ist nicht allein der Transfer von sicherheitsrelevanten Passwörtern durch ein Win 10 System über das Internet auf die Server des Betriebssystemherstellers. Hinzu kommt, dass ich selbst dann potentiell betroffen sein kann, wenn ich Win 10 gar nicht benutze:

Es reicht, einem Mitarbeiter/Bekannten, der sich mit einem Win10-Gerät (und möglicherweise sogar Smartphone mit Win 8.1) in Reichweite meines WLANs befindet, die Nutzung meines eigenen WLAN Access Points oder WLAN-Routers zu gestatten und ihm hierzu das Passwort "im Vertrauen" mitzuteilen. Das Passwort findet auch dann seinen Weg in die Cloud und wird ggf. von meinem Bekannten mit anderen geteilt. Auch wenn das Passwort selbst für die Beteiligten nicht direkt sichtbar ist, bleibt doch Fakt: Das Passwort ist von Dritten und Vierten einsetzbar, wenn ich es einmal einem Bekannten, der Win 10 Benutzer ist, für den Zugang zum WLAN gegeben habe. Selbst, wenn der betreffende Bekannte das gar nicht will oder weiß - aber mit der Standardinstallation von Win 10 auf seinem Wi-Fi fähigen Gerät wurde die Sache auf den Weg gebracht. Siehe für die Details die oben angegebenen Artikel, u.a. :
https://grahamcluley.com/2015/08/windows-10-wifi/

Dies bedeutet, dass ich die Kette der Personen, die ggf. ungewollt in den Besitz meines Passwortes gelangen, nicht mehr kontrollieren kann.

So wird dann etwa der Angestellte, der das lokale Firmen-WLAN auch schon mal mit dem privaten Laptop nutzt, weil er ja das Passwort kennt - und weil ggf. der Admin seinen Job bzgl. der Firewall nicht ordentlich gemacht hat - schon mal gewollt oder ungewollt zum Sicherheitsrisiko. Und denjenigen, die meinen, das Problem über MAC-Filter auf ihren Access Points oder WLAN-Routern lösen zu können, sei gesagt: Es gibt kaum etwas, das leichter und schneller zu fälschen ist als eine MAC-Adresse.

Will man sich gegen Wifi-Sense schützen, so muss man lt. MS seine SSID abändern und den Zusatz "_optout" hinzufügen. Ich empfinde das einerseits als Zumutung - wegen eines Upgrades eines PCs muss die Bezeichnung von Netzen geändert werden - wo sind wir denn? Andererseits: Woher weiß ich als Privatanwender oder Admin eigentlich, dass ich mich auf diese Vorgabe von MS dauerhaft verlassen kann?

Glauben statt überprüfbare Sicherheit

Zudem ist ja überhaupt nicht klar, welche Sicherheitsmaßnahmen MS eigentlich genau für den Transfer durchs Internet oder für die Lagerung auf den MS Servern einsetzt und was diese Maßnahmen wert sind.

De facto wird also mit der Standardinstallation von Win 10 "Sicherheit" für den Anwender durch "Glauben" des Anwenders an hinreichende Maßnahmen des Betriebssystem-Herstellers wie auch die Ver- und Bewahrung meiner Daten gegenüber Dritten ersetzt. Bin ich ganz naiv, "glaube" ich dann auch daran, dass meine Daten nicht (kommerziell) verwertet werden.

Die krude Grund-Haltung zur Sicherheit ist bei Win 10 wenigstens konsistent umgesetzt - denn Win 10 überträgt bekanntermaßen ja auch massenweise private Daten zur Nutzung des Systems, IT-Konten jeder Art, Freunden, Adressen, etc. auf eigene Server. Siehe für entsprechende Internet-Links etwa:
http://linux-blog.anracom.com/2015/08/11/win-10-linux-im-namen-der-informationellen-selbstbestimmung/

Insgesamt verfestigt sich beim Lesen aktueller Publikationen der Eindruck, dass MS mit Win 10 zumindest die elementare Regel für sichere SW - nämlich "privacy by design" - nicht nur im Bereich Wifi-Sense ignoriert. Nun gut, MS ist weiß Gott nicht allein, wenn es um die Abschaffung von Privatsphäre über die Cloud geht. Aber durch die Verlagerung und die potentiell einkalkulierte Verbreitung von sicherheitsrelevanten Passwörtern ist hier schon von einer Orwell'schen Umdefinition der Begriffe "Sicherheit" und Privatsphäre" auszugehen, die ich persönlich keinesfalls teilen kann.

Verschmelzung von Betriebssystem und Cloud

MS Win 10 ist ein Betriebssystem, in dem PC und Cloud "erstmalig" eng miteinander verschmolzen werden sollten. Nun ist die "Cloud" ja keineswegs etwas Abstraktes - es handelt sich i.d.R. um Server-Konglomerate, die jemandem gehören und von jemandem verwaltet werden. In unserem Fall von MS.

Das vorliegende Ergebnis der Cloud/Betriebssystem-Verschmelzung verheißt in puncto IT-Sicherheit jedenfalls nichts Gutes für die Zukunft: Wenn MS schon bestimmte Passwörter für technische Geräte, deren Sicherheit für die Netz-Infrastruktur daheim oder in der Firma essentiell sind, auf eigene Server verschiebt, warum sollte ich dann eigentlich daran glauben, dass dies in Zukunft nicht auch mit anderen Passwörtern passiert?

Genauer betrachtet ist das ja sowieso das ultimative Cloud-Ziel: Der Anwender lädt sein "Betriebssystem" in Miniform aus dem Netz auf einen Thin-Client herunter - alle wesentlichen Programme laufen aber auf Servern des Betriebssystem-Providers. Dann liegt die Passwortverwaltung auf den Cloud-Servern zwingend nahe. MS WIN 10 ist ein Schritt in diese Richtung. Voraussetzung für derartig umfassende Cloud-Dienste sollten jedoch immer klare Verträge und ein hinreichender Kenntnisstand des Anwenders sein.

Der Unterschied zur jetzigen Situation ist der:
Bislang glaubten wir, dass Passwörter auf unseren lokalen PCs liegen - und zwar verschlüsselt und für andere nicht nutzbar. Unter Linux kann ich das prüfen - unter MS Win nur partiell. Wir gingen ferner davon aus, dass Dritten die Passwörter nicht zugänglich gemacht werden. Unter Win 10 gilt dies zumindest für wichtige technische Infrastrukturkomponenten schon nicht mehr. Hinzu kommt, dass diese Änderung in der verlockenden Form eines kostenfreien Betriebssystem-Upgrades an den unaufgeklärten Anwender herangetragen wird, der natürlich auf Standardeinstellungen während des Installationsvorgangs vertraut.

Wäre MS WIN vollständig in die Cloud verlagert, so könnte der Benutzer das Risiko des Passwortverlagerns und -sharens mit andern Internetkonten vermutlich besser einschätzen. Im Falle der Verführung zu einem kostenfreien Upgrade seines "Privaten Computers" kann man sich fragen, ob die Masse der Anwender die substanzielle Änderung einer bislang etablierten Sicherheitspolitik bzgl. der Handhabung von Passwörtern überhaupt wahrnehmen.

Der Privatanwender ist meist überfordert

Vielleicht stimmt es ja, das man zumindest im Prinzip etwas gegen den Transfer der sensiblen Wi-FI-Passwörter zu MS Servern tun kann. Viele der oben angegebenen Artikel zeigen ja auf, was man gem. der Angaben von MS (!) dafür tun muss. Es stellt sich einem dennoch die Frage: Wer ist denn im Alltag des privaten Anwenders "man"? Ist "man" denn wirklich zu effektiven Gegenmaßnahmen fähig?

"Man" ist wohl letztlich er - also der Anwender - selber ... Damit wird aber weltweit Privatsphäre und Sicherheit vom Ausbildungsstand und dem (technischen) Wissen der Anwender abhängig gemacht. Meine Erfahrung mit Standard-Windows-Benutzern in meinem Bekanntenkreis ist leider: Die meisten sind bereits mit viel einfacheren Dingen als den Schritten zur Anstellung von Wi-Fi Sense überfordert - und haken in der Regel Systemrückfragen im Rahmen einer Betriebssysteminstallation einfach ab, weil sie die Sicherheitsimplikationen nicht übersehen können oder wollen ...

Gewiss: Große Firmen werden Wifi-Access Points mit zentralen Auth-Verfahren über z.B. 802.1x, EAP und Radius-Servern verbinden und damit zunächst (hoffentlich) vor Wifi-Sense geschützt sein - aber ich kenne haufenweise kleinere Firmen, die mit konventionellen WPA/WPA2 auf WLAN-Routern (z.B. Fritzboxen von AVM) arbeiten. Die sind somit alle potentiell von den neuesten "Segnungen" des Marktführers für Desktop-Systeme betroffen ....

Deswegen ist insgesamt davon auszugehen, dass MS beim Aufbau seiner weltumfassenden Datenbank für Wi-Fi-Passwörter letztlich Erfolg haben wird, zumal alle unsere lieben Freunde, Verwandte und Bekannte ja zur (ungewollten und unbewußten) Verbreitung von Wifi/WLAN-Passwörtern beitragen können - selbst wenn man selbst gar nicht WIN 10 benutzt.

Was haben wir da also eigentlich vor uns?

Die Verbreitung von Win 10 ist aus meiner Perspektive und aus den genannten Gründen mit einer Maschinerie gleichzusetzen, die u.a. dem Aufbau einer der größten Passwort-Datenbanken der Welt auf amerikanischen Servern dient. Hinzu kommen technische Informationen über die WIFI-Ausstattung weltweit. Die Datenübertragung und Verschlüsselung findet zudem über die SW eines Unternehmens statt, von dem einige Experten schon in der Vergangenheit bezweifelt haben, dass Datensicherheit die Top-Leitlinie des technischen und kommerziellen Handelns ist.

Mal abgesehen davon, welche mächtige Position MS selbst durch eine solche Datenbank erhält .... Wir müssen - ganz unabhängig von MS's Sicherheitsvorkehrungen - in jedem Fall mit Fug und Recht annehmen, dass eine solche Datenbank für Passwörter und technische Information zu WI-FI-Netzen und die Übertragungswege zu dieser Datenbank für viele Organisationen - darunter auch verbrecherische - von größtem Interesse sein dürfte. Den finanziellen Wert einer solchen Datenbank kann man gar nicht überschätzen. Sie ist sicher sehr viel mehr wert als ein paar Steuersünder-CDs. Im schlimmsten Fall ist es deshalb wohl nur eine Frage der Zeit, bis irgendein Böser entweder die Wifi-Sense Transfer-SW in Win 10 oder Win Phone 8.1 knackt oder Zugang zu der Wifi-Sense Datenbank selbst erhält.

Was sollte man also als Firma oder kundiger Anwender eines komplexeren Heimnetzes tun?

Als sicherheitsorientierter Admin wird man dafür sorgen, dass man von der ganzen potentiellen Misere möglichst gar nicht betroffen ist. Die eigentlich richtige Konsequenz, nämlich Win 10 in der Home-Version gar nicht erst zum Einsatz zu bringen, stellt sich für viele Admins kleiner Firmen leider von Haus aus nicht.

Netzwerksegmentierung
Aber auch in einer MS dominierten Welt zeigen so elementare Sicherheitsregeln wie die strikte Separation von Netzen/Netzwerksegmenten mit öffentlich zugänglichem Access Point (z.B. für externe Mitarbeiter) einerseits von privaten oder firmeninternen Netzen/Netzwerksegmenten andererseits Wirkung. Diese fundamentale Regel gewinnt mit Win 10 an Bedeutung - und ist technisch angemessen umzusetzen.

Ob einem Admin das aber rechtlich wirklich hilft, wenn etwa ein böser Facebook-Freund eines externen Mitarbeiters oder Freundes in Zukunft den öffentlichen Wifi-Zugang zum Internet einer Firma für illegale Zwecke nutzt, sei mal dahingestellt ....

Passwortwechsel
Eine weitere elementare Regel ist deshalb schlicht das häufige, nicht vorhersehbare Wechseln von Passwörtern zu den zu administrierenden Wireless-Netzen.

MAC-Filter
Zugangsfilter auf MAC-Ebene sind nur begrenzt wirksam und schrecken echte Hacker nicht ab. Aber warum nicht?

Zentralisierte Authentifizierungsverfahren über 802.X1
Ferner sieht es zur Zeit wohl (noch) so aus, dass MS die Finger von Passwörtern zu WIFI/WLAN-Access Punkten oder -Routern lässt, bei denen die Authentifizierung über zentrale Systeme läuft. Für Firmen, die mit Gedanken spielen, Win 10 Clients einzusetzen oder Win 10 Clients Zugang zum WLAN zu geben, kann die technische Devise im Moment wohl nur so lauten:

Weg von direkter WPA2/WPA-Authentifizierung gegenüber dem WIFI/WLAN-Access Point/Router und statt dessen hin zum Einsatz zentraler Authentifizierungsverfahren über IEEE 802.1x, EAP, Radius Server. Etliche WLAN AccessPoints/Router unterstützen schon seit längerem "WPA2 Enterprise", das solche Lösungen ermöglicht. Leider aber z.B. nicht die Produkte des Marktführers in Deutschland für die breite Allgemeinheit - nämlich AVMs Fritzboxen - und dies trotz mehrfacher Aufforderung von besorgten Anwendern. Aber es gibt ja Alternativen für Access-Points auch im preiswerten Consumer-Segment und Sicherheit sollte auch in kleinen Firmen eine überschaubare Investition wert sein ....

Flankiert müssen Vorkehrungen zur zentralen Authentifizierung in WLANs allerdings auch

  • durch umfassende Aufklärung der Win 10 Nutzer,
  • das systematische Abstellen von Wi-Fi-Sense auf Geräten, die wir kontrollieren können
  • sowie durch rigide Policies zur Wi-Fi/WLAN-Nutzung im Unternehmen.

Kein BYOD für WIN 10 Geräte
Ich war noch nie ein Freund von BYOD - aber "Bring your own (!) Win 10 Device or Win 8.1 Mobile Device" ist in einer Firma mit Sicherheitsanspruch sicher keine gute Idee.

Überwachung ausgehenden Datenverkehrs
Und wenn man sich auf Dauer nicht auf die Versicherung von MS verlassen will,dass 802.1X-Netze unangetastet bleiben, wird man wohl nicht darum kommen, ausgehenden Netzwerkverkehr von Win 10-Systemen daraufhin zu kontrollieren. Ich denke, es wird nur einen Frage der Zeit sein, bis entsprechende automatisch verwertbare Muster für den Datentransfer bekannt werden.

Konsequenz für Sicherheitsaudits

Das Feature "Wifi-Sense" von Win 10/Win Phone 8.1 sollte im Risiko-Management von Firmen und in zugehörigen Sicherheits-Audits einen festen Platz bekommen. In Kombination mit der Upgrade-Politik ist das Thema sogar ein idealer Prüfstein dafür, ob das Risiko-Management im Rahmen des Change Managements für das technischen Umfeld hinreichend funktioniert.

Ein paar Links zu 802.1X, EAP, Radius:

 

IT-Sicherheit und Zufallszahlengeneratoren – III

In den letzten beiden Artikeln dieser Miniserie

IT-Sicherheit und Zufallszahlengeneratoren – II
IT-Sicherheit und Zufallszahlengeneratoren – I

habe ich ein paar Ausführungen zu der Frage gemacht: "Warum sind Zufallszahlen hoher Qualität wichtig?". Im letzten Beitrag bin ich am Beispiel der Programmiersprache "PHP" darauf eingegangen, dass SW- und Web-Entwicklern in den Standardbibliotheken ihrer Sprachen oftmals keine software-basierten Zufallszahlen-Generatoren [PRNGs] zur Verfügung stehen, die eine hinreichende Qualität der Zufallszahlenverteilung liefern.

Ein Maß für die Qualität von Zufallszahlen ist die sogenannte statistische "Entropie". Je höher diese Entropie ist, desto besser erfüllt die Verteilung der Zufallszahlen in einem Zielraum die Kriterien einer vollständig musterfreien statistischen - also zufälligen - Verteilung. [In der physikalischen Natur erfüllen vor allem bestimmte Quantensysteme die Ansprüche an eine Abfolge rein zufälliger Ereignisse, die mit einer statistischen Verteilung von Meßwerten maximaler Entropie versehen sind.

 
Ich hatte im zweiten Artikel ein Beispiel aus meiner eigenen praktischen Erfahrung zum Einsatz eines PHP PRNG-Verfahrens erwähnt, in dem die Entropie völlig unzureichend war. Im Beispiel nutzten Spammer ihre Kenntnisse über den Einsatz eines bestimmten PRNG-Algorithmen in einer Web 2.0-Anwendung, um nach einer einfachen statistische Analyse für ein Captcha-Verfahren zuverlässige Vorhersagen der generierten alphanumerischen Sequenzen zu machen.

Ich möchte in diesem Artikel nun exemplarisch ein paar weitere Sicherheitsverfahren auflisten und kurz andiskutieren, bei denen der statistische Zufall auf die eine oder andere Weise besonders bedeutsam für die IT-Sicherheit ist. Im Falle der für die moderne IT so bedeutsamen Kryptierungsverfahren gehe ich dabei auch kurz auf potentielle Bedrohungen ein.

Den Abschluss bilden Links zu vielen Artikeln, die ich mir bei der einen oder anderen Gelegenheit mal zum Thema Zufallsgeneratoren und Kryptographie zu Gemüte geführt habe. (Leider und interessanterweise musste ich bei der Gelegenheit feststellen, dass früher funktionierende, öffentlich zugängliche Links zu vielen guten und interessanten Kursunterlagen amerikanischer Universitäten in den letzten Monaten deaktiviert oder mit Zugangsschutz versehen wurden.)

Passwörter und "Zufall"

Das einfachste Beispiel für ein letztlich auf pseudo-statistischen Methoden beruhendes Sicherheitsverfahren liefert der Passwortschutz für Daten oder Applikationen. Der Algorithmus ist hier stocksimpel:

Wenn das übergebene Passwort mit einem Vergleichswert übereinstimmt, wird der Zugang zu einem Geheimnis (schutzbedürftige Daten) oder zu einem sicherheitsrelevanten Verfahren gewährt. Je länger und komplexer ein Passwort ist,

  • umso geringer ist vordergründig die statistische Wahrscheinlichkeit, das Passwort zu erraten
  • und umso höher schätzt man subjektiv den Aufwand ein, es durch systematisches Durch-Probieren ["Brute Force" Angriff] von lexikalischen Wörtern mit Ergänzungen oder systematische Variation von Zeichen unter Berücksichtigung menschlicher und sprachbezogener Häufigkeitsverteilungen zu finden.

Diese Argumente ziehen in Wirklichkeit aber nur bei einer wirklich zufälligen Verteilung der genutzten alphanumerischen Zeichensequenzen. Das Zufallselement liegt hier beim Erzeuger des Passwortes selbst. Im Idealfall bedient sich der Passwort-Erzeuger eines statistischen Generators für die alphanumerische Zeichensequenz des Passworts. Ein solches Vorgehen fördert aber nicht gerade die Merkbarkeit der vielen Passwörter, die man im heutigen IT-Alltag benötigt.

Die statistische Verteilung der durch Menschen erzeugten Passwörter ist allein schon aus diesem Grund in den seltensten Fällen wirklich zufällig. Zudem ist die Zufälligkeit sehr durch Merkmale einer Spache, durch allzu menschliche Sprach-, Lebens- und Merkgewohnheiten, psychologische Gesetzmäßigkeiten sowie natürlich durch die begrenzte Länge der Passwörter/Passphrases eingeschränkt.

Deshalb ist das "Cracken" von Passwörtern für Angreifer durch "Brute-Force-Methoden", in denen menschliche Gewohnheiten berücksichtigt wurden, leider oft erschreckend einfach.

Warum ist diese Erkenntnis von fundamentaler Bedeutung?
Auch der sichere, praktische Einsatz vieler Kryptoverfahren - wie etwa PGP - hängt letztlich von Passwörtern - etwa von Passwörtern zum Öffnen privater Krypto-Schlüssels aus einer Verschlüsselungshülle oder aber von Zugangspasswörtern zu Datenspeichern für die privaten Schlüssel - ab. Es nutzt deshalb nichts, hochsichere Datenverbindungen zwischen Computersystemen im Internet aufzubauen oder Mails zu verschlüsseln, wenn der eigene Computer, der eigen Router oder die privaten Kryptoschlüssel selbst nur durch einfach zu erratende Passwörter/Passphrases geschützt sind. Siehe auch:

http://iso-blog.anracom.com/2013/10/open-source-sicherheit-und-die-sicherheit-des-umfelds/
http://iso-blog.anracom.com/2013/12/sind-asymmetrische-verschlusselungsverfahren-irgendwie-sicherer/

Wir stoßen hier also wieder auf einen generellen Punkt, den wir schon im ersten Artikel aufgegriffen hatten:

Auch bei Kryptoverfahren, in denen Schlüssel auf der Basis von hochwertigen RNGs erzeugt werden, ist die technische Verfahrenssicherheit insgesamt letztlich von der sicheren Verwahrung der privaten Keys - also vom sicherheitstechnischen Umfeld (Betriebssystem, Malware und Intrusion-Schutz, verschlüsselte Ablage, etc.) abhängig. Einen unrühmlichen Beleg für diese Tatsache lieferte zuletzt das Malheuer im Bundestagsnetz. Die Sicherheit auch komplexester Verschlüsselungsverfahren ist in der technischen Einsatzpraxis oft auf elementare Verfahren wie Passwortschutz zurückgeworfen und kann daher of t indirekt über ein unsicheres Einsatzumfeld angegriffen werden.

Es sollte einem daher immer bewusst sein: Auch eine hohe Qualität von Zufallszahlen als Basis von eingesetzten Sicherheits- und Verschlüsselungsverfahren allein erzeugt noch keine hinreichende IT-Sicherheit.

Deshalb müssen Zertifizierungs- und Prüfverfahren zur IT-Sicherheit zwingend immer die gesamte Kette von Sicherheitsvorkehrungen in einem Einsatzumfeld betrachten.

Kryptographie-Verfahren, Schlüsselgenerierung und Zufallszahlen

In Kryptographieverfahren werden Schlüssel und (symmetrische oder asymmetrische) Verschlüsselungsverfahren benutzt, um aus normalen Texten unleserliche "kryptierte" Texte zu erzeugen. Ein potentieller Gegner darf den erforderlichen Schlüssel für das kryptierte Geheimnis selbst dann nicht ermitteln können,

  • wenn er Einsichtnahme in einen abgefangenen kryptierten Text bekommt,
  • wenn ihm das eingesetzte Krypto-Verfahren bekannt sein sollte oder er es erraten sollte,
  • wenn er zusätzlich die Möglichkeit hat, das eingesetzte Krypto-Verfahren auf vorgegebene Texte wiederholt anzuwenden und die resultierenden Ergebnisse mit aufwändigen statistischen Methoden nach Mustern zu analysieren.

Der erste Punkt ist trivial. Er beschreibt das zu erreichende Ziel des Einsatzes eines Kryptoverfahrens. Die eigentliche Herausforderung liegt in den letzten beiden Punkten. Auch wenn das Krypto-Verfahren vom Gegner für vorgegebene Texte sehr, sehr oft - bei den heutigen Möglichkeiten hunderte Millionen oder Milliarden mal - auf bekannte Texte angewendet wird, dürfen sich keine Anhaltspunkte (Muster) ergeben, die Hinweise auf die Schlüsselstruktur oder Schlüsselzusammensetzung liefern.

Umgekehrt darf auch das Einsetzen systematisch generierter Schlüssel in den Dekodierungsalgorithmus des bekannten Verschlüsselungsverfahrens nicht zu einem Erraten des Schlüssels in endlicher Zeit führen. Beachte: Da IT-Kryptoverfahren algorithmisch arbeiten, wäre eine Forderung nach beliebiger Wiederholbarkeit letztlich sinnlos. Was aber heißt "sehr, sehr oft"? Das misst sich an den heutigen technischen Möglichkeiten:

Das Erkennen eines Musters oder das Erraten des Schlüssels darf bei Einsatz heutiger Supercomputer nicht mit einer signifikanten, sondern nur verschwindend kleinen Wahrscheinlichkeit möglich sein. Der Aufwand für ein systematisches Probieren muss in Hochsicherheitsumgebungen also auch angesichts der Leistungsfähigkeit von Supercomputern extrem hoch werden. Das wiederum bedeutet:

Der Schlüssel des eingesetzten Kryptoverfahrens muss durch durch ein geeignetes Verfahren aus der Menge aller möglichen Schlüssel statistisch und auch bei extrem vielen (!) Wiederholungen zumindest aus der Sicht von Analysatorprogrammen hinreichend "zufällig" ausgewählt werden.

In Verschlüsselungsverfahren spielt deshalb die Erzeugung von Zufallszahlen als Basis der Erzeugung zufälliger Schlüssel - im Sinne einer programmtechnischen ablaufenden Auswahl zufälliger Schlüssel aus der Menge aller möglichen Schlüssel - eine zentrale und eminent wichtige Rolle.

In der technischen Praxis ist deshalb für die Qualität von Kryptoverfahren die Verfügbarkeit hochwertiger Zufallszahlengeneratoren oder aber der Zugriff auf eine Zufallszahlenquelle hoher Entropie bei der Generierung der Krypto-Schlüssel ausschlaggebend. Ein Mangel an Entropie kann in diesem Zusammenhang nicht oder nur schwer durch andere oder zusätzliche Verfahrenseigenschaften ausgeglichen werden (siehe zu evtl. Maßnahmen 2 Links am Ende des Artikels).

Eine interessante Frage ist in diesem Zusammenhang übrigens, wie groß eigentlich die Menge der potentiellen Schlüssel im Vergleich zur Länge (Zeichenanzahl) der zu kryptierenden Texte sein sollte. Hierfür muss ich wegen der mathematischen Komplexität aber auf die Fachliteratur - s. die Links am Ende des Texts - verweisen.

Alle guten Verschlüsselungsverfahren erhöhen jedenfalls unter Nutzung eines statistischen Inputs hoher Entropie und unter Ausnutzung mathematischer Verfahren (Stichworte: Primzahlfaktorisierungsproblem für Produkte aus hinreichend großen Primzahlen) den Aufwand, der von einem Angreifer bei systematischen Versuchen und bekanntem Algorithmus durchzuführen ist, um durch systematische Analyse oder Probieren einen Zugang zur verschlüsselten Informationen zu bekommen. Ferner ist im Zuge einer konkreten technischen Implementierung eines Krypto- oder Sicherheitsverfahrens dafür zu sorgen, das ein systematische, wiederholtes Ausprobieren von Schlüsseln am angegriffenen System wirksam behindert wird.

Bedrohung etablierter Kryptographieverfahren?

Nebenbei lernen wir so auch, durch welche Umstände die Sicherheit von Kryptoalgorithmen systematisch bedroht werden kann. Stichworte sind:

  • Unzureichende mathematische Verfahren als Basis des Verschlüsselungsalgorithmus.
  • Gezielte Verwässerung der technischen Umsetzungsvorgaben für die praktische Implementierung von Kryptoalgorithmen unter bestimmten Betriebssystemen.
  • Unzureichende Prinzipien der technischen Zufallszahlengenerierung (im besonderen bei Einsatz von SW-PRNGs) und/oder fehlender Zugriff auf eine Quelle von Zufallszahlen hoher Entropie.
  • Schlampige Absicherung des Umfelds / menschliches Versagen in der Praxis.
  • Unterschätzung der Leistung moderner Supercomputer und begrenzte Länge von Schlüsseln.
  • Eine zufällige oder gezielt herbeigeführte Kombination aus allen genannten Defiziten.

Ich hatte mit Hilfe diverser Links schon im letzten Artikel angedeutet, dass man womöglich ein Fragezeichen hinter die Zuverlässigkeit des im Internet so wichtigen SSL/TLS-Verfahrens setzen konnte und kann.

Um ein Gefühl dafür zu bekommen, welche sonstigen Methoden und Techniken zur Korrumpierung von Verschlüsselungsverfahren (u.a. durch Ausnutzung einer unzureichenden Zufallszahlen-Entropie) - aus welchen guten oder schlechten Gründen auch immer - für möglich erachtet werden, sei auf folgende Links hingewiesen:

http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0
http://blog.cryptographyengineering.com/2013/09/on-nsa.html
http://www-cs-faculty.stanford.edu/~eroberts/cs201/projects/ethics-of-surveillance/tech_encryptionbackdoors.html
 
http://rt.com/usa/nsa-weak-cryptography-rsa-110/
http://www.heise.de/security/meldung/Mehr-Details-zur-Hintertuer-im-Zufallszahlengenerator-Dual-EC-DRBG-2159523.html
http://www.heise.de/security/meldung/NIST-beerdigt-umstrittenen-Zufallszahlengenerator-Dual-EC-DRBG-2731747.html

http://securityaffairs.co/wordpress/17577/intelligence/nsa-bullrun-program-false-perception-security.html
http://www.newyorker.com/online/blogs/elements/2013/09/the-nsa-versus-encryption.html

 
Dass heute auch in internationale Zusammenarbeit (z.B. unter Nicht-EU-Staaten) zur gezielten Dekodierung verschlüsselter Dateninhalte investiert wird, deuten beispielsweise folgende Artikel an:

 
Für mich ist im Kontext des hier behandelten Themas gar nicht die ethische oder politische Kritik an den in den Artikeln angesprochenen Vorhaben und Maßnahmen relevant. Viel wichtiger erscheint mir die Feststellung, dass offenbar überhaupt an der (massenweisen ?) Dekryptierung von Daten, die mit modernen, mathematisch fundierten Verfahren verschlüsselt wurden, gearbeitet wird. Man kann das u.a. als Hinweis darauf deuten, dass es in der Praxis mit der Qualität der heute eingesetzten Zufallszahlenverfahren oder Zufallszahlen-Quellen wohl nicht so weit her sein dürfte.

Gute Quellen von Zufallszahlen als nationale Aufgabe?

Die obigen Artikel verdeutlichen im Umkehrschluss auch, warum man die Bereitstellung hochwertiger Zufallszahlengeneratoren und Zufallszahlenquellen als Aufgabe mit größter Bedeutung für Staaten und die sie tragende Informationsgesellschaft - im Besonderen im Kontext eines zunehmenden E-Governments - verstehen kann und muss. Ein Beispiel hierfür liefert etwa der angemahnte Einsatz von hochwertigen Zufallszahlen im Zusammenhang mit dem deutschen Signaturgesetz:

 
Wichtige Arbeit im Zusammenhang mit Kryptoalgorithmen und zugehörigen RNGs leistet hierzulande u.a. das BSI, das auch Empfehlungen herausgibt:

 
Leider klappt es anscheinend und womöglich auch bei bestem Willen mit der Bereitstellung hochwertiger PRNGs nicht immer ganz so wie gewünscht. Auch bzgl. empfohlener Prüfverfahren zur Qualität von Zufallszahlen stellen interessierte Zeitgenossen offenbar Fragen:

 
Das alles zeigt nur, wie wichtig eine ständige Kontrolle publizierter Verfahren durch unabhängige Fachkundige wohl ist. Zumindest punktuell fördert das BMI Forschung im Bereich der Zufallszahlengenerierung:

 
Egal wie man zu den bisher zitierten Artikeln und ihren Inhalten steht: Als Fazit aus den zusammengestellten Links dürfte hoffentlich sehr deutlich geworden sein, dass gerade Krypto-Algorithmen ohne Quellen hoher Entropie für Zufallszahlen wenig wert sind.

Hashes

Interessant ist im Zusammenhang mit den oben bereits erwähnten Passwörtern auch die maschinelle Erzeugung von sogenannten "Hashes":

Hier besteht einer der Einsatzbereiche u.a. darin, ein Passwort oder gar eine Signatur durch einen "one-way"-Algorithmus so in eine scheinbar zufällige, aber eindeutige Folge von Zeichen zu verwandeln, dass man selbst bei bekanntem Erzeugungsalgorithmus aus der erzeugten Sequenz das ursprüngliche Passwort nur mit gigantischem Aufwand zurück ermitteln kann. Den erzeugten Hash-String kann man dann immer noch mit dem Hash vergleichen, der aufgrund eines in einem sicherheitsrelevanten Verfahren eingegebenen Passwortes oder einer elektronischen Signatur erzeugt wird.

Auch hier hängt die Sicherheit von 2 Faktoren ab:

  • Der mathematischen Qualität des Hashing-Algorithmus,
  • aber ganz offenkundig auch von einem zusätzlichen Zufallsinput in den Hash-Algorithmus selbst.

Denn die Hash-Generierung darf einerseits keine Muster aufweisen und sie muss andererseits auch "kollisionsfrei" sein: zwei unterschiedliche Imputs (Passwörter) dürfen nicht zu gleichen oder in statistischem Sinne zu "ähnlichen" Hashes führen. Diese Anforderungen lassen sich in Kombination nur durch den Einsatz von Zufallszahlen erfüllen.

Dass leider auch moderne Hash-Verfahren anfällig sind - insbesondere gegenüber Brute-Force-Angriffen - und sich in manchen Anwendungsbereichen sogar für "Denial of Service"-Angriffe nutzen lassen, belegen u.a. folgende Links:

 

Captcha-Verfahren

Auch ein Blick auf Captcha-Verfahren macht die Bedeutung von "Zufälligkeit" deutlich:

Sie stellen eine Variante von sog. Challenge-Response-Verfahren dar, in denen eine statistisch generierte Information von einem (hoffentlich menschlichen) Anwender aufgrund seines speziellen Wissens und oft kombiniert mit menschlichen Mustererkennungsfähigkeiten zur Beantwortung einer Frage genutzt und an eine autorisierende Instanz zurückgesendet werden muss.

Wir haben bereits im letzten Artikel an einem entsprechenden Beispiel diskutiert, dass eine unzureichende Entropie von Zufallszahlengeneratoren zur Vorhersagbarkeit der generierten Captcha-Zeichen/Nummern/Aufgaben-Folgen führen kann.

Zusammenfassung

Wichtige Sicherheitsverfahren, die insbesondere zur Absicherung von Kommunikation im Internet eingesetzt werden, kommen ohne qualitativ hochwertige Quellen für Zufallszahlen nicht aus. Eine unzureichende Entropie von RNGs oder technischen Quellen von Zufallszahlen, die bei der Generierung Kryptierungs-Schlüsseln einegsetzt werden, eröffnet potentiellen Angreifern mit hinreichendem Wissen und Ressourcen Möglichkeiten, Verschlüsselungsverfahren anzugreifen und letztlich die Inhalte verschlüsselter Information zu dekodieren.

In einem weiteren Artikel wende ich mich - sobald ich dazu Zeit finde - ein wenig anderen Quellen von Zufallszahlen als den bereits kritisierten SW-PRNGs in der IT zu.

Weiterführende Links

Elementare Definitionen

 

Heranführung an die Bedeutung von Zufallszahlen in einem einführenden Kurs

 

Grundlagen

http://www.seifried.org/security/cryptography/20000126-random-numbers.html
http://www.jochen-rondorf.de/fh/zufall_im_rechner.pdf
http://www.tu-chemnitz.de/urz/lehre/rs/rs02/krypto/crrng.htm
http://www.staff.uni-mainz.de/pommeren/Kryptologie/
https://www.st.cs.uni-saarland.de/edu/secdesign/randgen.pdf
 
https://calomel.org/entropy_random_number_generators.html
http://blog.cryptographyengineering.com/2012/02/random-number-generation-illustrated.html
http://blog.cryptographyengineering.com/2012/03/surviving-bad-rng.html
http://www.techsupportalert.com/content/encryption-not-enough.htm
http://cacr.uwaterloo.ca/hac/
especially
http://cacr.uwaterloo.ca/hac/about/chap5.pdf
http://www.std.com/~cme/P1363/ranno.html
http://cseweb.ucsd.edu/~mihir/cse207/s-prg.pdf
http://www.ceilers-news.de/serendipity/217-RSA-und-die-schwachen-Schluessel,-Teil-3-Die-Gefahren.html

 

Liste umfangreicher spezieller Artikel der Universität Stanford
http://crypto.stanford.edu/pbc/notes/crypto/

Umfangreiche Liste von grundlegenden Artikeln aus den 90ern
http://erngui.com/rng/

Angriffsverfahren auf unzureichende PRNGs aus wissenschaftlicher Sicht
https://www.schneier.com/paper-prngs.pdf

Auswege bei unzureichender Entropie?

 

"/dev/urandom" und "haveged" als Quellen von Zufallszahlen für Linux Systeme

 

Artikel über PGP und die dortige Verwendung von PRNGS