Asymmetrische Steganografie/Public-Key-Steganografie (PKS)

Theorie der PKS

 Die PKS wird meist als Asymmetrische Steganographie bezeichnet.
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 hinen 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.
Zudem gibt es Länder, die unterzeichnete internationalen Menschen- und Bürgerrechtsabkommen ignorieren und sogar schon den Besitz von einigen Informationen bestrafen; beispielsweise 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 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.

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 bzw. 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, unterscheibar.
Vor der Verwendung der Träger-Datei für die Steganografie, meist eine Bild-Datei, muß sie von versteckten Daten befreien: http://netzreport.googlepages.com/versteckte_daten_in_jpeg_dateien.html.
Die Anwendung ist danach wie folgt: Mit 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 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 Kentnisstand 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!!! Die 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/ct/01/09/links/170.shtml
Das Programm Steghide erfüllt unter Anderem nicht die Voraussetzung b, aber das Programm outguess erfüllt sie. Zudem bietet outguess optional ECC, also 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 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

Eine saubere Lösung ist aber 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.
2.) Einpacken, Verschicken, Auspacken (sihe Beispiel 1).
3.) Den Header nach RFC1991 rekonstruieren und 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/list/WA-LIST%20(04)%202.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 Public-Domain-Software unterliegt KEINEN Beschränkungen; sie ist ausdrücklich von dem Abkommen ausgenommen! Dies gilt auch für die allermeisten anderen Kryptografie-Software-Beschränkungen weltweit.
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.
Indirekte Einschränkungen gibt es natürlich beim illegalen Mißbrauch, aber bekanntlich kann ALLES illegal mißbraucht werden, beispielsweise lebenswichtiges wie Wasser für eine Wasservergiftung, Sauerstoff für eine Sauerstoffvergiftung und umgekehrt kann auch ein Mangel an Wasser oder Sauerstoff beispielsweise zur illegalen Tötung verwendet werden, aber das ist allgemein bekannt und selbstverständlich.

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.