Mitternachtshacking

Seltsam, seltsam. Mal wieder ist einer dieser genialen, hochsicheren, unknackbaren, mit 256-Bit AES-Verschlüsselung werbenden USB-Sticks gehackt worden. Genaugenommen wurde mal wieder der PIN-Schutz umgangen und die Daten direkt aus dem Flash-Speicher ausgelesen.

Wobei sich mir direkt die Frage stellt, was denn da genau mit 256-Bit AES verschlüsselt worden ist. Die Daten können es ja nicht sein, wenn man sie einfach so auslesen kann. Die PIN vielleicht.

Mann-oh-mann, bei verschlüsselten USB-Sticks ist ja noch mehr Snake Oil auf dem Markt als bei Virenscannern!

Ich habe nicht die geringste Ahnung wie gut oder wie schlecht der Victorinox Secure USB-im-Taschenmesser-Stick abgesichert ist. Als regelmäßiger Flugpassagier habe ich für Taschenmesser auch nicht mehr so viel Verwendungszweck. Die Fummler am Flughafen nehmen einem die gerne mal ab. Und zu guter Letzt muß ich bei Victorinox immer an das Bild aus Asterix und der Arvernerschild denken, in dem Vercingetorix seine Waffen Cäsar auf die Füße knallt.

Was ich aber bei Bruce Schneier gelernt habe ist, daß ein Crypto-Wettbewerb mit der Aufgabe für eine Summe x (bei Victorinox sind das immerhin 100.000 Pfund) eine Verschlüsselung zu brechen kein Hinweis für gute Verschlüsselung sondern viel häufiger ein Hinweis auf Snake Oil Cryptography ist:

Warning Sign #9: Cracking contests: Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don’t produce useful data.

Ob das alles jetzt für oder gegen Victorinox spricht, kann ich leider nicht beurteilen. Vielleicht wurde Victorinox auch nur von einer schlechten Marketingagentur beraten.

Foto: AskDaveTaylor, Lizenz: CC

Tja … das ist mein VPN-Client, lieber Virenscanner

Aber macht ja nix … wenigstens ist es kein wichtiges Windows Programm.

(und das sind nur die Meldungen von Oktober und November 2008 seufz)

Nachtrag:

Der Fehler wurde mit dem nächsten Update behoben … aber täusche ich mich oder häufen sich die Probleme mit Virenscannern tatsächlich die letzten Jahre deutlich?

Es hat mal wieder eine SnakeOil-Verschlüsselung erwischt, diesmal die Digittrade Security Festplatte, schreibt Heise. Schuld ist der Controller IM7206 des chinesischen Herstellers Innmax. Wer diese Chips aber noch einsetzt ist selber schuld. Die Sicherheitsdefizite hat Heise schon im Februar aufgedeckt. Übrigens ist der Hintergrundartikel schön zum Lesen und erklärt anschaulich, wie man besonders schlechte Verschlüsselung aufdecken kann.

Lustig finde ich den Kommentar des Herstellers: “Der IM7206 bietet nur einen einfachen Schutz und zielt auf den Durchschnittsanwender”

Wie ist das eigentlich zu verstehen? Der Durchschnittsanwender braucht keine sichere Verschlüsselung? Nur die Topterroristen der Al-Quaida? Dabei ist es inzwischen doch genau umgekehrt. Gerade der Durchschnittsbürger braucht starke Verschlüsselung um sich vor Schnüffel-Schäuble und seinen SPD-Komplizen zu schützen. Naja, ich bleibe bei meiner Komplettverschlüsselung mit Utimaco SafeGuard Easy und packe wichtige Dateien dann nochmal in einen eigenen TrueCrypt-Container. Das soll mir erstmal einer zerlegen.

Wenn es mir die Zeit erlaubt, spiele ich gerne ein wenig mit Virenscannern rum. Insbesondere die erschreckend schlechte Erkennungsquote bei trivialen Dateiveränderungen fasziniert mich immer wieder. Im Rahmen der Vorbereitung eines Vortrags habe ich ein paar Tests durchgeführt um zu sehen, wie es mit Virenscannern eigentlich so aussieht. Dafür habe ich ein bekanntes Schadprogramm verwendet, hier die Remote-Komponente von NetBus 1.70 und gekuckt, wie gut die Virenscanner diese Datei erkennen.

NetBus 1.70 ist zwar steinalt, im Kaspersky-Weblog (Viren-Almanach Nr. 8, September 2008)  stand jedoch, daß im September eine Variante von NetBus als bestgetarnter Schädling aufgetaucht ist, daher dachte ich, jeder Virenscannerhersteller müsste ein gesteigertes Interesse daran haben, dieses Programm zu erkennen.

Dazu habe ich die Patch.exe einmal direkt an Virustotal geschickt, einmal als UPX (UPX 3.03w, Optionen -f –ultra-brute) gepacktes Executable, einmal als Winzip-Archiv (Winzip Pro 10.0, bzip2-Archiv, maximale Kompression), und einmal als Winzip-gepacktes UPX.

Hier sind die Ergebnisse …

(weiterlesen…)

Ich frage mich ja schon seit einiger Zeit, was sich das BSI mit “Chiasmus” da so als Verschlüsselungsalgorithmus ausgedacht hat.

Das BSI selbst schreibt über Chiasmus: “Kern des Programms ist der BSI-eigene symmetrische Blockchiffrieralgorithmus Chiasmus. […] Chiasmus verschlüsselt 64-Bit-Blöcke in Abhängigkeit eines 160-Bit-Schlüssels in 64-Bit-Blöcke. Chiasmus für Windows verwendet Chiasmus im CBC-Modus (Cipher block chaining). Die effektive Schlüssellänge beträgt 128 Bit, die restlichen 32 Bit bilden eine Checksumme.”

Leider ist der Algorithmus anscheinend geheim und da bei mir recht offensichtlich zur Zeit kein öffentliches Interesse an der Nutzung besteht, habe ich keinen direkten Zugriff auf die Chiasmus-Software. Aber es gibt ja das BSI GSTOOL, das es ebenfalls erlaubt mit Chiasmus Daten zu ver- und entschlüsseln und vielleicht gibt das ja schon mal ein paar Hinweise auf die Art und Weise der Verschlüsselung oder zumindest der Implementierung.

Das GSTOOL erlaubt es, eine Datenbankdatei mit einem vorhandenen Schlüsselfile zu verschlüsseln, die Erzeugung von Schlüsseldateien selbst ebenfalls möglich. Zudem verrät die Software, daß Chiasmus-Schlüsseldateien auf “ckf” enden, vermutlich für “Chiasmus Key File”. Ich habe deshalb einfach mal eine Datei chiasmus.ckf mit dem Inhalt “aaaaaaaaaaaaaaaaaaaa” erzeugt, denn 20 Zeichen je 8 Bit ergeben genau 160 Bit.

Als nächstes habe ich eine definierte Datei zur Verschlüsselung erzeugt. Eine echte MDB-Datei zu verschlüsseln ist einfach nicht aussagekräftig. Die Datei dazu ist einfach ein Textfile mit der Endung .mdb und dem Inhalt “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa”, also 40 mal der Buchstabe “a”. Der folgende Screenshot zeigt, wie sich das im GSTOOL darstellt:

Interessanterweise ließ sich meine Datei verschlüsseln. Das Ergebnis ist eine Datei mit diesem Inhalt: “GSTOOL 3.0 - Chiasmus Encrypted File - OriginalFileSize:0000000000000040P2–VßÏQKP2–VßÏQKP2–VßÏQKP2–VßÏQKP2–VßÏQK
*€ðþ”

Die von mir verwendete GSTOOL-Version war 4.5, die aktuell von der Webseite des BSI zum Download angeboten wird. Das ist aber eigentlich egal. Interessant ist die im GSTOOL verwendete Chiasmus-Implementierung:

1. Die Schlüsseldatei mit 20 x a kann niemals eine Schlüsseldatei sein die aus einem 128 Bit Schlüssel und 32 Bit gültiger Prüfsumme besteht. Wenn Chiasmus tatsächlich eine solche Prüfsumme verwendet und nur der Schlüssel in der Datei steht, dann ignoriert die im GSTOOL verwendete Implementierung diese Prüfsumme einfach. Es gab bei der Verwendung des Schlüssels auch keine Warnung oder Fehlermeldung. Im Zweifelsfall wäre einfach mit einem korrupten Keyfile verschlüsselt worden. Das alleine finde ich schon mal nicht nett. Denkbar ist natürlich auch, daß eine Datei die keinen korrekten Schlüssel mit Prüfsumme enthält als Passwort-Datei interpretiert wird. Eine Verschlüsselung mit einem Keyfile, das nur ein “a” enthält funktioniert nämlich auch und die vom GSTOOL erzeugten Schlüsselfiles sind mit 104 Byte deutlich länger als 160 Bit. Aber selbst dann hätte ich zumindest gerne eine Warnung.

2. Von Cipher Block Chaining kann auch nicht die Rede sein. Man sieht den Chiasmus-Header der nach der Ziffer 0000000000000040 endet denn die Originaldatei war 40 Zeichen lang. “P2–VßÏQK” ist der erste verschlüsselte Datenblock, 8 Zeichen, also verwendet Chiasmus tatsächlich 64-Bit Datenblöcke bei der Verschlüsselung. Dieser Block wiederholt sich identisch fünf mal. Danach kommt ein Newline und vermutlich eine Prüfsumme über die Datei (die bei der Entschlüsselung mit dem GSTOOL nicht überprüft wird). Bei Cipher Block Chaining sollte jedoch jeder Datenblock mittels XOR mit dem verschlüsselten vorherigen Datenblock verknüpft werden, damit eben gerade zwei identische Datenblöcke nicht den gleichen Cryptotext ergeben. Implementiert ist offensichtlich statt dessen der Electronic Code Book Mode.

Das wirft ein paar Probleme auf. Zum einen besteht bei einer fehlerhaften Implementierung von Chiasmus im GSTOOL die Gefahr, daß Mitarbeiter von Behörden die mit dem GSTOOL arbeiten, sich auf die Sicherheit der Datenverschlüsselung verlassen. Die ist jedoch mangels Cipher Block Chaining deutlich schwächer als erwartet. Zum anderen besteht die Gefahr, daß sich mit dem GSTOOL verschlüsselte Daten nicht mehr mit anderen Chiasmus-Implementierungen entschlüsseln lassen, die den Algorithmus korrekt implementieren.

Ich habe ja inzwischen den ernsthaften Verdacht, daß die im GSTOOL enthaltene Chiasmus-Implementierung mit der ebenfall vom BSI angebotenen Software “Chiasmus für Windows 1.7” überhaupt nichts zu tun hat. Beispielsweise enthalten verschlüsselte Chiasmus für Windows Dateien den Anfang “XIA1″. Aber gerade darum ist der Etikettenschwindel auch im Hinblick auf legitime Gründe zur Geheimhaltung von Daten in Behörden nicht gerade klug. Anwender die ihre Grundschutzdaten sicher mit Chiasmus verschlüsselt glauben, werden über die tatsächliche Sicherheit getäuscht.

Snake Oil?

Ich freue mich ja immer, wenn ich unaufgefordert Werbung zu Snake Oil Security Produkten bekomme. Das gibt immer wieder einen schönen Blog-Eintrag.

Heute habe ich Spam eine gaaanz tolle Produktinformation der Firma Supernova Savernova bekommen, die eine gaaanz tolle Gridkarte für gaaanz tolle Passwörter anbieten. Gridkarten sind einfach Papp- oder Plastikkarten die je nach Ausstattung entweder Ziffern (für PINs) oder alphanumerische Zeichen für Passwörter in einer Tabelle anordnen und der Nutzer merkt sich dann entweder den Anfang (G3) und die Lese-Richtung (nach rechts) um sein Passwort wiederzufinden oder er wird nach mehreren Feldern (F5, A2, E4) zur Authentisierung gefragt. Das funktioniert dann wie Schiffe versenken. Im Grunde nix, das man sich nicht mit ein paar Zeilen Perl und/oder einem Radius-Server selbst basteln könnte.

Bei Savernova sieht die kostenfreie Ausdruckkarte (PDF) dann so aus:

Das ist zwar nicht ganz wie “Passwort aufschreiben” (außer, die 11 Felder rechts sind so gedacht, daß man da die Passwörter notiert) aber schon fast. Wenn jemand die Karte in die Hand bekommt, lassen sich nur endlich viele verschiedene Passwörter draus erzeugen. Die kann man ruckzuck durchprobieren. Und wenn man die Karte verliert, dann hat man das Passwort leider nicht mehr (oder man hat glücklicherweise das Passwort mittels Textmarker auf der Backupkarte markiert).

Andererseits ist das Marketing nicht blöd. Zum einen klingt der Claim “Savernova – Swiss IT Security” nach der Qualität eines Schweizer Armeetaschenmessers. Zum anderen die Verlinkung: “Unternehmen können die Webkarten mit eigenem Logo personalisieren und auf ihrer Homepage unlimitiert und kostenfrei zur Verfügung stellen.” So schafft man sich zumindest Bekanntheit.

Ich habe leider nicht herausgefunden, wie viel Savernova kosten soll. Bei PC-Welt gibt es jedenfalls Codestar für 20 Euro. Da kann man sich auch lustige bunte Passwort-Karten ausdrucken, einen Farbdrucker vorausgesetzt. Ok, da ist die berüchtigte Middleware nicht dabei, mit der sich die Passwortkarten an die Unternehmens-IT anbinden lassen. Aber will das wirklich irgendwer (PDF)?

Naja, für einige Leute mag die Passwortkarte ja ganz praktisch sein und erfreulicherweise wird bei jedem Aufruf eine andere Karte generiert (auch wenn ich nicht weiß, was die ID und der SecureCode darauf bedeuten soll). Allerdings darf man sich den Webserver auch nicht so genau ankucken. Manuell eingegebene URLs mag der nämlich nicht:

Also doch besser mit Perl selbst was gebastelt. Das funktioniert dann auch mit Linux. Oder weiter Schiffe versenken gespielt.

Ok, es ist vorbei. Das ganze Thema “Hacking” ist offensichtlich gelaufen. Wir sind jetzt endgültig absolut sicher. Aber nicht wegen dem § 202c, nein, nein. Statt dessen haben wir das der EADS und ihrem Ectocrypt-System zu verdanken.

“A team of researchers and engineers at a UK division of Franco-German aerospace giant EADS has developed what it believes is the world’s first hacker-proof encryption technology for the internet.”

Quelle: Telegraph.co.uk. Hier gibt es sogar ein lustiges Video und ein Datenblatt (PDF) dazu.

Hmm, mal testen …

• Secret System … ja, geheime EADS Technologie ohne veröffentlichten Details
• Technobabble … ja, z.B. “High Assurance Internet Protocol Encryptor (HAIPE)”, “lightning speed key scambling and re-formatting”
• Unbreakable … ja, offensichtlich
• One-time Pads … nein, leider nicht

75% Übereinstimmung mit der Definition für Snake Oil Cryptography.

Ich persönlich gebe der Technologie ja so ca. 12 Monate, bevor die NSA eine fette Lücke gefunden hat und das System wertlos ist. Ich fürchte, die Jungs bei der EADS sollte nicht so viel Ghostbusters kucken. Viel witziger hätte ich ja gefunden, wenn die Jungs ihre Verschlüsselung “Clearstream” genannt hätten.

Die Jungs (und Mädels) von Tweakers.net haben einen Secustick von Sipal International zerlegt, der angeblich absolut sicheren USB-Speicher anbietet. Die Daten werden geschützt auf dem Stick abgelegt und nach mehrfacher falscher Passwort-Eingabe automatisch gelöscht … angeblich.

Mit ein wenig Fummeln und Debuggen am Stick, wie in diesem Artikel beschrieben, haben die Holländer den gesamten Schutz umgangen und sind auf einfachste (und reproduzierbare) Weise an alle geschützten Daten gekommen. Der Trick besteht einfach darin, in der Abfrageroutine des Passworts mit einem Debugger einen Breakpunkt zu setzen und dann den Rückgabewert für ein falsches Passwort auf den Wert für ein richtiges Passwort (1 statt 0) zu ändern.

“Normally, the amount of security is sufficient, not everyone has the technical expertise that you have”, said a spokesperson.

Für Bruce Schneier ist das ein typisches Beispiel für “Snake-Oil Security”. Ich finde, da hat er recht.

Gerade im Internet gefunden: Bruce Schneier Facts:

Sehr gut gefallen mir diese:

• Bruce Schneier once beat an asymmetric cipher into symmetry.
• Bruce Schneier’s secure handshake is so strong, you won’t be able to exchange keys with anyone else for days.
• When Bruce Schneier observes a quantum particle, it remains in the same state until he has finished observing it.
• For Bruce Schneier, SHA-1 is merely a compression algorithm.
• Bruce Schneier writes his books and essays by generating random alphanumeric text of an appropriate length and then decrypting it.
• Bruce Schneier is not only the man-in-the-middle, he’s at both ends and has wiretaps on Alice, Bob, Carol and Dave.
• Bruce Schneier can crack a one-time pad before it’s used.
• Bruce Schneier’s car is powered by Snake Oil instead of fossil fuels.

Für die weniger informierten Leser: Bruce Schneier ist der Autor von “Applied Cryptograph” und “Secrets and Lies”, außerdem der Entwickler der Verschlüsselungsalgorithmen Blowfish und Twofish. Die Bruce Schneier Facts sind im Stil der bekannteren Chuck Norris Facts geschrieben.