Heute:

Der Erste Senat des Bundesverfassungsgerichts hat entschieden, dass die Regelungen des TKG und der StPO über die Vorratsdatenspeicherung mit Art. 10 Abs. 1 GG nicht vereinbar sind.

Auf das Bundesverfassungsgericht ist eben noch Verlass.

Es ist doch offensichtlich, dass sensible Kundendaten bei privaten Unternehmen mehr als schlecht aufgehoben sind.

und

Die heutige Praxis einer sechsmonatigen Speicherung direkt beim Telefonanbieter öffnet Missbrauch Tür und Tor.

Man traut also den Unternehmen den Umgang mit ihren eigenen Kundendaten nicht zu (die erwähnte “heutige Praxis” wurde doch gerade erst neu vorgeschrieben, das war vorher kürzer). Ob die Daten da beim Staat besser liegen? Ich glaub das ja eher nicht.

Bevor das neue Gesetz morgen im Bundestag (vermutlich) durchgewunken wird sollten daher möglichst viele Bürger nochmal klarstellen, daß sie damit nicht einverstanden sind (Demokratie!), und wenn ich schon nicht an der physischen Demonstration teilnehmen konnte (hey Leute, Stuttgart 17:00-19:00? Da bin ich noch im Büro) , so kann ich wenigstens diese Seite “Trauer tragen” lassen:

(Todesanzeige vom Arbeitskreis Vorratsdatenspeicherung)

Ich les’ jetzt nochmal 1984…

Ich bin aber nun einmal kein Jurist sondern Techniker, und ich mache mir deshalb ganz andere Gedanken. Deshalb blende ich mal die Frage des Sinns und der Rechtmäßigkeit aus und beschäftige mich nur mit der technischen Machbarkeit.

Welche Daten sollen wir Sammeln:

Nachdem erst Horrormeldungen über die Protokollierung jeder TCP/IP-Verbindung (oder sogar jedes Pakets) kursierten, hat man sich inzwischen auf eine Interpretation geeinigt, in der die gesammelten Daten sehr den ohnehin vorhandenen Logfiles ähneln. Von den Protokollpflichtigen Diensten betreibe ich auf meinem Server nur eMail. Da entstehen bei Versand und Empfang etwa diese Daten (die Mail geht von diesem WordPress-Blog an mich selbst):

Nov  2 17:00:52 charon postfix/pickup[12229]: DEDF9FC443A: uid=33 from=<www-data>
Nov  2 17:00:52 charon postfix/cleanup[14398]: DEDF9FC443A:
   message-id=<1e8ccd8056aded93f095b735e2d1373f@wazong.de>
Nov  2 17:00:52 charon postfix/qmgr[30704]: DEDF9FC443A:
   from=<www-data@wazong.de>, size=1154, nrcpt=1 (queue active)
Nov  2 17:00:52 charon postfix/local[14502]: DEDF9FC443A:
   to=<dentaku@wazong.de>, relay=local, delay=0,
   status=sent (delivered to command: procmail -a "$EXTENSION")
Nov  2 17:00:52 charon postfix/qmgr[30704]: DEDF9FC443A: removed

Beim Abruf diese:

Nov  2 16:08:54 charon imaplogin: LOGIN, user=dentaku,
   ip=[::ffff:90.186.88.15], protocol=IMAP
[...]
Nov  2 16:45:17 charon imaplogin: LOGOUT, user=dentaku,
   ip=[::ffff:90.186.88.15], headers=20200, body=2439620

Vergleichen wir das mal mit dem Gesetzesentwurf, wie er auf vorratsdatenspeicherung.de steht:

Anbieter von Diensten der elektronischen Post (E-Mail) speichern

1. bei Versendung einer Nachricht die Kennung des elektronischen Postfachs und die Internetprotokoll-Adresse des Absenders sowie die Kennung des elektronischen Postfachs jedes Empfängers der Nachricht,
2. bei Eingang einer Nachricht in einem elektronischen Postfach die Kennung des elektronischen Postfachs des Absenders und des Empfängers der Nachricht sowie die Internetprotokoll-Adresse der absendenden Telekommunikationsanlage,
3. bei Zugriff auf das elektronische Postfach dessen Kennung und die Internetprotokoll-Adresse des Abrufenden,
4. die Zeitpunkte der in den Nummern 1 bis 3 genannten Nutzungen des Dienstes nach Datum und Uhrzeit unter Angabe der zugrunde liegenden Zeitzone.

Ja, alles da.

Die Schwierigkeit wäre also eher entweder ein einheitliches Logformat einzuführen (lustig in diesem Zusammenhang, daß ausgerechnet der Webtraffic, für den es mit CLF einen Quasistandard gäbe, nicht bevorratsspeichert werden soll) oder für jedes Logformat einen Parser zu schreiben, der die gewünschten Daten extrahiert.

Platz:

Diverse Artikel haben ja schon größere Bedenken über die Menge der gespeicherten Daten geäußert. Diese Bedenken teile ich nur bedingt: natürlich kostet das alles Geld, die Preise für Speichermedien fallen aber so schnell, daß das keinen Provider in die Pleite treiben wird (kommt schon Leute, wohin speichert denn flickr die ganzen Bilder, selbst für unbezahlte Accounts?). Außerdem speichern die meisten Dienste die Daten ohnehin schon durch die ganz normalen Logfiles (siehe oben). Problematisch wird die Datenmenge erst bei der Auswertung (immer wieder lesenswert dazu: dieses Interview).

Wie kommen die Daten jetzt zu den Strafverfolgern:

Jetzt sind die Daten also vorgehalten, wie kommen die berechtigten Behörden denn jetzt dran? Dafür muß eine neue Serversoftware erstellt werden, an die auf alle Fälle hohe Sicherheitsanforderungen bestehen:

Einerseits darf natürlich nicht irgendein unberechtigter die Daten abrufen, es wird also eine X509/TLS-artige Schlüsselinfrastruktur benötigt. Damit kann sich die Behörde gegenüber dem Logfilesammler (auf Wunsch auch umgekehrt) ausweisen, und die Möglichkeit zur verschlüsselten Übertragung gibt’s bei vielen Implementationen auch gleich noch dazu.

Andererseits soll der Serverbetreiber natürlich möglichst auch nicht merken, daß die Daten eingesehen werden (denn er steckt ja vielleicht mit den bösen Buben unter einer Decke). An dieser Stelle wird es kompliziert, denn wenn auf der Vorratsdatenspeicherungsschnittstelle sonst nie was passiert, dann sieht der Administrator den Zugriff allein schon an den Datenvolumenauswertungen (insbesondere dann, wenn diese auf IP-Port-Basis aufgebrochen sind):

Da hilft es nur, die Daten ganz langsam herunterzuladen — aber was ist “langsam” genau?

Besser ist es, ständig (oder unregelmäßig) auf allen (oder zufälligen) angebundenen Servern Datenverkehr erzeugen, so wie es z.B. TOR macht, das ist aber durch hohe Übertragungskosten recht teuer.

Software:

Was wäre sonst noch zu wünschen?

Da die Logfiles doch eine beträchtliche Datenmenge beinhalten, die in dieser Form nur aufwendig durchsucht werden kann sollten die gewonnenen Daten in einer relationalen Datenbank mit guter Indexmöglichkeit abgelegt werden (sonst sieht der Betreiber die Abfrage an der Prozessorlast statt am Datenverkehr). Das erleichtert auch die Löschunggenau der Daten, deren Aufbewahrungspflicht abgelaufen ist.

Damit die neue Schnittstelle zur Abfrage nicht mit anderen Diensten kollidiert, sollte ihr am besten von der IANA offiziell einen Port zugewiesen werden (vgl. OpenVPN, die früher einfach Port 5000 benutzt haben — jetzt gehört ihnen “hochoffiziell” Port 1194).

Aus den Problemen mit ELSTER sollte unser Land gelernt haben, daß es nicht gut ist, (Pflicht-)Software nur für ein Betriebssystem bereitzustellen. Wo man einer (achtung, Klischee) Werbeagentur mit reiner Maclandschaft vielleicht noch zumuten kann, sich für die elektronische Umsatzsteuervoranmeldung halt doch einen Windows-PC anzuschaffen, da ist die gesetzliche Zwangsumstellung aller Mail-, RADIUS-, VoIP- und …-Server auf eine einheitliche Plattform (z.B. Windows Server 2008, nur 64bit?) schlicht nicht durchführbar (wobei ich keine Prognosen darüber wage, ob es nicht trotzdem versucht wird). Anderenfalls würden sich die Provider der bösen Buben vielleicht durch möglichst exotische Betriebssysteme aus der Vorratsdatenspeicherungspflicht herausstehlen (z.B. MPE/iX?).

Abhilfe schafft hier nur der Vertrieb im Sourcecode (die Unterstützung von POSIX- und win32-API sollte hier fas alles abdecken) oder ein offengelegtes Protokoll, so daß verschiedene Implementationen von dritten erstellt werden können. In diesen beiden Fällen läßt es sich aber kaum zu verhindern, daß der behördliche Zugriff in der einen oder anderen Version aufgezeichnet wird — ein Dilemma, für das es keinen Ausweg gibt…

Die technisch saubere Lösung:

Es sei denn man dreht die Zugriffsrichtung um und überträgt die Daten ständig sobald sie anfallen. Dieser Trick löst elegant sowohl die Probleme des Speicherplatzes als auch des Mitlesens bei Zugriffen durch die Strafverfolgungsbehörden. Diese Variante fordert allerding uneingeschränktes Vertrauen in die Behörde, die sich dann im Besitz der Daten befindet (wobei der Unterschied zwischen Daten, die sich schon dort befinden und Daten, die bei Bedarf jederzeit abgerufen werden können eigentlich in der Praxis kaum ins Gewicht fällt).

Wir verlassen an dieser Stelle allerdings auch wieder die technischen Aspekte, drum höre ich hier auf.