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

 

IT-Sicherheit und Zufallszahlengeneratoren – II

Im Jahr 2013 hatte ich einen Artikel zur Bedeutung von Zufallszahlen-Generatoren geschrieben. Vor kurzem habe ich dazu eine Mailkommunikation mit einem interessierten Leser führen dürfen, der sich selbst mit hardware-basierten Zufallszahlengeneratoren für IT-Systeme befasst. Dadurch wurde ich motiviert, dieses Thema mal wieder aufzugreifen.

Wir hatten im Artikel
IT-Sicherheit und Zufallszahlengeneratoren – I
festgestellt, dass die Qualität von Zufallszahlen als Element von Sicherheitsverfahren im Besonderen dann größte Bedeutung zukommt, wenn der Algorithmus von Sicherheitsverfahren bekannt ist. Dies gilt typischerweise für Open Source Programme, ist aber auch für viele technische Krypto-Verfahren von Bedeutung.

Ein Beispiel liefert etwa SSL/TLS. Zufallszahlengeneratoren müssen hier qualitativ hochwertige und nicht vorhersagbare statistische Element einstreuen. Dies ist einer der Gründe dafür, warum im Bereich der Herstellung von Software, die gezielt SSL/TLS-basierte Krypto- und Sicherheitsverfahren nutzt, hochwertige SW-Bibliotheken für die Generierung von Zufallszahlen zum Einsatz kommen. OpenSSL-Bibliotheken wären aber auch für Entwickler gewöhnlicher SW- und Web-Anwendungen von großem Interesse.

So würde man sich z.B. als Web-Entwickler freuen, wenn man derartige Bibliotheken auch im Rahmen von Webhosting-Angeboten deutscher Provider nutzen könnte. Mindestens im Jahr 2013 war das aber im Rahmen der Hosting-Angebote der marktdominanten Unternehmen (für Web-Hosting mit PHP-Unterstützung) nach eigener Recherche nicht der Fall.

Dieser Artikel beleuchtet ein wenig die Frage: Warum stellt dieser Zustand ein Problem dar? Wir erläutern dies am Beispiel der Entwicklung von Web-Anwendungen unter PHP. Zur Vertiefung für interessierte Leser verweisen wir unten explizit auf eine Website, die sich der Sicherheit unter PHP widmet, die aber auch für Nutzer anderer Programmiersprachen wie Java und interessierte Anwender von Web-Applikationen von Interesse sein dürfte.

Defizite von PRNGen in der Web-Programmierung am Beispiel PHP

Viele Web-2.0-Applikation beruhen auf der Programmiersprache PHP. Das betrifft u.a. Foren, Blogs, Gästebücher, Diskussionsplattformen, Bug-Tracker, etc.. PHP eignet sich daher gut als Beispiel für die Diskussion der Schwächen von PRNG-Bibliotheken.

Viele der genannten Verfahren setzen im Rahmen von Anmeldungen und/oder der Absendung von Beiträgen sog. Captcha-Verfahren mit zufällig generierten Zahlen und/oder Textsequenzen/Aufgaben ein, um Spammer abzublocken. Nun sind Entwickler meist bequeme Menschen - und setzen daher auf Software-PRNGs, die die PHP-Standardbibkliotheken anbieten.

Lassen sich darauf ohne weitere Zusatzmaßnahmen sichere Verfahren aufbauen? Die Antwort ist eindeutig: Nein!

Für PHP-Kundige aber auch andere Mitmenschen, die sich für die Sicherheit von Web-Applikationen interessieren, möchte ich in diesem Zusammenhang explizit den sehr guten und hinreichend tiefgehenden Artikel

 
(wie auch andere ergänzende Artikel der Website

 
empfehlen. Der genannte Artikel zeigt Einsatzgebiete von SW-PRNGen auf, er analysiert das Thema "unzureichende Entropie der Zufallszahlenverteilung" und leitet daraus einige wirksame Angriffsverfahren ab.

Ausgeführt wird dankenswerterweise auch, dass ein Mix von (deterministischen) mathematischen Konversionen (wie etwa Hashing) oder die Kombination mehrere PRNGs überhaupt nichts nutzt, um unzureichende Entropie zu kompensieren. Schon gar nicht im Fall von Open Source-Software ....

Im Gegensatz zur Meinung von etlichen Entwicklern macht der Artikel auch darauf aufmerksam, dass Verfahren, die auf dem bekannten "Mersenne Twister"-Algorithmus aufbauen (wie mt_rand()), ohne hinreichende Qualität und "Entropie" von Seeds keineswegs als sicher gelten können. Als Konsequenz fordert der Artikel u.a zwingend den zusätzlichen Einsatz von hochwertigen OpenSSL-Erweiterungen oder anderen Quellen hoher Entropie für die Zufallszahlen-Generierung.

Nun ist es leider aber so,

  1. dass die OpenSSL auf dem Ziel-Webserver der PHP-Web-Anwendung installiert sein muss
  2. und das die PHP-Module gegen die SSL-Bibliotheken compiliert und gelinkt sein müssen.

Das ist in den wenigsten Webhosting-Angeboten der Fall. Evtl. auch aus rechtlichen Gründen. So ist man als Entwickler von hochsicheren Lösungen eigentlich fast immer darauf angewiesen, mit eigenen Servern (oder gehosteten Root-Servern) zu arbeiten.

Wir lernen aus dem obigen Artikel jedenfalls, dass Software, die ihre Sicherheitsverfahren auf PRNGen ohne hinreichende Qualität (= "hohe Entropie") von Zufallselementen (Seeds) aufbaut, mathematisch kundigen Angreifern Tor und Tür öffnen kann. Das gilt natürlich nicht nur für die Sprache PHP, sondern auch andere web-relevante Sprachen wie etwa Java oder Ruby.

Sie glauben dennoch, das Thema sei so speziell, dass es in der täglichen Praxis wohl keine Rolle spielen dürfte?

Ein Beispiel aus der Praxis

Wir mussten selber im Rahmen der Implementierung einer Website für einen Kunden, in die ein beliebtes OpenSource Gäste-Buch (auf PHP-Basis) integriert war, erfahren, wie angreifbar PRNG-basierte Sicherheits-Verfahren sein können.

Das Gästebuch nutzte Captcha-Verfahren im Rahmen des Absendens von Beiträgen. Der User musste zufällig generierte und grafisch verzerrt dargestellte Zahlensequenzen beim Abschicken eines Beitrags in ein Formularfeld eingeben. Leider mussten wir feststellen, dass nach einer Weile das Spam-Aufkommen so zunahm, dass wir selbst mit zusätzlichen Text- und Ausdrucksfiltern der Flut nicht mehr Herr werden konnten. Wir hatten es mit einem typischen Fall eines erfolgreichen Angriffs auf die Schwäche von PHP-PRNGen (gemäß eines der Muster aus dem oben genannten Artikel) zu tun.

Wir haben deshalb den Code des Gästebuchs analysiert und letztlich festgestellt, dass die Captcha-Sequenzen nach einer statistischen Analyse tatsächlich vorhersagbar waren. Hierzu reichte eine überschaubare Anzahl von ca. (maximal) 60 Millionen Versuchen zur Seed-Sequenz-Prüfung. Die Analyse ließ sich locker in kürzester Zeit auf einem Laptop bewerkstelligen.

Ein typischer Fall von unzureichender Entropie. Wir änderten das Captcha-Verfahren dann selbst ab - und zwar

  • erstens mit Methoden, die dem Angreifer unbekannt waren
  • und zweitens mit eine Quelle für Seeds hoher Entropie.

Und siehe da: die Anzahl durchkommender Spams ging massiv zurück und hielt sich im Rahmen von Zufallstreffern im Promille-Bereich der Versuche.

Besonders lustig fanden wir, dass wir nach einer Weile tatsächlich auch noch eine Reaktion eines frustrierten Spammers im Rahmen abgewiesener, aber in einem Log-Bereich gespeicherten Beitragsversuches erhielten: Der Autor stellte eingerahmt in eine Reihe von Vulgärausdrücken fest, dass wir das Captcha-Verfahren wohl modifiziert hätten. Er glaube aber immer noch an das Potential seiner statistischen Analysen und würde das geänderte Verfahren früher oder später doch knacken. Er habe gerade nur keine Zeit ...

Hier sieht man mal, mit welchen Methoden in der Spammer-Szene gearbeitet wird.

Nun hatten wir den Vorteil, 2 Maßnahmen kombinieren zu können, von denen eine dem Prinzip von Open Source direkt zuwider lief. Ein Open Source Entwickler muss hingegen vollständig auf hohe Entropie von eingesetzten Zufallszahlen setzen.

OpenSSL unter UNIX/Linux als betroffenes Beispiel unzureichender Seed-Qualität

Trotz der Empfehlungen des oben erwähnten Artikels, der die Flankierung von PHP Software-PRNGen durch OpenSSL-Zufallsgeneratoren für Seeds empfiehlt, kann man mal die Frage stellen:

Wie sicher ist eigentlich OpenSSL selbst im Praxiseinsatz? Diese Frage ist deshalb von Bedeutung, weil es hier um den Kern sicherer Kommunikation mit Webseiten im Internet geht.

Für eine kritische Haltung muss man gar nicht mal auf den Heartbleed-Bug zurückgreifen oder gar Backdoors im (RSA-) Algorithmus vermuten:

 

Ein sehr schöner Artikel zu den diesjährig bekannt gewordenen grundlegenden Schwächen ist folgender:

 

Nach Meinung von Fachleuten führ(t)en aber schon sehr viel trivialere Umstände in der Praxis zu erheblichen OpenSSL-Schwächen. Folgender Artikel zeigt, dass auch die Entropie von OpenSSL unter bestimmten Umständen durch eine falsche Wahl von Seeds selbst wieder zu gering werden kann:

Auch der OpenSSL-Generator muss mit Seeds hinreichender Qualität versehen werden. Prozess IDs als Zusatz-Seed, auf die zumindest frühere OpenSSL-Implementierungen unter UNIX/Linux zurückgriffen, erweisen sich in diesem Zusammenhang interessanterweise und überraschenderweise als untauglich.

Dieses Beispiel zeigt, wie intrikat und kompliziert das Zusammenspiel von PRNG-Algorithmen und statistischen Seeds in einem konkreten Betriebssystem-Umfeld werden kann. Nicht gerade beruhigend? Der folgende Artikel befasst sich auch mit der damaligen OpenSSL-Schwäche und vertritt - wie ich - die Meinung, dass gerade wegen solcher Probleme Open Source wichtig ist:

 

Genug für heute. In einem weiteren Beitrag

IT-Sicherheit und Zufallszahlengeneratoren – III

werfen wir einen Blick auf einige weitere sicherheitsrelevante Verfahren, die eine hohe Qualität von Zufallszahlen erfordern.

Philosophische Fragen

Wie schon im letzten Blog-Artikel zu diesem Thema lassen wir den Leser mit ein paar "philosophischen" Fragen zurück:

Gehört es nicht zur Aufgabe einer modernen Staatsverwaltung, der heutigen Informationsgesellschaft, die den Staat trägt, einen (Web-) Service anzubieten, über den Entwickler und die Wirtschaft bei Bedarf kostenfrei ganze (verschlüsselte) Dateien mit hochwertigen Zufallszahlen abrufen können? Wäre ein solches Angebot nicht im nationalen Interesse? Eine Institution für ein solches öffentliches Angebot wäre in Deutschland etwa das BSI.
 
Natürlich fallen einem sofort zwei Fragen ein, die kritische Zeitgenossen aus zwei unterschiedlichen Perspektiven zu einem solchen Angebot stellen könnten:

  • Kann man einer solchen (staatlichen) Quelle von Zufallszahlen trauen? Unter welchen Voraussetzungen?
  • Kann dieses Angebot nicht auf von bösen Zeitgenossen genutzt - besser: missbraucht - werden? Wie sähe die Nutzen/Schadens-Bilanz aus?

Viel Spaß beim Nachdenken!