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 ?

„Open Source“-Sicherheit und die Sicherheit des Umfelds

In den letzten Tagen habe ich mich im Rahmen eine Kundenprojekts einmal mehr mit dem Thema "Open Source"-Sicherheit befassen müssen. In diesem Zusammenhang spielte u.a. der folgende Artikel von Ludger Schmitz eine Rolle

http://www.osb-alliance.de/blog/detailansicht/artikel/internet-ausspaehung-ist-open-source-sicher/

Der genannte Artikel stellt (zu Recht) die Frage, wie sicher eigentlich die auf Standards beruhenden Methoden und Verfahren sind, die auch in "Open Source"-Produkte einfließen. Bevor man sich aber mit dieser ganz grundsätzlichen Erwägung befasst, sollte man aus meiner Sicht jedoch in der täglichen Praxis andere Themenstellungen beleuchten, die für die Sicherheit von "Open Source"-Systemen - im besonderen im Unternehmens- und Verwaltungsumfeld - sicher ebenso bedeutsam sind.

  1. Genügt "Open" für Sicherheit?
    Bei Opensource besteht im Prinzip die Möglichkeit, Sicherheit dadurch dauerhaft zu erhöhen, dass unabhängige und viele Entwickler regelmäßig den Code sehen, prüfen und bearbeiten können. Zudem sorgen bei etlichen wichtigen Projekten Maintainer für eine hinreichende Codequalität. Hier kann dann ein Öko-System aus Checks und Balances entstehen, in dem auch Sicherheitsaspekte regelmäßig gewürdigt und im Lichte aktueller Erkenntnisse geprüft werden. Hinzu kommen gegenüber den Endverbrauchern die Distributoren als wichtiger Filter für eine getestete und qualitativ hinreichende Zusammenstellung von SW-Paketen für Desktops wie Server. Aber spiegelt diese graue Theorie die Wirklichkeit wieder ?
  2. Sicherheit bei und durch die Integration von Open Source in Eigenentwicklungen?
    Viele Opensource-Produkte (u.a. viele Libraries) fließen in Unternehmen in Eigenentwicklungen ein - dadurch wird ein neues SW-technisches Umfeld jenseits des Opensource-Produktes erzeugt, dass natürlich ebenfalls sicherheitsrelevant sein kann.
  3. "Open Source"-Sicherheit in heterogenen Umgebungen?
    Selbst wenn man mal annimmt, dass "Open Source"-Systeme aufgrund des Einblicks und einer regelmäßigen Prüfung von Codes durch unabhängige Entwickler einen anderen Grad an Sicherheit aufweist oder unter optimalen Bedingungen aufweisen kann wie proprietäre Produkte, so trifft man weder im Unternehmens- noch im Verwaltungsbereich eine reine "Open Source"-Welt an. Vielmehr liegt in der Regel ein heterogener Mix an Betriebssystemplattformen, Mobile Devices (BYOD!) und darauf laufenden "Open Source" basierten wie proprietären SW-Applikationen vor. Auch hier entsteht ein komplexes Umfeld, das in Wechselwirkung mit den "Open Source"-Produkten steht und deren Sicherheit beeinflussen kann.

Bevor ich mich diesen Punkten zuwende und dabei auch Kritik äußere, möchte ich von vornherein hervorheben, dass die Geschwindigkeit, mit der im "Open Source"-Umfeld Sicherheitslücken erkannt, publiziert und geschlossen werden, für mich sehr beeindruckend ist. Feststellen möchte ich auch, dass ich "Open Source" im Interesse des technischen Fortschritts für absolut unverzichtbar halte und die Vielfalt wie innovative Kraft von "Open Source" - vor allem im Linux-Umfeld - hoch schätze. Insgesamt stufe ich die Leit-Gedanken von "Open Source" als eine fundamentale und verteidigungswürdige Errungenschaft der technischen Zivilisation ein. Das soll einen aber weder blind gegenüber potentiellen Beeinträchtigungen von Sicherheit machen noch eine nüchterne "Erdung" überzogener Sicherheitserwartungen verhindern.

Genügt "Open" für Sicherheit?

Zu Punkt 1 der obigen Liste möchte ich aus persönlicher Erfahrung mit dem Einsatz von "Open Source"-Systemen (auf Desktop- und Server-Basis) über einige Jahre hinweg: Ja, aber.... Es gibt hier aus meiner Sicht vier Einschränkungen, die von der Öffentlichkeit oft übersehen werden.

Problem 1: Die Frage hinreichender Ressourcen in "Open Source"-Projekten

Sicherheit und Risikoanalyse erfordert ein gezieltes systematisches und proaktives Vorgehen. Die hohe Änderungsfrequenz gerade von "Open Source"-Projekten erfordert ferner eine permanente Anstrengung in puncto Sicherheit. Das muss gesteuert, aber vor allem aber personell abgedeckt und letztlich auch finanziert werden. Und nicht jeder Entwickler hat ein Interesse daran, alle möglichen Programm-Code-Teile systematisch nach Sicherheitslücken zu durchforsten. Schon gar nicht die von anderen Leuten. Und es gibt ja so viele, viel interessantere Aspekte von Cutting Edge-Technologie ...

Viele "Open Source"-Projekte werden dankenswerterweise von Freiwilligen und oft ohne jede hinreichende Bezahlung geleistet. Da bleibt einfach nicht immer beliebiger Spielraum für gezielte, systematische QA und Sicherheitsanalysen. Auch wenn es z.T. bewundernswert ist, was im Laufe der Zeit an phantastischen Dingen entsteht - wenn die Projekte nicht solide gesponsort sind, besteht eine beträchtliche Wahrscheinlichkeit dafür, dass systematische Risikoanalysen unter Einschluss aktuellster Angriffsvektoren auf der Strecke bleiben können. Sicherheit von SW ist letztliche ien Frage ihrer Qualität.

Ich setze Open Source auf breiter Front ein und habe insgesamt beste Erfahrungen damit. Hin und wieder komme ich mir als Endverbraucher aber auch wie ein dauerhafter Beta-Tester vor. Es hat keinen Sinn, darüber zu klagen: zu Recht wird man dann mit dem Hinweis auf die Freiwilligkeit der Arbeit konfrontiert. Zusätzlich begegnet mir bei professionellen SW-Entwicklern und Projektmanagern neuerdings vermehrt der "Hinweis", dass modernes "Scrum"-basiertes Vorgehen zu schnellen Ergebnissen führt, die dann leider, aber "naturgemäß" auch lange in einem dauerhaften Beta-Stadium verweilen würden und erst durch die "dauerhafte Wechselwirkung mit der Nutzer-Community reifen könnten" .... Ich hoffe, dass diese fundamentalen Missverständnisse Einzelfälle bleiben ...

Damit man mich richtig versteht: Das alles ist keine Fundamental-Kritik an Entwicklern oder Projekten im "Open Source"-Bereich. Es ist vielmehr ein Appell an Nutzer wie Sponsoren, solche Projekte ordentlich mit (finanziellen) Ressourcen auszustatten. Und zur Fehlerbehebung so gut und professionell wie möglich beizutragen.

Problem 2: Permanente technische Innovation

Viele "Open Source"-Projekte weisen einen beträchtlichen Zug zur permanenten technischen Innovation auf. Das ist im Kern natürlich überhaupt nicht verwerflich - es entspricht dem Drang von Entwicklern an der technischen Front zu arbeiten. Dieser Drang führt aber auch zu laufenden, teils massiven Code-Änderungen - und die Erfahrung zeigt eine resultierende, aus Endanwendersicht oft überraschende Schwankungen in der Qualität von diversen Open Source-Produkten, die Phasen massiver technischer Veränderungen unterliegen. Das ist verständlich - erstrecken sich die Qualitätsschwankungen im Einzelfall aber auch auf sicherheitsrelevante Bereiche, so entsteht hier ein echtes Problem.

An dieser Stelle ist wieder mal systematische QA gefordert. Quasi als balancierendes Gegengewicht zur Innovation. Im Besonderen sind hier auch die Distributoren als filternde Instanz gefordert. Sie sollten bei der Auswahl der sich laufend ändernden SW-Versionen darauf achten, dass bei aller Innovation auch der Qualität und Sicherheit der in die Distribution integrierten Produkte ein hoher Stellwert eingeräumt wird. Das klappt nach meiner Erfahrung mal besser, mal schlechter - letztlich muss man als Admin und Anwender - vor allem im Bereich von Desktop-Komponenten - selber eine sehr konservative Politik fahren. Im Bereich von Server-Komponenten sieht es aus meiner persönlichen Perspektive deutlich besser aus - vielleicht ist das aber eine selektive Wahrnehmung, die durch unzureichende Detailkenntnisse komplexer Serverprodukte bedingt ist.

Problem 3: Die Offenlegung auch sicherheitsrelevanter Algorithmen

Grundsätzlich muss man zur Kenntnis nehmen, dass die Offenlegung von Codes auch erst den Weg zu bestimmten Angriffsvektoren bahnen kann. Ein Beispiel:

Viele Opensource Produkte setzen zur Absicherung gegen Spam Captcha-Technologie ein. Beruht diese im Einzelfall aber auf unzureichenden Zufallszahlen-Generatoren, so eröffnet gerade die Offenlegung des Codes die Möglichkeit zum Aushebeln der "Sicherheitsmaßnahme". Schlechte Zufallszahlen-Generatoren führen ggf. zu vorhersagbaren Captcha-Sequenzen. Habe ich persönlich schon beim Einsatz von Open Source basierten Web-Produkten erlebt - und nach Änderungen des ursprünglichen (PHP-)Codes des Entwicklers nachweislich beheben können. Hinzu kommt, dass jeder - auch der beste Entwickler - fehlbar ist und heutzutage nicht einer allein alles sicherheitsrelvante Wissen haben wird.

Wohlgemerkt: Ich betrachte auch diesen Punkt keineswegs als Argument gegen "Open Source". Im Gegenteil: "Open Source" bietet auch die Chance, solche Lücken schnell zu erkennen und zu beheben. Aber auch dieser Punkt führt uns wieder zum ersten Problem - nämlich der Notwendigkeit einer systematischen, proaktiven, vom Entwickler unabhängigen Risikoanalyse im Rahmen von QA-Maßnahmen.

Problem 4: Gute Sicherheitsmaßnahmen erhöhen manchmal die Komplexität der SW-Codes, der SW-Konfiguration und auch des SW-Einsatzes. Sie können auch die Performance beeinträchtigen

Sicherheit hat manchmal auch negative Aspekte. Einer davon ist der Einzug einer für Endanwender oft beachtlichen Unbequemlichkeit oder Überforderung beim Einsatz von Sicherheitskomponenten. Jeder, der einem durchschnittlichen Anwender mal die individuelle Verschlüsselung von E-Mails mit OpenPGP unter Windows beibringen wollte, kann davon vermutlich ein Lied singen. Allein das Downloaden und Hantieren mit Schlüsseln und Passphrases überfordert viele Nutzer. Aber nicht jeder Einzelanwender oder kleine Unternehmen können sich eine professionelle, serverbasiert aufgesetzte PKI leisten.

Wer den Aspekt (potentieller) "Performance-Einschränkung" durch Sicherheitsmaßnahmen als wenig relevant einstuft, möge sich mal S. 18 im Linux-Magazin 08/2013 zu Gemüte führen. Dort geht es um Klagen von Thorvalds persönlich über Linux-Performance-Einbußen aufgrund diverser Sicherheitsmaßnahmen im und außerhalb des Kernels.

Sicherheit bei und durch die Integration von Open Source in Eigenentwicklungen oder eigene SW-Umgebungen?

Der Punkt 2 in der Eingangsliste betrifft die Tatsache, dass auch an und für sich sichere "Open Source"-Produkte Sicherheitsrisiken nicht verringern, wenn die Art ihres Einsatzes oder ihrer Integration in umgebende, selbst entwickelte Software selbst mit Problemen behaftet ist.

Das betrifft zum einen die mögliche Fehlkonfiguration betroffener Systeme. Ein banales Beispiel liefert OpenSSH. Es nutzt nichts, wenn im Rahmen selbst entwickelter, funktionsreicher Server-Verwaltungs-Programme SSH-Verbindungen zu Servern aufgebaut werden, aber der entsprechende Port auf den Servern danach für die ganze Welt offen steht, ein root-Zugang nicht ausgeschlossen wurde, und der Zugang wegen zu einfacher Authentisierungsverfahren durch Brute-Force-Angriffe kompromittiert werden kann. Oder was nützt einem ein FTP-Programm Filezilla auf einem unzureichend geschützten Windows-Rechner, mit dem man SFTP-Verbindungen zu Servern aufbauen kann, das aber die zugehörigen Zugangsdaten in Dateien hortet, die man ohne Probleme knacken kann ?

Es betrifft andererseits aber auch die Integration von Open Source Bibliotheken/Frameworks in SW-Eigen-Entwicklungen. Die Möglichkeiten einer sicherheitstechnisch mangelhaften Integration von Opensource-Bibliotheken in umgebende SW-Produkte sind vielfältig - gerade im Web-Bereich. Ein einfaches Beispiel liefert etwa der JSON-Einsatz für JQuery-basierte Ajax-Kommunikation in älteren Browsern bestimmter Klassen. Wird hier nicht ein zusätzlicher JSON-Interpreter unter Javascript installiert, greift JQuery dann als Notlösung auf "eval" im Javascript-Bereich zurück und das ist dann sicherheitsrelevant. Im Web-Bereich werden ferner immer wieder Beispiele für einen sorglosen Umgang mit GET/POST-Daten auch in ausgereifte Frameworks bekannt. Da werden dann Anstrengung in den automatischen oder erzwungenen Aufbau von HTTPS-Verbindungen für die Absicherung der Kommunikation gesteckt, aber was nützt das gegen einen angemeldeten Angreifer, der sich dann Schwächen bei der Prüfung der übermittelten Daten zunutze macht und z.B. einen SQL-Injection-Angriff durchbringt?

Wir sehen bereits hier: "Open Source" ist genau so sicher, wie sicherheitsbewußt sein Einsatz im Rahmen eines selbst gestalteten, komplexeren SW-Umfelds erfolgt.

"Open Source"-Sicherheit in heterogenen Umgebungen?

Während man bei den Punkten 1 und 2 etwas tun kann und sicherheitsrelevante Probleme eher hausgemacht sind, betritt man bei Punkt 3 eine andere schwer zu managende Ebene. Das liegt daran, dass man es in einem heterogenen Umfeld aus Opensource und Nicht-Opensource-Betriebssystemen sowie "Open Source"-basierten und proprietären SW-Komponenten mit einer Vielzahl von Angriffsvektoren auf unsichere, proprietäre Komponenten zu tun hat, die potentiell auch auf an sich sichere Opensource-Komponenten durchschlagen können. Oder umgekehrt...

Ein typisches Beispiel ist: Was nützt ein sicherer Linux-Server, wenn aufgrund einer Sicherheitslücke von Java eine Windows-Workstation eines Admins kompromittiert wird und über dort erhaltene Infos, sowie nachfolgende weitere Angriffe und SW-Manipulationen letztlich sogar Linux-Server mit Rootkits versehen werden können?

Sie meinen, dass sei doch sehr unwahrscheinlich? Dann nehme man sich mal 2 Stunden Zeit und lese mit viel Geduld [und Übersehen des teils ruppigen Umgangstons] folgenden Forenbeitrag zu Sicherheitsvorfällen Anfang des Jahres durch, die womöglich zig- wenn nicht hunderte gehostete virtuelle Server betrafen :

http://www.webhostingtalk.com/showthread.php?s=714ab2598f1b14729348957db7196325&t=1235797&page=1

Wem die hektische Diskussion über 100 Seiten zuviel ist, kann gerne die ersten Seiten lesen und sich dann von hinten nach vorne bewegen. Was danach bei mir an nüchternem Eindruck verblieb, ist eigentlich die Bestätigung einer Trivialität:

Linux-Server sind genau so sicher, wie die Zugangsvektoren zu diesen Systemen sicher sind. Und wenn es Zugangswege über leicht zu kompromittierende Desktops (auch Linux-Desktops !!) gibt, dann gibt es am Schluss trotz interner Sicherheitsbarrieren des Linux-Systems kein Halten mehr. Und es sei ferner und ausdrücklich darauf hingewiesen, dass nicht zuletzt der Anwender Teil der Kette des Zugangsweges ist.

Es zählt das schwächste Glied in der gesamten Kette potentieller Angriffswege - es zählen aber nicht zuletzt auch die Schwächen an deren Anfang. Dass auch Provider wichtiger Server-Administrationstools hier zu lernen haben, beweist der im Forum diskutierte Fall. Letztlich sind aber in den im Forum geschilderten Fällen viele Fehler gleichzeitig gemacht worden - auch von den Administratoren der gehosteten Linux-Server. Meine große Skepsis gegenüber "beliebten" z.T. webbasierten Server-Verwaltungstools hat hier zudem erneut Nahrung erhalten. Siehe auch

http://www.linux-magazin.de/Ausgaben/2004/10/Insel-Huepfer/%28language%29/ger-DE

Es behaupte dennoch niemand von sich, er sei besser als die Profis, denen das hier passiert ist. Die tückischsten Risiken sind eben immer die, die man nicht erkennt oder nicht für möglich hält.

Fazit

Wie sicher ist also Opensource ? Genauso sicher wie das Umfeld, in dem es zum Einsatz kommt und - um Hrn. Schmitz nochmal zu bemühen - so sicher wie die Standards, auf denen die "Open Source"-Komponenten ruhen.

"Open Source" hilft beim frühzeitigen Erkennen, Analysieren und Schließen von Sicherheitslücken. Es erspart einem aber nicht die Mühe der ständigen Analyse von Server-, Desktop und Netzwerk- wie Firewall-Logs. Es erspart einem nicht, sich schon vor und während des Einsatzes Gedanken über potentielle Angriffsvektoren im gesamten Netzwerk zu machen - das betrifft SW-Entwickler wie die Server-, Netzwerk- und Desktop-Administratoren gleichermaßen. Im Kompromittierungsfall erspart es einem bei einem einmal gerooteten Servern nicht eine Neuinstallation. Es erspart einem nicht ein kluge Passwort-, Zertifikats- und Backup-Politik.

Last but not least: Es erspart einem nicht eine regelmäßige Risiko-Analyse und -bewertung durch fachkundiges, vom Produktionsprozess unabhängiges Personal. Und es erspart einem nicht ein ständiges Arbeiten am Sicherheitsbewußtsein aller beteiligten Personen. Dafür braucht es Sicherheitsbeauftragte - auch in einem reinen "Open Source"-Umfeld.