DRM w aplikacjach mobilnych: podstawy, schematy ochrony i zasada działania

Co to jest DRM?

DRM — to zbiór metod kryptograficznych i programowych, które kontrolują dostęp do treści cyfrowych. W przeciwieństwie do prostego szyfrowania, DRM obejmuje system licencjonowania: treść jest zaszyfrowana, a do jej wyświetlenia wymagany jest klucz, który jest wydawany dopiero po sprawdzeniu praw użytkownika.

Głównym zadaniem DRM jest zapobieganie piractwu i zapewnienie przestrzegania ograniczeń regionalnych. Bez DRM właściciele treści (studia filmowe, wytwórnie płytowe) nie licencjonują swoich treści dla platform streamingowych. Według Motion Picture Association (2025), użycie DRM zmniejszyło nielegalne rozpowszechnianie filmów w streamingu o 62% w porównaniu z erą ripów DVD.

W programowaniu mobilnym DRM jest wbudowany na poziomie odtwarzacza multimedialnego: programista używa ExoPlayer (Android), AVPlayer (iOS) lub Shaka Player (Web), które obsługują wbudowane deszyfrowanie zaszyfrowanego strumienia. Programista nie musi implementować kryptografii — wystarczy zintegrować SDK do licencjonowania.

DRM i CENC (Common Encryption)

Standard CENC (Common Encryption — ISO/IEC 23001-7) pozwala na użycie jednego zaszyfrowanego pliku multimedialnego dla wszystkich systemów DRM. Treść jest szyfrowana raz, a klucze są rozpowszechniane przez różne serwery licencji. Jest to krytycznie ważne dla serwisów wieloplatformowych: Netflix szyfruje film raz i dostarcza go na Android (Widevine), iOS (FairPlay) i Windows (PlayReady) bez przekodowywania.

CENC używa szyfrowania CBC z różnymi kluczami dla ścieżek audio i wideo. Każdy klucz jest przechowywany w zaszyfrowanej formie w manifeście MPD (MPEG-DASH) lub M3U8 (HLS). Identyfikator treści (KID) łączy zaszyfrowany strumień z licencją na serwerze — bez ważnej licencji klucz nie jest odszyfrowywany.

Jak działa DRM w aplikacjach mobilnych

Proces odtwarzania DRM składa się z czterech etapów: pobranie manifestu, uzyskanie licencji, deszyfrowanie treści i wyświetlanie. Każdy etap jest wykonywany przez różne komponenty systemu — odtwarzacz multimedialny, moduł CDM i serwer licencji.

• Pobranie manifestu — odtwarzacz otrzymuje MPD (DASH) lub M3U8 (HLS) z metadanymi o zaszyfrowanych segmentach, schemacie szyfrowania i URL serwera licencji.
• Żadanie licencji — odtwarzacz przekazuje identyfikator treści (KID) do modułu Content Decryption Module (CDM), który tworzy żądanie do serwera licencji.
• Otrzymanie klucza — serwer sprawdza prawa użytkownika (subskrypcja, region, urządzenie) i zwraca klucz zaszyfrowany kluczem publicznym urządzenia.
• Deszyfrowanie strumienia — CDM odszyfrowuje klucz kluczem prywatnym urządzenia i przekazuje go odtwarzaczowi do deszyfrowania segmentów wideo w czasie rzeczywistym.

Content Decryption Module (CDM)

CDM — to zabezpieczony programowy lub sprzętowy moduł, który wykonuje deszyfrowanie treści. Na Android CDM jest zaimplementowany na poziomie API MediaDrm, na iOS — wbudowany w AVFoundation przez AVContentKeySession. CDM nigdy nie ujawnia klucza aplikacji — wszystkie operacje kryptograficzne są wykonywane wewnątrz zabezpieczonego środowiska (TEE — Trusted Execution Environment).

Na urządzeniach ze wsparciem sprzętowym (Secure Level 1) CDM działa wewnątrz TEE — klucz nigdy nie trafia do głównej pamięci urządzenia. Jest to wymóg studiów do odtwarzania treści w 4K HDR. Na urządzeniach bez TEE klucze są odszyfrowywane programowo (L3), co obniża ochronę i ogranicza maksymalną jakość do 540p.

Główne schematy DRM

Na platformach mobilnych dominują trzy systemy DRM. Każdy jest ekskluzywny dla swojego ekosystemu, ale obsługuje CENC, co pozwala na używanie jednej zaszyfrowanej treści na wszystkich platformach.

Wybór DRM dla serwisu wieloplatformowego

Dla serwisu streamingowego działającego na wszystkich platformach wymagane jest wsparcie wszystkich trzech DRM. Praktycznym rozwiązaniem jest użycie CDN z obsługą multi-DRM (Muvi, Vualto, Axinom), które automatycznie kierują żądania licencji do odpowiedniego serwera w zależności od urządzenia użytkownika. Według Streaming Learning Center (2025), 78% serwisów streamingowych używa podejścia Multi-DRM.

Standard MPEG-DASH z CENC upraszcza architekturę: treść jest szyfrowana raz z wspólnym kluczem, a system DRM jest wybierany na kliencie. Serwer licencji otrzymuje żądanie z identyfikatorem urządzenia i zwraca klucz zaszyfrowany pod konkretny CDM. Żadnej różnicy w treści dla różnych platform — tylko inny serwer licencji.

Widevine: poziomy i cechy

Widevine — system DRM Google, który jest standardem de facto na Android. Obsługuje trzy poziomy bezpieczeństwa, określające gdzie i jak wykonywane jest deszyfrowanie treści. Poziom bezpieczeństwa zależy od możliwości sprzętowych urządzenia i określa maksymalną rozdzielczość treści.

Poziomy bezpieczeństwa Widevine

Widevine L1 (sprzętowy) — najwyższy poziom ochrony. Wszystkie operacje kryptograficzne są wykonywane wewnątrz Trusted Execution Environment (TEE). Klucz nigdy nie opuszcza zabezpieczonego obszaru. Urządzenia z L1 mogą odtwarzać treść do 4K HDR. Wymagana jest certyfikacja Google — procedura, którą przechodzą flagowe urządzenia.

Widevine L3 (programowy) — deszyfrowanie odbywa się w głównej pamięci urządzenia. Klucz może zostać wydobyty przez technicznie zaawansowanego atakującego. Rozdzielczość ograniczona do 540p (960x540) dla treści premium. Wszystkie urządzenia z Android obsługują L3, nawet jeśli nie są certyfikowane dla L1.

Widevine L2 — rzadki poziom pośredni, gdzie deszyfrowanie odbywa się w TEE, ale renderowanie — niechronioną ścieżką. Używany na niektórych Smart TV. Na urządzeniach mobilnych praktycznie nie występuje.

Jak określić poziom Widevine na urządzeniu

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 — ochrona sprzętowa"
        "L3" -> "Widevine L3 — ochrona programowa"
        else -> "Widevine $securityLevel"
    }
}

Metoda pobiera od CDM właściwość securityLevel przez UUID Widevine. Zwracana wartość — ciąg L1, L2 lub L3, który wskazuje aktualny poziom ochrony urządzenia. Ta informacja jest krytyczna dla serwisów streamingowych: jeśli urządzenie ma tylko L3, treści w 4K nie można wyświetlać.

Apple FairPlay: architektura i zasada działania

FairPlay — system DRM Apple, wbudowany we wszystkie platformy ekosystemu: iOS, iPadOS, macOS, tvOS i watchOS. W przeciwieństwie do Widevine, FairPlay nie ma poziomów bezpieczeństwa — ochrona jest określana przez urządzenie. Na iOS z Secure Enclave FairPlay zapewnia poziom ochrony porównywalny z Widevine L1.

FairPlay działa wyłącznie z protokołem HLS (HTTP Live Streaming). Treść jest pakowana w segmenty .ts (MPEG-TS) lub fragmenty .m4s (fMP4). Manifest M3U8 zawiera tag #EXT-X-KEY z URI serwera licencji (KSM — Key Server Module) i IV inicjalizacji. Przy starcie odtwarzania AVPlayer czyta manifest i przez AVContentKeySession żąda klucza.

Integracja FairPlay Streaming

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)
        )
    }
}

Delegat AVContentKeySession otrzymuje żądanie klucza z identyfikatorem treści (assetId). Aplikacja wysyła ten ID na swój serwer licencji (KSM), który zwraca zaszyfrowany klucz. Wywołanie processContentKeyResponse przekazuje klucz do CDM w celu deszyfrowania. Jeśli licencja jest nieprawidłowa (wygasła, nieopłacona), serwer zwraca błąd 403, a AVPlayer nie rozpoczyna odtwarzania.

Persistent Key Loading dla treści offline

FairPlay obsługuje persistent keys — zapisywanie licencji na urządzeniu do przeglądania offline. Po otrzymaniu klucza aplikacja wywołuje processContentKeyResponse z flagą allowsPersistableKey. Klucz jest zapisywany w Keychain i może być użyty bez odwoływania się do serwera przy ponownym odtwarzaniu. Jednak okres ważności licencji offline jest ograniczony — zwykle 7–30 dni, po czym wymagane jest odnowienie.

Licencje offline są przechowywane w zabezpieczonym magazynie iOS — Keychain. Przy próbie włamania (jalibreak, wyodrębnienie zrzutu pamięci) Secure Enclave niszczy klucze. Według Apple (2025), technologia persistent keys jest używana w Apple TV+, Netflix i Disney+ do pobierania treści na iPad przed podróżą.

Microsoft PlayReady do uniwersalnej ochrony

PlayReady — DRM od Microsoft, używany na Windows, Xbox i przestarzałych Windows Phone. Chociaż na urządzeniach mobilnych PlayReady występuje rzadziej niż Widevine i FairPlay, jest ważny dla uniwersalnych rozwiązań streamingowych działających na wszystkich platformach Microsoft. PlayReady obsługuje zarówno ochronę programową, jak i sprzętową przez TPM.

PlayReady używa architektury SL (Security Level): SL2000 (programowa, odpowiednik Widevine L3), SL3000 (sprzętowa, odpowiednik L1). Na Xbox Series X PlayReady SL3000 działa przez TEE+TPM — klucze są wyodrębniane tylko w zabezpieczonym środowisku. Pozwala to odtwarzać 4K Blu-ray na konsoli bez ryzyka kopiowania.

Według Microsoft Docs (2026), PlayReady obsługuje CENC i może pracować z MPEG-DASH przez Media Source Extensions (MSE) w przeglądarkach Edge. Dla aplikacji mobilnych na Android i iOS PlayReady jest dostępny przez SDK, ale używany rzadko — głównie dla aplikacji korporacyjnych i serwisów multimedialnych Microsoft.

PlayReady Native SDK dla Androida

Microsoft udostępnia PlayReady Native SDK dla Android i iOS. Integracja odbywa się przez ExoPlayer z rozszerzeniem PlayReady: programista dodaje PlayReadyRenderer, który jest wbudowywany w łańcuch dekodowania. ExoPlayer automatycznie przełącza się między Widevine i PlayReady w zależności od tego, które DRM jest wskazane w manifeście MPD.

Chociaż PlayReady rzadko występuje w aplikacjach mobilnych, jego obsługa jest obowiązkowa dla serwisów wchodzących w skład ekosystemu Microsoft — na przykład korporacyjnych platform edukacyjnych na SharePoint i Stream. Według Microsoft (2025), PlayReady jest używany w 23% korporacyjnych rozwiązań multimedialnych wobec 62% Widevine.

Integracja DRM w aplikacji mobilnej

Integracja DRM w aplikacji mobilnej nie wymaga pisania kodu kryptograficznego — programista pracuje z odtwarzaczem, który obsługuje DRM od razu. Rozważmy integrację na Android przez ExoPlayer z rozszerzeniem DRM.

Konfiguracja ExoPlayer z obsługą Widevine

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 zarządza sesją DRM: tworzy sesję MediaDrm, przetwarza żądania licencji i przekazuje klucze dekoderowi. Parametr setMultiSession(true) pozwala jednocześnie deszyfrować wiele strumieni (audio + wideo) w różnych sesjach. MediaDrmCallback implementuje żądanie HTTP do serwera licencji — zazwyczaj POST z ciałem żądania w formacie SignedRequest.

MediaDrmCallback do żądania licencji

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
}

Callback wysyła żądanie POST na serwer licencji z UUID Widevine w ciele. Serwer sprawdza uwierzytelnienie użytkownika (token w nagłówku) i zwraca zaszyfrowany klucz. Jeśli użytkownik nie ma aktywnej subskrypcji, serwer zwraca 403 Forbidden — ExoPlayer generuje błąd DRM, który należy obsłużyć przez onPlayerError.

Obsługa błędów DRM

Błędy DRM występują, gdy licencja jest nieprawidłowa, wygasła lub urządzenie nie obsługuje wymaganego poziomu ochrony. ExoPlayer przekazuje błąd przez Player.Listener.onPlayerError z kodem TYPE_DRM_LICENSE_EXPIRED, TYPE_DRM_UNSUPPORTED lub TYPE_SOURCE. Zaleca się wyświetlanie użytkownikowi informacyjnego komunikatu: „Treść niedostępna dla tego urządzenia” lub „Przedłuż subskrypcję, aby oglądać”.

Według analityki serwisów streamingowych (2025), do 8% nieudanych uruchomień odtwarzania jest związanych z błędami DRM. Z nich 60% — wygasłe licencje, 25% — niekompatybilność urządzenia i 15% — błędy sieciowe przy żądaniu klucza. Automatyczna ponowna próba po 5 sekundach rozwiązuje 40% przypadków błędów sieciowych.