Der Staat schnüffelt in deinen Daten? Weil du sie nicht schützt!

Ein offensiver Titel, ich weiß. Und natürlich ist das auch nur die halbe Wahrheit, denn man kann nicht alle Daten schützen, ohne zumindest ein Teil dieser Daten auch zu kommunizieren. Wer niemals spricht, wird auch nicht gehört, aber gelegentlich muss man eben sprechen.

Datensicherheit fängt jedoch immer hinten an, niemals vorn. Daten zu sichern ist keine Eintagsgeschichte und das gilt für Unternehmen genauso, wie für Privatmenschen. Wenn mir ein Privatmensch sagt, er habe keine zu sichernden Daten, dann ist das glatt gelogen, denn wenn ich in meine Passwortverwaltung schaue, finde ich da weit über 200 zu sichernde Passwörter für verschiedene Logins. Das fängt von Karten-PINs an, geht über Facebook & Co. bis hin zu Logins für so exotischere Dienste wie die Packstation oder das Passwort für die Gastherme im Haus. Alles Dienste und Gerätschaften, die Passwörter brauchen und Sicherheit fängt damit an, dass man niemals immer das gleiche Passwort verwendet.

Sicherheit ist eine unglaubliche Schweinearbeit, das stimmt. Ich kenne Unternehmer, deren IT-Abteilung inzwischen weit über die Hälfte ihrer Arbeitszeit in IT-Sicherheit investiert und dennoch gibt es dort viel zu tun. Vollkommene Sicherheit ist eine Utopie, aber dennoch muss man zuschauen, sich vor Virenbefall weitestgehend zu schützen und dafür zu sorgen, dass sicherheitsrelevante Daten nicht in falsche Hände geraten. Oder eben in falsche Netze. Sicherlich würden die Behörden dieser Welt an alle meine Login-Daten kommen, wenn sie das unbedingt wollten. Es ist aber immer eine Frage des Aufwandes, wenn sie alle diese Dienste fragen müssten und nicht durch meine Dummheit vielleicht an ein Passwort kommen würden, das ich, wenn ich fahrlässig wäre, für alle Logins einsetzen würde.

Dazu kommt, dass man sensible Daten nicht einfach nur auf die Festplatte legt. Und auch nicht in ein besonders verstecktes Verzeichnis. Oder auf einen USB-Stick, den man bei Omi in der Schublade versteckt. Nein, Daten sind niemals sicher, wenn sie nicht sinnvoll verschlüsselt sind. Sind sie sinnvoll verschlüsselt und ist das Passwort hinreichend komplex, spielt es keine Rolle, wo die Dateien liegen.

In der IT-Sicherheit unterscheidet man nicht zwischen Unbefugtem, Ex-Mitarbeiter, Hacker, feindlichem Staat oder Heimatstaat. Es gibt schutzbedürftige Daten und die müssen geschützt werden, Punkt. Da man davon ausgehen darf, dass Verkehrsdaten, also Daten, die man beim Kommunizieren erzeugt, allesamt alle aufgezeichnet und mit allen anderen, verfügbaren Verkehrsdaten in Beziehung gesetzt werden – ob nun vom Geheimdienst der USA, Deutschlands, Großbritanniens oder vom Geheimdienst von Krypton, ist irrelevant. Sie schnüffeln alle, sie tauschen alle munter Daten aus, wenn es ihren eigenen Interessen nicht zuwiderläuft und alle verantwortlichen Politiker werden einen Teufel tun, diesem Treiben ein Ende zu setzen, weil Intelligence deren Hintern politisch absichert und die Schnüffelindustrie den nächsten Wahlkampf finanziert. Der Staat gibt auf deinen Datenschutz keinen Pfifferling.

Deshalb: Datenschutz fängt immer von unten an. Und zwar bei dir. Nicht der Staat schützt deine Daten, sondern du selbst musst sie schützen. Und das machst du sinnvollerweise nicht beispielsweise mit den eingebauten Verschlüsselungssystemen von Windows, MacOS, iPhone, Android & Co., sondern nutzt dazu alternative, unabhängige Programme und Verschlüsselungssysteme und Einrichtungen, die ein Stück deiner Privatsphäre schützen und für dich allein sichtbar halten.

Als da wären ein paar Tipps:

Und gleich der Hinweis vorweg: IT-Sicherheit ist harte Arbeit und hat viel mit Disziplin zu tun, um die einmal aufgebaute Sicherheitsebene auch dauerhaft zu halten. Es gibt keine einfachen Lösungen. Es ist aber dafür sehr leicht, seine Daten nicht halbwegs im Griff zu haben. Die Wahl hat da jeder ganz persönlich.

Die mobile Halbherzigkeit von Apple Safari in Sachen FTP.

Ich habe mehr oder weniger aus Jux und Dollerei gerade einmal probiert, ob der Mobile Safari, der Webbrowser auf iOS-Gerätschaften, FTP beherrscht. Und tatsächlich, ich war sehr gut beraten, die ansonsten eigentlich schon prädestine, museale Ausstattung des Mobile Safari nicht in einer Wette dazu zu nutzen, eine Gegenwette abzuschließen. Denn tatsächlich beherrscht der Mobile Safari FTP. Allerdings, und da bleibt sich Apple treu, so bescheuert schlecht, dass es doch schon wieder alle Vorurteile erfüllt.

Als Webbrowser FTP zu können, ist leichter gesagt, als getan. Denn im Gegensatz zum Web ist FTP vor allem eine Geschichte, die für gewöhnlich passwortgeschützt passiert. Hier mal mein Setup:

Meine Fritzbox hat einen angeschlossenen USB-Stick, das ich als Speicherlaufwerk einsetze. Mit der VPN-Funktionalität der Fritzbox habe ich auf diese Weise eine ziemlich praktische Home-Cloud, die ich aus dem Internet problemlos erreichen kann – per VPN und innerhalb meines LAN dann per SMB („Windows Netzwerk) oder auch per FTP. Im Webbrowser gebe ich für diesen Zugriff einfach ein:

ftp://fritz.box/

Normale Webbrowser probieren den FTP-Zugriff und bekommen dann von meiner Fritzbox die Rückmeldung, dass der FTP-Zugriff nicht anonym erfolgen kann, sondern Zugangsdaten erforderlich ist. Normale Webbrowser kennen dieses Verhalten und fordern den Benutzer mit einem Passworteingabefeld auf, Zugangsdaten einzugeben, mit denen dann der FTP-Zugriff nochmals durchgeführt werden kann, nun eben mit Authentifizierung.

Für Apple scheint dies völlig neu zu sein. Denn gebe ich einfach die obige Adresse ein, fragt mich der Mobile Safari nicht etwa nach Zugangsdaten, sondern lässt mich im Regen stehen:

Keine Zugriffsrechte
Sie haben nicht die erforderlichen Zugriffsrechte, um „/“ anzuzeigen.

Darauf wäre ich gar nicht gekommen.

Allerdings sind wir ja nicht vollkommen blöd, sondern wissen ja, wie das URL-Schema funktioniert. Und das URL-Schema hat feste Regeln, wie man neben einer Adresse auch Zugangsdaten übermittelt:

ftp://benutzername:passwort@fritz.box

Und siehe da: So funktioniert das sogar im Mobile Safari, danach bin ich auf meinem Speicherlaufwerk und kann Dateien herunterladen.

Eine ganze Reihe von Nachteilen gibt es, allesamt Mobile-Safari-Schwächen:

  • Es wird nur FTP unterstützt, nicht die verschlüsselte Variante SFTP. Das ist freilich nur ein „weiches“ Problem, denn SFTP unterstützen auch andere Webbrowser nicht. Damit ist der FTP-Zugriff per Webbrowser immer eine Geschichte, die man, wenn es um sensible Daten geht, nur mit einer zusätzlichen Transportverschlüsselung machen sollte. Da der FTP-Zugriff zu meiner Homecloud nur innerhalb meines LAN funktioniert und ich vom Internet aus zwangsläufig ein VPN nach Hause benötige, ein in diesem Szenario vernachlässigbares Problem.
  • Mobile Safari kennt zwar das URL-Schema und die Art und Weise, wie in diesem Schema Zugangsdaten übermittelt werden, allerdings ist die Umsetzung halbherzig. Denn den obigen URL mit integriertem Passwort kann ich so nicht als Lesezeichen hinterlegen, sondern würde gern folgendes als URL verwenden:ftp://benutzername@fritz.boxMit diesem URL können nämlich alle anderen, FTP-fähigen Webbrowser etwas anfangen und fragen nur noch das Passwort ab, das für den Zugriff notwendig ist. Mobile Safari kann mit diesem URL nichts anfangen.
  • Sehr, sehr wichtig: Mobile Safari führt, so wie jeder andere Webbrowser auch, einen URL-Verlauf, in dem alle aufgerufenen URL der letzten Zeit gespeichert werden. Leider speichert Mobile Safari hierbei auch Adressen, in denen sich Benutzernamen und/oder Passwörter befinden. Um das zu verschmerzen, gibt es zwei Möglichkeiten. Das so genannte „private Surfen“ in den Safari-Einstellungen aktivieren oder an der gleichen Stelle den Verlauf löschen. Ist leider relativ umständlich, weil beide Dinge nicht direkt im Mobile Safari vorgenommen werden können, aber leider nicht unwichtig, wenn man sensible Zugangsdaten nicht im Verlauf herumspazieren möchte.

Nun gut, immerhin kann Mobile Safari FTP-Zugriff so auch mit Zugangsdaten, wenn auch auf eine ziemlich vorsintflutliche Weise. Schön sehen die Dateiauflistungen auch nicht aus, aber technisch funktioniert es und ich kann Inhalte aus meiner Homecloud auf iPhone/iPad herunterladen.

Unsicherheiten auf Unkonferenzen.

WLAN-Netzwerke sind eine coole Sache. Gerade auf Barcamps. Und dabei stört meist noch nicht mal, dass gerade auf solchen „nerdigen“ Unkonferenzen die aufgebauten WLAN-Netzwerke schwer unter Last stehen und schon die Netzplanung für eine kleinere Veranstaltung recht anspruchsvoll sein kann. Die hohe Zahl an Geräten ist auch recht einfach zu erklären: Zwei WLAN-fähige Gerätschaften sind mit Smartphone und Laptop fast schon normal und nicht wenige Nutzer bringen es auf drei, vier oder gar mehr WLAN-fähige Geräte. Mal eben einen Access Point hinstellen, um einen WLAN-Hotspot aufzubauen, ist da nicht. Da braucht es schon segmentierte Netze.

Ü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.

De-Mail: Die Schnüffelpost ist da.

Über das „De-Mail“-Projekt habe ich schon hinlänglich gebloggt, ausnahmslos vernichtend. Bescheuert und traumbehaftet.

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.

Quo vadis, iKeePass?

Beim Thema iKeePass, der Portierung der Passwortverschlüsselungssoftware für das iPhone, nicht von einem Drama zu sprechen, fällt schwer, denn als etwas anderes kann man es inzwischen gar nicht mehr bezeichnen.

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.

KeePass für das iPhone: Ein Schritt weiter.

Mitte April gab es wieder einen kleinen Ruck für iKeePass, dem KeePass-Client für das iPhone, der zwar bis dato weitgehend fertig ist, allerdings von Apple noch nicht für denn App-Store freigegeben wurde, was in der ein klein wenig polizeistaatlich organisierten Softwarewelt des iPhone-Universums bedeutet, dass es sich niemand herunterladen und installieren kann.

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.

TrueCrypt 6.2.

Die wunderbare Open-Source-Verschlüsselungssoftware TrueCrypt ist gestern in einer neuen Version veröffentlicht worden und hört nun auf die Versionsnummer 6.2. Das Update ist weitgehend ein Wartungsupdate, das nur ein paar kleinere Neuerungen mitbringt:

  • 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.

Wer unverschlüsselt twittert, ist selbst schuld.

Ich könnte mich auf den Boden werfen und stundenlang lachen, bis der Parkettboden auseinanderfällt, wenn ich die Geschichte auf netzpolitik.org lese, dass offenbar ein Verantwortlicher des Twitter-Streams „cdu_news“ auf dem PolitCamp 09 getwittert hat, jemand offensichtlich im WLAN-Netzwerk herumgesnifft hat, durch den Tweet die Credentials von „cdu_news“ mitbekam und eine Fake-Nachricht twitterte.

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.

DECT-Verschlüsselung nun an oder aus?

Das ganze, jämmerliche Drama um viele DECT-Telefone, die nur auf dem Papier Gespräche verschlüsseln und teilweise noch nicht mal die DECT-eigene Verschlüsselung implementiert haben, zeigt wunderschön, wohin proprietäre Technik führt. Das DECT-Forum gibt Informationen über die eingesetzte Verschlüsselung nicht heraus, weil sie mit dem Argument kontert, dass das die Sicherheit von DECT gefährden würde, was aus kryptologischer Sicht schon mal völliger Nonsens ist, da moderne Verschlüsselungsverfahren zwischen Algorithmus und Schlüssel trennen und man beides braucht, um ein Kryptogramm zu entschlüsseln. Und zum anderen gibt es keine Qualitätskontrolle innerhalb des Forums, so dass im Prinzip jeder Hersteller, der im DECT Forum organisiert ist, mit dem Standard tun und lassen kann, was er möchte, Hauptsache, der Schein bleibt gewahrt und das Endgerät ist mit anderen kompatibel, wenn dann im Zweifelsfall auch nur auf den niedrigsten gemeinsamen Nennern.

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.

Der saure Apfel der Online-Durchsuchung.

Okay, lassen wir mal das Träumen: Dass die Online-Durchsuchung kommen würde, war klar wie passierte Dashi-Brühe und nichts eignet sich zum Durchziehen besser, als der Herbst einer Legislaturperiode.

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.