Kryptografie

Eine kleine Story zu TrueCrypt (unter Windows), Backups und warum man sich ein paar Gedanken machen sollte.

Gestern war es dann endlich so weit. Nach einem Start und mehrmaliger Eingabe des TrueCrypt Passworts kam das, was im TrueCrypt Manual so beschrieben wird: "If you repeatedly enter the correct password but TrueCrypt says that the password is incorrect, it is possible that the master key or other critical data are damaged". In diesem Fall muss die TrueCrypt Rettungs-CD zum Einsatz kommen, um die Schlüsseldaten wiederherzustellen, die während der Systemverschlüsselung über ein ISO Image erstellt und gebrannt werden kann. "Kann" – denn man kann das Image auch mit einem der Tools für virtuelle Laufwerke auf eine virtuelle CD schreiben, wie das einige Nutzer machen, die der Brennvorgang nervt. Ich nehme als Tool die bekannten Daemon Tools (ohne Adware) und hatte das auch so gemacht. Das ISO Image hatte ich in TrueCrypt Containern auf USB-Stick und Partition gespeichert, aber mit dem Hintergedanken, das bei Bedarf zu brennen, nicht gebrannt. Ein falscher Hintergedanken, wenn man nur einen CD/DVD Brenner im Rechner hat.

Zum Beginn der Beschäftigung mit und dem Einsatz von TrueCrypt hatte ich mir außerdem überlegt, wie man für Windows und TrueCrypt Backups und/oder Images machen kann, die selbst wiederum mit TrueCrypt gesichert sind, denn verschlüsselte Partitionen und unverschlüsselte Backups/Images sind unsinnig und deshalb auch in ein paar Webforen nachgelesen, wie es andere Nutzer damit halten. Dafür gibt's verschiedene Vorgehensweisen. Meine ist folgende:

Ich habe eine WD SATA Festplatte in dem externen MX-1 Gehäuse von Antec, mit dem ich übrigens sehr zufrieden bin. Auf der befinden sich wie auf der internen Festplatte TrueCrypt verschlüsselte Partitionen. Eine Windows BartPE/XPE Boot-CD enthält das Image-Programm TrueImage von Acronis, TrueCrypt und verschiedene andere Sachen. Mit der boote ich regelmäßig und entschlüssle/mounte mit TrueCrypt die Partitionen auf der externen Festplatte. Dann werden von interessierenden Partitionen der internen Festplatte mit TrueImage Images ohne Komprimierung und die Acronis eigene Verschlüsselung in die TrueCrypt Partitionen auf der externen Festplatte erstellt, damit es schnell geht. Für die verschlüsselte Systempartition gibt es zwei "TrueImages" in zwei TrueCrypt Partitionen: Eines per "Sektor-für-Sektor" der Systempartition im verschlüsselten Zustand in die eine externe TrueCrypt Partition und eines nach gemounteter Systempartition ohne Pre-Boot Authentifizierung, bei dem der entschlüsselte Inhalt komplett in das Acronis Image auf der anderen externen TrueCrypt Partition gespeichert wird. Da sich das erste Image bereits im verschlüsselten Zustand befindet, könnte man das Image auch auf einer unverschlüsselten Partition ablegen, das zweite Image dient dazu, zumindest und immer an Daten zu kommen, wenn es mit dem ersten Image nicht hinhaut.

Eigentlich unverzeilich, bin ich diesem Schema gefolgt, ohne jemals selbst ausprobiert zu haben, ob eine Wiederherstellung mit Acronis, dessen Images, der Boot-CD und TrueCrypt überhaupt funktioniert, weil diverse Leute ausführlich berichtet hatten, dass es funktioniert. Man sollte sich aber trotzdem nicht darauf verlassen.

Der zweite DAU Fehler war, wie bereits angedeutet, die nicht gebrannte TrueCrypt Rettungs-CD, denn mit dem nachträglichen Brennen wurde es nichts über meine BartPE/XPE und eine Knoppix-CD, denn mit nur einem Laufwerk muss man natürlich die Boot-CD mit einem Rohling wechseln und danach ging nichts mehr mit Brennen – falls es da nicht eine Vorgehensweise oder einen Trick gibt, der mir nicht eingefallen ist. Damit auch keine Möglichkeit, das beschädigte Schlüsselmaterial wiederherzustellen.

Um mir zu behelfen und zum Brennen zu kommen, habe ich dann ein weiteres Image der aktuellen unzugänglichen Systempartition erstellt, wieder per Sektor-für-Sektor. Danach habe ich das alte Acronis Image der Systempartion wiederhergestellt, das per Sektor-für-Sektor erzeugt wurde. Für diejenige, die das auch so mit Acronis machen wollen oder müssen: Man muss wiederum die Sektor-für-Sektor Methode aktivieren, dann zuerst die Partition und als weitere "Partition" den MBR auswählen. Danach löscht Acronis zuerst die existierende Partition, stellt sie aus dem Image wieder her und danach wird der MBR wiederhergestellt.

Danach kam der Zeitpunkt, ob das alles so klappt mit der Vorgehensweise und den Acronis Images. Nach einem Neustart ging es aber wie gewohnt mit der TrueCrypt Pre-Boot Authentifizierung nebst Entschlüsselung der Systempartition und erfolgreichem Booten des "alten" Windows weiter – die zu späte Bestätigung der Vorgehensweise. Mit dem "alten" Windows habe ich dann das ISO Image der TrueCrypt Rettungs-CD auf eine CD-RW gebrannt und danach den ganzen Zauber erneut durchgeführt, sprich Booten mit der BartPE/XPE CD, Wiederherstellen des Images der unzugänglichen Systempartition mit Acronis, Einlegen der TrueCrypt Rettungs-CD, Neustart und Reparatur des TrueCrypt Schlüssels der Systempartition mit der Restore Key data Funktion im Menü der Rettungs-CD. Tja und danach war wieder alles in Butter. Abgesehen von der rot angelaufenen Stirn aufgrund der Zusammenstöße mit dem Schreibtisch

Für die GnuPG Anwender, die es benötigen.

David Shaw, einer der Entwickler im GnuPG Team, hat für *nix und Windows Version 1.0 des Paperkey Programms veröffentlicht.

Um ein Backup des eigenen Schlüsselpaares in Datenform zu pflegen, kann man entweder die Schlüsselringdateien komplett als Kopie oder den geheimen Schlüssel als Datei exportieren und ihn auf einem Datenträger speichern. Da ein Datenträger verloren gehen, beschädigt werden oder nach längerer Zeit seine Lesbarkeit verlieren kann, ist es ggf. sinnvoll, für ein zusätzliches Backup auf das gute alte Papier und Drucker auszuweichen.

Um ein Backup des eigenen Schlüsselpaares in Papierform anzulegen, könnte man einfach den geheimen Schlüssel mit ASCII Hülle exportieren und den Inhalt ausdrucken. Zum späteren Wiederherstellen des Schlüsselpaars kann dann der Ausdruck entweder per OCR eingelesen oder abgetippt und das Ergebnis wieder mit GnuPG importiert werden. Der Nachteil bei dieser Methode ist die Menge an Zeichen, die der Export enthält, denn darin ist alles enthalten, was einen Schlüssel ausmacht, inklusive des öffentlichen Schlüsselmaterials.

Das bedeutet, dass sich der Ausdruck unter Umständen auf mehrere Seiten Papier verteilt bzw. die Schriftgröße stark verkleinert werden muss und sich damit die Wahrscheinlichkeit erhöht, dass sich beim Einlesen und Abtippen Fehler einstellen und deshalb eine Wiederherstellung fehlschlägt.

Hier setzt Paperkey an, das aus dem exportierten geheimen Schlüssel in Binärform nur die relevantesten Anteile extrahiert und sie ebenfalls in ASCII Zeichen auswirft, die dann zu einem komprimierten Ausdruck auf Papier führen, der viel besser zur späteren Wiederherstellung geeignet ist. Zur vollständigen Wiederherstellung des Schlüsselpaars ist neben dem eingelesenen oder abgetippten Ausdruck der öffentliche Schlüssel nötig, der sich bei den meisten GnuPG Anwendern auch nach einem Schlüsselverlust auf einem Schlüsselserver befindet, auf einer Webpage angegeben wird oder in anderer Form bereits existiert.

Zu Paperkey gibt es eine kurze Anleitung, die aber nicht vollständig ist und zu keinem vollständigen Ergebnis führt, deshalb hier die "vollständige" Version:

Erstellung des Paperkey Backups

1. Export des geheimen Schlüssels in Binärform in die Datei SchlüsselIDsec:
   
   gpg -o SchlüsselIDsec --no-armor --export-options no-export-clean,export-minimal --export-secret-keys Schlüssel-ID
   
   
2. Erzeugung der komprimierten Version der relevanten Schlüsselbestandteile des geheimen Schlüssels für den Ausdruck:
   
   paperkey --secret-key SchlüsselIDsec --output SchlüsselIDpaper.txt
   
   Für meinen zurückgezogenen Schlüssel 0x0A146804 reduziert sich das auf folgenden Output:

   # Secret portions of key 5AB6B450D8CC132B80B17F24431C6A350A146804
   # Base 16 data extracted Fri Jan 23 10:21:51 2009
   # Created with paperkey 1.0 by David Shaw
   
   # File format:
   # a) 1 octet:  version of the paperkey format (currently 0).
   # b) 1 octet:  OpenPGP key version (currently 4)
   # c) n octets: Key fingerprint (20 octets for a version 4 key)
   # d) 2 octets: 16-bit big endian length of the following secret data
   # e) n octets: secret data: an OpenPGP secret key or subkey as specified in
   #              RFC 4880, starting with the string-to-key usage octet and
   #              continuing until the end of the packet.
   # Repeat fields b through e as needed to cover all subkeys.
   # To recover, use the fingerprint to match an existing public key with the
   # corresponding secret data, then append field e to the public key to
   # create a secret key.
   # Each base 16 line ends with a CRC-24 of that line.
   # The entire block of data ends with a CRC-24 of the entire block of data.
   
     1: 00 04 5A B6 B4 50 D8 CC 13 2B 80 B1 7F 24 43 1C 6A 35 0A 14 68 04 0C08F6
     2: 00 53 FE 0A 03 08 24 28 E0 0F 13 57 BB 10 60 3B 5B 31 C9 7B F3 69 08B4F5
     usw.
    17: 4B AD 65 E2 E9D940
    18: 5B7490
   

   Das ist doch im Gegensatz zur anfangs erwähnten Methode erheblich weniger, gut einzulesen und zur Not auch gut abzutippen. Genauso wie beim tatsächlichen geheimen Schlüssel ist auch die Ausdruckversion durch die Passphrase geschützt, denn natürlich ist die Verschlüsselung durch die Passphrase und den gewählten symmetrischen Algorithmus ebenfalls Bestandteil im Ausdruck.
   
   Ist die Passphrase nicht im "Susi" Style gewählt, sondern ausreichend lang, in ihrer Zusammensetzung ausreichend komplex und ein starker symmetrischer Algorithmus gewählt, kann auch ein Ausdruck in die Hände der Möchtegern-Cracker des BKA, BND oder anderer Geheimdienste fallen, wenn es sich nicht verhindern lässt. Sollte man spätestens seit Annes Story mit dem PGP Schlüssel wissen und beherzigen. Wer es etwas paranoider haben möchte und sich selbst im Umgang mit GnuPG nicht vertraut, kann ja noch eine symmetrische Verschlüsselungsschicht um das Paperkey Backup legen und den Ciphertext ausdrucken (aber zusätzliche Passphrase nicht vergessen!)
   
   gpg --cipher-algo TWOFISH --s2k-digest-algo SHA256 -ac SchlüsselIDpaper.txt
   
   
3. Die SchlüsselIDpaper.txt Datei ausdrucken, den Ausdruck abheften, verbuddeln, verstecken usw. und danach wie die SchlüsselIDsec Datei "rückstands- und spurenlos" löschen, wie es immer so schön in den Sicherhheitsgesetzen heißt.

Wiederherstellung des Schlüsselpaares mit Paperkey

1. Davon ausgehend, dass man nicht mehr über die GnuPG Schlüsselring- oder Schlüsseldateien verfügt, wird der eigene öffentliche Schlüssel über die oben genannten Quellen bezogen.
2. Da der öffentliche Schlüssel meistens in ASCII Form vorliegt oder erhalten wird, konvertiert man die Datei mit dem öffentlichen Schlüssel in seine Binärform:
   
   gpg --dearmor SchlüsselID.asc (mit SchlüsselID.asc.gpg als Resultat)
   
   
3. Wiederherstellung des geheimen Schlüssels in seine Binärform mit dem Paperkey "Ausdruck" (entweder bereits auch als Datei vorliegend oder eingelesen/abgetippt) und dem öffentlichen Schlüssel:
   
   paperkey --pubring SchlüsselID.asc.gpg --secrets SchlüsselIDpaper.txt --output SchlüsselIDsec
   
   
4. Import der Dateien mit dem geheimen und öffentlichen Schlüssel:
   
   gpg --import --import-options no-import-clean,import-minimal SchlüsselIDsec
   gpg --import --import-options no-import-clean,import-minimal SchlüsselID.asc.gpg
   
   
5. Vetrauenswert für eigenen Schlüssel wiederherstellen und aktuelle Fremd-Zertifikate von Schlüsselserver importieren:
   
   gpg --edit-key SchlüsselID
   trust
   5
   
   gpg --refresh-keys SchlüsselID

Danach kann das Schlüsselpaar wie gewohnt mit GnuPG genutzt werden. Die Vorgehensweise habe ich auch mit einem aktuell aktiven Schlüssel anwenden können.

Die --*armor Option, Import- und Export-Optionen dienen dazu, jenseits möglicher Optionen, die bereits in der gpg.conf vom Nutzer oder anderen Programmen gesetzt wurden, doppelte Zertifikate im Schlüssel zu vermeiden und die für Paperkey benötigte Binärform anzuwenden. Die Änderung des Vetrauenswerts des Schlüssels nach Wiederherstellung kann unterbleiben, wenn zuvor beim Export/Backup des geheimen Schlüssels auch die Vetrauenswerte mit gpg --export-ownertrust > mytrust.asc exportiert wurden, so dass sie nach Wiederherstellung des Schlüssels mit gpg --import-ownertrust mytrust.asc wieder importiert werden können. Die Vetrauenswertedatei kann man natürlich ebenfalls als Backup ausdrucken.

Bisher nutzte ich unter Windows für Downloads mit Firefox immer die FlashGot Erweiterung (vom Programmierer stammt auch NoScript) mit dem Free Download Manager, der Feedreader brachte auch noch seinen eigenen Download-Manager für Podcasts, Movies usw. mit. Mal direkt oder über Tor, I2P und JonDonym für anonymisierte Downloads. Die beiden Download-Manager hatten die meiste Zeit nichts zu tun und so etwas gefällt mir nicht. Auch wenn ich mir bei den niedrigen Speicherpreisen jetzt den Arbeitsspeicher aufgerüstet habe, um demnächst etwas mit Virtualisierung herumzuspielen.

Da ich Wget in der Konsole ebenso gerne für Downloads nutze und es zu dessen Einbindung in FlashGot auf der Features Seite ein Beispiel gab (was mir nicht ausreichte), habe ich mir mit ein paar Batchdateien, der Wget Portierung des GnuWin32 Projekts und ein paar weiteren Sachen einen minimalen Wget "Download-Manager" gebastelt, der dann im FlashGot Kontextmenü von Firefox so aussieht: Die "NoProxy" Menüeinträge rufen, wie der Name schon sagt, Wget für den Download ohne Proxy und Weiterleitung an Tor, I2P oder JonDonym auf, bei den "Proxy" Menüeinträgen werden Downloads über den Privoxy Proxy und ggf. einen Anondienst abgewickelt, für FTP Downloads statt Privoxy über JonDonym, da Privoxy kein FTP unterstützt.

"NoSSLcheck" ist für SSL/TLS verschlüsselte Downloads von Servern da, die nur selbst signierte Zertifikate anbieten und deshalb nicht gegen die CA-Zertifikate geprüft werden können bzw. bei CA-Zertifikaten, die man noch nicht einer Datei mit einem Paket aller CA-Zertifikate hinzugefügt hatte, aber wo man trotzdem etwas herunterladen möchte. Bei Menüeinträgen ohne "NoSSLcheck" werden immer Server-Zertifikate gegen die CA-Zertifikate geprüft und deshalb ein Download abgebrochen, wenn etwas nicht mit den Host- und Zertifikatangaben stimmt. Was aufgrund von Angriffsmöglichkeiten und Schlampereien bei den CAs auch nicht unbedingt eine Garantie bietet, wie man immer wieder erfahren muss.

Natürlich kann man die Liste beliebig für weitere Zwecke und Funktionen von Wget erweitern.

Für die Datei mit dem Paket aller CA-Zertifikate habe ich mich der Zertifikatespeicher der Browser und OpenSSL bedient. Man kann natürlich auch selbst alle CA Sites absurfen und sich die Zertifikate selbst besorgen und "behandeln". Weitere Methoden werden in der readme Datei genannt.

Falls es jemanden interessiert oder für diejenigen, für die das Ganze nützlich sein könnte, habe ich die Batchdateien und eine eingerichtete wgetrc Datei in ein Archiv gepackt. In der readme Datei steht auch alles Weitere ausführlich erklärt. Verbesserungsvorschläge und Tipps sind wie immer willkommen.

Vermutlich kommen ein paar Leser angerannt, die mir sagen wollen, das sei alles zu kompliziert und Download-Manager XY viel besser, schöner, bunter und mächtiger. Aber genau die wollte ich eben nicht. Was die Wget Geschichte nicht kann – wie zum Beispiel der Free Download Manger, ist die automatische Konvertierung von Filmchen, die man bei YouTube herunterlädt. Aber dafür gibt es dann auch wieder einfache Tools.

Siehe auch:
WackGet

Erster Test mit der SSL Blacklist Erweiterung für Firefox, die neben den schwachen Schlüsseln des OpenSSL Bugs jetzt auch die mit MD5 signierten Zertifikate als Warnung auswerfen soll: Angesurft habe ich bis jetzt daneben nur mein Kreditinstitut, die Arge, die Fireox Add-ons Site und meinen Provider. Zur Ergänzung auch ganz nett ist die Cert Viewer Plus Erweiterung, die aber nichts mit den obigen Schwachstellen zu tun hat. Die Informationen in der Zertifikatsansicht: Hintergründe:
25C3 - MD5 considered harmful today - Creating a rogue CA Certificate (BitTorrent)
Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger - MD5 considered harmful today - Creating a rogue CA certificate
Heise - 25C3: Erfolgreicher Angriff auf das SSL-Zertifikatsystem

Siehe auch:
Fefe - Ich habe gerade mal einen Bug gegen Firefox gefiled (ja, auch "nett" )
eWeek - SSL Certificate Vendor Sells Mozilla.com Cert to Some Guy

Wie bereits im Beitrag Lass das mal den CopyRouter machen angesprochen, bereitet die Regierung Australiens ein Filtersystem vor, das wie zum Beispiel in China nicht auf Benutzereben installiert und kontrolliert wird, sondern auf Ebene der Internetzugangsprovider.

Wir hatten Ende der 90er Jahre und mit den Sperrverfügungen in NRW ähnliche Diskussionen und Pläne in der Pipeline. In Großbritannien und den USA experimentieren aktuell Internet Provider mit Deep Packet Inspection Systemen zur Analyse und Steuerung des Internettraffics und auf globaler Ebene gehört zu "Internet Governance" die Weiterentwicklung, Förderung und Verbreitung von Filtersystemen – mal zur Bekämpfung von Filesharing und P2P, zur Bekämpfung des Terrorismus oder zum Schutz von Minderjährigen vor "schädigenden Inhalten im Internet".

In Australien ist es auch der Kinderschutz, der als Deckmantel benutzt wird, um allen australischen Internetnutzern ein zwingend zu nutzendes Filtersystem überzustülpen. Denn das als "Clean Feed" bezeichnete Filtersystem, wie es von der australischen Regierung angedacht ist, soll aus zwei Filter-Blacklists bestehen, die den Zugriff auf Sites blockieren bzw. für Kinder schädliche Inhalte filtern. So ganz klar ist man sich da noch nicht, ob es einfach dumme Blacklists mit URLs und IP-Adressen sein sollen oder die Listen Muster, Schlüsselwörter usw. enthalten, um mit ihnen den Netzwerkverkehr zu analysieren, filtern und zu blockieren. Für diese Filterlisten zum Erhalt "gesäuberter Internetinhalte" sollen die Internetnutzer die Möglichkeit der Abbestellung erhalten. So weit, so gut, so schlecht, denn wie alle anderen Filtersysteme wird auch die australische Variante zu umgehen sein, zu ungenau sein, zu viele oder falsche Zugriffe filtern und die Fragen, wie Kinder und Eltern mit dem Internet umgehen können oder was überhaupt auszublenden wäre, auf eine rein technische Ebene verlagern, die sie nicht beantworten kann.

Im Huckepackverfahren bringt der Plan aber auch noch eine weitere Filter Blacklist mit sich, die unpräzise und weitgehend formuliert, auf "illegale und unangemessene Inhalte" filtert, womit die australische Regierung auch im Sprachgebrauch große Ähnlichkeiten mit dem chinesischen Regime beweist. Für diese Blacklist gibt es kein Opt-out, d. h. der Traffic aller Internetnutzer muss diesen Filter zwingend durchlaufen. Was als "illegaler Inhalt" einzustufen ist, bestimmt die Regierung bzw. das Ministerium für Internet und Telekommunikation und das Pendant zur Bundesnetzagentur, die Australian Communications and Media Authority (ACMA) Aufsichtsbehörde für Rundfunk, Telekommunikation und Internet, die auch die Filterlisten administriert. Deren genaue Inhalte bleiben unter Verschluß – wenn sie nicht wie andere Filterlisten in der Vergangenheit durch freiheitsliebende Hacker entschlüsselt oder aufgedeckt werden. Das heißt, bei Umsetzung des "Plans für mehr Cyber-Sicherheit", der nebenbei die australische Gesellschaft 125,8 Millionen australische Dollars kosten würde, von denen 44 Millionen $ für das Filterschema vorgesehen sind, bekommt die australische Regierung auch ein Zensurinstrument in die Hände, um alles auf die Filterlisten zu setzen, was ihr nicht in den Kram passt und das auch die Medienindustrie und die Urherberrechteverwalter schätzen werden.

Die Filterlisten sollen täglich dynamisch generiert, erweitert und genauso dynamisch von den Internetzugangsprovidern angewendet werden, wie die australische Regierung träumt. Vertreter der Internetprovider, die genauso gegen die Pläne der Regierung Sturm laufen wie Bürgerrechtsorganisation oder die Mehrheit der australischen Internetnutzer, weisen dagegen wie die ACMA selbst darauf hin, dass der Einsatz dynamischer Filtersysteme auf Providereben mindestens zu einem Einbruch der Netzwerkperformance von durchschnittlich 30 Prozent führen würde. Zensur und Filter bedeuten unter Umständen eben auch die Rückkehr von "World Wide Wait".

Als nächster Schritt zur Verwirklichung des "Cyber-Safety" Plans steht ein praktischer Versuch mit Internetprovidern unter Live-Bedingungen zum Ende des Jahres auf der Agenda, bei dem sich die Zensoren anschauen wollen, welche Filtermethode am effektivsten ist, wie gut sie sich von Internetnutzern umgehen lassen und welche Kosten und Geschwindigkeitseinbrüche in Kauf genommen werden müssten.

Wie das Magazin The Age am 11. November 2008 im Beitrag Net censorship plan backlash berichtete, hat die australische Regierung die ISPs eingeladen, sich bei Interesse an einer Teilnahme am Live-Versuch zu melden, der pünktlich zur Weihnacht am 24. Dezember starten soll. Der Einladung ist iiNet, einer der größten Internet-Provider in Australien, gefolgt. Aber nicht aus vorauseilendem Gehorsam, sondern um der Regierung "mit harten Fakten zu zeigen, wie bescheuert" das Filtersystem ist, wie es der Managing Director von iiNet, Michael Malone, ausdrückte. Malone erwartet dem verantwortlichen Minister Stephen Conroy, den Malone als "den schlechtesten Minister, den wir nach 15 Jahren seit Bestehen der Internetindustrie hatten", der "sich in eine Reihe mit China und Saudi Arabien stellt" beschrieb, als harte Fakten zeigen zu können, wie leicht sich das Filtersystem umgehen lässt, dass es P2P Traffic nicht filtern kann und zu erheblichen Einbrüchen der Übertragungsgeschwindigkeiten führt. Er fügte hinzu: "Jedes Mal, wenn es einem Jugendlichen gelingt, das Filtersystem zu durchbrechen, werden wir es publizieren. Jedes Mal, wenn es legale Inhalte blockiert, werden wir es publizieren." Ich wünsche ihm Erfolg mit der Taktik, das System mit dessen eigenen Mitteln zu schlagen. Das technisch interessierte und versierte Internetnutzer – zu denen anwachsend die Kids selbst gehören – die plumpe Filter- und Zensurgeilheit der Regierung über VPNs, SSL-Proxys, SSH Tunnel oder anonymisierende Netzwerke unterlaufen können, solange Anwendung und Verbreitung der Methoden und Programme nicht drastisch kriminalisiert werden und man für sie mit zusätzlicher Technik zur Paketanalyse und Mustererkennung aufrüstet, wird von der australischen Regierung erst einmal völlig ignoriert und in den Köpfen der Apparatschiks ausgefiltert, denn es geht zunächst darum, politisch und technisch einen Fuß in die Tür zu bekommen, bevor man dann eine "Great Firewall" wie in China aufzieht.

Wer aktuelle und weitere Informationen zur heißer werdenden Auseinandersetzung um Filter und Zensur erhalten will, kann sich bei den Electronic Frontiers Australia (EFA), auf der von ihnen eingerichteten Website NO CLEAN FEED und im dazugehörigen Weblog umschauen. Allen australischen Internetnutzern und der EFA wünsche ich viel Erfolg bei ihrem Kampf um ihre Rezipienten- und Meinungsfreiheit.

Aktuelle Informationen zum Filter-Zensur Anlauf in Australien gibt es auch bei: Zum Beispiel die technische Rahmenbeschreibung zum Filterpilot Projekt aus dem Hause von Minister Conroy, in der die zwei Filterstreams vorgestellt werden:

1. Index filtering only of the Australian Communications and Media Authority (ACMA) blacklist of prohibited URLs [Anm.: IP-Adresse oder URL oder IP-Adresse und URL mit bis zu 10000 Einträgen]; or
2. The ACMA blacklist plus additional filtering e.g. more extensive index filtering through to dynamic filtering of other unwanted internet content and non web based applications [Anm.: z. B. "verbotene" Wörter, "pornografische" Bilder, "sprechende" Dateinamen, Inhaltsanalyse von Texten, Manipulationen bei der Namensauflösung wie im NRW Filterprojekt, Hinzunahme von Blacklists, die Quellen anhand des Labelings als "verboten" markieren].

Was die Zensoren der Regierung interessiert sind die gleichen Punkte, die bei den Gegnern in ihrer Kritik genannt werden: Wie groß ist der negative Einfluss der Zwangsfilter auf die Netzwerkperformance beim Internetnutzer und beim ISP, wie hoch ist die Rate der Websites, die ungerechtfertigt durch die Filtersysteme ausgeblendet werden und der Websites, die man zensieren will, die aber trotzdem durchkommen, welche Möglichkeiten der Umgehung der Zensur gibt es und wie leicht verfüg- und anwendbar für den Nutzer, welche Mittel müssen für die Umsetzung von ISPs aufgebracht werden und wie weit könnte man das Filter-Zensur System bei einem ISP ausdehnen, ohne das dessen Netzwerk crasht.

Siehe auch:
The Age - Spoof Conroy website protests at internet filter plan (18.12.2009)
The Age - Fatal flaws in website censorship plan, says report (23.12.2008)
The Age - The great porn war (18.12.2008)
The Age - Labor plan to censor internet in shreds (09.12.2008)
Computerworld - Anti-content-filtering rebels take to Australia's streets (03.12.2008)
Ban.This.Url -
Interview with a white hat hacker, 1. Teil: White hat hacker tears apart flaws in Aussie net filtering scheme
Interview with a white hat hacker, 2. Teil: The filters' vulnerabilities
Interview with a white hat hacker, 3. Teil: What machines can't judge and why

SOCKS-Wrapper, Tor und Remailer

Seit Service Pack 3 für Windows XP funktionierten (bei mir – wie es bei anderen Usern ausschaut, weiß ich nicht) die verschiedenen SocksCap Versionen nicht mehr, die im Netz umlaufen. SocksCap stammt ursprünglich von NEC, bei denen das SOCKS 4 Protokoll auch entwickelt wurde, dann erfolgte der Verkauf an Permeo und der Weiterverkauf an Blue Coat, die es in ihre Proxyprodukte integrierten, die man kaufen muss.

SocksCap ist eine, eigentlich die originäre SOCKS-Wrapper Anwendung für Windows, um Verbindungen von Internetanwendungen, die keine Schnittstelle zur Nutzung von SOCKS-Proxys aufweisen, abzufangen und an einen SOCKS-Proxy bzw. Server umzuleiten. Braucht man fast nie für die Anonymisierung über Tor, der auf SOCKS basiert, da mittlerweile die meisten Internetanwendungen unter Windows SOCKS direkt unterstützen. Braucht man aber für Stunnel, um verschlüsselte SSL / TLS Tunnel durch Tor zu leiten. Das braucht man wiederum, wenn man als Remailer Programm Quicksiler nutzt und verschlüsselte Verbindungen zu Remailern aufnehmen will, da Quicksilver kein SSL / TLS eingebaut hat und Tor nur in Teilen unterstüzt.

Die übrigen SOCKS-Programme und -Wrapper unter Windows, die mir zum Test auf die Platte kamen, versagten alle ihren Dienst für den obigen Zweck. Dann habe ich es mit der SOCKS Anwendnung von Hummingbird versucht. Für den Download muss man sich anmelden. Wer damit Probleme hat, kann mit speziellen E-Mail Adressen und einer anderen Identität die gwünschten Daten liefern, was ja auch für andere Formulare gilt. Für die Anmeldung bekommt man einen kostenlosen SOCKS-Wrapper, der ohne Tricks wie bei SocksCap ohne Zeitlimit funktioniert und auch noch neben Stunnel mit Tor harmoniert.

Das Ding hat ein paar Haken: 1. Hummingbirds SOCKS 5 versteht Tor nicht, Tors SOCKS 4A hat es nicht, bleibt also nur SOCKS 4. Das damit einhergehende "Problem" direkter Namensauflösungen statt Namensauflösung über den SOCKS-Proxy (Tor) stellt aber kein Problem dar, wenn man sowieso die Namensauflösung über TorDNS -> Tor abwickelt. 2. Hummingbirds Socks gräbt sich so tief ein, dass automatisch alle Internetverbindungen "socksifiziert" werden. Also auch für Internetanwendungen, wo das nicht erwünscht oder unnötig ist. Wer aber immer alle Verbindungen automatisch über Tor laufen lassen will, braucht sich wohl bei keiner Internetanwendung mehr Gedanken machen, denn Hummingbird fängt's ab Wer das nicht will, kann oder muss das "Modul" (sprich ∗.exe, ∗.dll) der Internetanwendung, das "socksifiziert" werden soll, extra angeben und dafür alle anderen "Module", für die das nicht gelten soll, manuell in eine Liste eintragen oder Verbindungen als "direkt" ausschließen.

Das ist mal wieder alles unheimlich kompliziert und technisch, wird aber anders aufbereitet nochmals in der kommenden Remailer Anleitung auftauchen, die ich bis Ende 2008 fertig haben will. Unter Linux hat man es einfacher und mehr Möglichkeiten, alles zu realisieren, aber es geht darum, wie man's unter Windows machen kann. Bestes Beispiel ist der heutige Hinweis auf den Torsocks Socks-Wrapper für Linux auf der Tor Mailingliste, der alle Patches für tsocks und ein paar Verbesserungen integriert.

Jabber, Tor, OpenPGP, OTR und die VDS

Der Anonymisierung dient auch meine schrittweise Rückkehr zum jabber.ccc.de Jabber Server. Der swissjabber.ch Jabber Server, den ich ebenfalls nutzte, ist zwar auch ein guter Jabber Server, verbindet man sich aber über Tor, gab es bei diesem Jabber Server für mich zu viele Verbindungsunterbrechungen – auch während laufender Chats, die ich bei jabber.ccc.de nicht beobachten konnte. Jabber Verbindungen sind zwar nicht in der EU-Richtlinie und im Gesetz zur Vorratsdatenspeicherung aufgeführt und demnach Jabber Server von der Vorratsdatenspeicherung ausgeschlossen, aber ich will, dass die Nutzung eines Anonymisierungsdienstes funktioniert.

Mehr mit Verschlüsselung hat es auf sich, dass ich nun statt OpenPGP die OTR Verschlüsselung nutze, auch wenn ich kein Fan von OTR bin. Dafür gibt es zwei Gründe: 1. Immer weniger Kontakte nutzen – wenn überhaupt – Clients, die OpenPGP jabberkonform unterstützen oder OpenPGP an sich. Dafür setzt sich OTR immer mehr durch. 2. Jabber Server machen (u. U.) Probleme bei der OpenPGP Nutzung, dies umso mehr, je länger die eingesetzten GnuPG Schlüssel sind. Mit OTR gibt es keine Probleme.

GIMP, IrfanView, ImageMagick, Exif und CC

Unter Windows nutze ich für die Bild- und Fotobearbeitung gerne und oft GIMP und IrfanView. Demnächst will ich alle Fotos in der Galerie und die auf der Platte dümpelnde Fotos überarbeiten und anders abspeichern. Die Batchfunktionen sind dafür bei IrfanView ganz nett – die benutze ich zum Beispiel für Bilderfolgen wie hier. Mit GIMP kann man das wohl auch mit Skripten, aber die finde und schreibe man erst.

Mir kam wieder ImageMagick in den Sinn, das bei Serendipity zur Skalierung benutzt wird und dessen convert Anwendung auch in der Serendipity Konfiguration auftaucht. Außerdem kannte ich das noch unter Linux und prächtig ausprobieren, spielen kann man mit ImageMagick allemal. Eigentlich sollte oder kann man einem einzelnen Foto seine ganze Aufmerksamkeit widmen, aber für eine "Knips-Galerie" möchte ich es einfach haben und Vieles in einem Rutsch machen können. Aus dem Dickicht der ImageMagick Operatoren, Optionen, Tests mit ein paar Bildern und Seiten wie Sharpening using Image Magick habe ich mir ein erstes ImageMagick Kommando zusammengebastelt, besser gesagt zusammengereimt, das mir in einer Batchdatei alle JPEGs in einem Verzeichnis bearbeitet: mogrify -path LW:\output -monitor -compress jpeg -interlace line -comment "(CC) BY-SA Kai Raven" -quality 85 -density 72 -resample 100 -filter Sinc -resize 640x -sampling-factor 1x1,1x1,1x1 -unsharp 0.66x0.5+1.0+0.0.

Das ist und wird nicht der Weisheit letzter Schluß sein, ich will ja noch weiter spielen, aber vielleicht gibt es noch Ideen und Anregungen von ImageMagick Nutzern, was man sonst noch benötigt und machen kann. Zur Creative Commons Lizenzgeschichte gibt es noch die informative Seite Commons:Manipulation von Metadaten, die auf den Gebrauch von exiftool eingeht, das ich mir neben der ExifToolGui installiert habe, um Lizenzangaben nicht nur als JPEG Kommentar zu speichern. Für die Windowsversion von GIMP tauchte übrigens gestern in der GIMP Plugin Registry das Exif Viewer Plugin auf, das mit meiner GIMP 2.6.0 Version läuft.

Dies und Das

Tja – und wenn ich nicht am Rechner bin, um etwas zu bearbeiten oder auszuprobieren, auch nicht draußen in der Realwelt im Meatspace, dann lese ich u. a. gerade Hawthornes "Haus mit den sieben Giebeln". Deshalb gilt für mich in Zukunft an den Wochenenden Blog-Enthaltsamkeit, auch wenn ich mir heute selbst widerspreche

Eigentlich nur noch eine Formalie: Vor drei Tagen wurde im Federal Register die Annahme des "Federal Information Processing Standard" (FIPS) 180-3 für den "Secure Hash Standard" (SHS) vom NIST und dem US-Handelsministerium bekanntgegeben, in dem der "Secure Hash Algorithmus" (SHA) und seine Hashwerte definiert und festgelegt werden. Für FIPS-180-3 sind das nach SHA-1, der immer mehr durch Angriffe geschwächt wird, SHA-224, SHA-256, SHA-384 und SHA-512 der "SHA-2 Familie", die u. a. bei der OpenPGP Verschlüsselung mit GnuPG für die Erzeugung der digitalen Signaturen benutzt werden oder für Prüfsummen zur Überprüfung heruntergeladener Software.

Wegen der Fortschritte auf dem Gebiet der Kryptoanalyse von Hashalgorithmen, insbsondere der Angriffen gegen SHA-1 und den Diskussionsergebnissen der NIST Workshops über Hashalgorithmen hatte das NIST am 2. November 2007 ähnlich wie zur Entwicklung des "Advanced Encryption Standard" (AES) die Durchführung des offenen Wettbewerbs um den Nachfolger des Hashalgorithmus SHA-1 und der SHA-2 Familie eröffnet, der den Namen "SHA-3" bekommt und für den Kryptologen bis Ende Oktober 2008 ihre Kandidaten einreichen können.

Der Kandidat muss wie die SHA-2 Familie Hashwerte mit den Längen 224, 256, 384 und 512 bits anbieten, während 160 bit wie bei SHA-1 und RIPEMD-160 nicht mehr vorgesehen ist, weil laut NIST "der 160-bit Hashwert zu klein für die Verwendung für digitale Signaturen wird", mindestens die Sicherheitsstärke der SHA-2 Familie aufweisen und Angriffsmethoden, die möglichweise gegen die SHA-2 Familie praktikabel sind, erfolgreich widerstehen. Nach Abschluss der Prüfungen, Bewertungen und Konferenzen ist mit einer endgültigen Entscheidung nicht vor Ende 2012 zu rechnen. Aktuelle Änderungen kann man in der NIST Zeitachse zum Wettbewerb verfolgen.

Im Tech Beat vom 12. November 2008 teilte das NIST mit, dass bis zur Deadline 64 Hashverfahren von Einzelpersonen bis zu Gruppen mit 15 Mitgliedern für den Wettbewerb eingereicht wurden. Die Einreichungen werden danach begutachtet, ob sie komplett und formal richtig verfasst wurden, um auf der Wettbewerbseite veröffentlicht zu werden und in die erste Wettbewerbrunde zu gehen.

Auf der Hash-Forum Mailingliste teilte William Burr, Manager der Security Technology Group im NIST, am 10.12.08 mit, dass von den 64 Einreichungen 51 Kandidaten überlebt haben und in die erste Wettbewerbrunde gelangen, zu der vom 25 - 28. Februar 2009 die erste SHA-3 Konferenz in Leuven, Belgien stattfindet. Außerdem skizzierte er den Weg des weiteren Wettbewerbverlaufs. Während des Sommers 2009 sollen aus den 51 Kandidaten 15 für die nächste Wettbewerbrunde ausgewählt werden, für die zum August 2010 die zweite SHA-3 Konferenz geplant ist. In die dritte Runde gelangen danach 5 Hashfunktionen als Finalisten, aus denen nach einer dritten Konferenz eine Hashfunktion zum SHA-3 gekürt wird.

Weitere Informationen zu den Kandidaten und den SHA-3 Wettbewerb:

Skein Hashfunktion Bruce Schneier, Niels Ferguson, Stefan Lucks, Doug Whiting, Mihir Bellare, Tadayoshi Kohno, Jon Callas, Jesse Walker.
MD6 Hashfunktion Ron Rivest, Benjamin Agre, Daniel V. Bailey, Christopher Crutchfield, Yevgeniy Dodis, Kermin Elliott Fleming, Asif Khan, Jayant Krishnamurthy, Yuncheng Lin, Leo Reyzin, Emily Shen, Jim Sukha, Drew Sutherland, Eran Tromer, Yiqun Lisa Yin.
The SHA-3 Zoo führt eine Liste über alle Kandidaten und die Ergebnisse ihrer Kryptoanalyse. Das eBASH (ECRYPT Benchmarking of All Submitted Hashes) Projekt untersucht Hashfunktionen hinsichtlich ihrer Performance, auf der Seite zum Skein Hash gibt es Engineering comparison of SHA-3 candidates und im Ecrypt Wiki eine Übersicht zu SHA-3 Hardware Implementations.

MSNBC hat den ausführlichen Artikel ISPs are pressed to become child porn cops nebst einer Powerpoint-Präsentation über das Tool "CoypRouter" von Brilliant Digital im Angebot, das Deep Packet Inspection (DPI) Techniken, die Analyse von Anfragen in Filesharing-Netzen und Umleitung des Traffics an polizeiliche Server und Man-in-the-Middle Angriffe zur Aushebelung schwacher Verschlüsselungstechniken in Filesharing-Netzen bietet.

Ein interessanter Artikel, der die Vorzüge von Deep Packet Inspection Systemen für die Absicherung von Netzwerken, Erkennung und Verhütung von Angriffen, aber auch die Potentiale für Filter-, Blockier- und Überwachungszwecke beinhaltet, wenn man in der Lage ist, zwischen den Zeilen zu lesen, ist der Beitrag Another View - Leveraging deep packet inspection von Timothy Waters vom 30. Oktober 2008 in den Government Computer News.

Nichts Neues soweit und vergleichbar mit einer Reihe anderer Tools, dass es für mich ermüdend wäre, mir das wieder genauer unter die Lupe zu nehmen. Was Produkt und Artikel aber nochmals unterstreichen, ist die Tatsache, dass Internetzugangs-Provider immer mehr zu Hilfssheriffs der Polizeibehörden, der Geheimdienste und Medienindustrie werden sollen, denn die sollen CopyRouter auf ihren Cisco-Routern einsetzen und das den Internetzugangs-Providern und Verbänden der Provider mit derartigen Produkten und Programmen immer mehr die Luft aus den Segeln ihrer Argumente genommen wird, dass effektive Kontrollen und Filterungen auf Providerebene technisch nicht zu realisieren sind. Was ja auch so bleibt, wenn Internetnutzer die richtigen Tools, Techniken und Netzwerke verwendet, aber in den politischen Diskussionen zur Durchsetzung einer stärkeren Verpflichtung der Provider für allerlei Kontroll- und Überwachungszwecke ohne Belang ist.

Sie unterstreichen auch, dass solche Techniken neben dem beliebten Beispiel der Bekämpfung des Austauschs von Kinderpronografie, das für CoypRouter wieder ins Zentrum gesetzt wird, auch – wie zum Beispiel in China – für die Überwachung, Analyse, Filterung und Blockierung aller anderen Daten und Inhalte benutzt werden können – Chatnachrichten, E-Mails, Webseiten usw. usf. Was doch prima Vorratsdatenspeicherung und staatliche "Initiativen" zur "Cyber Security" oder "Anti-Terror" Netzwerküberwachung ergänzt.

Und nicht zuletzt unterstreichen sie auch, dass es schon lange mit der unbedarften Anwendung von P2P-Techniken und -Netzen vorbei ist, die nicht mit starken Verschlüsselungs- und Anonymisierungsfunktionen gegen derartige Angriffe gehärtet sind – bis man versucht, auch denen den Garaus zu machen.

Australien steht davor, den nächsten Schritt zu unternehmen – siehe den Beitrag No opt-out of filtered Internet – Australians will be unable to opt-out of the government's pending Internet content filtering scheme... in der InfoWorld und die Meldung EFA alarmed at "creeping" clean feed der Electronic Frontiers Australia und in der EU benutzt man für ähnliche Zwecke und Ziele ja das Deckmäntelchen des Schutzes des geistigen Eigentums.

Via: Slashdot - Tool To Allow ISPs To Scan Every File You Transmit