© violetkaipa - Fotolia.com

Häufige Schwachstellen in der Verschlüsselung durch Apps

Nachdem kurz nach der WhatsApp Übernahme die Suche nach und Diskussion über einen sicheren Messenger begann, möchte ich im Folgenden kurz auf die häufigsten Fehler aufmerksam machen, die App-Entwickler bei der Implementierung von Verschlüsselung zur Datenübertragung machen.

Schwachstelle 1: Die App nutzt einen gleichbleibenden, symmetrischen Schlüssel

Leider immer noch sehr häufig in Verwendung - gleichbleibendene, symmetrische Schlüssel.

symmetrische Verschlüsselung

Das Risiko liegt klar auf der Hand. Der Schlüssel muss im Client zu irgendeiner Zeit im Klartext vorliegen und kann ausgelesen werden. Ab diesem Punkt ist jede Verschlüsselung hinfällig - die Kommunikation jedes Clients kann entschlüsselt werden.

Schwachstelle 2: Die App nutzt den ECB Verschlusselungsmodus

Den ECB Verschlüsselungsmodus habe ich bereits in folgendem Beitrag beschrieben. Gleiche Klartext-Blöcke führen stets zu gleichen Cipher-Blöcken.

ECB Mode Schwachstelle
Darstellung des Klar- und Chiffretextes im ECB Modus.

Apps nutzen (zwangsläufig) ein standartisiertes Kommunikationsprotokoll für ihre Server-Kommunikation. Echte Sicherheit im ECB Modus ist kaum realisierbar.

Verschlüsselungsmodus ECB

Schwachstelle 3: Die App nutzt keinen randomisierten Initialisierungsvektor im CBC Mode

Die Sicherheit von CBC Modus hängt maßgeblich vom IV ab. Ist der IV nicht zufällig oder gar statisch, kommt, wie im ECB Modus, kein unterschiedlicher Cipher-Block bei gleichem Klartext-Block heraus.

Verschlüsselungsmodus CBC

Schwachstelle 4: Die App nutzt einen konstanten Salt für Passwort-Hashes

Die Verwendung eines Salts hilft zuverlässig gegen vorberechnete Rainbowtables und zur Stärkung schwacher Passwort-Hashes. Schwache Passwort-Hashes entstehen beispielsweise durch die Verwendung sehr einfacher oder kurzer Passwörter. Der Rechenaufwand zur Erstellung eines Salt-Spezifischen Rainbowtables lässt sich drastisch reduzieren, in dem für jeden Passwort Hash derselbe Salt verwendet wird. In diesem Fall können mit einer Rainbowtable alle Hashes geprüft werden.

Schwachstelle 5: Die App nutzt wenige Iterationen zum Hashen von Passwörtern

Der Aufwand zum Überprüfen eines Hashes lässt sich drastisch erhöhen, indem der Klartext mehrfach gehashed wird. Gängig werden mehr als 1000 Iterationen mit einem als sicher geltenden, salted Hash-Algorithmus (z.B. SHA512) als Minimum empfohlen.

Deutlich sicherer lässt sich der Vorgang z.B. mit BCrypt gestalten, siehe folgenden Heise Artikel: Heise.de - Passworter unknackbar speichern.

Schwachstelle 6: Der Zufallszahlengenerator wird mit einem statischen Wert geseedet

Zufallszahlengenerstoren brauchen einen dynamischen Seed, um korrekt zu funktionieren. Die Verwendung eines statischen Seeds macht die Sicherheit eines CSPRNG kaputt.

Eine Studie der University of California, Santa Barbara hat über 11000 beliebte Apps geprüft und herausgefunden, dass über 88% der Apps mindestens eine, der oberen sehr groben Implementierungsfehler enthält. Der Hinweis, dass eine App AES verwendet bedeutet noch lange nicht, dass diese auch nur rudimentär abhörsicher ist. Verschlüsselung korrekt zu implementieren, benötigt umfangreiche Skills, die Verwendung einer fertigen Standard-Bibliothek ist nicht gleichzusetzen mit der Aussage, dass die App einen hohen Sicherheitsstandard erreicht.

Weitere Fehler, die immer wieder auftauchen:

  • es wird ein eigener Chiper entwickelt und verwendet,
  • der IV wird aus dem Key ableitet,
  • Standards wie AES werden verändert oder erweitert (im konkreten Fall hat eine App die AES Substitutionsboxen verändert),
  • Plain-MD5 wird zum Hashen eines Passworts verwendet oder
  • zu niedrige Schlüsselstärken werden verwenden.

Die korrekte Implementierung eines Verschlüsselungs-Algorithmus bedarf einiges an Erfahrung. App- Entwickler sollten sicherstellen, dass wenigstens die gerade genannten, groben Fehler nicht auftauchen.

Auch die Verwendung einer fertigen Bibliothek erspart einem Entwickler nicht die Arbeit, sich vorher umfangreich mit Verschlüsselung auseinander gesetzt zu haben.

Bildnachweis:

  • Beitragsbild: © violetkaipa - Fotolia.com
  • [1] Das Bild ist Public Domain / Quelle: https://en.wikipedia.org/wiki/File:ECB_encryption.svg
  • [2] Das Bild ist Public Domain / Quelle: https://en.wikipedia.org/wiki/File:CBC_encryption.svg

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert