Mega gestartet

Danisch hat natürlich recht, wenn er das Gerede von "militärischer Sicherheit" als PR-Geschwafel bezeichnet. Die jetzt eröffnete Dateihosterseite Mega selbst ist in ihrem Auftreten wenn auch nicht bescheiden, so doch etwas dezenter und sachlicher, sodass man sie sich ruhig mal anschauen kann. Das Konzept von verschlüsseltem Speicherplatz in der Cloud ist ja nun nicht uninteressant.

Funktionsweise

Wie kann man etwas so mithilfe des Browsers verschlüsseln, dass der Nutzer immer wieder dran kommt, der Betreiber es aber nicht entschlüsseln kann?

Bei Mega (laut der Seite selbst und den Kommentaren auf HN, ich habe nicht in den JS-Code geschaut) arbeitet man mit einem Nutzerpasswort, einem bei der Registrierung erstellten RSA-Schlüsselpaar (2048 bit) und symmetrischer Verschlüsselung auf dem Server selbst. Meiner Spekulation nach läuft alles nach diesem Schema ab:

1. Die Datei "Batman.mkv" soll hochgeladen werden.
2. Der Client erstellt den Hash H(Batman) der Datei und verschlüsselt mit diesem Hash und einem symmetrischen Verschlüsselungsverfahren wie AES (128 bei Mega) die Datei selbst.
3. Nun bildet er den Hash der verschlüsselten Datei, also Hash(encrypt(Batman.mkv)), und nennt ihn Lokalisierer.
4. Diesen Lokalisierer sendet er an den Server. Kennt der Server den Lokalisierer schon, kann er die Datei verfügbar machen, sonst muss die Datei hochgeladen werden.
5. Wird die Datei hochgeladen, wird dieser Transfer mittels RSA verschlüsselt. Der Client holt sich vom Mega-Server seinen privaten Key, der mit dem Nutzerpasswort verschlüsselt ist, entschlüsselt ihn und verschlüsselt damit die Datei. Der Server kann sie dann mit dem öffentlichem Schlüssel (trotz des Namens nur dem Server bekannt) entschlüsseln.
6. Da der Browser nicht zuverlässig Daten speichern kann, muss der Key H(Batman) ebenfalls auf dem Server gespeichert werden, natürlich ebenfalls verschlüsselt (ob mit RSA oder symmetrisch mit AES und dem eigenen Passwort ist eigentlich egal).

Das ist deutlich komplizierter, als die Datei einfach per RSA auf dem Client zu verschlüsseln und so verschlüsselt auf dem Server zu speichern. Es hat aber zwei Vorteile:

Obwohl der Serverbetreiber nie den Inhalt der Datei sieht, kann er doppelte Datei duplizieren, anstatt sie mehrfach speichern zu müssen. Erst durch diese Duplikation werden solche Speicherdienste überhaupt bezahlbar.

Außerdem wird es theoretisch möglich, im kleinen Kreis Dateien zu teilen, ohne den öffentlichen RSA-Schlüssel weitergeben zu müssen, indem der Datei-Key (H(Batman)) weitergegeben wird.

Sicherheit

Dass Kim Dotcom überhaupt einen so verschlüsselten Dienst aufbaut hat natürlich primär ein Ziel: Er will von nichts wissen. Da sein Server nie den Inhalt der Dateien sieht, kann er nur schwer belangt werden, wenn auf seinem Server Schwarzkopien gehostet und getauscht werden. Nach dem illegalen Angriff der USA auf ihn ist das ein verständliches und für ihn wichtiges Ziel. Das heißt aber nicht, dass Dateien auf Mega absolut sicher sind. Es gibt durchaus ein paar Bedenken.

Zum einen wird die RSA-Keygenerierung im Browser per Javascript erledigt. Javascript jedoch hat keinen Zugriff auf einen echten Zufallszahlgenerator (RNG). Schon deshalb halten manche die so erstellten RSA-Keys für unsicher.

Ich teile die Meinung nicht: Im wahrscheinlichsten Angreifermodell hat der Angreifer nur Zugriff auf den Dateistrom zwischen Mega und Client. Selbst wenn der RNG nicht perfekt arbeiten würde, ist da immer noch der Input aus den Mausbewegungen und sonstigen Eingabedaten des Nutzers. Daran dürfte ein Angreifer erstmal knabbern.

Es gibt keinen Grund anzunehmen, dass trotz dieses Inputs mit hoher Wahrscheinlichkeit nur ein kleiner Zahl des Zahlenraums gewählt wird.

Viel gewichtiger ist das Bedenken gegen Crypto per JS, das auf dem Misstrauen gegen den Serverbetreiber beruht. Denn die Skripte kommen ja vom Server selbst. Wenn Mega wirklich wollte, könnten sie natürlich eine bestimmte Datei unverschlüsselt übertragen lassen, es prüft ja niemand jedes mal allen Javascript-Code. Daran hat Mega aber eigentlich kein Interesse. Trotzdem, im Kampf gegen einen Staat mit einem Geheimdienst, der Mega entsprechend beeinflussen könnte, würde ich mich nicht darauf verlassen.

Bleibt die Urheberrechts-Industrie. Die hätte im oben beschriebenen Verfahren tatsächlich die Möglichkeit, Dateien vom Server wegfiltern zu lassen, indem sie den Lokalisierer bekannter illegaler Kopien erstellt und an Mega schickt. Da bisher aber noch keine Möglichkeit besteht, Videos von Mega aus öffentlich zu streamen (wie es früher mit MegaUpload ging), dürfte sie das relativ wenig reizen und sie auch wenig rechtliche Handhabe haben, diese Filterung privater Dateien duchzusetzen.

Ob das relevant wird dürfte davon abhängen, welche weiteren Funktionen die Seite noch bekommt.

Fazit

Ich würde Mega nutzen. Weniger wegen der Verschlüsselung, obwohl ich das Verfahren nett finde, sondern weil 50 GB kostenloser Online-Speicher auch ohne Verschlüsselung nicht schlecht zu haben ist.

Wichtiger als die Sicherheitsfrage ist derzeit die Nutzbarkeit, der Server ist gerade komplett überlastet. Und es muss sich sowieso noch zeigen, ob so ein Online-Dateimanager irgendwie relevant für meine tägliche Nutzung werden kann. Ich bezweifel das bisher und denke mehr an ein zusätzliches Backup. Mit der vorhandenen API könnten aber noch ein paar interessante Programme gebaut werden, die das ändern - ein Dropbox-ähnlicher Client mit 50 GB kostenlosem Speicher wäre schon sehr reizvoll, auch weil dann die Verschlüsselung nicht in vom Server gesendeten Skripten passieren müsste.

Oder vielleicht bewährt sich Mega doch als als Server zum Filesharing, eventuell RetroShare-mäßig begrenzt auf den Freundeskreis oder im großen Stil, wenn die Dateischlüssel einfach geteilt werden können. Da muss man abwarten, wie genau die Share-Funktion umgesetzt werden wird - genau wie beim Rest der Seite.