© feverpitched, 123RF.com

Im Rahmen von HTML 5 erhalten Webbrowser die Fähigkeit, Inhalte zu verschlüsseln. Das Sicherheitsfeature hat sich nun zum Politikum entwickelt, denn die Anbieter von digitalen Inhalten möchten es für Digital Rights Management (DRM) verwenden. Hier ein freier Blick auf die Technik.

Die modernen Webtechnologien, die HTML 5 zusammenfasst, stehen eigentlich für Offenheit. Sie ermöglichen Webanwendungen in HTML, Javascript und CSS, die ohne proprietäre Fremdkörper wie Adobe Flash oder Microsoft Silverlight auskommen. Doch ausgerechnet aus der HTML-5-Ecke sehen die Verfechter des offenen Web nun eine neue Gefahr heraufziehen.

Im Zuge der Verschlüsselungsfunktionen in HTML 5 möchten Anbieter, zum Beispiel der Online-Filmverleih Netflix oder die britische Rundfunkanstalt BBC, Digital Rights Management (DRM) für digitale Inhalte umsetzen. Netflix bezeichnet den Kopierschutz als “HTML 5 Premium Video Extensions” [1] und die BBC sieht es als gerechtfertigt an, ihre Sendungen nur den britischen Gebührenzahlern zugänglich zu machen [2]. Der passende Vorschlag beim Standardisierungsgremium W3C heißt Encrypted Media Extensions (EME) und befindet sich im Entwurfsstadium [3].

Technisch fußt das geplante DRM auf der künftigen Fähigkeit von Webbrowsern, Anwendungsdaten mit Hilfe von Javascript zu ver- und entschlüsseln. Die Programmierschnittstelle dafür ist im Web Cryptography API [4] spezifiziert, das ebenfalls als Entwurf beim W3C liegt. Ergänzend zur Transportsicherung per HTTPS lassen sich damit Anwendungsdaten verschlüsseln, etwa vor dem Speichern in der Cloud oder vor ihrer Übertragung mittels Websockets oder Web RTC.

Polyfills

Die Implementierung des Web Cryptography API im Chrome-Browser [5] sowie im Mozilla Firefox [6] hat bereits begonnen. Bis die Browser die volle Unterstützung mitbringen, dienen so genannte Polyfills dazu, einzelne Features nachzurüsten. Bei diesen – nach einer beliebten britischen Spachtelmasse benannten – Browser-Ausbesserungen handelt es sich um Javascript-Bibliotheken, die ein Webbrowser bei Bedarf aus dem WWW lädt.

Dazu zählt auch Polycrypt [7], das zwar einen älteren Entwurf des Web Cryptography API implementiert, sich aber gut zu Demonstrationzwecken eignet. Seine Lizenz ist unklar, es steht aber im Web zur kostenlosen Verwendung bereit. Der Entwickler bindet Polycrypt wie jede andere Javascript-Datei in ein HTML-Dokument ein. Damit das Polyfill funktioniert, muss er das HTML-Dokument über einen Webserver laden. Abbildung 1 zeigt Polycrypt im Einsatz auf der Javascript-Konsole des Browsers.

Abbildung 1: Die Konsole im Browser Chrome wertet mit Polycrypt den Aufruf »encrypt(“abc”)« aus.

Eine weitere Implementierung ist Webcrypto von Netflix [8]. Im Unterschied zu Polycrypt ist es aber keine Javascript-Bibliothek, sondern ein nativ kompiliertes Browser-Plugin für Google Chrome.

Symmetrische Verschlüsselung

Zum Schutz von Anwendungsdaten in einer Cloud ist das symmetrische Verschlüsselungsverfahren AES [9] geeignet. Listing 1 zeigt seine Verwendung zusammen mit dem Web Cryptography API. Zeile 1 speichert einen (im Listing gekürzten) Schlüssel zum Ver- und Entschlüsseln von Anwendungsdaten in der Variablen »encRawKey« als hexadezimale Zahlenfolge ab. Die Variable »encAlg« in den Zeilen 2 bis 9 speichert ein Konfigurationsobjekt.

01 var encRawKey =  "4ea1...b2bf";
02 var encAlg = {
03   name : "AES-GCM",
04   params : {
05     iv : hex2bin("534aea17"),
06     additionalData: hex2bin("534aea17"),
07     tagLength: 128
08   }
09 };
10 function encrypt(text) {
11   polycrypt.importKey("raw", hex2bin(encRawKey)).oncomplete = function(e) {
12     var key = e.target.result;
13     polycrypt.encrypt(encAlg, key, str2bin(text)).oncomplete = function(e) {
14       var cipher = e.target.result;
15       polycrypt.decrypt(encAlg, key, cipher).oncomplete = function(e) {
16         console.log("encrypted: "+bin2str(cipher));
17         console.log("decrypted: "+bin2str(e.target.result));
18       };
19     };
20   };
21 }

Dieses wählt im Feld »name« den AES-Algorithmus im Betriebsmodus GCM mit dem Initialisierungsvektor aus »iv« und der Benutzerkennung aus » additionalData« für die Verschlüsselung per »encrypt()« (Zeile 13) und die Entschlüsselung mit »decrypt()« (Zeile 15).

Die Werte für den Initialisierungsvektor und die Benutzerkennung muss der Programmierer als Bytefolge angeben. Die Konvertierung übernimmt die Funktion »hex2bin()« . Innerhalb der Encrypt-Funktion importiert Zeile 11 mit »polycrypt.importKey()« den Schlüssel aus Zeile 1. Die Formatangabe »raw« im Aufruf erfordert es, den Schlüssel in eine Bytefolge umzuwandeln.

Die Funktion »importKey()« führt der Browser genauso wie die API-Methoden Encrypt, Decrypt, Generatekey, Sign oder Verify asynchron aus. Im Erfolgsfall ruft er für alle Methoden die angegebene Rückruffunktion zum Ereignis »oncomplete« auf. Die Zeilen 11 bis 20 zeigen diese Rückruffunktion. Sie verwendet den importierten Schlüssel in der Variablen »key« im Encrypt-Aufruf (Zeile 13) zum Verschlüsseln.

Im Aufruf von Decrypt (Zeile 15) dient er zum Entschlüsseln der Nachricht aus der Variablen »text« (Zeile 10). Die ver- und die entschlüsselte Nachricht konvertiert »bin2str()« vor der Ausgabe auf die Konsole in eine lesbare Zeichenkette (Zeilen 16, 17). Abbildung 1 zeigt das symmetrische Verschlüsseln im Einsatz.

Zum Schutz von Anwendungsdaten beim Übertragen mittels Websockets oder Web RTC eignet sich das asymmetrische Verschlüsselungsverfahren RSA [10]. Im Gegensatz zu einem symmetrischen Verfahren verwendet RSA ein Schlüsselpaar. Die beiden Kommunikationspartner verwenden den jeweils fremden öffentlichen Schlüssel zum Verschlüsseln und ihren eigenen privaten Schlüssel zum Entschlüsseln einer Nachricht.

Unterschreiben

Daneben eignet sich RSA dazu, Nachrichten mit einer Signatur zu unterschreiben, mit der sich die Echtheit überprüfen lässt. Listing 2 zeigt die Kombination von RSA und Web Cryptography API zum Signieren einer Nachricht. Das Konfigurationsobjekt in den Zeilen 1 bis 7 macht Angaben für das Erzeugen eines Schlüsselpaars im Aufruf von »generateKey()« (Zeile 14): Das Feld »name« wählt eine Variante des RSA-Algorithmus, »modulusLength« das zu verwendende Modul und »publicExponent« den öffentlichen Exponenten. Die Zeilen 8 bis 11 speichern ein Konfigurationsobjekt zur Parametrisierung der Aufrufe der Methoden »sign()« (Zeile 16) und »verify()« (Zeile 18). Der Parameter »hash« bestimmt den Algorithmus SHA-1, der die Prüfsumme über die Nachricht »text« bildet.

01 var sigKeyAlg = {
02   name: "RSASSA-PKCS1-v1_5",
03   params: {
04     modulusLength: 512,
05     publicExponent: new Uint8Array([0x01, 0x00, 0x01])
06   }
07 };
08 var sigAlg = {
09   name: "RSASSA-PKCS1-v1_5",
10   params: { hash: "SHA-1" }
11 };
12 function signature(text) {
13   var arr = str2bin(text);
14   polycrypt.generateKey(sigKeyAlg).oncomplete = function(e) {
15     var key = e.target.result;
16     polycrypt.sign(sigAlg, key.privateKey, arr).oncomplete = function(e) {
17       var sign= e.target.result;
18       polycrypt.verify(sigAlg, key.publicKey, sign, arr).oncomplete = function(e) {
19         console.log("verifyed?: "+e.target.result);
20       };
21     };
22   };
23 };

Die Rückruffunktion zum Aufruf von »generateKey()« und zum Ereignis »oncomplete« (Zeilen 14 bis 22), verwendet in Zeile 16 den privaten Schlüssel aus der Komponente »privateKey« , um die Signatur zu bilden. In Zeile 18 benutzt sie den öffentlichen Schlüssel aus »publicKey« zum Verifizieren der Signatur. Zeile 19 gibt das Ergebnis der Verifikation auf der Javascript-Konsole aus.

Mit solchen kryptographischen Funktionen lässt sich eine Anwendung schreiben, die beispielsweise das Abspielen einer verschlüsselten Videodatei nur einem bestimmten Browser in einer einzigen Sitzung erlaubt. Das heißt, Anbieter wie Netflix oder BBC können über diese HTML-5-Erweiterung effektiv Digital Rights Management (DRM) betreiben.

Widerstand

Das trifft auf den Widerstand der Electronic Frontier Foundation (EFF). Die US-amerikanische Organisation für digitale Bürgerrechte bekämpft seit Jahren DRM. Im Mai 2013 reichte die EFF daher förmlichen Einspruch gegen die Statuten der HTML-Arbeitsgruppe beim W3C ein: Die Encrypted Media Extensions widersprechen nach Meinung der Foundation der Vision des W3C von einem offenen Web und schlössen bestimmte Browser und Plattformen vom WWW aus. Die EME behinderten die Interoperabilität sowie die Partizipation aller am Web.

Gegen das Hollyweb

Dieser Kritik schließt sich die Free Software Foundation (FSF) an, die seit jeher von “Digital Restrictions Management” spricht und es bekämpft (Abbildung 2). Für die aktuelle Bedrohung haben die Aktivisten den Begriff “Hollyweb” geprägt und meinen damit ein Internet, das sich an den Vorstellungen der Filmkonzerne aus Hollywood orientiert [11]. Am 3. Mai 2013 feierten sie mit internationalen Partnern einen Tag gegen DRM und überreichten dem W3C eine Protestnote mit Zehntausenden Unterschriften.

Abbildung 2: Die Free Software Foundation bekämpft Digital Rights Management mit ihrer Kampagne “Defective by Design”.

Förmlichen Einspruch gegen EME hat auch der Software-Entwickler Andreas Kuckartz eingelegt [12]. Der Deutsche ist seit zwei Jahren Invited Expert in der HTML-Arbeitsgruppe des W3C. Er sieht bei EME Probleme mit den Lizenzen von Open-Source-Software: “Seit GPLv3 sind DRM und freie Software nicht mehr vereinbar.” Seiner Meinung nach besteht für das W3C keine Verpflichtung, den Wünschen der Unterhaltungsindustrie nach Digital Rights Management nachzukommen. Der Standardisierungsprozess werde noch einige Stadien durchlaufen, erklärt er und hält den Ausgang für unklar. “Falls das W3C DRM aus den Standards rauslässt, könnten die Interessenten auch einen Alleingang machen”, prognostiziert er vorsichtig.