Die häufigsten Muster für den Fehlgebrauch von Kryptografie

Der Electronic-Codebook-(ECB-)Modus verschlüsselt jeden Block unabhängig mit demselben Schlüssel. Identische Klartextblöcke erzeugen identische Chiffratblöcke. Die klassische Demonstration ist der „ECB-Pinguin“: Wird ein Bitmapbild im ECB-Modus verschlüsselt, bleibt die Struktur des Bildes auf Blockebene erhalten, sodass der Umriss des Pinguins im Chiffrat deutlich sichtbar bleibt. Der ECB-Modus bietet keine semantische Sicherheit und sollte niemals für praktische Verschlüsselungszwecke verwendet werden.

Die kryptografischen Primitive selbst zu implementieren gehört zu den gefährlichsten Praktiken in der Softwareentwicklung. Kryptografie muss unter Bedingungen mit einem Angreifer als Gegenüber vollkommen korrekt funktionieren: Ein subtiler Timing-Leak, ein Off-by-one-Fehler beim Padding oder ein Missverständnis der Sicherheitsanforderungen kann ausnutzbare Sicherheitslücken erzeugen, die sich bei normalen Tests nicht von korrektem Verhalten unterscheiden lassen. Selbst erfahrene Kryptografen machen Implementierungsfehler; Anwendungsentwickler sollten ausschließlich gut geprüfte Bibliotheken verwenden.

MD5 gilt seit 2004 als kollisionsgebrochen; zwei Dateien mit demselben MD5-Hash zu erzeugen, ist mit geringem Rechenaufwand möglich. Praktische Kollisionsangriffe auf SHA-1 wurden 2017 durch Googles SHAttered-Angriff demonstriert, bei dem zwei PDF-Dateien mit demselben SHA-1-Hash erzeugt wurden. Keine der beiden Funktionen sollte für Sicherheitszwecke verwendet werden: weder für digitale Signaturen, die Integrität von Inhalten, die Passwortspeicherung noch für HMAC. Verwenden Sie für moderne Systeme SHA-256, SHA-3 oder BLAKE2.

Die Verwendung von time() oder anderen vorhersehbaren Werten als Startwert für einen Pseudozufallszahlengenerator ist eine kritische Sicherheitslücke, wenn die Ausgabe des PRNG für Sicherheitszwecke verwendet wird. Ein Angreifer, der ungefähr weiß, wann ein Schlüssel erzeugt wurde, kann den möglichen Bereich der Startwerte (alle Zeitstempel in einem kleinen Zeitfenster) per Brute-Force durchsuchen und den Schlüssel rekonstruieren. Ein klassisches Beispiel: Frühe Versionen von Netscape verwendeten die Zeit und die Prozess-ID zum Erzeugen von SSL-Schlüsseln; beides konnte ein Angreifer auf demselben Rechner beobachten.

rand() in C, java.util.Random und Pythons Modul random verwenden deterministische lineare Kongruenzgeneratoren oder den Mersenne-Twister. Diese sind für statistische Qualität in Simulationen ausgelegt, nicht für Sicherheit. Ein Angreifer, der genügend Ausgaben dieser Generatoren beobachtet, kann ihren internen Zustand rekonstruieren und alle zukünftigen Ausgaben vorhersagen. Verwenden Sie für Sicherheitszwecke vom Betriebssystem bereitgestellte CSPRNGs: secrets.token_bytes() in Python, crypto.randomBytes() in Node.js oder /dev/urandom unter Linux.

Verschlüsselung ohne Authentifizierung bietet nur Vertraulichkeit, nicht aber Integrität. Ein Angreifer, der den Klartext nicht lesen kann, kann das Chiffrat dennoch verändern und dadurch möglicherweise vorhersehbare Änderungen am Klartext bewirken (insbesondere im CTR- oder CBC-Modus). Diese Manipulierbarkeit ermöglicht Angriffe: Ein Angreifer, der eine verschlüsselte Banktransaktion abfängt, kann Bits umkehren und so den Überweisungsbetrag oder das Zielkonto ändern, ohne den Klartext zu kennen. Verwenden Sie immer authentifizierte Verschlüsselung (AEAD).

Das Festschreiben von Verschlüsselungsschlüsseln oder Initialisierungsvektoren im Quellcode ist eine kritische Sicherheitslücke. Quellcode wird häufig in Versionsverwaltungssysteme eingecheckt, manchmal in öffentliche. Selbst in privaten Repositorys kann jeder mit Zugriff auf den Code den Schlüssel verwenden. Fest hinterlegte Schlüssel bedeuten, dass alle Instanzen denselben Schlüssel verwenden, und eine Schlüsselrotation erfordert eine erneute Bereitstellung. Schlüssel müssen in Umgebungsvariablen, Systemen zur Verwaltung von Geheimnissen (HashiCorp Vault, AWS Secrets Manager) oder Hardware-Sicherheitsmodulen gespeichert werden.

Die Verwendung desselben Initialisierungsvektors für mehrere Verschlüsselungen mit demselben Schlüssel erzeugt schwerwiegende Sicherheitslücken. Im CTR-Modus erzeugt die Wiederverwendung des IV denselben Schlüsselstrom, wodurch sich der Klartext über XOR rekonstruieren lässt. Im CBC-Modus kann ein Angreifer durch die Wiederverwendung des IV erkennen, wann zwei Nachrichten mit denselben Klartextblöcken beginnen. Im GCM-Modus ist die Wiederverwendung der Nonce (IV) katastrophal (siehe die Lektion zur Nonce-Wiederverwendung). Erzeugen Sie für jede Verschlüsselungsoperation einen neuen zufälligen IV und stellen Sie ihn zur Speicherung gemeinsam mit dem Entschlüsselungskontext dem Chiffrat voran.

Passwörter mit MD5, SHA-256 oder einer anderen schnellen kryptografischen Hashfunktion zu speichern, ist unzureichend. Moderne GPUs können Milliarden SHA-256-Hashes pro Sekunde berechnen, wodurch Offline-Brute-Force-Angriffe auf gestohlene Hash-Datenbanken trivial schnell werden. Passwort-Hashing erfordert speziell dafür entwickelte langsame, speicherintensive Funktionen: bcrypt, scrypt oder Argon2id. Diese sind darauf ausgelegt, Brute-Force-Angriffe selbst mit spezialisierter Hardware teuer zu machen und Offline-Angriffe rechnerisch praktisch unmöglich zu halten.

Das Deaktivieren der SSL/TLS-Zertifikatsprüfung (durch Setzen von ssl.CERT_NONE in Python, Übergabe von -k an curl oder Setzen von trustAllCerts=true in Android) beseitigt den Schutz vor Man-in-the-Middle-Angriffen. Ein Angreifer kann jedes beliebige Zertifikat vorlegen und die gesamte Kommunikation abfangen. Dieses Vorgehen wird in der Entwicklung eingesetzt, um Fehler durch selbstsignierte Zertifikate zu umgehen, bleibt aber häufig in der Produktion bestehen. Verwenden Sie immer eine korrekte Zertifikatsprüfung und beheben Sie die zugrunde liegenden Zertifikatsprobleme ordnungsgemäß.

Kryptografische Funktionen melden Fehler über Rückgabewerte oder Ausnahmen. Werden diese ignoriert, kann die Ausführung mit einem ungültigen Zustand fortgesetzt werden: etwa nach einer Entschlüsselung, die unbrauchbare Daten erzeugt hat, einer fehlgeschlagenen Verifizierung oder einer fehlerhaften Schlüsselerzeugung. Bei C-basierten APIs wie OpenSSL ist das Ignorieren von Rückgabewerten besonders gefährlich, da das Programm möglicherweise mit nicht initialisiertem Speicher fortfährt. Prüfen Sie immer jeden Rückgabewert kryptografischer Funktionen und behandeln Sie Fehler sicher.

Warum gilt der ECB-Modus (Electronic Codebook) als unsicher für die Verschlüsselung von Daten?

Die wichtigsten zu vermeidenden Fehlanwendungen: Verwenden Sie niemals den ECB-Modus (Preisgabe von Blockmustern), implementieren Sie niemals kryptografische Primitive selbst, lehnen Sie MD5 und SHA-1 für Sicherheitszwecke ab, initialisieren Sie PRNGs nicht mit time(), sondern mit einem CSPRNG, verwenden Sie für alle sicherheitsrelevanten Zufallswerte einen CSPRNG, authentifizieren Sie verschlüsselte Daten immer (AEAD), hinterlegen Sie Schlüssel oder IVs niemals fest im Code, erzeugen Sie für jede Verschlüsselung einen neuen IV, verwenden Sie für Passwörter Argon2id statt schneller Hashfunktionen, prüfen Sie TLS-Zertifikate immer und kontrollieren Sie jeden Rückgabewert kryptografischer Funktionen.