Open Source Sicherheit: Warum offener Code wichtig ist
Macht offener Quellcode sicherer? Was Kerckhoffs’ Prinzip besagt, was Audits leisten und warum Code, der bei jedem Aufruf neu kommt, ein Sonderfall ist.
In der Welt der Datensicherheit gibt es eine eiserne Regel: Vertraue niemandem blind, vertraue nur dem, was du überprüfen kannst. Genau hier setzt die Diskussion um Open Source Sicherheit an.
Das Dilemma der Nutzer
Für viele Nutzer stellt sich die Frage: Warum sollte Software, deren Bauplan für jeden Hacker sichtbar im Netz liegt, sicherer sein als ein geheimes, gut bewachtes Programm? Die Antwort auf diese Frage bildet das Fundament für Tools wie Crypto-Burri und moderne Sicherheitsinfrastrukturen weltweit.
Das Vertrauensproblem bei proprietärer Sicherheits-Software
Stell dir vor, du kaufst einen Tresor, aber der Hersteller weigert sich, dir zu erklären, wie der Schließmechanismus funktioniert. Bei geschlossener (proprietärer) Software stehst du vor demselben Problem.
Wenn Schwachstellen oder eingebaute Hintertüren (Backdoors) existieren, bleiben diese den Nutzern verborgen. Forscher haben keine Möglichkeit, die Versprechen der Hersteller zu überprüfen. Bei sicherheitskritischen Werkzeugen wiegt dieses blinde Vertrauen schwer - deshalb ist Nachprüfbarkeit dort ein eigenes Kriterium.
Was bedeutet Open Source genau?
Open Source bedeutet schlichtweg, dass der Quellcode öffentlich zugänglich ist. Jeder, der über Programmierkenntnisse verfügt, kann den Code analysieren und modifizieren.
Im Kontext der Cybersicherheit bedeutet offener Code nicht, dass Passwörter öffentlich sind, sondern lediglich die Mechanik der Verschlüsselung. Dieses Prinzip der Open Source Sicherheit ermöglicht radikale Transparenz: Die Sicherheit beruht nicht auf Geheimhaltung, sondern auf der mathematischen und strukturellen Stärke der bewährten Algorithmen.
Warum 'Security through Obscurity' nicht funktioniert
Der Ansatz, Sicherheit durch Geheimhaltung des Systems zu erreichen, wird als Security through Obscurity bezeichnet. Die Geschichte der Kryptographie hat gezeigt: Dieser Ansatz scheitert zwangsläufig.
Kerckhoffs' Prinzip
Ein System ist nicht sicher, nur weil sein Aufbau geheim ist; es ist erst sicher, wenn sein Aufbau bekannt ist und trotzdem niemand einen Fehler findet. AES ist das Musterbeispiel: in einem offenen Wettbewerb ausgewählt, seither öffentlich analysiert. Open Source Sicherheit stützt sich auf Kerckhoffs' Prinzip: Offene Systeme überleben den ständigen Angriff der besten Köpfe weltweit. Nur durch offene Überprüfung entsteht echtes Vertrauen.
Wie öffentliche Audits und Bug-Bounties funktionieren
Die wahre Stärke von Open Source Sicherheit entfaltet sich durch die globale Community. Unabhängige Sicherheitsforscher und Entwickler prüfen den Code kontinuierlich.
Viele Projekte lassen ihren Code durch IT-Sicherheitsfirmen auditieren (Security Audits). Zusätzlich motivieren Bug-Bounty-Programme Hacker dazu, Fehler zu suchen. Finden sie eine Sicherheitslücke (Vulnerability) und melden diese verantwortungsvoll, erhalten sie eine Belohnung. Der Anreiz kehrt die Ökonomie um: Eine gemeldete Lücke bringt Geld, eine verschwiegene nur Risiko.
Welche Bibliotheken wir verwenden — und warum
Um ein Höchstmaß an Open Source Sicherheit zu gewährleisten, entwickelt Crypto-Burri das Rad nicht neu, sondern setzt auf kampferprobte Open-Source-Bibliotheken.
Für die PGP-Funktionen kommt die Bibliothek OpenPGP.js zum Einsatz, die unabhängig geprüft wird; wie das Verfahren dahinter arbeitet, steht in der PGP-Einführung. Durch die Nutzung der modernen Web Cryptography API stellen wir sicher, dass Schlüssel unsere Server nie berühren. Unsere Architektur basiert auf dem Zero-Trust-Prinzip: Du kannst den Code selbst inspizieren und musst uns nicht blind vertrauen.
Fazit: Offener Code als Basis für echtes Vertrauen
Trotz aller Vorteile gilt: Nur weil ein Code offen zugänglich ist, bedeutet das nicht automatisch, dass er zu 100 % sicher ist. Die Open Source Sicherheit lebt von der aktiven Überprüfung durch die Community.
Es ist essenziell, nicht blind auf jedes Tool zu vertrauen, sondern auf weit verbreitete und regelmäßig geprüfte Projekte zu setzen. Offener Quelltext ist damit keine Garantie, aber die Voraussetzung dafür, dass eine Prüfung überhaupt möglich ist.
Der Sonderfall Browser: Code, der bei jedem Aufruf neu kommt
Bei installierter Software lässt sich prüfen, was auf dem Rechner liegt: Signatur kontrollieren, Prüfsumme vergleichen, im Zweifel selbst übersetzen. Eine Webanwendung entzieht sich dem. Der JavaScript-Code wird bei jedem Aufruf neu vom Server geladen, und niemand garantiert, dass die nächste Auslieferung derselbe Code ist wie die letzte - auch nicht, dass alle Besucher dieselbe erhalten. Was das für Schlüssel bedeutet, die im Browser entstehen, behandelt der Artikel zu Zero Knowledge Proofs.
Für Aufgaben, bei denen nichts das Gerät verlässt - eine Prüfsumme bilden, ein Passwort erzeugen, eine Datei lokal verschlüsseln - ist das trotzdem meist vertretbar: Selbst manipulierter Code kann ohne Netzwerkzugriff nichts abfliessen lassen, und ein solcher Zugriff fällt in den Entwicklerwerkzeugen des Browsers auf.
Wo die Grenze verläuft
Anders liegt der Fall bei langfristigen Geheimnissen. Einen privaten Hauptschlüssel oder das Passwort eines Passwortmanagers sollte man nicht in einer Seite eingeben, die bei jedem Aufruf neu geladen wird - dafür sind quelloffene, installierte und reproduzierbar übersetzte Programme der richtige Ort. Die Faustregel: Der Browser eignet sich für Einzeloperationen mit begrenzter Tragweite, nicht für die Verwahrung dessen, woran alles andere hängt.
Wenn offener Code trotzdem versagt
Die Annahme "viele Augen sehen jeden Fehler" hält der Praxis nur bedingt stand. Sie setzt voraus, dass tatsächlich jemand hinsieht - und genau daran fehlt es oft.
Der deutlichste Fall ist die Hintertür in den xz-utils, die im März 2024 bekannt wurde (CVE-2024-3094). Über rund zwei Jahre hatte sich eine Person das Vertrauen des überlasteten Hauptentwicklers erarbeitet, bis sie selbst Freigaben erteilen durfte, und schleuste dann Schadcode ein, der den SSH-Zugang praktisch jeder betroffenen Linux-Installation geöffnet hätte. Der Code lag die ganze Zeit offen. Aufgefallen ist er nicht bei einer Prüfung, sondern weil einem Entwickler eine Anmeldung ein halbes Zehntel Sekunde zu lange dauerte.
Ähnlich lagen die Dinge bei Heartbleed: Die Lücke steckte zwei Jahre lang in OpenSSL, einer der meistgenutzten Bibliotheken überhaupt, die damals von einer Handvoll Freiwilliger gepflegt wurde.
Was das für die Auswahl bedeutet
Offenheit ist die Voraussetzung für Prüfbarkeit, nicht deren Ersatz. Aussagekräftig ist deshalb weniger die Lizenz als die Frage, ob ein Projekt genügend Menschen hat, ob veröffentlichte Audits vorliegen und ob sich die ausgelieferte Fassung reproduzierbar aus dem Quelltext erzeugen lässt. Ein kleines, unbeachtetes Projekt mit offenem Code ist nicht sicherer als ein geprüftes geschlossenes - es ist nur überprüfbar, falls jemand die Arbeit auf sich nimmt.