Mega-Facts
Bislang ist wenig konkretes über Funktionsweise und Zuverlässigkeit des Cloud-Dienstes Mega bekannt. Doch die verfügbare Dokumentation und eigene Beobachtungen lassen bereits ein paar Rückschlüsse zu.
Der neue Cloud-Speicher-Dienst Mega hat soeben erst den Betrieb aufgenommen. Eine detaillierte Untersuchung der Funktionsweise steht noch aus. Das Folgende bezieht sich auf erste Beobachtungen und die vom Betreiber veröffentlichte Dokumentation.
Verschlüsselung
Konkrete Details, wie das alles funktioniert, gibt es derzeit nicht. Auch die von Mega bereit gestellte Doku ist nicht sonderlich hilfreich. Es sieht so aus, als würde jede Datei mit einem separaten Key AES verschlüsselt. Dieser wird – laut Mega – nicht an den Server übertragen; Ver- und Entschlüsselung erfolgen jeweils lokal durch eine App, die im Browser läuft.
Derartige Konzepte sind nicht neu; Zerobin etwa implementiert ein ähnliches Konzept, um den Server-Betreiber von der Haftung für den Inhalt seiner Nutzer zu befreien. Von diesen hat sich Mega auch den Trick abgeschaut, die Schlüssel in HTML-Anker einzubetten. Mega-URLs haben die Form:
https://mega.co.nz/#!12wlkJza!PRA-8y246I55pJUl-...
Dabei ist der komplette Teil hinter dem # ein Verweis auf eine Einsprungmarkierung in die HTML-Seite. Solche Anker wertet der Browser immer lokal aus und schickt sie nicht an den Server. In diesem Fall ist offenbar 12wlkJza ein Index für die Datei und PRA-8y246I55pJUl-... der zugehörige Schlüssel.
Bedenklich stimmt allerdings folgender Satz aus der Mega-Dokumentation:
Each user account uses a symmetric master key to ECB-encrypt all keys of the nodes it keeps in its own trees. This master key is stored on MEGA's servers, encrypted with a hash derived from the user's login password.
Demnach werden alle Schlüssel in verschlüsselter Form auf dem Mega-Server gespeichert. Sollte der dazu verwendetete Master Key tatsächlich direkt und ausschließlich mit dem Anwender-Passwort gesichert sein, das dem Betreiber normalerweise bekannt ist, dann hätte Mega darüber Zugriff auf alle Inhalte. Es ist aber nicht ausgeschlossen, dass die Dokumentation hier lediglich ungenau ist.
[Update, 22.1.2013, 20:00: Unsere ersten Analysen der Kommunikation mit dem Server zeigen, dass der Login-Vorgang nicht mit dem Passwort sondern mit einem daraus abgeleiteten Hash erfolgt. Es ist also durchaus möglich, dass das vom Anwender gewählte Passwort nie an den Mega-Server übertragen wird, sondern nur dem Anwender bekannt ist und dessen Rechner nicht verlässt.]
Verfolgbarkeit
Das Verschlüsselungskonzept ist primär dazu gedacht, den Server-Betreiber vor rechtlichen Konsequenzen zu schützen. Ob Strafverfolger sich von dem technisch verordneten Unwissen der Server-Betreiber beeindrucken lassen, muss sich jedoch erst zeigen. Und ob der Dienst eventuell Sicherheitslücken aufweist, die das Konzept unterminieren, kann erst eine intensive Begutachtung erweisen.
Über die Kooperationswilligkeit des Betreibers bei Ermittlungsverfahren, die sich nicht gegen ihn sondern gegen seine Nutzer richten, kann man derzeit nur spekulieren. Dass Mega den Behörden da gar nicht helfen kann, ist nicht korrekt. So könnte Mega beispielsweise den vom Browser geladenen Script-Code jederzeit so ändern, dass er etwa die zur Verschlüsselung eingesetzten Schlüssel an einen Web-Server sendet. Das ist ein grundsätzliches Problem, wenn das Programm für den Umgang mit Schlüsseln aus einer nicht vertrauenswürdigen Quelle stammt.
Außerdem kann Mega zwar nach eigenen Aussagen nicht feststellen, ob Hans strafbare Inhalte in seinem Cloud-Speicher aufbewahrt. Doch Megas Nutzungsbedingungen sehen in Punkt 8 eine De-Duplizierung der gespeicherten Daten vor. Ist beispielsweise bekannt, dass Eva eine strafrechtlich relevante Datei bei sich abgelegt hat, kann dies zu Problemen für Andere führen.
Bei der De-Duplizierung führt der Server-Betreiber Listen mit Hashes von bereits gespeicherten Datenblöcken. Will ein Anwender eine Datei speichern, die bereits ein anderer Nutzer hochgeladen hat, bekommt er einen Verweis auf den bereits existierenden Speicherort. Das erspart dem Anwender den Upload und vor allem dem Betreiber viel Speicherplatz für mehrfach genutzte Dateien. Das Problem, dass die Daten verschlüsselt sind, kann man durch geschickte Schlüsselverwaltung lösen.
Allerdings könnte Mega damit durchaus feststellen, dass etwa Werner die von Eva hochgeladene, problematische Datei ebenfalls in seinem Besitz hat. Und im Zweifelsfall ließe sich eine solche Situation bei der Suche nach bestimmten Inhalten auch durchaus gezielt herbeiführen. Ob Mega tatsächlich De-Duplizierung einsetzt, ist derzeit nicht bekannt. In der Vergangenheit hat der Betreiber noch versichert, er verzichte auf diese Funktion. Aber warum räumt er sich dann jetzt in den Nutzungsbedingungen das Recht dazu ein?
Qualität
Der Dienst befindet sich derzeit noch im Beta-Stadium. So ist es keineswegs verwunderlich, dass Anwender – wie bereits mehrfach geschehen – etwa Cross-Site-Scripting-Lücken (XSS) finden. Über die ließe sich unter Umständen Code in den Browser einschleusen, der die Schlüssel kompromittiert. Auch dass die Infrastruktur dem anfänglichen Ansturm nicht gewachsen ist, die Performance also sehr mäßig ist und sogar regelmäßig Aussetzer auftreten, ist nicht außergewöhnlich.
Fazit
Mega hat aus technischer Sicht einige interessante Ansätze vorzuweisen. Auch wenn man die reale Umsetzung derzeit noch nicht endgültig beurteilen kann, ist eines jedoch schon klar: Dass man einem solchen Dienst unbesehen vertrauen könnte, weil man selbst beziehungsweise seine Daten durch Verschlüsselung geschützt sind, stimmt ganz und gar nicht. Und ob der Mega-Gründer Kim DotCom das erforderliche Vertrauen verdient, steht auf einem ganz anderen Blatt.
Nachtrag (23.1.2013, 11:00)
Bereits erste Analysen offenbaren Anfängerfehler bei der Benutzung von Krypto-Funktionen. So lädt Mega Code von externen Systemen eines Content Distribution Networks nach. Statt dessen dessen Integrität mit einer der üblichen Hash-Funktionen wie SHA256 zu überprüfen, setzt es eine Funktion ein, die für diesen Einsatzzweck überhaupt nicht geeignet ist. Zum Einsatz kommt CBC-MAC mit einem im JavaScript-Code fest einprogrammierten Schlüssel (111111, 222222, 333333, 444444).
Sogar die Beschreibung der CBC-MAC bei Wikipedia enthält einen deutlichen Hinweis darauf, dass diese Message Authentication Codes bei bekanntem Schlüssel einfach zu fälschen sind (unter: Using the same key for encryption and authentication). In der Folge kann jeder, der einen dieser CDN-Server kontrolliert – oder den Betreiber zur Mithilfe bewegen kann – den nachgeladenen Code ganz einfach manipulieren, ohne dass dies einen Fehler hervorruft. Damit wäre dann die gesamte Mega-Infrastruktur kompromittiert und Anwender ließen sich beliebig ausspionieren. Derartige Anfängerfehler lassen auch für den Rest der Krypto-Infrastruktur nichts Gutes ahnen. (ju)
