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!

IT-Sicherheit und Zufallszahlengeneratoren – I

Selbst manche IT-Fachleute und SW-Entwickler sind sich nicht immer bewusst darüber, wie wichtig gute Zufallszahlengeneratoren in diversen Sicherheitsverfahren sind. Es kann potentiell fatale Auswirkungen haben, wenn z.B. im Unternehmensbereich Sicherheitsverfahren auf unzureichenden Zufallszahlengeneratoren beruhen. "Unzureichend" bezieht sich dabei auf die statistische Qualität der Zufallsverteilung.

Ein typisches Beispiel liefert der Einsatz von Pseudozufallszahlengeneratoren [Pseudo Random Number Generator [PRNG]] im Zuge der Entwicklung von Security-Komponenten in Web-Applikationen fürs Unternehmens-Intra- oder -Extra-Net sowie fürs Internet. Hier greifen Entwickler oft auf zu schwache PRNGs zurück, die mit der jeweiligen Programmiersprache (z.B. PHP, Java,...) ausgeliefert werden, und reißen so Löcher in Enterprise-Web-Applikationen:

Krypto-Algorithmen, Authentisierungsverfahren oder Captcha-Verfahren für Transaktionsautorisierungen können bei unzureichender Statistik eingefütterter Zufallszahlen zum Ziel von Angriffsvektoren werden, die oftmals nicht erkannt oder aber unterschätzt werden. Dies gilt im Besonderen beim Einsatz eigenentwickelter Sicherheitsverfahren.

Zufallszahlen spielen aber auch beim Einsatz von professioneller, kommerzieller und von Open Source basierter Sicherheits-Software eine fundamentale Rolle. Immer wieder fragen mich einige meiner Kunden, die aufgrund ihres Berufes Wert auf die Verschlüsselung personenbezogener Daten legen müssen, warum beim Einsatz verschlüsselter Datencontainer (z.B. mit Realcrypt) oder aber auch bei der Generierung von kryptographischen Schlüsseln (z.B. in PGP) eine Phase der Generierung von Zufallszahlen auftritt, bei der der User z.B. durch erratische Mausbewegungen mitwirken muss.

Im Zuge der bekannt gewordenen Nachrichten im Umfeld der Abhöraktionen von Geheimdiensten im Internet tauchten ferner Nachrichten auf, in denen darüber spekuliert wurde, ob manche tragenden Verschlüsselungsmechanismen im Netz inzwischen korrumpiert seien. Dabei war einerseits von programmtechnischen "Backdoors" der Kryptierungsalgorithmen selbst die Rede; zur Sprache kamen andererseits aber auch Manipulationen standardisierter Verfahren zu Erzeugung von Kryptierungsschlüsseln oder Challenge-Response-Secrets in automatisiert ablaufenden Verfahren zur Kryptierung von Netzwerkverbindungen auf der Basis von Zufallszahlengeneratoren.

Wie erklärt sich das? Warum ist "Awareness" im Bereich von Zufallszahlen-Generatoren für Sicherheitsverfahren generell und im Besonderen für Kryptographieverfahren so wichtig? Und warum ist Unbedarftheit an dieser Stelle potentiell gefährlich?

Diese Fragen rechtfertigt einige kleine Artikel in diesem Blog. Ich kann dabei aus Platz- und auch Verständnisgründen nur an der Oberfläche kratzen. Lesern, die daran interessiert sind, sich intensiver mit dem Zusammenhang von kryptographischen Verfahren, Wahrscheinlichkeiten, Unvorhersagbarkeit und PRNGs auseinanderzusetzen, lege ich als eine erste Einführung die Online-Kurse nahe, die unter
https://www.udacity.com/course/viewer#!/c-cs387/l-48632905/m-48740007
abrufbar sind.

Hinweis: Vielfach wird in der deutschen Literatur ein PRNG auch als "Zufallsgenerator" bezeichnet. Ich verwende den Begriff "Zufallszahlengenerator" synonym. Die Erzeugung von Zufallssequenzen von Strings oder anderen Objekten kann i.d.R. auf die Erzeugung zufälliger Zahlensequenzen abgebildet werden.

Woran liegt es, dass Zufallszahlengeneratoren im Sicherheitsumfeld so wichtig sind?

Grundsätzlich muss man sich klarmachen, dass fast alle aktuellen computerbasierten Verfahren - und eben auch Kryptographieverfahren - algorithmisch und damit deterministisch arbeiten. Der Anspruch an solche Verfahren ist dabei heute der, dass selbst dann, wenn die Arbeitsweise des Sicherheits- oder Kryptierungs-Verfahren im Detail bekannt ist, die Kenntnis der algorithmischen Struktur nicht für eine Aufdeckung des zu bewahrenden Geheimnisses hinreichend sein darf - zumindest nicht innerhalb eines vernünftigen Zeitraums.

Grundsätzlich kann man bzgl. der Geheimhaltung im Zusammenhang mit Sicherheits- und Kryptierungsverfahren zwei Strategien nutzen:

  • Geheimhaltung des Algorithmus und der dabei Schlüssel (Zugangscodes oder Chiffrierungsschlüssel)
  • oder nur Geheimhaltung der Schlüssel (und ggf. zugehöriger zusätzlicher Autorisierungscodes).

Ob man ein Sicherheitsverfahren und dessen Algorithmus an sich geheimhalten muss, hängt u.a. von der mathematischen Struktur des eingesetzten Algorithmus ab. Ist es einem Angreifer selbst bei bekanntem Algorithmus nicht möglich, Autorisierungs-, Zugangs- oder Kryptierungsschlüssel zu erraten oder durch eine systematisches Verfahren in überschaubarer Zeit zu ermitteln, so darf der Algorithmus selbst durchaus einer breiten Öffentlichkeit bekannt sein.

Nehmen wir also an, jemand kenne den sicherheitstechnischen Algorithmus, der zum Schutz von Daten oder Informationen in IT-Systemen eingesetzt wird. Man sollte sich klarmachen, dass das heute praktisch für alle etablierten Verfahren außerhalb des geheimdienstlichen Bereichs der Fall ist! Wie und in welcher Weise kann dann z.B. ein Zugang zu einem System oder einer geheimen Botschaft trotzdem "abgesichert" sein?

Ein Beispiel liefert ein kompliziertes Safe- oder Koffer-Schloss, dessen Struktur durch einen Zahlencode nach einem bekannten Prinzip definiert wird. (Nehmen wir ferner an, jeder gewaltsame physische Versuch des Öffnens würde zu einer Zerstörung des Inhalts führen. Auch ein Abhorchen von Einrast-Klicks des Schlosses sei unmöglich.) Dann müsste ein Angreifer auf gut Glück einen alphanumerischen Code ("Schlüssel") nach dem anderen durchprobieren, um das Schloss durch einen Zufallstreffern zu öffnen. Die Sicherheit hängt dann von drei Faktoren ab:

  • der Länge und Komplexität des gewählten Codes,
  • der Zufälligkeit der als Schlüssel gewählten Buchstaben/Zahlen-Kombination,
  • der Existenz eines kleinen, aber hinreichend langen minimalen Zeitintervalls für einen Entschlüsselungsversuch

Die ersten beiden Punkte führen zu einer hoffentlich geringen statistischen Wahrscheinlichkeit für das Erraten des Schlüssels und bei einer minimalen Zeiteinheit pro Entschlüsselungsversuch auch zu einem hohen Erwartungswert für das Zeitintervall, bis ein systematisches Durch-Probieren von alphanumerischen Codes zu einem Öffnen des Schlosses führt.

Eine geringe Wahrscheinlichkeit für das Erraten eines Schlüssels sorgt hier für einen ggf. zu hohen Aufwand für den Angreifer, das Schloss zwischen zwei Kontrollgängen von Sicherheitspersonal oder vor einer erneuten Änderung des Schlüssels zu knacken.

Das Beispiel verdeutlicht:

Bei bekanntem Algorithmus hängt die Sicherheit eines algorithmischen Kryptierungs-, Autorisierungs- oder Zugangsverfahrens grundsätzlich von zusätzlichen statistischen Input-Elementen ab, die dem potentiellen Gegner nicht bekannt sein dürfen.

Sprich:

  • Die statistischen Elemente eines Krypto- oder Sicherheits-Algorithmus müssen wirklich statistisch sein, d.h. sie müssen sich echtem physikalisch-statistischem "Rauschen" annähern. Man sagt auch: Sie müssen eine hinreichend hohe "Entropie" aufweisen. In der Praxis bedeutet das u.a., dass grafische Darstellungen der letztlich durch ein Sicherheitsverfahren generierten Werte (meist "Schlüssel", aber auch die verschlüsselten Geheimnisse selbst) in einem geeigneten Parameter- und Beschreibungsraum keine erkennbaren oder sich gar wiederholenden Muster aufweisen dürfen.
  • Die statistischen Elemente eines Krypto- oder Sicherheits-Algorithmus müssen so erzeugt werden, dass der potentielle Gegner darauf möglichst keinen Einfluss hat und die ggf. systematisch erzeugten Werte oder deren Sequenz ihm nicht bekannt werden. Das betrifft sog. "Seeds" (Samen) und statistische Initialisierungsvektoren von Sicherheitsverfahren, es betrifft die im Verfahren zu erzeugenden Kryptierungsschlüssel oder Zugangs- und Autorisierungsschlüssel wie etwa Autorisierungsschlüssel für die Aktivierung von Kryptierungsschlüsseln selbst oder für das Betriebssystem.

(Vermeintliche) Sicherheit entsteht in modernen Verfahren primär dadurch, dass statistische Größen mit Algorithmen so kombiniert werden, dass man selbst bei bekanntem Algorithmus einen komplexen und geheimgehaltenen Schlüssel nicht in vernünftigen Zeiträumen durch systematische Analysen und Entschlüsselungsversuche reproduzieren kann.

Bereits hier sehen wir, dass "Zufälligkeit" eine bedeutsame Rolle spielt. Nur "zufällige" Verteilungen einer Größe in einem hinreichend großen Raum potentieller Parameter - z.B. erzeugter Kryptierungsschlüssel - sorgen für die benötigte geringe Wahrscheinlichkeit des Erratens eben solcher Schlüssel oder von Sicherheitscodes.

Nun lassen sich Zufallsverteilungen jeder Art von Größe auf die Verteilung von reellen Zahlen in einem Zahlenintervall oder kombinierten Zahlenintervallen abbilden. Über diesen Aspekt kommen in etlichen sicherheitsrelevanten Verfahren Pseudo-Zufallszahlengeneratoren ins Spiel - also Algorithmen, die Sequenzen von Zufallszahlen erzeugen :

Sie liefern oftmals den (hoffentlich) statistischen Input für übergeordnete algorithmische Verfahren.

Aufwandserhöhung erfordert den Einsatz von Zufallszahlen

Grundlage vieler aktueller Verfahren ist eine aufwändige Zerlegung von (sehr) großen Zahlen in Primfaktoren. [Die Zerlegung einer Zahl in Primfaktoren ist ein sog. "NP-Problem" der Komplexitätstheorie. Salopp gesagt bedeutet dies: Es ist kein effizienter Algorithmus bekannt, bei dem mit heutigen Mitteln das Problem bei hinreichend großen Primzahlen in überschaubarer Zeit berechnet werden kann.] Das schützt weitgehend vor systematischen Angriffen auf den Algorithmus selbst.

Dennoch bedienen sich auch solche Verfahren erzeugter oder von außen (durch den User oder physikalische Geräte) zugelieferter Zufallszahlen:
Etwa bei der Erzeugung der benötigten großen Primzahlen, bei der Erzeugung bestimmter Schlüssel, internen Werten, die temporär sog. zufällige Initialisierungsvektoren erzeugen, etc.. An bestimmten Stellen werden auf Basis von externer Zufalls-Seeds intern weitere Zufallszahlensequenzen mit Hilfe von PRNGs produziert.

Fazit: Ohne Zufallszahlen geht es nicht

Wir fassen mit Hilfe eines Zitats des Kryptographie Experten Bruce Schneier (siehe für das Zitat: https://www.schneier.com/yarrow-qa.html) zusammen:

Why is a PRNG important?

PRNGs are used everywhere in cryptography. In fact, it is hard to imagine a well-designed cryptographic application that doesn't use random numbers. Random numbers are used to generate session keys, initialization vectors, salts to be hashed with passwords, unique parameters in digital signature operations, random initialization for public-key generation, and nonces in different protocols. If the random numbers in any of these applications are insecure, than the entire application is insecure. Algorithms and protocols can't cover for bad random numbers.

Wie ernst man die mögliche Korrumpierung von PRNGs nimmt, zeigt folgender Artikel:
http://arstechnica.com/security/2013/09/stop-using-nsa-influence-code-in-our-product-rsa-tells-customers/

Ergänzung 1: Warum überhaupt definierte Algorithmen in Sicherheitsverfahren ?

Nun könnte jemand ganz spontan einwenden: Warum müssen denn IT-Sicherheitsverfahren überhaupt grundsätzlich "algorithmisch" aufgebaut sein?

Ein trivialer Teil der Antwort besteht sicher darin, dass auch nach Anwendung des Sicherheitsverfahrens der Zugang zu einem eventuellen Geheimnis für Berechtigte möglich sein muss. Bestimmte Teile der Sicherheitsvorkehrungen - z.B. die Kryptierung eines geheimen Textes - müssen also insofern reversibel gehalten sein, als man die Sicherheitssperren (wie etwa die Kryptierung) durch autorisierte Personen oder Systeme wieder aufheben können muss, sobald der Zugang zum geschützten Geheimnis oder einem gesicherten Verfahren erforderlich wird.

Hierzu bedarf es definierter und auch künftig gültiger Verfahren mit eindeutigen Handlungs- und Verarbeitungsschritten - also Algorithmen. Der Einsatz von Algorithmen dient also ganz wesentlich der erforderlichen Reversibilität der Sicherheitsmaßnahmen.

Tatsächlich gibt es aber Sicherheitsverfahren, in denen die Sicherheit durch zeitlich statistisch fluktuierende Änderungen von Elementen der Basis-Algorithmen erhöht wird. Z.B. könnte man - statt verschlüsselte Texte statisch zu halten - "aktive" Botschaftscontainer erzeugen, die die kryptierte Botschaft über eine durch Umweltdaten ausgelöste Algorithmenvariation immer wieder neu erzeugen. Solche Verfahren sind zwar interessant, lassen sich letztlich aber auf komplexere Algorithmen mit weiteren (symmetrisch für den Dekryptierer bekannten) Zufalls-Seeds zurückführen. Interessant sind diese Verfahren also eher weniger wegen der vordergründigen Algorithmen-"Verschleierung" als vielmehr wegen des Rückgriffs auf wirklich statistisch fluktuierende Input-Daten.

Ergänzung 2: Der Schutz von Schlüsseln erfordern zusätzliche Maßnahmen

Selbst bei erfolgreicher Geheimhaltung eines Algorithmus bliebe in jedem Fall die Frage der Autorisierung zur Aktivierung des "unbekannten" Dekryptierungs-Algorithmus mittels eines Schlüssels offen. Gerät ein Angreifer in den physischen Besitz eines Schlüssels, so kann man immer noch versuchen, die Sicherheit durch Abfrage eines persönlichen Zugangs- und Autorisierungscodes zu schützen. Sprich: Der Schlüssel wird nur aktiv, wenn sein Besitzer ein nur ihm bekanntes Geheimnis angibt.

Hier ist der Austausch von Identitäts- und Autorisierungsdaten (ggf. weiteren Geheimnissen) erforderlich. Das Autorisierungsproblem wirft die Sicherheit letztlich immer wieder auf elementarste Sicherheitsverfahren und die Geheimhaltung von Autorisierungscodes durch Personen zurück. Bin ich im Besitz von Identitäts- und Autorisierungsdaten und kann ich sie an der richtigen Stelle anbringen, muss mich deren weitere algorithmische Verwendung nicht mehr interessieren - solange der Zugang zu einem Verfahren oder die Dekryptierung eines codierten Geheimtextes erfolgreich durchgeführt werden.

Da aber

  • sowohl die Lagerung von vielen Autorisierungscodes, die ein Mensch im IT-Umfeld heute behalten muss,
  • als auch die Vorhaltung von vielen Autorisierungscodes vieler Nutzer für viele IT-Systeme

systematisch durch IT-Systeme selbst unterstützt werden muss, landen wir wieder bei dem Problem der sicheren - also kryptierten - Lagerung von Information und deren Dekryptierung auf IT-Systemen mit einem menschlichen Zugangskanal. Die Verfahren müssen systematische, reproduzierbare Schritte beinhalten - wir sprechen also auch hier wieder von Algorithmen.

Ergänzung 3: Muss der Sicherheitsalgorithmus den beteiligten Benutzern bekannt sein? Was bringt Geheimhaltung?

Man muss natürlich nicht immer einen Algorithmus bzw. ein algorithmisches arbeitendes Werkzeug kennen oder verstehen, um ihn bzw. es einsetzen zu können. Man muss ihn nur in einer praktikablen Form besitzen und anwenden können. Faktisch verstehen heute auch Sicherheits-Experten nicht die Details aller von Ihnen eingesetzten Algorithmen. Ein echtes Verständnis erfordert meist auch erhebliche mathematische Kenntnisse.

Da der Anwender den sicherheitstechnischen Algorithmus nicht verstehen muss, zieht das die Frage nach sich, ob man ihn dann nicht besser geheimhalten sollte. Gerade die NSA-Skandale der letzten Zeit und die zugehörige Backdoor-Diskussion werfen immerhin die Frage auf, wie man in einen nicht mehr bekannten oder nicht mehr nachvollziehbaren Algorithmus "Backdoors" einbauen will? Die Geheimhaltung von Algorithmen kann für Staaten, Geheimdienste oder Wirtschaftsunternehmen aus diesem Grunde durchaus relevant erscheinen.

Das Problem ist hierbei aber das des klassischen menschlichen Versagens. Um an die Kenntnis von Algorithmen zu kommen, müssen nämlich nur Einzelne "versagen". Gegen massiven Druck auf einzelne Person zur Offenlegung eines Algorithmus oder zugehörigen Schlüssels ist kein Kraut gewachsen - deswegen dürfen aber kryptierte Nachrichten anderer Personen, die andere Schlüssel nutzen, nicht gefährdet sein. Deshalb ist es so viel wichtiger, mit Verfahren zu arbeiten, bei denen selbst der Zugang zum Algorithmus die Sicherheit der mit ihm verschlüsselten Nachrichten nicht substanziell gefährdet. Bei bekanntem Algorithmus verlagert sich Sicherheit in der Masse auf die statistische und nicht in vernünftiger Zeit reproduzierbare Erzeugung von Schlüsseln und deren Geheimhaltung bzw. deren Schutz.

Weitere Argumente gegen eine Geheimhaltung von Algorithmen und zugehöriger Programmcodes sind klassische "Open Source" Argumente:

  • Wenn ich einen sicherheitsrelevanten Algorithmus kenne, kann ich seine Eigenschaften analysieren und evtl. Schwachstellen entdecken - aber auch beheben.
  • Wenn ich Zugang zu den Programmcodes für die Umsetzung von Sicherheits- oder Kryptierungs-Algorithmen habe, können andere Experten oder im Zweifelsfall sogar ich selbst prüfen, ob die Umsetzung einwandfrei erfolgt ist (keine backdoors) oder ob sich durch die programmtechnische Art der Umsetzung ggf. sekundäre Schwachstellen ergeben haben.

Beide Argumente eröffnen in einem Umfeld, in dem man an die Existenz mathematisch begründeter sicherer Kryptierungs-Algorithmen mit statistischen "Seeds" glaubt, vielleicht gerade für den Privatmann die einzige Chance auf eine angemessene Absicherung seiner Privatsphäre.

Im nächsten Artikel
IT-Sicherheit und Zufallszahlengeneratoren – II
vertiefen wir diese Überlegungen und betrachten ein einfaches Beispiel für die Kombination von statistischen Wahrscheinlichkeitselementen mit algorithmischen Strukturen.

Zusatzfrage

Für die Philosophen unter den Lesern habe ich zum Abschluss dieses Beitrags folgende Frage:

Kann man technische, informationsverarbeitende Systeme bauen, die "selbständig" Kryptoverfahren erzeugen, die für einen menschlichen Angreifer nicht mehr rekonstruierbar sind? Kann "etwas" (algorithmische) Verfahrensstrukturen entwickeln, die wir nicht in vernünftiger Zeit nachbauen oder rekonstruieren können, die wir aber dennoch zur Kryptierung und Dekryptierung einsetzen könnten? Und würde das die Sicherheit gegenüber "sicheren" Verfahren mit bekannten Algorithmen und zusätzlichen Zufallselementen wirklich erhöhen? Und wenn: in welchem Sinne genau ?