Asymmetrische Steganografie/Public-Key-Steganografie (kurz PKS)

Theorie der PKS

 Optimal wäre die PKS in monolithischer Form: Die Information wird mit dem öffentlichen Schlüssel des Empfängers eingebettet und nur der Empfänger kann die Information mit seinem privaten Schlüssel extrahieren. In gleicher Weise funktioniert ja die Pulic-Key-Kryptografie schon seit den 90ern.

Die PKS benötigt man zur unauffälligen und nicht nachweisbaren Kontaktaufnahme und auch anschießender Kommunikation z. B. über anonyme Email-Accounts. Allein mit Public-Key-Kryptografie ist dies nicht zu erreichen, denn eine nur verschlüsselte Nachricht kann leicht gefunden werden.
Wichtig ist dies beispielsweise für Journalisten und Informantenschutz, denn auch schon die Information wann eine verschlüsselte Nachricht geschickt wurde, kann einen Informanten verraten! Zudem kann man auch aus der Größe einer verschlüsselten Nachricht Schlüsse ziehen; beispielsweise kann in einer kleinen verschlüsselten Nachricht keine große Nachricht untergebracht sein, sofern auch mit Kompression die unverschlüsselte Nachricht zu groß ist um hinein zu passen.
Die Praxis zeigt auch, das Staatsanwälte gerne in verschlüsselte Nachrichten etwas belastendes hineinphantasieren. Zudem gibt es Länder in denen wegen allgemeiner Zensur verschlüsselte Nachrichten nicht legal sind und auch dem Empfänger Probleme bereiten.
Zusätzlich gibt es Länder, die unterzeichnete internationalen Menschen- und Bürgerrechtsabkommen ignorieren und sogar schon den Besitz von einigen Informationen bestrafen; beispielsweise Nordkorea und England:
http://www.heise.de/tp/r4/artikel/26/26579/1.html
http://www.heise.de/tp/r4/artikel/26/26668/1.html
In solchen Ländern gibt es auch menschen- und bürgerrechtswidrige Gesetze, die zu einer Passwort-Herausgabe verpflichten können:
http://www.heise.de/newsticker/meldung/97050
Verstoßen wird in diesem Fall beispielsweise gegen den Rechtsgrundsatz "Accusare se nemo debet." (Niemand muss sich selbst belasten.), festgeschrieben u. A. im Internationalen Pakt über bürgerliche und politische Rechte,
http://www.uni-potsdam.de/u/mrz/un/int-bill/ipbprde.htm Artikel 14, Paragraph 3, Absatz g.
Mit PKS vermeidet man all diese Probleme.

Eine weitere Anwendung der PKS ist das Verstecken von Informationen zu verstecken ( Hiding Information Hiding, ISSN 0302-9743, and Information Hiding: 8th International Workshop, IH 2006, ISBN 978-3-540-74123-7, Page 161-171).

Praxis der PKS

 Bisher ist noch kein Programm bekannt, das PKS realisiert; die bekannten Steganografie-Programme, z. B. steghide oder outguess, realisieren nur symmetrische Steganografie, also mit nur einem Schlüssel.
Bis es ein PKS-Programm gibt, muß man daher mit Workarounds arbeiten, also die PKS mit mehreren Programmen realisieren.

Neben den theoretischen Anforderungen an die PKS gibt es weitere, die erfüllt werden müssen um für Anwender akzeptabel zu sein. Die wichtigsten sind:

- Optional eine Kompression der Daten

- Nicht nachweisbare Stenanografie (deniable steganography).

Dies erreicht man durch Modularisierung: Ein Programm A wird für die optionale Kompression und sichere Verschlüsselung verwendet und ein Programm B für die Steganografie.
Hierbei muß man auf ein paar Details achten; die beiden wichtigsten sind: A muß Deniable Encryption (abstreitbare Verschlüsselung) verwenden: Die verschlüsselte Datei darf keinen unverschlüsselten Header oder ähnliches enthalten, denn das würde das Verschlüsselte verraten; es wäre von weißem Rauschen, beispielsweise dem Inhalt von /dev/urandom, unterscheidbar.

Vor der Verwendung der Träger-Datei für die Steganografie, meist eine Bild-Datei, sollte man sie von möglicherweise verräterischen Metadaten befreien oder diese Daten anpassen: http://netzreport.googlepages.com/versteckte_daten_in_jpeg_dateien.html.

Die Anwendung ist danach wie folgt: Mit dem Programm A und dem public key wird die Nachricht vom Sender verschlüsselt (u. optional komprimiert), so das sie von Zufallsbytes (Datenmüll/weißes Rauschen) nicht unterschieden werden kann, und mit dem Programm B wird diese verschlüsselte Nachricht ohne Passwort eingebettet.
Der Empfänger extrahiert die verschlüsselte Nachricht mittels B und anschließend entschlüsselt er sie mit A und seinem privaten Schlüssel.

Für A, also das Programm zum Verschlüsseln mit Public-Key-Kryptografie, eignen sich PGP und GPG (und andere PGP-Klone), denn deren Verschlüsselung ist nach heutigem Kenntnisstand unknackbar. Zudem können sie auch komprimieren und die verschlüsselte Nachricht binär ausgeben.
Zusätzlich verarbeitet zumindest GPG angehängten Datenmüll korrekt, so das zumindst GPG auch steganografische Verfahren verwendet werden kann, bei denen an die eingebettete Nachricht beim Extrahieren etwas Datenmüll angehängt wird.
Allerdings gibt es noch ein Problem: Die mit GPG verschlüsselte Nachricht enthält einen Header und dieser ist NICHT verschlüsselt!!! Es gibt zwar Programme wie Truecrypt, die ohne unverschlüsselten Header verschlüsseln können, aber die bieten keine Public-Key-Kryptografie.

Die PGP/GPG-Nachricht beginnt gemäß der RFC 1991 mit dem cipher type byte (CTB). Und dieses CTB ist praktisch immer 0x85, was bedeutet normal CTB, public-key-encrypted packet, 2-byte packet-length field.
Beispielsweise beginnen zwei verschiedene Nachrichten, die mit verschiedenen Schlüsseln verschlüsselt wurden, nach der Verschlüsselung einmal mit 0x85020e03867b und einmal mit 0x85040e038b77.

Für B, also die Steganografie, eignen sich nur solche Steganografie-Programme, die a) ohne Passwort oder mit leerem Passwort einbetten und extrahieren können und b) ohne Passwort oder mit leerem Passwort auch dann extrahieren können, wenn vorher KEINE Nachricht eingebettet wurde. Dieser letzte Punkt b ist für die Abstreitbarkeit der Steganografie eine wichtige Voraussetzung, aber natürlich nicht die einzige, wie man beispielsweise in diesem Artikel nachlesen kann: http://www.heise.de/kiosk/archiv/ct/2001/9/170_kiosk.
Die grundlegende Anforderung an in Frage kommende Steganografie-Programme ist natürlich eine hohe Resistenz sowohl gegen visuelle/auditive Angriffe (d. h. Anschauen/Hinhören) als auch gegen statistische Angriffe (z. B. mittels stegdetect). An dieser grundlegenden Anforderung scheitern schon gut zwei Drittel der Steganografie-Programme.

Das Programm Steghide erfüllt unter Anderem nicht die Voraussetzung b, aber das Programm outguess erfüllt sie. Zudem bietet outguess optional ECC, also automatische Fehlerkorrektur, so das einzelne gekippte Bits korrigiert werden können und im Gegensatz zu Steghide können die damit eingebetteten Daten nicht erkannt werden (Linuxmagazin 04.2008, Seite 83). Zudem kann man mit outguess auch problemlos mehrere Dateien mit je einem separaten Passwort einbetten und auch separat extrahieren (LinuxUser 07/2007, Seite 94-95). Dadurch kann beispielsweise ein Bild separate Nachrichten für mehrere Empfänger enthalten, ohne das ein Empfänger etwas von den anderen erfahren kann; es ist nicht einmal die Anzahl der versteckten Nachrichten erkennbar.

Beispiel 1
0.) GPG installieren und für dieses Beispiel den public key der German Privacy Foundation importieren
1.) Erstellen der Nachricht text.txt
2.) Falls nicht vorhanden, ist mit einem Hex-Editor wie khexedit eine Datei
mit Namen 0x85.bin mit nur dem Byte 0x85 anzulegen.
3.) Verschlüsseln der Nachricht, hier an die German Privacy Foundation:
gpg --encrypt --bzip2-compress-level 9 -r 580E34BE text.txt
4.) Das erste Byte abschneiden (unter Linux/BSD etc. oder Cygwin unter MS-Win):
4.1) mv text.gpg tmp.gpg
4.2) dd if=tmp.gpg of=text.gpg bs=1 skip=1
4.3) rm tmp.gpg
5.) Einpacken der Nachricht in ein Bild:
outguess -d text.gpg picture.jpg bild.jpg
6.) Verschicken des Bildes über einen Anonymizer oder Proxy oder Onion-Router wie Tor von einem anonymen Email-Account weit weg im Ausland, z. b. bei https://hushmail.com, in einer unauffälligen Mail.
7.) Der Empfänger muß zuerst das Bild bild.jpg abspeichern.
8.) Auspacken der Nachricht:
outguess -r bild.jpg tmp.gpg
9.) Anfügen des redundanten Bytes (unter Linux/BSD etc. oder Cygwin unter MS-Win):
cat 0x85.bin tmp.gpg > text.gpg
10.) Entschlüsseln der Nachricht:
gpg --decrypt text.gpg > text.txt

Der Schritt 6.) ist wichtig für absteitbare Kommunikation (deniable communication), denn schon Kommunikations-Verhältnisse können zum Datenmißbrauch führen. Hierzu gibt es ja Programme wie Ontrack Firstview, aber es reicht ja schon eine Darstellung in Matrix-Form um zu erkennen, wer mit wem wie oft und in welchem Umfang kommuniziert und wie gerichtet die Kommunikationsbeziehung ist. Deshalb sollte man für neue Kontakte möglichst neue anonyme Email-Accounts verwenden und keinen anonymen Email-Account über Jahre hinweg.
Dieses Beispiel ist aber nicht wirklich gut, weil in der gemailten Nachricht noch ein Rest des unverschlüsselten GPG-Headers steht, aber der variiert mit der Nachricht und die Nachricht ist gut versteckt, sehr sicher verschlüsselt und ein Nachweis der Steganografie immerhin unsicher.
Ein kleines Problem ist hierbei auch die Statistik von dem, was outguess ohne ein Passwort extrahiert, denn das könnte sich statistisch von einer eingebetteten Nachricht unterscheiden. Es ist aber kein großes Problem, auch weil auch Spam oder sonstiger Datenmüll eingebettet sein kann; ohne korrekte Entschlüsselung kann das nicht sicher festgestellt werden.

Eine Verbesserung ist ein zuätzlicher Salt: Die Nachricht ohne das erste Byte wird nicht direkt eingepackt, sondern es werden zuvor 0 oder 1 oder 2 oder ... n Zufallsbytes (z. B. aus /dev/urandom) angefügt. Der Empfänger muß dann bis spätestens zum Ende es Extrahierten ausprobieren (testen) ob nach dem Entfernen der ersten m Bytes und Anfügen des 0x85-Bytes eine Nachricht entpackt werden kann. Dies ist nicht sehr aufwendig: GPG erkennt relativ zuverlässig ob eine Nachricht vorhanden ist oder nicht und meldet im Fehlerfall:

> gpg --decrypt tmp.txt
gpg: no valid OpenPGP data found.
gpg: decrypt_message failed: eof
> echo $?
2

Ein weiteres Tuning erlauben die GPG-Optionen --throw-keyids und --hidden-recipient um den Empfänger der Nachricht geheim zu halten: http://linux.die.net/man/1/gpg.
Aber auch damit ist das Beispiel nicht perfekt; eine saubere Lösung ist nur eine komplette Verschlüsselung der Nachricht, inklusive Header, wie im nächsten Beispiel.

Beispiel 2
Skizze:
0.) Die Nachricht wird mit GPG oder PGP in einem binären Standard-Format verschlüsselt
1.) Der durch das Standard-Format redundante Header wird entfernt.
Das PGP Stealth, http://cypherspace.org/adam/stealth/ reicht hierfür nicht, unter Anderem weil in dessen Dokumentation steht, das Stealth nicht alle Auffälligkeiten entfernt, den private Key benötigt und 1996 für das inzwischen veraltete PGP 2.6.x gemacht wurde.
Vielleicht ist MacPGP ab Version 2.6.3 mit der Option Stealthify eine Alternative.
2.) Einpacken, Verschicken, Auspacken (sihe Beispiel 1).
3.) Den Header Rekonstruieren und vorne Anhängen.

Demnächst kommt hier das ausführliche Beispiel, auch mit einem Bild: Einmal mit und einmal ohne Nachricht.

Juristische Fallstricke

 Es gibt einige Länder die das Wassenaar Abkommen unterzeichnet haben und daher Export-Beschrändkungen auch für Kryptografie-Software unterliegen: http://www.wassenaar.org/controllists/2008/WA-LIST%20(08)%201/WA-LIST%20(08)%201.pdf.
In dem Abkommen steht zwar nicht, welche Länder es unterzeichnet haben und die Lockerung der Krypto-Exportbeschränkung von 1999, http://www.heise.de/newsticker/Clinton-lockert-Krypto-Exportbeschraenkung--/meldung/6142, fehlt ebenfalls aber man findet die Liste und einiges andere zu dem Bereich Kryptografie-Beschränkungen auf http://rechten.uvt.nl/koops/cryptolaw/cls2.htm.
Nach dem Wassenaar Abkommen ist einige Software, insbesondere Software für Kryptografie ein "Dual-Use Good" das generell Exportbeschränkungen unterliegt, aber beispielsweise Public-Domain-Software unterliegt KEINEN Beschränkungen; sie ist ausdrücklich von dem Abkommen ausgenommen!
Zudem ist sie in den meisten Ländern der Erde durch Rechte wie Redefreiheit, Pressefreiheit, Meinungsfreiheit usw. geschützt, so das man zumindest in der EU und auch den meisten Staaten der Erde keinerlei Einschränkungen bei der Verwendung und dem Export von Public-Domain-Software hat.

Von der Legende, das Kryptografie-Software als Waffe kategorisiert wird, ist auch in dem Wassenaar Abkommen nichts zu finden. Bei dieser Legende handelt es sich nur um eine Übertreibung einiger Journalisten, denn eine Waffe ist ein Mittel, das Gegenstände (auch Lebewesen) und immaterielle Güter beschädigen, zerstören oder gebrauchsunfähig machen kann, aber die (angewandte) Kryptografie bewirkt nur eine Verhinderung von unauthorisierten Zugriffen auf Daten durch Transformation und hat daher nichts mit einer Waffe gemein.
Eine nur passiv schützende Technik wie die angewandte Kryptografie als Waffe zu bezeichnen ist daher Unfug.

Sitemap