Einführung in verschlüsselte Medienerweiterungen

Sam Dutton

Encrypted Media Extensions (EME) bietet eine API, mit der Webanwendungen mit Systemen zum Schutz von Inhalten interagieren können, um die Wiedergabe von verschlüsselten Audio- und Videodaten zu ermöglichen.

EME wurde entwickelt, damit dieselbe App und dieselben verschlüsselten Dateien in jedem Browser verwendet werden können, unabhängig vom zugrunde liegenden Schutzsystem. Ersteres wird durch die standardisierten APIs und den Ablauf ermöglicht, letzteres durch das Konzept der Common Encryption.

EME ist eine Erweiterung der HTMLMediaElement-Spezifikation – daher der Name. Da EME eine Erweiterung ist, ist die Browserunterstützung optional: Wenn ein Browser verschlüsselte Medien nicht unterstützt, kann er sie nicht abspielen. EME ist jedoch nicht für die Einhaltung der HTML-Spezifikation erforderlich. Aus der EME-Spezifikation:

EME-Implementierungen verwenden die folgenden externen Komponenten:

  • Schlüsselsystem:Ein Mechanismus zum Schutz von Inhalten (DRM). EME definiert keine Key-Systeme, mit Ausnahme von Clear Key (weitere Informationen dazu unten).
  • Content Decryption Module (CDM): Ein clientseitiger Software- oder Hardwaremechanismus, der die Wiedergabe verschlüsselter Medien ermöglicht. Wie bei Key Systems werden bei EME keine CDMs definiert, sondern eine Schnittstelle für Anwendungen bereitgestellt, über die sie mit verfügbaren CDMs interagieren können.
  • Lizenzserver (Schlüsselserver):Interagiert mit einem CDM, um Schlüssel zum Entschlüsseln von Medien bereitzustellen. Die Aushandlung mit dem Lizenzserver liegt in der Verantwortung der Anwendung.
  • Verpackungsdienst:Codiert und verschlüsselt Medien für die Verteilung/Wiedergabe.

Eine Anwendung, die EME verwendet, interagiert mit einem Lizenzserver, um Schlüssel für die Entschlüsselung zu erhalten. Die Nutzeridentität und ‑authentifizierung sind jedoch nicht Teil von EME. Das Abrufen von Schlüsseln zur Medienwiedergabe erfolgt nach der optionalen Authentifizierung eines Nutzers. Dienste wie Netflix müssen Nutzer in ihrer Webanwendung authentifizieren: Wenn sich ein Nutzer in der Anwendung anmeldet, ermittelt die Anwendung die Identität und Berechtigungen des Nutzers.

Wie funktioniert EME?

So interagieren die Komponenten von EME entsprechend dem folgenden Codebeispiel:

  1. Eine Webanwendung versucht, Audio- oder Videoinhalte mit einem oder mehreren verschlüsselten Streams abzuspielen.
  2. Der Browser erkennt, dass die Media verschlüsselt sind (siehe unten) und löst ein encrypted-Ereignis mit Metadaten (initData) aus, die aus den Media zur Verschlüsselung abgerufen werden.
  3. Die Anwendung verarbeitet das encrypted-Ereignis:
    1. Wenn dem Media-Element kein MediaKeys-Objekt zugeordnet ist, wählen Sie zuerst ein verfügbares Key System aus. Verwenden Sie dazu navigator.requestMediaKeySystemAccess(), um zu prüfen, welche Key Systems verfügbar sind. Erstellen Sie dann über ein MediaKeySystemAccess-Objekt ein MediaKeys-Objekt für ein verfügbares Key System. Die Initialisierung des MediaKeys-Objekts sollte vor dem ersten encrypted-Ereignis erfolgen. Die URL des Lizenzservers wird von der App unabhängig von der Auswahl eines verfügbaren Schlüsselsystems abgerufen. Ein MediaKeys-Objekt stellt alle Schlüssel dar, die zum Entschlüsseln der Medien für ein Audio- oder Videoelement verfügbar sind. Sie stellt eine CDM-Instanz dar und bietet Zugriff auf das CDM, insbesondere zum Erstellen von Schlüsselsitzungen, die zum Abrufen von Schlüsseln von einem Lizenzserver verwendet werden.
    2. Nachdem das MediaKeys-Objekt erstellt wurde, weisen Sie es dem Media-Element zu: setMediaKeys() verknüpft das MediaKeys-Objekt mit einem HTMLMediaElement, sodass seine Schlüssel während der Wiedergabe, d.h. während der Decodierung, verwendet werden können.
  4. Die App erstellt ein MediaKeySession durch Aufrufen von createSession() für das MediaKeys. Dadurch wird ein MediaKeySession erstellt, der die Gültigkeitsdauer einer Lizenz und ihrer Schlüssel darstellt.
  5. Die App generiert eine Lizenzanfrage, indem sie die im encrypted-Handler abgerufenen Media-Daten an das CDM übergibt. Dazu ruft sie generateRequest() für das MediaKeySession auf.
  6. Das CDM löst ein message-Ereignis aus: eine Anfrage zum Abrufen eines Schlüssels von einem Lizenzserver.
  7. Das MediaKeySession-Objekt empfängt das message-Ereignis und die Anwendung sendet eine Nachricht an den Lizenzserver (z. B. über XHR).
  8. Die Anwendung empfängt eine Antwort vom Lizenzserver und übergibt die Daten mithilfe der update()-Methode des MediaKeySession an das CDM.
  9. Das CDM entschlüsselt die Medien mit den Schlüsseln in der Lizenz. Ein gültiger Schlüssel kann aus einer beliebigen Sitzung innerhalb der MediaKey verwendet werden, die dem Media-Element zugeordnet sind. Das CDM greift über die Schlüssel-ID auf den Schlüssel und die Richtlinie zu.
  10. Die Medienwiedergabe wird fortgesetzt.

Puh…

Zwischen dem CDM und dem Lizenzserver können mehrere Nachrichten ausgetauscht werden. Die gesamte Kommunikation in diesem Prozess ist für den Browser und die Anwendung nicht sichtbar: Nachrichten werden nur vom CDM und vom Lizenzserver verstanden. Die Anwendungsschicht kann jedoch sehen, welche Art von Nachricht das CDM sendet. Die Lizenzanfrage enthält einen Nachweis der Gültigkeit des CDM (und der Vertrauensbeziehung) sowie einen Schlüssel, der zum Verschlüsseln der Inhaltsschlüssel in der resultierenden Lizenz verwendet wird.

…aber was machen CDMs eigentlich?

Eine EME-Implementierung bietet an sich keine Möglichkeit, Medien zu entschlüsseln. Sie stellt lediglich eine API für eine Webanwendung zur Interaktion mit Content Decryption Modules bereit.

Was CDMs tatsächlich tun, ist nicht in der EME-Spezifikation definiert. Ein CDM kann sowohl die Dekodierung (Dekomprimierung) von Medien als auch die Entschlüsselung übernehmen. Es gibt mehrere potenzielle Optionen für die CDM-Funktionalität, die von der am wenigsten bis zur robustesten reichen:

  • Nur Entschlüsselung, die die Wiedergabe über die normale Media-Pipeline ermöglicht, z. B. über ein <video>-Element.
  • Entschlüsselung und Decodierung, Übergabe von Videoframes an den Browser für das Rendern.
  • Entschlüsselung und Decodierung, Rendering direkt in der Hardware (z. B. der GPU).

Es gibt mehrere Möglichkeiten, ein CDM für eine Web-App verfügbar zu machen:

  • Ein CDM mit dem Browser bündeln
  • Ein CDM separat verteilen
  • Erstellen Sie ein CDM im Betriebssystem.
  • Ein CDM in die Firmware einbinden
  • Einbetten eines CDM in Hardware

Wie ein CDM zur Verfügung gestellt wird, ist nicht in der EME-Spezifikation definiert. In jedem Fall ist jedoch der Browser für die Prüfung und Bereitstellung des CDM verantwortlich.

EME schreibt kein bestimmtes Key System vor. Unter den aktuellen Desktop- und mobilen Browsern unterstützt Chrome Widevine und IE11 PlayReady.

Schlüssel von einem Lizenzserver abrufen

Bei der typischen kommerziellen Nutzung werden Inhalte mit einem Verpackungsdienst oder -tool verschlüsselt und codiert. Sobald die verschlüsselten Medien online verfügbar sind, kann ein Webclient einen Schlüssel (in einer Lizenz enthalten) von einem Lizenzserver abrufen und damit die Entschlüsselung und Wiedergabe der Inhalte ermöglichen.

Der folgende Code (angepasst aus den Spezifikationsbeispielen) zeigt, wie eine Anwendung ein geeignetes Schlüsselsystem auswählen und einen Schlüssel von einem Lizenzserver abrufen kann.

var video = document.querySelector('video');

var config = [{initDataTypes: ['webm'],
  videoCapabilities: [{contentType: 'video/webm; codecs="vp9"'}]}];

if (!video.mediaKeys) {
  navigator.requestMediaKeySystemAccess('org.w3.clearkey',
      config).then(
    function(keySystemAccess) {
      var promise = keySystemAccess.createMediaKeys();
      promise.catch(
        console.error.bind(console, 'Unable to create MediaKeys')
      );
      promise.then(
        function(createdMediaKeys) {
          return video.setMediaKeys(createdMediaKeys);
        }
      ).catch(
        console.error.bind(console, 'Unable to set MediaKeys')
      );
      promise.then(
        function(createdMediaKeys) {
          var initData = new Uint8Array([...]);
          var keySession = createdMediaKeys.createSession();
          keySession.addEventListener('message', handleMessage,
              false);
          return keySession.generateRequest('webm', initData);
        }
      ).catch(
        console.error.bind(console,
          'Unable to create or initialize key session')
      );
    }
  );
}

function handleMessage(event) {
  var keySession = event.target;
  var license = new Uint8Array([...]);
  keySession.update(license).catch(
    console.error.bind(console, 'update() failed')
  );
}

Common Encryption

Mit Common Encryption-Lösungen können Contentanbieter ihre Inhalte einmal pro Container/Codec verschlüsseln und verpacken und sie mit einer Vielzahl von Schlüsselsystemen, CDMs und Clients verwenden, d. h. mit jedem CDM, das Common Encryption unterstützt. Ein mit PlayReady verpacktes Video kann beispielsweise in einem Browser mit einem Widevine-CDM wiedergegeben werden, indem ein Schlüssel von einem Widevine-Lizenzserver abgerufen wird.

Das ist anders als bei älteren Lösungen, die nur mit einem vollständigen vertikalen Stack funktionieren, einschließlich eines einzelnen Clients, der oft auch eine Anwendungs-Laufzeitumgebung enthielt.

Common Encryption (CENC) ist ein ISO-Standard, der ein Schutzschema für ISO BMFF definiert. Ein ähnliches Konzept gilt für WebM.

Schlüssel löschen

EME definiert zwar keine DRM-Funktionen, die Spezifikation schreibt jedoch derzeit vor, dass alle Browser, die EME unterstützen, Clear Key implementieren müssen. Mit diesem System können Medien mit einem Schlüssel verschlüsselt und dann einfach durch Angabe dieses Schlüssels wiedergegeben werden. Clear Key kann in den Browser integriert werden. Es ist kein separates Entschlüsselungsmodul erforderlich.

Clear Key wird zwar wahrscheinlich nicht für viele Arten von kommerziellen Inhalten verwendet, ist aber vollständig mit allen Browsern kompatibel, die EME unterstützen. Es ist auch praktisch zum Testen von EME-Implementierungen und Anwendungen, die EME verwenden, ohne dass ein Inhaltsschlüssel von einem Lizenzserver angefordert werden muss. Unter simpl.info/ck finden Sie ein einfaches Clear Key-Beispiel. Unten finden Sie eine Anleitung zum Code, die den oben beschriebenen Schritten entspricht, jedoch ohne Interaktion mit dem Lizenzserver.

// Define a key: hardcoded in this example
// – this corresponds to the key used for encryption
var KEY = new Uint8Array([
  0xeb, 0xdd, 0x62, 0xf1, 0x68, 0x14, 0xd2, 0x7b,
  0x68, 0xef, 0x12, 0x2a, 0xfc, 0xe4, 0xae, 0x3c
]);

var config = [{
  initDataTypes: ['webm'],
  videoCapabilities: [{
    contentType: 'video/webm; codecs="vp8"'
  }]
}];

var video = document.querySelector('video');
video.addEventListener('encrypted', handleEncrypted, false);

navigator.requestMediaKeySystemAccess('org.w3.clearkey', config).then(
  function(keySystemAccess) {
    return keySystemAccess.createMediaKeys();
  }
).then(
  function(createdMediaKeys) {
    return video.setMediaKeys(createdMediaKeys);
  }
).catch(
  function(error) {
    console.error('Failed to set up MediaKeys', error);
  }
);

function handleEncrypted(event) {
  var session = video.mediaKeys.createSession();
  session.addEventListener('message', handleMessage, false);
  session.generateRequest(event.initDataType, event.initData).catch(
    function(error) {
      console.error('Failed to generate a license request', error);
    }
  );
}

function handleMessage(event) {
  // If you had a license server, you would make an asynchronous XMLHttpRequest
  // with event.message as the body.  The response from the server, as a
  // Uint8Array, would then be passed to session.update().
  // Instead, we will generate the license synchronously on the client, using
  // the hard-coded KEY at the top.
  var license = generateLicense(event.message);

  var session = event.target;
  session.update(license).catch(
    function(error) {
      console.error('Failed to update the session', error);
    }
  );
}

// Convert Uint8Array into base64 using base64url alphabet, without padding.
function toBase64(u8arr) {
  return btoa(String.fromCharCode.apply(null, u8arr)).
      replace(/\+/g, '-').replace(/\//g, '_').replace(/=*$/, '');
}

// This takes the place of a license server.
// kids is an array of base64-encoded key IDs
// keys is an array of base64-encoded keys
function generateLicense(message) {
  // Parse the clearkey license request.
  var request = JSON.parse(new TextDecoder().decode(message));
  // We only know one key, so there should only be one key ID.
  // A real license server could easily serve multiple keys.
  console.assert(request.kids.length === 1);

  var keyObj = {
    kty: 'oct',
    alg: 'A128KW',
    kid: request.kids[0],
    k: toBase64(KEY)
  };
  return new TextEncoder().encode(JSON.stringify({
    keys: [keyObj]
  }));
}

Um diesen Code zu testen, benötigen Sie ein verschlüsseltes Video, das abgespielt werden kann. Ein Video für die Verwendung mit Clear Key kann für WebM gemäß der webm_crypt-Anleitung verschlüsselt werden. Kommerzielle Dienste sind ebenfalls verfügbar (zumindest für ISO BMFF/MP4), und es werden weitere Lösungen entwickelt.

Media Source Extensions (MSE)

Das HTMLMediaElement ist ein einfaches, aber schönes Element.

Wir können Medien laden, decodieren und abspielen, indem wir einfach eine Quell-URL angeben:

<video src='foo.webm'></video>

Die Media Source API ist eine Erweiterung von HTMLMediaElement, die eine genauere Steuerung der Medienquelle ermöglicht, indem JavaScript Streams für die Wiedergabe aus Video-„Chunks“ erstellen kann. Das ermöglicht wiederum Techniken wie adaptives Streaming und Time-Shifting.

Warum ist MSE für EME wichtig? Denn neben der Verteilung geschützter Inhalte müssen kommerzielle Inhaltsanbieter in der Lage sein, die Inhaltsbereitstellung an Netzwerkbedingungen und andere Anforderungen anzupassen. Netflix ändert beispielsweise die Bitrate des Streams dynamisch, wenn sich die Netzwerkbedingungen ändern. EME funktioniert mit der Wiedergabe von Media-Streams, die von einer MSE-Implementierung bereitgestellt werden, genauso wie mit Medien, die über ein src-Attribut bereitgestellt werden.

Wie kann ich Medien, die mit unterschiedlichen Bitraten codiert sind, in Chunks aufteilen und wiedergeben? Weitere Informationen finden Sie unten im Abschnitt zu DASH.

Unter simpl.info/mse können Sie MSE in Aktion sehen. Für dieses Beispiel wird ein WebM-Video mit den File APIs in fünf Blöcke aufgeteilt. In einer Produktionsanwendung würden Videosegmente über Ajax abgerufen.

Zuerst wird ein SourceBuffer erstellt:

var sourceBuffer = mediaSource.addSourceBuffer('video/webm; codecs="vorbis,vp8"');

Der gesamte Film wird dann in ein Videoelement „gestreamt“, indem jeder Chunk mit der Methode appendBuffer() angehängt wird:

reader.onload = function (e) {
  sourceBuffer.appendBuffer(new Uint8Array(e.target.result));
  if (i === NUM_CHUNKS - 1) {
    mediaSource.endOfStream();
  } else {
    if (video.paused) {
      // start playing after first chunk is appended
      video.play();
    }
    readChunk_(++i);
  }
};

Weitere Informationen zu MSE

Dynamic Adaptive Streaming over HTTP (DASH)

Ob Sie es nun als „Multi-Device“, „Multi-Plattform“ oder „Mobil“ bezeichnen – das Web wird oft unter Bedingungen mit wechselnder Konnektivität genutzt. Die dynamische, adaptive Bereitstellung ist entscheidend, um mit Bandbreitenbeschränkungen und ‑variabilität in der Multiscreen-Welt umzugehen.

DASH (auch MPEG-DASH genannt) wurde entwickelt, um sowohl beim Streaming als auch beim Download eine bestmögliche Medienbereitstellung in einer unzuverlässigen Welt zu ermöglichen. Mehrere andere Technologien funktionieren ähnlich, z. B. HTTP Live Streaming (HLS) von Apple und Smooth Streaming von Microsoft. DASH ist jedoch die einzige Methode für adaptives Bitraten-Streaming über HTTP, die auf einem offenen Standard basiert. DASH wird bereits von Websites wie YouTube verwendet.

Was hat das mit EME und MSE zu tun? MSE-basierte DASH-Implementierungen können ein Manifest parsen, Videosegmente mit einer geeigneten Bitrate herunterladen und sie an ein Videoelement übergeben, wenn es benötigt wird. Dabei wird die vorhandene HTTP-Infrastruktur verwendet.

DASH ermöglicht es Anbietern kommerzieller Inhalte also, geschützte Inhalte adaptiv zu streamen.

DASH macht genau das, was der Name besagt:

  • Dynamisch:Reagiert auf sich ändernde Bedingungen.
  • Adaptiv:Die Audio- oder Videobitrate wird automatisch angepasst.
  • Streaming:Ermöglicht das Streamen und Herunterladen.
  • HTTP:Ermöglicht die Bereitstellung von Inhalten mit den Vorteilen von HTTP, ohne die Nachteile eines herkömmlichen Streaming-Servers.

Die BBC hat damit begonnen, Teststreams mit DASH bereitzustellen:

Zusammenfassung:

  1. Media werden mit unterschiedlichen Bitraten codiert.
  2. Die Dateien mit unterschiedlichen Bitraten werden über einen HTTP-Server bereitgestellt.
  3. Eine Client-Web-App wählt aus, welche Bitrate mit DASH abgerufen und wiedergegeben werden soll.

Im Rahmen der Videosegmentierung wird programmatisch ein XML-Manifest erstellt, das als Media Presentation Description (MPD) bezeichnet wird. Hier werden Adaptationssets und Darstellungen mit Dauer und URLs beschrieben. Eine MPD sieht so aus:

<MPD xmlns="urn:mpeg:DASH:schema:MPD:2011" mediaPresentationDuration="PT0H3M1.63S" minBufferTime="PT1.5S" profiles="urn:mpeg:dash:profile:isoff-on-demand:2011"
type="static">
  <Period duration="PT0H3M1.63S" start="PT0S">
    <AdaptationSet>
      <ContentComponent contentType="video" id="1" />
      <Representation bandwidth="4190760" codecs="avc1.640028" height="1080" id="1" mimeType="video/mp4" width="1920">
        <BaseURL>car-20120827-89.mp4</BaseURL>
        <SegmentBase indexRange="674-1149">
          <Initialization range="0-673" />
        </SegmentBase>
      </Representation>
      <Representation bandwidth="2073921" codecs="avc1.4d401f" height="720" id="2" mimeType="video/mp4" width="1280">
        <BaseURL>car-20120827-88.mp4</BaseURL>
        <SegmentBase indexRange="708-1183">
          <Initialization range="0-707" />
        </SegmentBase>
      </Representation>

      …

    </AdaptationSet>
  </Period>
</MPD>

(Dieses XML stammt aus der MPD-Datei, die für den YouTube DASH-Demoplayer verwendet wird.)

Gemäß der DASH-Spezifikation könnte eine MPD-Datei theoretisch als src für ein Video verwendet werden. Um Webentwicklern mehr Flexibilität zu bieten, haben sich Browseranbieter jedoch dafür entschieden, die DASH-Unterstützung JavaScript-Bibliotheken zu überlassen, die MSE verwenden, z. B. dash.js. Durch die Implementierung von DASH in JavaScript kann sich der Anpassungsalgorithmus weiterentwickeln, ohne dass Browser aktualisiert werden müssen. Mit MSE können auch alternative Manifestformate und Bereitstellungsmechanismen getestet werden, ohne dass Browseränderungen erforderlich sind. Der Shaka Player von Google ist ein DASH-Client mit EME-Unterstützung.

Im Mozilla Developer Network finden Sie eine Anleitung dazu, wie Sie mit WebM-Tools und FFmpeg Videos segmentieren und eine MPD erstellen.

Fazit

Die Nutzung des Internets zur Bereitstellung von kostenpflichtigen Video- und Audioinhalten nimmt rasant zu. Anscheinend kann jedes neue Gerät, egal ob Tablet, Spielekonsole, Smart-TV oder Set-Top-Box, Medien von den großen Content-Anbietern über HTTP streamen. Über 85 % der mobilen Browser und Desktopbrowser unterstützen jetzt <video> und <audio>. Cisco schätzt, dass Video bis 2017 80 bis 90 % des globalen Internetdatenverkehrs von Verbrauchern ausmachen wird. In diesem Zusammenhang wird die Browserunterstützung für die Verteilung geschützter Inhalte wahrscheinlich immer wichtiger, da Browseranbieter die Unterstützung für APIs, auf die die meisten Media-Plug-ins angewiesen sind, einschränken.

Weitere Informationen

Spezifikationen und Standards

Artikel