INFSEC.de

Hallo zusammen,

zur Abwechslung mal was über Krypto. Ein Bekannter hat mir einen Hinweis gegeben, dass in einer Stargate SG1 Folge (S7E09 „Avenger 2.0“) auf einer Tafel etwas geschrieben stand, was recht „kryptisch“ aussieht. Hier ein Bild der Szene (ca. Minute 12):

Auf den ersten Blick vermutet man Java, was natürlich recht amüsant wäre: Ob (damals Sun) Oracle wohl eine JVM für Stargates (bzw. Wahlgeräte) anbietet? Tatsächlich ist es jedoch C#, was es nicht weniger amüsant macht. Da es eine über 10 Jahre alte Episode ist, ist dies natürlich auch anderen schon aufgefallen. Es handelt sich bei diesem Quelltext um eine etwas intensiver kommentierte Version einer Klasse zur Entschlüsselung von Dateien auf dem Dateisystem, die man hier finden kann. Analog gibt es natürlich auch eine Version zur Verschlüsselung.

Es ist natürlich so, dass die „Macher“ der Serie nur etwas kryptisch aussehenden Programmtext präsentieren wollten und sind dabei über diese Zeilen gestolpert. Aber aus Neugier habe ich mir das Programm etwas näher angesehen. Es besteht aus einer Hilfsklasse StoreCryptoStream, aus einer Klassenmethode zur Generierung des Schlüsselmaterials (GenerateKey) und einer weiteren Klassenmethode zur Vorbereitung und Durchführung der Entschlüsselung (DecryptData).

In der DecryptData-Methode werden Streams eingerichtet und die Entschlüsselung durchgeführt. Aufmerksam wurde ich, als ich mir die GenerateKey-Methode genauer angesehen habe, welche aus einer Passphrase (String) das zur Verschlüsselung (DES) passende Schlüsselmaterial generiert:

          symKey = new byte[8];
          symIV = new byte[8];

          SHA1_CSP sha = new SHA1_CSP();
          sha.Write(bt)
          sha.CloseStream();
          for (int i = 0; i < 8; i++) {
              symKey[i] = sha.Hash[i];
          }
          for (int i = 8; i < 16; i++) {
              symIV[i - 8] = sha.Hash[i];
          }

Das fand ich recht interessant: Hier werden, aus dem Hashwert (SHA1) der Passphrase (String), Schlüssel und Initialisierungsvektor abgeleitet. Da wir bei DES (DecryptData-Methode) eine 64 Bit Schlüssellänge (wovon 56 effektiv sind) und 64 Bit Blocklänge haben, brauchen wir also 128 Bit die uns durch den 160 Bit SHA1 zur Verfügung stehen. Ein Hashverfahren zu verwenden um aus einer Passphrase Schlüsselmaterial zu gewinnen ist ja nicht neu: Dies findet auch bei PBKDF2 statt. Es wird zur Erhöhung der Brute-Force-Resistenz eingesetzt, da die Berechnung eine gewisse Zeit in Anspruch nimmt und nicht abgekürzt werden kann. Dabei werden jedoch sehr viel mehr Iterationen durchgeführt (z.B. 100 000) und nicht nur eine.

Die meisten symmetrischen Blockchiffren benötigen keinen Initialisierungsvektor (IV): so auch der DES nicht. Da allerdings regelmäßig keine blockweise Verschlüsselung sondern ein Betriebsmodus zum Einsatz kommt, hat er einen festen Platz in den Programmbibliotheken. Normalerweise wird der IV vor der Verschlüsselung zufällig generiert und vor/nach der Übermittlung als Klartext mitgesendet. Der Empfänger kann mittels geheimen Schlüssels und mitgesendeten IVs das Chiffrat entschlüsseln. Die Generierung eines IVs aus der Passphrase hat den enormen praktischen Vorteil, dass diese dem verschlüsselten Ciphertext nicht beigefügt sein muss. Der Nachteil ist, dass der IV dann nicht mehr zufällig generiert wird sondern deterministisch vom Schlüssel bzw. der Passphrase abhängt.

So was Ähnliches wird zwar auch im SSH Protokoll durchgeführt. So wird dort unter Einsatz einer Hashfunktion und unterschiedlichen Salt-Werten mehrere Schlüssel und IVs generiert. Allerdings wird hierbei schon zu einem frühen Zeitpunkt der „Zufall“ eingebracht und genau diese Zufälligkeit fehlt beim gezeigten Programm vollständig.

Ist das jetzt gut oder schlecht? Ich habe dazu recherchiert und mir meine eigenen Gedanken gemacht und die Antwort ist: Es kommt darauf an, ist aber fast immer schlecht.

Nehmen wir z.B. Stromchiffren (wie, mittlerweile unsicher, RC4). Hier würde, bei gleichem Passwort, immer der gleiche IV und damit der gleiche Schlüsselstrom generiert werden. Sofern zwei verschlüsselte Texte mit dem gleichen Schlüsselstrom verschlüsselt sind, könnten diese gegenseitig ge-xor-t und damit der Schlüsselstrom herausgerechnet werden. Ebenso bei bei Blockchiffren mit dem entsprechenden Betriebsmodus wie dem Cipher Feedback Mode (CFB) oder dem Output Feedback Mode (OFB): Da hier aus einer Blockchiffre eine Stromchiffre konstruiert wird, haben wir exakt das gleiche Problem. Bei diesen Verfahren hängt die Sicherheit sehr stark an der Zufälligkeit des IVs, welcher so jedoch nicht mehr zufällig ist.

Wie ist es bei einer Blockchiffre im ECB und CBC Modus? Beim ECB-Modus sind wir schmerzfrei, denn dort wird der IV nicht verwendet. Müssen dabei jedoch die allgemeine Unsicherheit des ECBs hinnehmen. Beim CBC-Modus (den ich schonmal erklärt habe) haben wir zunächst auch kein Problem. Allerdings muss man hierbei gut aufpassen: Verschlüsselungsbibliotheken werden beim CBC-Modus den IV ans Ende des Chiffretextes setzen, da dieser üblicherweise zufällig generiert und zur Entschlüsselung gebraucht wird. Das bedeutet aber, dass wir dem verschlüsselten Text ein (Teil)Hash des Passwortes mitsenden! Möglicherweise kann genau dieser Teilhash dann in einer Rainbowtable für SHA1 gefunden und entschlüsselt werden. Ebenso erleichtern wir dem Angreifer die vollständige Schlüsselsuche beträchtlich. Allgemein wird der IV als „öffentlich“ angesehen und wird dementsprechend ungeschützt sein. Eine Klassifizierung, welcher ein einfacher SHA1 Hash der Passphrase nicht haben sollte.

Zusammenfassend sollte man den IV zufällig generieren und auch genau so verwenden. Nur wenn man ganz genau weiß was man tut, kann man von dieser Regel abweichen.

Wie ist es nun bei diesem Programm? Das ist leider nicht ganz klar, denn der Programmtext lässt sich (zumindest unter Visual Studio) nicht mehr übersetzen: in über 10 Jahren hat sich C# diesbezüglich weiterentwickelt. Man könnte das Programm zwar durch Anpassungen wieder lauffähig bekommen, würde jedoch damit ggf. auch die Funktionsweise beeinflussen. Es ist zu vermuten, dass hier der ECB-Modus zum Einsatz kam und so der IV keine Rolle spielt. Wenn der CBC eingesetzt wurde, müsste man prüfen, ob dem Ciphertext der IV beigelegt war. So oder so war jedoch schon damals (und ist heute weiterhin) von der Nutzung dieses Quelltextes (bzw. einer lauffähigen Variante) grundsätzlich abzuraten.

Dies könnte auch der Grund sein, weshalb der in dieser Episode programmierte „Avenger“ (Computervirus) so unsicher war ;-).

Hallo zusammen,

durch einen Beitrag von fefe bin ich auf diese Amazon Rezension aufmerksam geworden.

Bei diesem Produkt handelt es sich, soweit ich dies aus der Produktbeschreibung herauslesen konnte, um eine „smarte“ Steckdose, die über WLAN bzw. eine App gesteuert werden kann. Der Rezension nach basiert dies auf dem ESP8266-Chip, von welchem ich auch ein paar besitze. Sie sind derzeit der günstigste Weg (2-3€), eine (kleine) elektronische Schaltung ins WLAN zu bekommen sofern man keine zu hohen Ansprüche hat und etwas Geduld mitbringt.

Der Rezensionist hat sich etwas Mühe gemacht, das Gerät genauer unter die Lupe zu nehmen. Sofern sich die steuernde Hardware (Smartphone+App) im WLAN befindet, werden die Befehle wohl direkt an die Steckdose übermittelt. Sofern der Nutzer jedoch außer Haus ist, wird das Ganze über einen Server in China gelenkt:

If your phone is connected to the same network as the socket then this is just done by sending a command directly, but if not you send a command via an intermediate server in China (the socket connects to the server when it joins the wireless and then waits for commands).

Ich denke die technischen Gründe hierfür sind klar. Der Hersteller wollte damit Probleme durch wechselnde IP-Adressen und vor allem notwendige NAT-Weiterleitungsregeln umgehen. Es muss auch beachtet werden, dass insb. im asiatischen Raum die Verwendung von NAT deutlich intensiver ist als in Europa. Daher ist IPv6 dort auch schon weiter fortgeschritten als hier. Wäre interessant, ob die Steckdose hierfür im Sekundentakt (polling) eine Anfrage stellt und mit welchem Protokoll. Sinnvoll gelöst wäre es (mMn), wenn in gewissen Intervallen ein UDP-Datagramm gesendet und damit eine Lücke im NAT geöffnet wird, durch die der Server dann antworten kann, wenn es notwendig ist. Flusskontrolle ist hier ohnehin nicht gefragt und quittieren kann man die Befehle auch manuell.

Weiter geht’s in der Rezension:

The command packets look like they’re encrypted, but in reality there’s no real cryptography here at all. I wrote a simple program to decode the packets and looked at them in more detail. There’s a lot of unnecessary complexity in the packet format, but in the end the relevant things are just a command and the MAC address of the socket. On the local network this is sent directly to the socket, otherwise it goes via the server in China. The server looks at the address and uses that to decide which socket to pass it on to. Other than the destination, the packets are identical.
This is a huge problem. If anybody knows the MAC address of one of your sockets, they can control it from anywhere in the world. You can’t set a password to stop them, and a normal home router configuration won’t block this.

Hier ist natürlich ein Nerv getroffen. Hier scheint einfach die primitivste Form (Security by obscurity) gewählt worden zu sein: Die App übermittelt dem Server einen Befehl bzgl. einer MAC-Adresse und bei einer Anfrage von einer MAC-Adresse wird dieser Befehl weitergegeben. Hier ist natürlich offensichtlich, dass die MAC-Adresse Bestandteil des Protokolls ist, da diese auf dem Weg durch das Internet verloren geht. Eine Überprüfung findet daher nicht statt. Offenkundig kann daher jeder sowohl App, als auch Steckdose spielen.

Aber ich möchte die Sache noch etwas weiter durchdenken und überlegen, wie ICH dieses Problem gelöst hätte. Damit meine ich eine Lösung mit EINFACHEN MITTELN die auf dieser schwachbrüstigen Hardware auch funktionieren kann.

Die Tatsache, dass in der App kein Passwort hinterlegt werden kann, wäre zunächst mal noch kein Indikator für ein unsicheres Gerät. Die App könnte bei erstmaliger „Bekanntmachung“ mit der Steckdose passendes Schlüsselmaterial über WLAN austauschen, ähnlich wie bei Bluetooth: Bei erstmaliger Inbetriebnahme würfelt sich die Hardware einen Schlüssel. Hier muss noch beachtet werden, dass „Würfeln“ für diese Hardware ein schwieriges Problem ist. Daher würde ich bevorzugen, dass sowohl App, als auch Steckdose, gemeinsam ein Passwort ausknobeln. Die Smartphone-Hardware müsste gute Fähigkeiten dazu haben. Ob bei Nutzung mehrerer Smartphone-Apps verschiedene Passwörter Verwendung finden, lasse ich an dieser Stelle mal offen. Besser wäre es, aber notwendig wäre es nicht; kommt auf die Hardware an.

Das gemeinsam gefundene Schlüsselmaterial kann fortan die App verwenden um Befehle an die Steckdose zu verschlüsseln. Hierbei muss man eine Designentscheidung treffen: Möchte man einen Schutz der Vertraulichkeit und Integrität, oder genügt der Schutz der Integrität allein. Bei letzterem würde eine Hash-Funktion zur Absicherung genügen. Ich wähle ersteres, da der Aufwand nicht viel größer ist:

CMD = E(MAC + ZAEHLER + BEFEHL , SCHLUESSEL) + MAC

wobei E(Klartext,Schüssel)=Chiffretext eine symmetrische Verschlüsselungsfunktion (mit ordentlichem Betriebsmodus) und „+“ eine Konkatenation ist. So verschlüsseln wir den Befehl auf Basis des gemeinsam ausgetauschten Schlüsselmaterials. Der Zähler hat den Zweck, dass das Kryptogramm unabhängig vom Befehl (und unabhängig vom Betriebsmodus) nicht immer identisch aussieht. Durch die diffusiven Eigenschaften der Verschlüsselungsfunktion ändert sich das Kryptogramm bei Änderung des Zählers.

Hierbei haben wir jedoch noch das Problem des Replay-Angriffs vernachlässigt. Jemand, der dieses Kryptogramm abfängt, könnte diesen Befehl immer und immer wieder senden. Dies bekommt man mit einem Challenge-Response zunächst gelöst, würde das Protokoll jedoch wieder gegenüber Man-in-the-Middle angreifbar machen: theoreitisch ein Vorteil, aber nicht praktisch. Daher sehe ich hier nur zwei Möglichkeiten:

1. die Steckdose merkt sich den Zähler im Kryptogramm und ignoriert Befehle die darunter liegen oder
2. App und Steckdose besitzen synchronisierte Uhren.

Da Lösung 2 vermutlich über die Fähigkeiten der Hardware hinausgehen, muss man sich wohl mit 1 begnügen. Dabei muss man ggf. aber auch noch im Kopf behalten, dass dies beim Zugriff von mehreren Geräten/Apps gleichzeitig zu Problemen führt. Die bekommt man aber in den Griff.

Vermutlich wird man das Replay-Problem (oder ein verzögertes Senden) nicht mit einfachen Mitteln in den Griff bekommen. Jedoch wäre schon allein die Tatsache, dass nicht jeder in der Lage ist die Steckdose zu schalten und jeden Schaltprozess beobachten zu können. Ein Gewinn, der nur etwas mehr Implementierungsarbeit gekostet hätte.

Die Frage danach, inwieweit Personen mit Zugriff auf das WLAN auch (langfristig) Zugriff auf die Steckdose haben, lasse ich an dieser Stelle ebenfalls unbeachtet. Derzeit ist mein WLAN auch noch eine absolut vertrauenswürdige Zone für mich und die kürzliche Änderung des Telemediengesetzes wird daran wohl auch zunächst nichts ändern. Aber das ist eine andere Geschichte.