Über was sich allerdings relativ wenig Nutzer Gedanken machen, ist die Übertragungssicherheit. Bei offenen WLAN-Netzwerken wird in der Regel nicht mit Verschlüsselung gearbeitet, um das Benutzen des WLAN-Netzwerks zu vereinfachen. Das bedeutet allerdings, dass Übertragungen von und zum Access Point so offen sind, wie Postkarten. Schneidet ein Nutzer einfach mal den Datenverkehr im Äther mit, sind Zugangsdaten, Passwörter und vertrauliche Informationen offen, wenn der Einzelne nicht mit einer optionalen Verschlüsselung seine Übertragungen absichert, beispielsweise durch die Nutzung sicherer Kanäle per SSL oder einem VPN. Letzteres wäre der Königsweg: VPN aufbauen und den gesamten Übertragungsweg absichern, dann spielt auch das offene WLAN-Netzwerk keine Rolle.

Zwar können die meisten Endgeräte (selbst Smartphones) heutzutage als VPN-Client tätig werden – sogar das iPhone – allerdings scheitert es meist daran, dass es an einem VPN-Endpunkt fehlt, der idealerweise im eigenen Betrieb oder zu Hause steht. Es gibt zwar kommerzielle Dienste, die VPN-Endpunkte anbieten, aber im Grunde genommen höhlt das jede Sicherheitsphilosophie schon wieder aus.

Hat mal also kein VPN, muss man zuschauen, wie man seine Dienste auf verschlüsseltem Wege nutzt. Bei HTTP, IMAP, SMTP und POP3 ist das theoretisch alles kein Problem, hier gibt es verschlüsselte Varianten, sofern die Gegenstelle mitspielt. Tja, sofern. Bei E-Mail kann man da ja durchaus mit seinem ISP diskutieren, aber bei HTTP und einem Web-2.0-Dienst ist man darauf angewiesen, dass der Diensteanbieter auch HTTPS anbietet. Twitter und Facebook, um bei zwei größeren Anbietern zu testen, tun das – hier kann man die Portale auch via “https://” erreichen.

Alles kein Problem, wenn die Dienste direkt im Browser aufgerufen werden, denn dort hätte man die Wahl, einfach HTTPS zu verwenden. Die wenigsten Clients und Apps bieten das jedoch. Die meisten Twitter- und/oder Facebook-Clients bieten erst gar keine Einstellmöglichkeit für den API-Zugriff hinsichtlich HTTPS und das bedeutet, dass die meisten Clients unverschlüsselt mit den jeweiligen Diensten kommunizieren. Und das bedeutet, dass Zugangsdaten für die jeweiligen Dienste bzw. Cookie-Authentifizierungen unverschlüsselt über die Luftschnittstelle wandern, wenn das WLAN-Netzwerk offen ist.

Was tun? In solchen Umgebungen entweder tatsächlich den eigenen Datenverkehr über einen VPN-Tunnel absichern oder lieber auf das WLAN-Netzwerk verzichten und auf GSM/UMTS umschwenken. Genau genommen ist auch die Verschlüsselung im GSM-Standard nicht wirklich (mehr)  frei von Fragwürdigkeiten, allerdings besser als gar nichts.

• 

Ich bin da weiterhin ganz offen und halte De-Mail für nichts anderes als ein kläglicher Versuch, deutsche Behörden auf modern zu trimmen. Und für einen Versuch, den Bürgern ein System aufzuschwatzen, das sie besonders einfach kontrollieren und die dort verschobenen Inhalte im Zweifelsfall sehr einfach beschnüffeln können – so als ob tatsächlich gerade die Leute, die im Internet herumgaunern, so bescheuert sind, ausgerechnet beim Staat ein Postfach zu eröffnen, um darüber andere Leute zu betrügen. Ich kann aber inzwischen wirklich nicht mehr mit gutem Gewissen ausschließen, dass es hier und da tatsächlich durchgeknallte Politiker und Beamte gibt, die auf solche fast schon obszöne Zufälle hoffen und denen so Begriffe wie Privacy kilometerweit vorbeigehen, wenn es darum geht, den eigenen Hintern durch Aktionismus abzusichern. Das machen schon genügend Spitzenpolitiker und Spitzenbeamte mit mehr oder weniger hübsch versteckten Versuchen, Gestapo-Methoden zu etablieren, vortrefflich vor. Warum sollte es da bei den weniger begabten Politikern und Beamten anders sein?

De-Mail ist daher nichts, was man als freier Bürger nutzen will. Der Sinn ist ohne vernünftige Reform des “Backends”, also den Behörden und Ämtern, die auf elektronische Anfragen reagieren soll, zweifelhaft und der Staat ist mit seiner nach wie vor nicht vorhandenen Vision über eine vernünftige Netzpolitik und genügend nicht vertrauenswürdigen Protagonisten in verantwortlichen Stellen nicht vertrauenswürdig als Diensteanbieter. Negropontes Feststellung, dass niemand im Internet wissen könne, ob du ein Mensch oder ein Hund bist, gilt in meiner Empfindung da auch für den Staat. Mit dem Unterschied, dass es dem Staat nach wie vor völlig egal ist, ob im Internet ein Mensch oder ein Hund mit ihm kommunizieren will, er antwortet so oder so nicht. Dass das jetzt mit De-Mail fundamental anders werden soll, das glaube ich sogar nicht, wenn es als Satire in der Titanic stehen würde.

Aber auch aus technischer Sicht ist De-Mail in einem Detail das, was man in der Kryptoanalyse schon aufgrund von einfachsten Informationen über die grundlegende Architektur sofort als nicht vertrauenswürdig einstufen würde: Keine funktionierende Ende-zu-Ende-Verschlüsselung, über die dankenswerterweise die Frankfurter Rundschau und auch netzpolitik.org schreiben.

Zwar ist der Zugriff zum De-Mail-System verschlüsselt, so dass ein Absender tatsächlich eine Nachricht verschlüsselt von seinem Rechner zu De-Mail bekommt. Allerdings wird für den Weg von De-Mail zum Empfänger die zu übertragende Information neu verschlüsselt. Und das stört offensichtlich niemanden der Projektentwickler:

“Die Deutsche Telekom bestätigt, dass die De-Mails kurz geöffnet werden. Gert Metternich, Projektleiter der Telekom, sagte der FR: ‘Im De-Mail-System werden die Mails für den Bruchteil einer Sekunde auf den Servern der Provider entschlüsselt und sofort wieder verschlüsselt und dann weitergeschickt.’ Dies geschehe auf Servern, die staatlich überprüften Sicherheitsstandards entsprächen und abgeschottet seien. ‘Insofern haben wir überhaupt keine Bedenken, dass die De-Mails nicht sicher sind.’”

Würde man diese Vorgehensweise auf den normalen Briefdienst herunterbrechen, hieße das: Sie schreiben einen Brief an Ihre Omi. Sie packen den Brief in einen Kuvert und stecken ihn in den Briefkasten. Der Brief wird von Ihrem Briefzusteller abgeholt. Der nimmt den Brief in sein Verteilzentrum, packt den Brief aus dem Briefumschlag und steckt ihn in einen neuen, mit dem dann der Brief zu Ihrer Omi kommt.

Wer, bitteschön, hält das für eine vertrauenswürdige Kommunikation? Und wer soll bitteschön nicht glauben, dass der Kommunikationsdienstleister das niemals deswegen tun würde, um damit für den Zweifelsfall einen perfekten Zugang zum Schnüffeln zu haben? Eine nicht durchgehende Verschlüsselung ist wie gemacht für das, was man in der Fachsprache als Man-in-the-middle-Attacke versteht und wer als so genannter Projektleiter das entweder nicht versteht oder dieses Potential für unbedenklich hält, dem ist eigentlich nicht mehr zu helfen.

Eine gute IT-Landschaft ist eine, in der eine Staatsgewalt möglichst wenig selbst herumpfuscht. Es hat sich praktisch ausnahmslos gezeigt, dass staatliche Regulierungen des Internets lobbygesteuert sind und teilweise zu groben Benachteiligungen des Verbrauchers geführt haben. Das französische HADOPI ist so eine herausragende Nullnummer, die nichts anders tut, als die Staatsmacht zum Handlanger einer skrupellosen Unterhaltungsindustrie zu machen, die ihre alten Businessmodelle nicht mehr im Griff hat und zynischerweise ihre Lobbyarbeit mit dem Geld der Leute bezahlt, die sie zu knebeln versucht.

Ich bleibe nach wie vor dabei: Dem Staate ist in Sachen Internet und Netzpolitik nach wie vor schon im Ansatz nicht zu trauen. Und bei den Unternehmen, die am De-Mail-System partizipieren, kollaborieren und offenkundig gewollte Schwachstellen herunterspielen, darf sich jeder selbst Gedanken darüber machen, was er davon zu halten hat.

• 

Aus deutscher Sicht ist die iPhone-Welt seit dem Projektstart von iKeePass im März 2008 praktisch am gleichen Ort, wie damals – iKeePass ist im deutschen App-Store nicht verfügbar. Genaugenommen ist es außerhalb der USA und Kanada nirgendwo verfügbar, weil jegliche Software, die Verschlüsselungskomponenten enthält, eine gesonderte Zertifizierung benötigt, um aus den USA exportiert werden zu können. Da alle App-Stores von Apple idiotischerweise in den USA stationiert sind, ergibt sich der skandalöse Zustand, dass Software, die gar nicht in den USA entwickelt wurde, dennoch für die USA eine Zertifizierung benötigt, um außerhalb der USA auf iPhones genutzt werden zu können.

Immerhin gibt es iKeePass 1.0 nun seit Oktober 2009 im US-App-Store und wer sich die Mühen macht, einen Account im US-App-Store anzulegen (dazu benötigt man eine Anschrift in den USA) kann tatsächlich iKeePass für 99 US-Cent erwerben und auf sein iPhone installieren. Alternativ können Besitzer eines gejailbreakten iPhones anhand Cydia einen Fork von iKeePass (und zwar schon der Version 1.1) namens JBiKeePass herunterladen und installieren (das übrigens auch außerhalb den USA).

Die Version 1.0 von iKeePass offenbart dann allerdings eine herb enttäuschende Software, die in meinen Augen selbst die 99 US-Cent, die iKeePass im US-AppStore kostet, derzeit keinesfalls wert ist. Passwortdateien müssen umständlich über einen externen Webserver importiert werden, die Entschlüsselung von größeren Datenbankdateien dauert und alle geöffneten KeePass-Dateien sind darüberhinaus read-only – es gibt keine Schreibfunktion. Dazu kommen dann noch so Dinge wie der fehlende Support der TAN-Listenfunktion (keine Einblendung des Benutzernamenfeldes in der Übersicht) und kein Support der Zwischenablage (behoben ab der Code-Basis 1.1, die Zwischenablagefunktion funktioniert also mit JBiKeePass). Im Grunde genommen lassen sich KeePass-Dateien einfach nur öffnen und betrachten. Für die KeePass- und auch für die iPhone-Idee und vor allem nach fast zwei Jahren Entwicklungsdauer ein mageres Produkt.

Was wirklich mehr als dürftig ist, ist die Kommunikation, denn die ist quasi nicht vorhanden. Der letzte Artikel im Projekt-Weblog stammt von Ende November und berichtet davon, dass die Version 1.1 von Apple nicht zugelassen wurde, da von der Version 1.1 undokumentierte API-Aufrufe benutzt werden, die von Apple so nicht gewünscht sind. Gut, kein Thema, könnte man ja fixen. Oder zumindest darüber diskutieren – wenn man denn wollte. So sammeln sich in jedem der wenigen Artikel jeweils viele Dutzend Kommentare von Nutzern, die wissen wollen, in welchem Stadium das Projekt ist, wie die Bemühungen um Zertifizierung zwecks Exportmodalitäten der Verschlüsselung aussehen, ob die Version 1.1 inzwischen denn mal resubmitted wurde und und und. Resonanz: Null. Hier und da werden vereinzelt Fragen zu einzelnen Benutzerproblemen geklärt, der Rest bleibt unbeantwortet.

Damit wir uns nicht falsch verstehen: Ich verstehe, dass iKeePass – ebenso wie KeePass und die anderen Portierungen – weitgehend Projekte sind, die in der Freizeit entstehen und gepflegt werden. Es spricht jedoch überhaupt nichts dagegen, iKeePass als kostenpflichtige Software anzubieten oder einen PayPal-Button zum Spenden hinzupappen, bei denen selbst ich nicht einfach vorbeigehe, sondern meinen Obolus entrichte. Ich erwarte jedoch auch bei Entwicklern von Open-Source-Projekten, die auf bestehenden Projekten aufbauen, eine gewisse Professionalität und Verantwortung und es ist sicherlich nicht zu viel verlangt, mit seinen Nutzern oder Interessenten zu kommunizieren oder einfach einmal ein Forum einzurichten, wo sich eine Community bilden könnte. Schafft man das nicht, sollte man als Maintainer eines Projektes, das wirklich einen Bedarf nachweisen kann, wirklich so fair sein und sich bemühen, das Projekt auf eine größere Entwicklerbasis zu stellen oder in andere Hände zu geben. Oder, so fürs erste, einfach mal einen Statusbericht und Projektausblick zu geben.

• 

Immerhin hat sich nun etwas kleinlaut herausgestellt, dass man von einem Apple-Mitarbeiter, der sich um die Exportregularien für Verschlüsselungssoftware kümmert, kontaktiert wurde, man darauf aber nicht habe reagieren können, da man umgezogen sei und in den letzten Monaten keinen richtigen Internet-Zugang gehabt habe. Nun denn. Jedenfalls ist man übereingekommen, zunächst eine Veröffentlichung von iKeePass in den USA und in Kanada zu avisieren, weil für eine Veröffentlichung in diesen Staaten keine Exportregularien für Verschlüsselungssoftware zu beachten sind und der so genannte BIS-Prozess, ein Audit des US-Handelsministeriums, das für zu exportierende Verschlüsselungssoftware durchgeführt werden muss, offenbar noch nicht gänzlich durchgeführt wurde.

Das Thema KeePass für das iPhone ist also noch nicht abgefrühstückt und zumindest noch augenscheinlich in der Pipeline.

• 

• Der Bootloader unterstützt nun Motherboards mit BIOS-Versionen, die größere Speicherbereiche für Systemfunktionen reservieren, in der Regel für integrierte RAID-Controller. Unter Windows Vista ist es an dieser Stelle notwendig, dort das Service Pack 1 zu installieren (was grundsätzlich nicht falsch ist).
• Das automatische Mounten soll nun erheblich schneller ablaufen, da nun Partitionen mit unverschlüsselten File-Systemen übersprungen werden.
• Wenn Volumes schreibgeschützt oder als auswerfbar gemountet und als bevorzugte Volumes gespeichert werden, werden sie als schreibgeschützt und als auswerfbar gemountet, wenn die Funktion zum Mounten von bevorzugten Volumes benutzt wird.
• Es gibt zudem eine Änderung beim sicheren Löschen von Inhalten mit Algorithmen, die in Mehrfachdurchgängen eingesetzt werden; hier werden die Header zunächst gelöscht, bevor die verschlüsselten Header auf das Laufwerk geschrieben werden.
• Sonstiges, übliches Bugfixing.

Wie auch bisher lässt sich TrueCrypt autonom auf einem USB-Stick ablegen und von dort aus starten. Nie war TrueCrypt so wertvoll wie heute.

• 

Tja, dumm gelaufen. Traue niemals einem fremden Netzwerk. Und wenn du es schon benutzen willst, dann nutze entweder ein VPN für deine Netzkommunikation oder nutze für deine einzelnen Dienste möglichst verschlüsselte Zugangswege. Das geht bei E-Mail beispielsweise mit SSL-Zugangswegen (das können sogar die Discounthoster wie 1&1) und bei vielen webbasierten Diensten über HTTPS-Websites. Xing leitet Website-Anfragen standardmäßig auf HTTPS-Zugänge und Twitter geht auch per HTTPS. Und das sogar meistens performant, was höchstwahrscheinlich an dem bedauerlichen Umstand liegt, dass kaum jemand den HTTPS-gesicherten Zugang nutzt.

• 

Willkommen in der Welt von Absurdistan und eigentlich sollte man nun DECT-Telefone auf eine Erdumlaufbahn schießen. Andererseits ist die Technik millionenfach im Einsatz und ganz so billig ist die ganze Hardware ja sicherlich auch nicht gewesen. Deshalb: Evaluieren und wenigstens zuschauen, dass die Gerätschaften verschlüsseln.

Nur: Wie erkennen? Wie es sich für Bellheads gehört, hat sich kaum jemand aus dieser Personengruppe je darum geschert, es dem normalen Anwender auf einfache Weise zu ermöglichen, zu überprüfen, ob Gespräche denn nun gerade verschlüsselt werden oder nicht. Das versteht der gemeine Endkunde sowieso nicht, das hat er damit auch nicht zu wissen und deshalb gibt es meines Wissens nach keine klassische DECT-Anlage, die eine aktivierte Verschlüsselung anzeigt. Und wie die ZDF-Sendung Frontal 21 dann auch feststellen musste, stellen sich die meisten Hersteller von DECT-Gerätschaften bei direkten Anfragen auch einfach mal stumm.

AVM macht es auch hier wieder vor. In der Fritzbox 7270 ist bekanntlicherweise eine DECT-Basisstation integriert und deren Interaktion mit angemeldeten Mobilteilen lässt sich über einen DECT-Monitor beobachten. Auf welcher Frequenz und auf welchem Zeitschlitz eine angemeldete Basisstation sendet, ist da eher weniger interessant als die Angabe, ob für eine bestehende Verbindung aktuell Verschlüsselung aktiv ist oder nicht, was zumindest einen Rückschluss darauf geben kann, ob das Mobilteil überhaupt verschlüsseln kann. Meine Siemens-Mobilteile können das offensichtlich mit der Fritzbox 7270.

Allerdings ist das eben auch nur die eine Hälfte: Um nachzuprüfen, ob die Siemens-Mobilteile auch mit der Siemens-Basisstation verschlüsseln, ist ein Scanner und ein Stück Software zum Decodieren der DECT-Übertragung notwendig und gänzlich erschwert wird das alles durch den Umstand, dass die Verschlüsselung zwischen Mobilteil und Basisstation fallweise erfolgt, also bei jedem Verbindungsaufbau aufs Neue.

Alles nicht wirklich hübsch. Es bleibt abzuwarten, wie die plötzliche, negative Publicity und die immer stärkere, technische Aufklärung mit der damit verbundenen Sensibilität gegenüber Verschlüsselung (und vor allem schlechter oder fehlender Verschlüsselung) dem DECT-Standard und letztendlich auch den Bellheads auf Dauer bekommt.

• 

Ich halte die Online-Durchsuchung nach wie vor für hochproblematisch, vermutlich ist sie aber im heutigen Zeitgeist und der Art, wie heute kommuniziert wird, ein Ansatz, den man braucht. Telefone können (und werden) abgehört, Briefpost kann abgefangen, Gespräche belauscht, Wohnungen durchsucht werden. Warum sollte das Notebook von alledem ausgeschlossen sein? Ist der Laptop des Verbrechers rechtsfreier Raum? Aber wo fängt die Privatsphäre an und wo hört sie auf? Früher war es der Hausschlüssel, heute sind es mehrere Dutzend Passwörter.

Alles sehr diffizile Fragen, die man nicht einfach damit beantworten kann, dass man alles so belässt. Der nun zumindest in der Regierungskoalition konsensfähige Mittelweg, dass eine Online-Durchsuchung bundesweit geregelt werden soll und dass dazu ein richterlicher Beschluss, zwei durchsuchende Beamte des Bundeskriminalamtes und auch noch ein Datenschützer notwendig sind, der ausdrücklich bei Daten, die die Privatsphäre des Betroffenen berühren, nochmal das Okay des Richters einholen muss, sind hohe Hürden, die der Rechtsstaat auferlegt – auferlegen muss. Lustig ist das alles nicht, vermutlich für keinen der Beteiligten einer solchen Online-Durchsuchung.

Und ich darf immer wieder gern darauf hinweisen: Verschlüsselung ist kein Luxus und auch nicht verboten. Mit relativ wenig Aufwand können Sie sich ihre Umgebung so einrichten, dass vieles ins Leere läuft.

• 

• Es lassen sich unter Windows Vista und Windows Server 2008 nun auch Nicht-System-Partitionen ohne Datenverlust verschlüsseln.
• Unterstützung von Sicherheits-Tokens und Smartcards.
• Der Bootloader kann so konfiguriert werden, dass er keine Texte anzeigt und sich damit nicht identifiziert. Alternativ kann er mit eigenen Texten bestückt werden.
• Passwörter, die vor dem Booten eingegeben werden müssen, können nun im Treiberspeicher zwischengespeichert werden, so dass diese zum Mounten von TrueCrypt-Volumes (nicht Systempartitionen) genutzt werden können.
• Die Linux- und MacOS-X-Versionen können nun auch eine Windows-Systempartition und komplett unter Windows verschlüsselte Partitionen öffnen, die mit TrueCrypt verschlüsselt wurden.
• Verbessert wurde der Speicherschutz, der durch bestimmte, schlecht designte BIOS-Version gefährtet wurde.
• Verbessert wurde zudem das Verhalten bei der Erstellung einer versteckten Systempartition, da nun nach der Erstellung der verschlüsselten Systempartition die ursprüngliche Partition sicher gelöscht wird.

Heruntergeladen werden kann TrueCrypt, wie immer, auf der Projektseite unter http://www.truecrypt.org/. Und kosten tut es immer noch nichts.

• 

Was offensichtlich einige, die ihre Rechnungen mit einer qualifizierten, elektronischen Signatur ausstatten, nicht wissen, ist der Umstand, dass Kryptografie ein Bereich ist, der sich stetig im Wandel befindet. Was heute dadurch sicher ist, dass der Schlüsselraum so groß oder der Algorithmus so schwer zu berechnen ist, kann morgen schon anders sein. Genau das Problem hat SHA-1 erlebt.

SHA-1 ist ein Algorithmus zur Erzeugung eines so genannten Hashes. Vereinfacht gesagt: Einer eindeutigen Prüfsumme, die dazu genutzt wird, einen digitalen Fingerabdruck einer Datei zu erzeugen. So ein mit SHA-1 erzeugter Fingerabdruck war lange Zeit hinreichend stabil, das heißt, niemand anderes konnte auf die Schnelle einen identischen Fingerabdruck einer Datei erstellen. Das ist seit Februar 2005 vorbei, denn da gab es die ersten Meldungen, dass SHA-1 geknackt war – man konnte offensichtlich das Knacken einer digitalen SHA-1-Prüfsumme manipulieren. Sprich: SHA-1 begann, nicht mehr vertrauenswürdig zu sein. Das passiert mit den besten Algorithmen und ist per se erst einmal nichts verwerfliches.

Da die stärksten Algorithmen durchaus (theoretisch) einmal unpässlich werden könnten, veröffentlicht der Gesetzgeber jedes Jahr einen Algorithmenkatalog, in dem definiert ist, welche Algorithmen noch “gut” sind und für qualifizierte, elektronische Signaturen genutzt werden dürfen und sollen. Diese weitgehend für Laien unlesbaren Dokumente stellen quasi die “Jahreslosung” in Sachen nutzbare Algorithmen dar – nutzt jemand einen Algorithmus für seine qualifizierten elektronischen Signaturen, der nicht mehr empfohlen wird, ist die Signatur nicht vertrauenswürdig und das signierte Dokument damit auch nicht.

Das passiert vielen Rechnungsausstellern, die an sich guten Willen zeigen, seit Anfang des Jahres eben mit SHA-1, das offiziell seit 1. Januar 2008 nicht mehr genutzt werden sollte und ab 30. Juni 2008 nach Ablauf der Übergangsfrist auch nicht mehr als Hashing-Algorithmus anerkannt wird. Wer also eine qualifizierte, elektronische Signatur nach dem 30. Juni 2008 noch mit dem SHA-1-Algorithmus einsetzt, hat ein Problem. Beziehungsweise – und das ist das pikante an elektronischen Signaturen – der Rechnungsempfänger hat eines, denn er darf so eine Rechnung eigentlich gar nicht akzeptieren.

Gängige Signaturanwendungen berücksichtigen diesen Umstand übrigens, wenn man denn die Anwendung auch regelmäßig aktualisiert. Zum einen nutzen diese Anwendungen dann SHA-1 erst gar nicht mehr und zum anderen wird bei Prüfungen auch explizit darauf hingewiesen, wenn SHA-1 genutzt wurde und dass die Prüfung eigentlich fehlgeschlagen ist.

•