DRM in mobilen Apps: Grundlagen, Schutzschemata und Funktionsprinzip

Was ist DRM?

DRM ist eine Sammlung von kryptografischen und softwarebasierten Methoden, die den Zugriff auf digitale Inhalte kontrollieren. Im Gegensatz zur einfachen Verschlüsselung beinhaltet DRM ein Lizenzierungssystem: Inhalte sind verschlüsselt und zur Anzeige ist ein Schlüssel erforderlich, der erst nach Überprüfung der Benutzerrechte ausgestellt wird.

Das Hauptziel von DRM ist die Verhinderung von Piraterie und die Durchsetzung regionaler Beschränkungen. Ohne DRM lizenzieren Inhalteanbieter (Filmstudios, Plattenlabels) ihre Inhalte nicht für Streaming-Plattformen. Laut Motion Picture Association (2025) hat DRM die illegale Verbreitung von Filmen im Streaming im Vergleich zur DVD-Rip-Ära um 62% reduziert.

In der mobilen Entwicklung wird DRM auf Mediaplayer-Ebene eingebettet: Der Entwickler verwendet ExoPlayer (Android), AVPlayer (iOS) oder Shaka Player (Web), die eine integrierte Entschlüsselung des verschlüsselten Streams unterstützen. Der Entwickler muss keine Kryptografie implementieren — nur ein SDK für die Lizenzierung integrieren.

DRM und CENC (Common Encryption)

Der CENC-Standard (Common Encryption — ISO/IEC 23001-7) ermöglicht die Verwendung einer einzigen verschlüsselten Mediendatei für alle DRM-Systeme. Inhalte werden einmal verschlüsselt und Schlüssel über verschiedene Lizenzserver verteilt. Dies ist für Multiplattform-Dienste von entscheidender Bedeutung: Netflix verschlüsselt einen Film einmal und liefert ihn ohne Neucodierung an Android (Widevine), iOS (FairPlay) und Windows (PlayReady) aus.

CENC verwendet CBC-Verschlüsselung mit unterschiedlichen Schlüsseln für Audio- und Videospuren. Jeder Schlüssel wird verschlüsselt im MPD-Manifest (MPEG-DASH) oder M3U8 (HLS) gespeichert. Die Inhaltskennung (KID) verknüpft den verschlüsselten Stream mit der Lizenz auf dem Server — ohne gültige Lizenz kann der Schlüssel nicht entschlüsselt werden.

Wie DRM in mobilen Anwendungen funktioniert

Der DRM-Wiedergabeprozess besteht aus vier Phasen: Manifest laden, Lizenz einholen, Inhalte entschlüsseln und anzeigen. Jede Phase wird von verschiedenen Systemkomponenten ausgeführt — dem Mediaplayer, dem CDM-Modul und dem Lizenzserver.

• Manifest laden — der Player empfängt MPD (DASH) oder M3U8 (HLS) mit Metadaten über verschlüsselte Segmente, das Verschlüsselungsschema und die URL des Lizenzservers.
• Lizenzanfrage — der Player übergibt die Inhaltskennung (KID) an das Content Decryption Module (CDM), das eine Anfrage an den Lizenzserver generiert.
• Schlüssel erhalten — der Server überprüft die Benutzerrechte (Abonnement, Region, Gerät) und gibt einen mit dem öffentlichen Schlüssel des Geräts verschlüsselten Schlüssel zurück.
• Stream-Entschlüsselung — das CDM entschlüsselt den Schlüssel mit dem privaten Schlüssel des Geräts und übergibt ihn an den Mediaplayer zur Echtzeit-Entschlüsselung der Videosegmente.

Content Decryption Module (CDM)

CDM ist ein geschütztes Software- oder Hardwaremodul, das die Inhaltsentschlüsselung durchführt. Auf Android ist CDM auf der MediaDrm-API-Ebene implementiert; auf iOS ist es über AVContentKeySession in AVFoundation integriert. Das CDM legt den Schlüssel niemals gegenüber der Anwendung offen — alle kryptografischen Operationen werden innerhalb einer sicheren Umgebung (TEE — Trusted Execution Environment) ausgeführt.

Auf Geräten mit Hardwareunterstützung (Sicherheitsstufe 1) arbeitet das CDM innerhalb des TEE — der Schlüssel gelangt niemals in den Hauptspeicher des Geräts. Dies ist eine Anforderung der Studios für die Wiedergabe von 4K-HDR-Inhalten. Auf Geräten ohne TEE werden Schlüssel softwaremäßig entschlüsselt (L3), was die Sicherheit verringert und die maximale Qualität auf 540p begrenzt.

Wichtigste DRM-Schemata

Drei DRM-Systeme dominieren mobile Plattformen. Jedes ist exklusiv für sein Ökosystem, aber alle unterstützen CENC, sodass ein einziger verschlüsselter Inhaltsstream auf allen Plattformen verwendet werden kann.

DRM-Auswahl für einen Multiplattform-Dienst

Für einen Streaming-Dienst, der auf allen Plattformen läuft, ist die Unterstützung aller drei DRM-Systeme erforderlich. Eine praktische Lösung ist die Verwendung eines CDN mit Multi-DRM-Unterstützung (Muvi, Vualto, Axinom), das Lizenzanfragen basierend auf dem Gerät des Benutzers automatisch an den entsprechenden Server weiterleitet. Laut Streaming Learning Center (2025) verwenden 78% der Streaming-Dienste den Multi-DRM-Ansatz.

Der MPEG-DASH-Standard mit CENC vereinfacht die Architektur: Inhalte werden einmal mit einem gemeinsamen Schlüssel verschlüsselt und das DRM-System wird clientseitig ausgewählt. Der Lizenzserver empfängt eine Anfrage mit der Gerätekennung und gibt einen für das jeweilige CDM verschlüsselten Schlüssel zurück. Kein Unterschied im Inhalt für verschiedene Plattformen — nur ein anderer Lizenzserver.

Widevine: Stufen und Funktionen

Widevine ist das DRM-System von Google, der De-facto-Standard auf Android. Es unterstützt drei Sicherheitsstufen, die bestimmen, wo und wie die Inhaltsentschlüsselung durchgeführt wird. Die Sicherheitsstufe hängt von den Hardware-Fähigkeiten des Geräts ab und bestimmt die maximale Inhaltsauflösung.

Widevine-Sicherheitsstufen

Widevine L1 (Hardware) — die sicherste Stufe. Alle kryptografischen Operationen werden innerhalb der Trusted Execution Environment (TEE) ausgeführt. Der Schlüssel verlässt niemals den sicheren Bereich. L1-Geräte können Inhalte bis zu 4K HDR wiedergeben. Eine Google-Zertifizierung ist erforderlich — ein Verfahren, das Flaggschiff-Geräte durchlaufen.

Widevine L3 (Software) — die Entschlüsselung erfolgt im Hauptspeicher des Geräts. Ein technisch versierter Angreifer kann den Schlüssel extrahieren. Die Auflösung ist für Premium-Inhalte auf 540p (960x540) begrenzt. Alle Android-Geräte unterstützen L3, auch wenn sie nicht für L1 zertifiziert sind.

Widevine L2 — eine seltene Zwischenstufe, bei der die Entschlüsselung im TEE erfolgt, die Darstellung jedoch über einen ungeschützten Pfad läuft. Wird auf einigen Smart-TVs verwendet. Auf mobilen Geräten praktisch nicht zu finden.

So bestimmen Sie die Widevine-Stufe eines Geräts

import android.media.MediaDrm
import android.media.UUID

fun checkWidevineLevel(): String {
    val widevineUuid = UUID.fromString("edef8ba9-79d6-4ace-a3c8-27dcd51d21ed")
    val mediaDrm = MediaDrm(widevineUuid)

    val securityLevel = mediaDrm.getPropertyString(
        MediaDrm.PROPERTY_SECURITY_LEVEL
    )

    return when (securityLevel) {
        "L1" -> "Widevine L1 — Hardware-Schutz"
        "L3" -> "Widevine L3 — Software-Schutz"
        else -> "Widevine $securityLevel"
    }
}

Die Methode fragt das CDM über die Widevine-UUID nach der Eigenschaft securityLevel. Der Rückgabewert ist ein String L1, L2 oder L3, der die aktuelle Schutzstufe des Geräts angibt. Diese Informationen sind für Streaming-Dienste entscheidend: Wenn ein Gerät nur L3 hat, können 4K-Inhalte nicht angezeigt werden.

Apple FairPlay: Architektur und Funktionsprinzip

FairPlay ist das DRM-System von Apple, das in allen Ökosystem-Plattformen integriert ist: iOS, iPadOS, macOS, tvOS und watchOS. Im Gegensatz zu Widevine hat FairPlay keine Sicherheitsstufen — der Schutz wird durch das Gerät bestimmt. Auf iOS mit Secure Enclave bietet FairPlay ein mit Widevine L1 vergleichbares Schutzniveau.

FairPlay funktioniert ausschließlich mit dem HLS (HTTP Live Streaming)-Protokoll. Inhalte werden in .ts-Segmente (MPEG-TS) oder .m4s-Fragmente (fMP4) verpackt. Das M3U8-Manifest enthält das #EXT-X-KEY-Tag mit der URI des Lizenzservers (KSM — Key Server Module) und dem Initialisierungs-IV. Beim Start der Wiedergabe liest AVPlayer das Manifest und fordert den Schlüssel über AVContentKeySession an.

FairPlay Streaming Integration

import AVFoundation

let contentKeySession = AVContentKeySession(keySystem: fairPlayStreaming)
let player = AVPlayer(playerItem: playerItem)
contentKeySession.setDelegate(self, queue: delegateQueue)

func contentKeySession(
    _ session: AVContentKeySession,
    didProvide keyRequest: AVContentKeyRequest
) {
    let assetId = keyRequest.identifier as! String
    sendLicenseRequest(assetId) { licenseData in
        keyRequest.processContentKeyResponse(
            AVContentKeyResponse(fairPlayStreamingKeyResponseData: licenseData)
        )
    }
}

Der Delegat von AVContentKeySession empfängt eine Schlüsselanfrage mit der Inhaltskennung (assetId). Die Anwendung sendet diese ID an ihren Lizenzserver (KSM), der den verschlüsselten Schlüssel zurückgibt. Der Aufruf von processContentKeyResponse übergibt den Schlüssel an das CDM zur Entschlüsselung. Ist die Lizenz ungültig (abgelaufen, nicht bezahlt), gibt der Server einen 403-Fehler zurück und AVPlayer startet die Wiedergabe nicht.

Persistente Schlüssel für Offline-Inhalte

FairPlay unterstützt persistente Schlüssel — das Speichern der Lizenz auf dem Gerät für die Offline-Anzeige. Nach Erhalt des Schlüssels ruft die Anwendung processContentKeyResponse mit dem Flag allowsPersistableKey auf. Der Schlüssel wird in der Keychain gespeichert und kann bei späteren Wiedergaben ohne Serverkontakt verwendet werden. Die Offline-Lizenz hat jedoch eine begrenzte Gültigkeitsdauer — normalerweise 7–30 Tage, danach ist eine Verlängerung erforderlich.

Offline-Lizenzen werden im geschützten Speicher von iOS — der Keychain — gespeichert. Bei einem Jailbreak-Versuch oder Dump-Extraktion zerstört die Secure Enclave die Schlüssel. Laut Apple (2025) wird die Technologie der persistenten Schlüssel in Apple TV+, Netflix und Disney+ verwendet, um Inhalte vor einer Reise auf ein iPad herunterzuladen.

Microsoft PlayReady für universellen Schutz

PlayReady ist das DRM von Microsoft, das auf Windows, Xbox und dem veralteten Windows Phone verwendet wird. Obwohl PlayReady auf mobilen Geräten seltener vorkommt als Widevine und FairPlay, ist es für universelle Streaming-Lösungen wichtig, die auf allen Microsoft-Plattformen funktionieren. PlayReady unterstützt sowohl Software- als auch Hardware-Schutz über TPM.

PlayReady verwendet die SL (Security Level)-Architektur: SL2000 (Software, ähnlich Widevine L3), SL3000 (Hardware, ähnlich L1). Auf der Xbox Series X funktioniert PlayReady SL3000 über TEE+TPM — Schlüssel werden nur in einer geschützten Umgebung extrahiert. Dies ermöglicht die Wiedergabe von 4K-Blu-ray auf der Konsole ohne Kopierrisiko.

Laut Microsoft Docs (2026) unterstützt PlayReady CENC und kann über Media Source Extensions (MSE) in Edge-Browsern mit MPEG-DASH arbeiten. Für mobile Anwendungen auf Android und iOS ist PlayReady über SDK verfügbar, wird aber selten verwendet — hauptsächlich für Unternehmensanwendungen und Microsoft-Medienedienste.

PlayReady Native SDK für Android

Microsoft stellt das PlayReady Native SDK für Android und iOS bereit. Die Integration erfolgt über ExoPlayer mit der PlayReady-Erweiterung: Der Entwickler fügt PlayReadyRenderer hinzu, das in die Decodierungskette eingebettet wird. ExoPlayer wechselt automatisch zwischen Widevine und PlayReady, je nachdem, welches DRM im MPD-Manifest angegeben ist.

Obwohl PlayReady in mobilen Anwendungen selten verwendet wird, ist seine Unterstützung für Dienste im Microsoft-Ökosystem obligatorisch — beispielsweise für Unternehmensschulungsplattformen auf SharePoint und Stream. Laut Microsoft (2025) wird PlayReady in 23% der Unternehmensmedienlösungen verwendet, verglichen mit 62% für Widevine.

Integration von DRM in eine mobile Anwendung

Die Integration von DRM in eine mobile Anwendung erfordert kein Schreiben von kryptografischem Code — der Entwickler arbeitet mit einem Player, der DRM von Haus aus unterstützt. Sehen wir uns die Integration auf Android über ExoPlayer mit der DRM-Erweiterung an.

Einrichten von ExoPlayer mit Widevine-Unterstützung

val drmSessionManager = DefaultDrmSessionManager.Builder()
    .setUuidAndExoMediaDrmProvider(
        C.WIDEVINE_UUID,
        FrameworkMediaDrm.DEFAULT_PROVIDER
    )
    .setMultiSession(true)
    .build(mediaDrmCallback)

val mediaItem = MediaItem.Builder()
    .setUri(mpdUrl)
    .setDrmConfiguration(
        MediaItem.DrmConfiguration.Builder(C.WIDEVINE_UUID)
            .setLicenseUri(licenseUrl)
            .setLicenseRequestHeaders(headers)
            .build()
    )
    .build()

exoPlayer.setMediaItem(mediaItem)
exoPlayer.prepare()

DefaultDrmSessionManager verwaltet die DRM-Sitzung: Erstellt eine MediaDrm-Sitzung, bearbeitet Lizenzanfragen und übergibt Schlüssel an den Decoder. Der Parameter setMultiSession(true) ermöglicht die gleichzeitige Entschlüsselung mehrerer Streams (Audio + Video) in verschiedenen Sitzungen. MediaDrmCallback implementiert die HTTP-Anfrage an den Lizenzserver — normalerweise ein POST mit einem SignedRequest-Textkörper.

MediaDrmCallback für Lizenzanfrage

val mediaDrmCallback = DefaultDrmSessionManager.MediaDrmCallback {
    url, requestBody ->

    val response = OkHttpClient().newCall(
        Request.Builder()
            .url(url)
            .post(RequestBody.create(requestBody, MediaType.parse("application/octet-stream")))
            .addHeader("Authorization", "Bearer ")
            .build()
    ).execute()

    val responseBytes = response.body?.bytes()
        ?: throw DrmSessionException(Exception("Empty license response"))

    responseBytes
}

Der Callback sendet eine POST-Anfrage an den Lizenzserver mit der Widevine-UUID im Textkörper. Der Server überprüft die Authentifizierung des Benutzers (Token im Header) und gibt den verschlüsselten Schlüssel zurück. Wenn der Benutzer kein aktives Abonnement hat, gibt der Server 403 Forbidden zurück — ExoPlayer generiert einen DRM-Fehler, der über onPlayerError behandelt werden muss.

Behandlung von DRM-Fehlern

DRM-Fehler treten auf, wenn eine Lizenz ungültig ist, abgelaufen ist oder das Gerät die erforderliche Schutzstufe nicht unterstützt. ExoPlayer übergibt den Fehler über Player.Listener.onPlayerError mit den Codes TYPE_DRM_LICENSE_EXPIRED, TYPE_DRM_UNSUPPORTED oder TYPE_SOURCE. Es wird empfohlen, dem Benutzer eine informative Meldung anzuzeigen: „Inhalt ist für dieses Gerät nicht verfügbar“ oder „Verlängern Sie Ihr Abonnement zum Ansehen.“

Laut Analysen von Streaming-Diensten (2025) stehen bis zu 8% der fehlgeschlagenen Wiedergabestarts im Zusammenhang mit DRM-Fehlern. Davon sind 60% abgelaufene Lizenzen, 25% Geräteinkompatibilität und 15% Netzwerkfehler bei der Schlüsselanfrage. Ein automatischer Wiederholungsversuch nach 5 Sekunden löst 40% der Netzwerkfehlerfälle.