© hypermania2, 123RF

Zähneknirschend erlaubt Mozilla in Firefox das Digital Rights Management. Der folgende Artikel beschreibt die dafür eingesetzte Technik inklusive der Sandbox.

Manche halten es für alternativlos [1], andere für Verrat an den eigenen Idealen [2]: Mozilla hatte sich Mitte Mai dazu entschieden, künftig Digital Rights Management (DRM) in Firefox zu unterstützen, um gegenüber der Konkurrenz nicht ins Hintertreffen zu geraten [3].

Schon länger treiben etwa Microsoft, Google, Apple und Netflix trotz Protesten einen W3C-Standard zum Umgang mit DRM voran, der in dem Entwurf Encrypted Media Extensions (EME, [4]) mündet. Zwar hat das World Wide Web Consortium (W3C) ihn noch nicht zum Standard erhoben, doch die Browserhersteller bauen die neue Technologie bereits ein: der Internet Explorer, Chrome und Safari unterstützen DRM über EME [5].

Ein EME-API, viele CDMs

Die DRM-Technologie ermöglicht es Anbietern wie Netflix, Amazon Prime oder Hulu, die Filme der großen Studios verschlüsselt zu streamen. User dürfen diese nur anschauen, wenn sie berechtigt dazu sind. Um sicherzustellen, dass ein User Filme nicht lokal aufzeichnet, installiert der Anbieter proprietäre Closed-Source-Software auf seinem Rechner, die ihn daran hindert.

Bestellt ein Nutzer zum Beispiel online einen Film, schickt der Anbieter MP4-Container zurück, die einen oder mehrere verschlüsselte Tracks enthalten. Diese Tracks haben zwar einen Key Identifier im Gepäck, nicht aber den Schlüssel selbst. Die EME-Spezifikation macht keine Vorgaben zur Art der Verschlüsselung.

Ein Javascript-Programm reicht nun Initialisierungsdaten der verschlüsselten Container an ein Content Decryption Module (CDM) weiter. Hierbei handelt es sich um die vernagelte Komponente auf dem Benutzerrechner. Sie kontaktiert den Keyserver und sucht den passenden Schlüssel, um den Inhalt des Containers zu dechiffrieren. Dabei kann das CDM den entschlüsselten Daten verschiedene Grade an Restriktionen auferlegen:

• Es kann die entschlüsselten und enkodierten Daten einfach an den Browser senden, etwa im H.264-Format.
• Es kann die Daten entschlüsseln, dekodieren und die Raw-Frames an den Browser schicken, der sie auf das Canvas zeichnet.
• Es kann die Daten entschlüsseln und die dekodierten Pixel vorbei am Browser direkt an den Compositor des Betriebssystems schicken.
• Oder es schickt die Pixel gleich an die GPU, sodass das Betriebssystem diese nicht zurückholen kann.

Die EME-Spezifikation macht dem CDM auch in dieser Frage keine Vorschriften. Das EME-API, auf das sich die genannten Hersteller geeinigt haben, kommt dann beim Schlüsselaustausch zwischen Keyserver und dem lokalen CDM zum Einsatz. Das erwähnte Javascript-Programm nutzt das API, um über XML-HTTP-Requests standardisierte Nachrichten an den Keyserver zu schicken.

Es existiert also eine herstellerübergreifende Interoperabilität, was Mediendateien und Javascript-Code angeht, doch es gibt verschiedene CDMs, die unterschiedliche DRM-Schemata und Protokolle implementieren. Im EME-Sprachgebrauch heißen diese DRM-Schemata Key Systems oder Schlüsselsysteme, EME selbst hat mit Clear Key ein eigenes Schlüsselsystem für Tests entworfen. Abhängig vom eingesetzten Schlüsselsystem reicht das Javascript-Programm Byte-Puffer vom Keyserver an das CDM weiter, die nur das CDM versteht. Diese Daten enthalten den Schlüssel, mit dem das CDM den Film dechiffriert.

Ein Streaming-Anbieter kann also identische verschlüsselte Container über das gleiche Javascript-Programm an die Browser verschiedener Hersteller senden. Letztere verwenden unterschiedliche CDMs mit je eigenen Schlüsselsystemen, Microsofts Internet Explorer 11 unterstützt etwa Play-Ready, Googles Chrome setzt auf Widevine. Um plattformübergreifend zu streamen, muss ein Streaming-Anbieter also Keyserver für jedes Schlüsselsystem anbieten.

Mozillas Weg

Mozilla hat sich lange gegen die EME-Spezifikation gesträubt, der Browserhersteller plädierte für eine Wasserzeichenlösung. Mit der Kehrtwende haben sich die Firefox-Macher auf Adobe Access festgelegt, das als Shared Library vorliegt und einen eigenen H.264-Encoder mitbringt. Dieser spielt als Nebeneffekt auch unverschlüsselte H.264- und AAC-Dateien ab. Nutzer sollen nach den bisherigen Plänen den DRM-Support explizit aktivieren, von Hause aus will Mozilla den Browser ohne ausliefern.

Um das Content Decryption Module herum möchten die Entwickler einen quelloffenen CDM-Host stricken, eine Sandbox [3]. Dabei handelt es sich um eine ausführbare Datei, die per IPC mit dem Browser redet. Der CDM-Host vermittelt zwischen Browser und CDM und soll Letzteres im Zaum halten (Abbildung 1). Bevor der Host CDM-Funktionen aufruft, ändert er laut Mozilla zum Beispiel die Rechte für den Zugriff auf die Festplatte und das Netzwerk.

Abbildung 1: Eine Open-Source-Sandbox soll in Mozillas DRM-Implementierung Adobes CDM einschließen.

Auch das Node Locking, so heißt das fremdgesteuerte Verrammeln des Rechner eines DRM-Nutzers, will Mozilla besser kontrollieren als die Konkurrenz. Es funktioniert unter anderem über Fingerprinting. Das CDM greift auf die Hardware zu und bastelt sich aus verschiedenen Informationen eine eindeutige Identifikationsnummer zusammen, den Fingerprint. Mit ihm lässt sich ein Rechner eindeutig identifizieren, der Content-Anbieter liefert seine Inhalte nur an dieses Gerät. Der Knackpunkt: Meist ist unbekannt, welche Daten das CDM sammelt und ob diese eventuell auch den Anwender eindeutig identifizieren.

Mozillas CDM-Host will daher lediglich eine Identifikationsnummer des Geräts liefern, ohne weiter gehende Infos über den User und dessen Gerät preiszugeben. Zudem soll Firefox für jede Site, die DRM verwendet, eine andere Identifikationsnummer anlegen, was das Tracken über mehrere Sites hinweg erschweren würde. Der Code für den CDM-Host liegt zwar offen, wer ihn aber selbst kompiliert, darf ihn nicht verändern: Das CDM lehnt die Zusammenarbeit ab, wenn der selbst gebaute CDM-Host nicht Bit-gleich zu dem von Mozilla ist.

Vom Regen in die Traufe?

Rein technisch stellt sich die Frage, ob die geplante Regelung irgendwelche Vorteile gegenüber dem Ist-Zustand besitzt. Die Entwickler jedenfalls sind davon überzeugt. Das Netscape Plugin API (NPAPI) erlaubt seit Jahren das Einbinden externer Plugins, etwa von Adobes Flashplayer. Ein hoher Prozentsatz der Firefox-Nutzer verwendet die proprietäre Software, die bereits heute den Einsatz von DRM ermöglicht. Das gilt auch für Linux-User. Warum also eine neue Lösung?

Anders als das CDM bringt der Flashplayer noch eine Reihe weiterer Software mit, etwa eine Runtime für Actionscript, einige APIs, einen Grafik-, Media- und Netzwerkstack. Das CDM besteht hingegen aus einer Bibliothek, die kompakt und kontrollierbarer ist. Sie lässt sich über die »<audio>« – und »<video>« -Tags von HTML 5 einbauen, während aktuell die Tags »<embed>« und »<object>« zum Einsatz kommen.

Ohnehin ist die Zukunft der NPAPI-Plugins unsicher und die darüber eingebundenen Plugins wie Adobes Flashplayer und Microsofts Silverlight stehen bereits jetzt auf den Abschusslisten der Hersteller. Läuft deren Support aus, dann stehen die Firefox-Nutzer, die Onlinevideos eines DRM-Anbieters ansehen wollen, irgendwann im Regen.

Ausblick

Technisch bleiben noch einige Fragen offen. So ist im Detail noch unklar, wie das CDM auf den Rechnern der Nutzer landet. Firefox könnte es auf Wunsch herunterladen oder es bereits an Bord haben und nur aktivieren. Welche Streaming-Dienste Adobe unterstützt, ist ebenfalls noch unklar. Für den einzelnen Nutzer ändert sich nur eins: Er muss fortan entscheiden, ob er DRM auf seinem System aktivieren möchte oder nicht.

Fakt ist jedoch auch: Wenn niemand die Technologie nutzt, hilft der schönste Standard nicht weiter. Zumindest im Musikbereich haben sich nach Benutzerprotesten wieder zahlreiche Anbieter von DRM verabschiedet.