Software

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.

Ich möchte Euch noch eine Erweiterung für Mozilla Browser vorstellen, mit der man eine weitere "Sicherheitsschicht" um die Browser legen kann.

Sie betrifft alle Anfragen und Verbindungen, die der Browser von einer Webpage einer Website, die aktuell aufgerufen wurde, zu einer anderen Website startet, um von der anderen Website Bilder, Skripte, eingebetten Frames usw. nachzuladen, die dann als Objekte der aktuell aufgerufenen Webpage angezeigt werden oder um Funktionen einer aktuellen oder fremden Webanwendung auszuführen und zu verändern, wobei beide Websites unterschiedliche Server betreffen können. Wurde die aufgerufene oder die andere Webpage/Website manipuliert oder dem Nutzer eine URL zu- und untergeschoben (z. B. über die beliebten Spam- und Phishing Mails), die manipulierte Websites aufrufen, kann das u. a. für die Cross-Site Request Forgery Angriffe (XSRF/CSRF & Co.) ausgenutzt werden.

Bei verschiedenen Angriffen spielen deshalb immer Anfragen eine große Rolle, die vom Nutzer unbemerkt im Hintergrund abgewickelt werden, wenn er sich eine Webpage "anschaut" und dortige Webanwendungen nutzt. Klar, könnte man auch ständig alle Anfragen selbst beobachten, überwachen und nachprüfen, aber das wäre beim alltäglichen Surfen kaum zu praktizieren. Hier setzt die RequestPolicy Erweiterung an, die ähnlich wie bei NoScript, RefControl und anderen Erweiterungen alle Anfragen gegen White- und Blacklist prüft. Nur das im Fokus der RequestPolicy Erweiterung die oben geschilderten Anfragen zu Domains fremder Websites stehen, während zum Beispiel mit NoScript das Verbeiten und Zulassen von Javascript, Plugins, iFrames usw. im Mittelpunkt steht, wobei auch NoScript mittlerweile verschiedene Schutzfunktionen gegen Cross-Site Anfragen und Scripting integriert hat, weshalb der Autor der RequestPolicy seine Erweiterung auch als Ergänzung zu NoScript sieht.

Zu RequestPolicy ein Beispiel von der Installation bis zur Anwendung anhand des letzten Beitrags im Weblog: Den größtmöglichen Sicherheitslevel für die Funktionen, die RequestPolicy bietet, der aber auch mit maximalem Einrichtungsaufwand einhergeht, erreicht man also, wenn keine vorkonfigurierte Whitelist und die höchste "Strictness" Überprüfung aktiviert, aber nur die "Quelle-zu-Ziel" Whitelist verwendet wird.

Die RequestPolicy Erweiterung kann über die Homepage der Erweiterung oder, da sie noch im Experimentalstadium ist, nach Login über die Firefox Add-ons Seite installiert werden. Wie man auf der Seite zu aktuellen und geplanten Features von PolicyRequest nachlesen kann, hat der Autor mit PolicyRequest viel vor. Wie gesagt ist sie noch experimentell. Andererseits besteht die Möglichkeit, dass Erweiterungen wie NoScript und AdBlock Funktionen von PolicyRequest übernehmen. Zu erwähnen ist auch, dass es neben PolicyRequest auf Firefox Add-ons eine Reihe anderer Erweiterungen gibt, die sich ebenfalls CSRF und XSS annehmen. Zu begrüßen wäre es, wenn in zukünftigen Mozilla Browsern die Funktionen einer Reihe von Sicherheits-Erweiterungen fest integriert würden, die sich als nützlich und absichernd erwiesen haben, denn die Liste der Erweiterungen, mit denen man seinen Browser zusätzlich absichern muss, wird immer länger.

Da es sich anbietet, hier mal wieder das beliebte Spiel "Zeigst Du mir Deine Erweiterungen, zeig ich Dir meine". Aktuell installierte Erweiterungen, dir direkt oder indirekt der Sicherheit, dem Datenschutz und Anonymisierung dienen:

• Adblock Plus
• BetterPrivacy
• Cache Status
• Cert Viewer Plus
• Controle de Scripts
• CookieSafe
• CustomizeGoogle
• Flashblock
• FoxyProxy
• Layerblock
• NoScript
• RefControl
• RequestPolicy
• SafeCache
• SafeHistory
• Secure Login
• SSL Blacklist
• SSL Blacklist Local Database
• User Agent Switcher

Via:
ha.ckers Blog - RequestPolicy Firefox Extension

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

steht es im Beitrag Windows 7 überlastet Microsoft-Server - Downloads vorerst gestoppt geschrieben.

Tja, Microsoft bleibt eben bescheuert. Das Ganze über BitTorrent angeboten und für jedes DVD Image eine GnuPG Signatur oder eine signierte Datei mit SHA-256 Hashes für alle Images per Download oder signierter E-Mail und gut wäre es gewesen. Denn über BitTorrent werden sowieso alle Images verbreitet – nur eben ohne Prüfmöglichkeiten für die saugenden Nutzer. So bleibt nur diese PR-wirksame Luftnummer übrig.

Wie hoffentlich alle wissen, wurde am 1. Januar die zweite Stufe der Vorratsdatenspeicherung mit der sechsmonatigen Speicherung der Internet-Verkehrsdaten gezündet, d. h. die Speicherung der Anschluss- bzw. DSL-Kennung, der zugewiesenen IP-Adresse, Datum, Uhrzeit und Zeitzone von Anfang und Ende der Internetnutzung durch den Internetzugang-Provider, die gleichen Zeitangaben, Anschlusskennungen von Anrufer und Angerufenen und ihre IP-Adressen durch VoIP-Provider, die Postfachkennungen bzw. E-Mail Adressen von Absendern und Empfängern, ihre IP-Adressen und die gleichen Zeitangaben bei E-Mail Nutzung durch E-Mail Provider. Das auch noch einmal zur Verdeutlichung, weil ich immer noch in der Presse und anderswo lese, "sie" würden auch URLs, IP-Adressen und Hostnamen der Zielrechner auf Vorrat speichern, was "sie" laut Gesetz nicht dürfen, sondern "nur" machen würden, wenn sie die Telekommunikation einer Person komplett überwachen.

Wie hoffentlich auch alle wissen, geht es u. a. um die Verkettung zwischen einer IP-Adresse, die zum Beispiel in der ausgewerten Logdatei eines Servers gefunden wird und der IP-Adresse, die von den zur VDS verpflichteten Providern gespeichert wurden, also um die Ermittlung der Beziehung zwischen beiden IP-Adressen mit anschließender Aufdeckung der Identität durch die Abfrage, welchem Kunden die aufgefunden IP-Adresse zu einem bestimmten Zeitpunkt zugewiesen war, die der Provider mit seinen Vorratsdaten beantwortet. Darüber hinaus über die gleichen Vorratsdaten, welche Beziehungen zwischen Personen bestehen, wenn man ihre Identität erst über Abfragen und Auswertungen der Vorratsdaten aufgedeckt hat.

Dagegen hilft praktisch im Rahmen des technischen Selbst-Datenschutzes, wie hoffentlich alle wissen, die Anonymisierung der eigenen Identität und der Nutzung aller Internetdienste, so dass in den VDS Datenbanken wirklich nur noch zurückbleibt, dass man mit einer IP-Adresse das Internet soundso lang genutzt hat.

Das wissen die Gesetzgeber und Politiker der Vorratsdatenspeicherung so lange, wie sie ihre Pläne zur Umsetzung der Vorratsdatenspeicherung in ihren Köpfen bewegen, weshalb gerade der deutsche Gesetzgeber alle öffentlich zugänglichen Anonymisierungsdienste ebenfalls zur Vorratsdatenspeicherung verpflichtet sehen möchte.

Der verlinkte Beitrag enthält auch die Positionen der VDS-Gegner, die der Ansicht der Bundesregierung und der Bundestagsfraktionen der CD/CSU und SPD widersprechen. Sie sehen die gesetzliche Verpflichtung von Anonymisierungsdiensten und ihre Begründungen in der Gesetzesbegründung als unzulässig an, weshalb zumindest für Privatpersonen und Vereine, die kostenlos einen Anondienst betreiben oder für ihn Serverdienste zur Verfügung stellen, der ohne vertragliche Beziehungen zu seinen Nutzern funktioniert, die Verpflichtung zur Vorratsdatenspeicherung nicht bestehe.

Aus diesen Gründen hatte zum Beispiel die German Privacy Foundation (GPF) erklärt, für ihre Tor, I2P und Mixmaster Nodes keine Vorratsdatenspeicherungsfunktionen umzusetzen. Und wie ein Blick in die Statistik der Tor Nodes zeigt, wird diese Haltung von zahlreichen deutschen Tor Node Betreibern bis jetzt geteilt. Eine weitere Klärung werden die Verfassungsbeschwerden gegen die VDS und die eventuellen Gerichtsverfahren gegen nicht-speichernde Betreiber von Anonymisierungsdiensten erbringen.

Einen ersten Schritt in die andere Richtung, der den Argumenten der VDS-Gegner nicht folgt – da es sich ebenfalls um nicht-kommerzielle Anbieter handelt, die ihre Teilnahme am JonDonym Anonymisierungsdienst unentgeldlich erbringen – und beinahe untergegangen wäre, haben die Betreiber der kostenlosen Mix Nodes des universitären AN.ON Projekts unternommen, namentlich die TU Dresden mit ihrem Lehrstuhl Datenschutz und Datensicherheit, die Uni Regensburg mit ihrem Lehrstuhl Sicherheitsmanagement und das Unabhängigen Landeszentrum für Datenschutz Schleswig-Holstein (ULD), die mit ihren Nodes auch am "JAP" Dienst teilnahmen und jetzt am JonDonym Anonymisierungsdienst teilnehmen. Auf der Seite Umsetzung der Vorratsdatenspeicherung durch AN.ON erklärten sie: Die Vorratsdatenspeicherung der AN.ON Nodes (wohlgemerkt wird hier nicht für die JonDonym Nodes gesprochen, die als Mixe an Kaskaden mit AN.ON beteiligt sind oder in reinen JonDonym Kaskaden laufen!) sieht dann nach meiner Ansicht zusammengefasst so aus, wenn tatsächlich alle Mixe einer Kaskade AN.ON stellen würde. Das Schema gibt aber nur an, was ein AN.ON Mix an der jeweiligen Position in der Mix-Kaskade macht, an denen er teilnimmt. Davon abgesehen, dass es im Gesetz zur Vorratsdatenspeicherung keine Vorschrift gibt, irgendwelche Portnummern auf Vorrat speichern zu müssen, ist die AN.ON Implementation der VDS ein schönes Beispiel dafür, wie man über die Verkettung aller Daten, die bei den einzelnen Mix Nodes gespeichert werden, die Anonymität des Nutzers wieder aufhebt. Von der IP-Adresse des 3. AN.ON Mixes ausgehend, die man in der Logdatei des Zielrechners findet oder der überwacht wird, greift man auf die Daten des 3. Mixes zu und kann rückwärts über die Kanalnummern und Zeitangaben eine Verbindunganfrage über den 2. Mix bis zum 1. Mix zurückverfolgen, bis man schließlich vom 1. Mix auch die IP-Adresse des Nutzers erfährt, die mit der Kanalnummer der ursprünglichen Verbindungsanfrage des Nutzers verknüpft ist. Neben den Kanalnummern sind also die Zeitangaben wichtige Daten.

Etwas Zeit werden auch die Anfragen der abfragenden Sicherheitsbehörden benötigen, da ihnen zunächst nur die Beziehung 3. Mix <-> Zielrechner bekannt ist und sie dann schrittweise gesonderte Anfragen an den 2. Mix und danach an den 1. Mix stellen müssen, d. h. an alle beteiligten Mixe einer Kaskade. Aber es ist machbar. Die Aussage der AN.ON Leute, dass "auch nach Umsetzung dieser Maßnahmen gilt, dass der AN.ON-Dienst vor seinen Betreibern sicher ist: Ein einzelner Mix-Betreiber kann mit den gespeicherten Verkehrsdaten keine Nutzer zurückverfolgen" ist zutreffend. Genauso ist zutreffend, dass eine einzelne Sicherheitsbehörde die Anonymität eines Nutzers über Anfragen an alle Mix Nodes aufheben könnte, wenn alle Mix Nodes von AN.ON gestellt würden oder sich alle JonDonym Mix Nodes einer Kaskade und ihre Betreiber in Ländern befinden würden, in denen Gesetze zur verpflichtenden Vorratsdatenspeicherung für Anonymisierungsdienste existieren.

Zur Zeit sind noch nicht in allen Staaten Gesetze zur Vorratsdatenspeicherung von Internet-Verkehrsdaten umgesetzt oder gar ein Gesetz wie in Deutschland, dass Anonymisierungsdienste unter die Knute zwingen will. Und auch in diesen Staaten befinden sich JonDonym Mix Nodes. Derzeit gibt es auch keine reinen AN.ON Mixkaskaden, so dass die Anfragen von Sicherheitsbehörden nur unter erheblichem Zeitaufwand und Schwierigkeiten für die Behörden befriedigend beantwortet werden könnten bzw. überhaupt nicht. Ob sich das in der Zukunft ändern wird, hängt davon ab, wie alle Staaten ihre Gesetze zur Vorratsdatenspeicherung weiter verändern werden (oder auch nicht), wie die Staaten ihre Verfahren für grenzüberschreitende Ermittlungen und Rechtshilfe-Kooperationen beschleunigen und ob sie mit Mix-Kaskaden konfrontiert sind, von denen zwei Nodes in Staaten betrieben werden, die keine Vorratsdatenspeicherung für Anonymisierungsdienste kennen oder umsetzen.

Zur Zusammensetzung der Mix-Kaskaden stellen sich deshalb die Fragen, wo sich die internationalen "Partner" der JonDonym Mix-Kaskaden befinden und wie dort die Vorratsdatenspeicherung für Mix Nodes bzw. Anonymisierungsdienste ausgestaltet ist und wie (außer der GPF) die "Partner" der AN.ON Mixe verfahren, denn die AN.ON Mitteilung spricht nur für die eigenen Nodes, wenn es darin weiter heißt, Zum Beispiel wäre für den Nutzer von Interesse, wie zur Kaskade SpeedPartner-ULD die Position des deutschen Mix Node Betreibers SpeedPartner zur VDS aussieht, doch dazu finden sich keine Informationen, auch nicht auf der Seite von SpeedPartner.

Schaut man sich die Status an, scheint das die Nutzer der kostenlosen Mix-Kaskaden allerdings wenig zu kümmern, denn auf der SpeedPartner-ULD Kaskade, von der ein Betreiber in Deutschland auf Vorrat speichert und nichts über den anderen Betreiber in Deutschland bekannt ist, tummeln sich neben der JonDos-GPF Kaskade (weil die GPF die Nicht-Speicherung erklärt hat) die meisten Nutzer, was nebenbei wieder ausweist, dass sich die wenigsten Internetnutzer ihre Anonymität etwas kosten lassen wollen, was vergangene Erfahrungen mit bezahlten reinen Anonymisierungsdiensten bestätigt und deshalb auf allen anderen Bezahl-Kaskaden trotz besserer Geschwindigkeit und Verfügbarkeit die Nutzeranzahl viel zu klein ist, um große Anonymsierungsgruppen zu bilden: Zum Punkt der kleinen Nutzerzahlen (geschätzt 30 -100 Nutzer im Durschnitt) auf den Bezahl-Kaskaden denke ich, dass sich JonDonym überlegen muss, welche zusätzlichen Funktionen und Dienste JonDonym neben dem reinen Datentransport anbieten könnte, denn angesichts kostenloser Alternativen wie I2P, Tor, Freenet & Co wird meiner Meinung nach JonDonym sonst langfristig nicht überleben. Ob sich das Ganze bis jetzt überhaupt rechnet, kann ich nicht beurteilen. Aber das nur nebenbei bemerkt.

Für die Oberfläche des JonDonym Clients wäre es sinnvoll, wenn direkt und nicht nur in einem Untermenü der Einstellungen für den Nutzer erkennbar wäre, wo Betreiber und Server ihren Standort haben, ob es an diesem Standort VDS für Anonymisierungsdienste gibt und ob der Betreiber dafür eine Funktion implementiert hat.

Für den Dienst als solchen und seine Nutzer wäre es meiner Meinung nach sinnvoller, wenn Betreiber wie die Universitäten und das ULD lieber direkt ihren Dienst einstellen, anstatt VDS- und Überwachungs-Funktionen für Mixe zu entwickeln und umzusetzen, wie man das bereits seit 2006 macht, denn neben der oben beschriebenen "neuen" Funktion wird im AN.ON Projekt "momentan an einer möglichst datenschutzfreundlichen Überwachung" gearbeitet, wobei schon jetzt und nach den Erfahrungen mit dem BKA und LKA der JAP Client eine "Strafverfolgungsfunktion" zur "Überwachung zukünftiger Verbindungen durch die Mix-Kaskaden" eingebaut hat, die das AN.ON Projekt auf der Seite JAP und Strafverfolgung so beschreibt: Die sogenannte "datenschutzfreundliche Überwachung", mit der sich der JAP Client und AN.ON an der Quadratur des Kreises versuchen, die man auch als "aufhebbare Anonymisierung im Einzelfall" bezeichnen könnte, eignet sich wie die "neue" Funktion ebenfalls zur Vorratsdatenspeicherung, denn laut der Kurzbeschreibung der "datenschutzfreundlichen Überwachung" "kann die Aufdeckung [Anm.: der IP-Adresse des Nutzers] in Echtzeit geschehen oder über früher geloggte Daten". Die Kurzbeschreibung: Die Hervorhebungen habe ich angebracht, weil sie für die Probleme der Sicherheitsbehörden ausschlaggebend sind, die weiter oben dargestellt wurden, weil sie noch die einzigen "Datenschutz" Funktionen in einem System bieten, das mehrfache Fuktionen zur Überwachung und Vorratsdatenspeicherung umsetzt und weil sie unterstreichen, dass langfristig für alle Betreiber-Standorte (Staaten) die verpflichtende Vorratsdatenspeicherung für Anonymisierungsdiensteanbieter umgesetzt werden müsste, um der Anonymität den Garaus zu machen. Worauf dieser Beitrag nicht eingeht, ist das Modell eines omnipotenten globalen Angreifers, der in der Lage wäre, alle Verbindungen zu allen, zwischen allen und von allen Knoten eines Anonymisierungsdienstes zu Zielrechnern ausgehenden Verbindungen zu überwachen und ggf. zusätzlich alle Internetzugang-Provider zur tieferen Inspektion der Datenpakete seiner Kunden verpflichtet oder dies erlaubt.

Ich hoffe, mein Beitrag ist so objektiv, wie es mir möglich ist Darüber hinaus würde ich mir eine aktuellere und umfassendere Aufklärung und Information seitens JonDonym und AN.ON wünschen, die vielleicht kürzer und für alle Nutzer verständlicher daherkommt als dieser Beitrag, nicht nur auf ein paar Seiten oder in einem Forum stattfindet und eben nicht in einem Weblog. Hat man doch nichts aus der Informations-Misere während und nach der BKA/LKA Geschichte gelernt?

Weitere Meldungen und Informationen zur Frage, wie es mit Anonymisierungsdiensten und der VDS weitergeht, werden unter diesen Beitrag eingestellt oder angehängt.

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

Zur Liste der IP-Adressen auf WikiLeaks, die dem BND gehören sollen, über die u. a. Heise in der Meldung BND-Mitarbeiter haben angeblich Wikipedia-Einträge geändert berichtete und Fefe hinwies, hatte mir jemand seine IP Blockliste zugeschickt, die neben den "BND" IP-Bereichen aus der WikiLeaks Veröffentlichung und den whois Informationen auch IP-Bereiche für diverse Landes- und Bundesministerien, sowie Landeskriminalämter und das BKA enthält, aber die auskommentiert und ohne Verbotsanweisung.

Das Ganze ist für die Unix/BSD Portierung des DenyHosts Daemon gedacht, der /etc/hosts.deny aktualisiert, könne aber auch für Firewalls, Paketfilter und Filteranwendungen verwendet werden, wie der Einsender dazu schreibt. DenyHosts setzen Anwender dazu ein, um Login- und Einbruchsversuche bei ihren SSH Servern zu unterbinden. Wer damit etwas anfangen kann oder will, kann sich die Liste herunterladen.

Nun ist es ja nichts Neues und sollte spätestens seit Einrichtung der von Polizei- und Geheimdienstbehörden gemeinsam betriebenen Zentren zum Monitoring von Webseiten, Webforen, Weblogs, IRC-Channels usw. bekannt sein, dass Polizei- und Geheimdienstbehörden "im Internet auf Streife gehen", sich Inhalte anschauen und automatisiert analysieren lassen, Plattformen und Dienste beobachten oder auch verdeckt teilnehmen.

Sofern es mein Weblog oder meine Homepage betreffen könnte, wäre es vielleicht interessant, wie Fefe schrieb, nachzuschauen, ob mich der BND, der Verfassungschutz, ein LKA, das BKA, irgendein ausländischer Dienst oder andere Behörden und Ministerien "besuchen". Aber auf der anderen Seite interessiert es mich auch nicht brennend. Nicht, weil ich alle Ansätze der Sicherheitsbehörden zur Überwachung von Internetdiensten und -nutzern legitim finde, sondern weil sie sich meinetwegen anschauen und durchlesen können, was ich hier schreibe. Themen, Inhalte und Aussagen, die zu einer engeren Fokusierung, sprich harten Überwachung führen würden, würde ich eh anders und anderswo präsentieren.

Ich könnte einen möglichen Besuch auch nicht mit IP Blocklisten verhindern, jedenfalls nur so lange, wie solche IP-Adressen und Bereiche dafür genutzt werden. Was mich zur Frage bringt, wie dämlich eigentlich Behörden wie der BND sind, wenn sie für ihre Recherchen keine Tools wie den TCP Onion-Router (Tor) benutzen, für die sie anfänglich auch gedacht waren. Wenn sie es aber machen oder über einen anderen anonymisierenden Dienst gehen oder sich verdeckt zusätzliche Anschlüsse bei einem Internetzugangsanbieter besorgen, wie es jeder machen kann oder mal was privat erledigen ("Karl-Heinz, kannst Du das heute Abend bei Dir erledigen, wir haben ja gleich Feierabend"), dann kann ich Besuch und Beobachtung erst recht nicht mit IP-Listen und -Filtern verhindern oder bemerken.

Etwas anders verhält es sich, wenn ich Server betreibe, für die ich als Betreiber identifizierbar bin und die öffentlich zugänglich sind. Dann kann es schon interessant sein, staatliche und kommerzielle Interessenten und Schnüffler auszusperren – wenn es auch dabei nicht die erwähnten Umgehungsmöglichkeiten gäbe, die man umgekehrt als Internetnutzer anwendet, um Überwachung, Kontrolle und Zensur zu unterlaufen. Von der potentiellen Gefahr, legitime Besucher und Nutzer ganz auszusperren, wenn man Filter- und Blockiersysteme nicht prüft und pflegt oder die IP-Adressen und -Bereiche auf eine andere Person oder Organisation übergehen (das meinte ich damit).

Wirklich interessant und bedenklich wird die Geschichte mit den BND IPs, wenn Geheimdienst- und Polizeibehörden mit ihnen oder anderen IPs im Netz aktiv werden: um Inhalte wie in der Wikipedia zu ändern, zu manipulieren oder selbst einzustellen, um in fremde Rechnersysteme einzudringen, um dort "den Bundestrojaner" für das Abfangen von Passwörtern, Gesprächsinhalten und Abgreifen oder Vernichten von Daten unterzubringen, um als Undercover Agents in extremistischen Umfeldern zu operieren mit der Gefahr, als Agent Provocateur zu wirken und wenn ihnen dazu die Befugnisse und Mittel von Sicherheitspolitikern per Gesetz in die Hände gelegt werden. Ich denke nicht, dass Kontrollinstanzen wie das Parlamentarische Kontrollgremium solche "Anwendungen" ausreichend auf ihrem Kontrollschirm haben und wenn, erfahren wir nichts darüber.

P. S.: Klar, Angebote wie WikiLeaks, Cryptome oder andere Informationsverbreiter, interessante Mailsendungen und ihre Inhalte sind immer wichtig. Nicht das es zu Missverständnissen kommt