DRM у мобільних додатках: основи, схеми захисту та принцип роботи

Що таке DRM?

DRM — це сукупність криптографічних та програмних методів, які контролюють доступ до цифрового контенту. На відміну від простого шифрування, DRM включає систему ліцензування: контент зашифрований, і для його перегляду потрібен ключ, який видається лише після перевірки прав користувача.

Основне завдання DRM — запобігти піратству та забезпечити дотримання регіональних обмежень. Без DRM власники контенту (кіностудії, звукозаписувальні лейбли) не ліцензують свій контент для стрімінгових платформ. За даними Motion Picture Association (2025), використання DRM скоротило нелегальне поширення фільмів у стрімінгу на 62% порівняно з епохою DVD-рипів.

У мобільній розробці DRM вбудовується на рівні медіаплеєра: розробник використовує ExoPlayer (Android), AVPlayer (iOS) або Shaka Player (Web), які підтримують вбудоване дешифрування зашифрованого потоку. Розробнику не потрібно реалізовувати криптографію — достатньо інтегрувати SDK для ліцензування.

DRM та CENC (Common Encryption)

Стандарт CENC (Common Encryption — ISO/IEC 23001-7) дозволяє використовувати один зашифрований медіафайл для всіх DRM-систем. Контент шифрується один раз, а ключі поширюються через різні сервери ліцензій. Це критично важливо для мультиплатформених сервісів: Netflix шифрує фільм один раз і доставляє його на Android (Widevine), iOS (FairPlay) та Windows (PlayReady) без перекодування.

CENC використовує CBC-шифрування з різними ключами для аудіо- та відеодоріжок. Кожен ключ зберігається в зашифрованому вигляді в маніфесті MPD (MPEG-DASH) або M3U8 (HLS). Ідентифікатор контенту (KID) пов'язує зашифрований потік з ліцензією на сервері — без валідної ліцензії ключ не дешифрується.

Як працює DRM у мобільних додатках

Процес DRM-відтворення складається з чотирьох етапів: завантаження маніфесту, отримання ліцензії, дешифрування контенту та відображення. Кожен етап виконується різними компонентами системи — медіаплеєром, CDM-модулем та сервером ліцензій.

• Завантаження маніфесту — плеєр отримує MPD (DASH) або M3U8 (HLS) з метаданими про зашифровані сегменти, схему шифрування та URL сервера ліцензій.
• Запит ліцензії — плеєр передає ідентифікатор контенту (KID) до Content Decryption Module (CDM), який формує запит до сервера ліцензій.
• Отримання ключа — сервер перевіряє права користувача (підписка, регіон, пристрій) і повертає ключ, зашифрований публічним ключем пристрою.
• Дешифрування потоку — CDM розшифровує ключ закритим ключем пристрою та передає його медіаплеєру для дешифрування відеосегментів у реальному часі.

Content Decryption Module (CDM)

CDM — це захищений програмний або апаратний модуль, який виконує дешифрування контенту. На Android CDM реалізовано на рівні MediaDrm API, на iOS — вбудований в AVFoundation через AVContentKeySession. CDM ніколи не розкриває ключ додатку — всі криптографічні операції виконуються всередині захищеного середовища (TEE — Trusted Execution Environment).

На пристроях з апаратною підтримкою (Secure Level 1) CDM працює всередині TEE — ключ ніколи не потрапляє в основну пам'ять пристрою. Це вимога студій для відтворення контенту в 4K HDR. На пристроях без TEE ключі дешифруються програмно (L3), що знижує захист і обмежує максимальну якість до 540p.

Основні схеми DRM

На мобільних платформах домінують три DRM-системи. Кожна ексклюзивна для своєї екосистеми, але підтримує CENC, що дозволяє використовувати єдиний зашифрований контент на всіх платформах.

Вибір DRM для мультиплатформенного сервісу

Для стрімінгового сервісу, що працює на всіх платформах, потрібна підтримка всіх трьох DRM. Практичне рішення — використовувати CDN з підтримкою мульти-DRM (Muvi, Vualto, Axinom), які автоматично маршрутизують запити ліцензій до потрібного сервера залежно від пристрою користувача. За даними Streaming Learning Center (2025), 78% стрімінгових сервісів використовують Multi-DRM підхід.

Стандарт MPEG-DASH з CENC спрощує архітектуру: контент шифрується один раз із загальним ключем, а DRM-система вибирається на клієнті. Сервер ліцензій отримує запит з ідентифікатором пристрою та повертає ключ, зашифрований під конкретний CDM. Жодної різниці в контенті для різних платформ — лише різний сервер ліцензій.

Widevine: рівні та особливості

Widevine — DRM-система Google, яка є стандартом де-факто на Android. Вона підтримує три рівні безпеки, що визначають, де і як виконується дешифрування контенту. Рівень безпеки залежить від апаратних можливостей пристрою та визначає максимальну роздільну здатність контенту.

Рівні безпеки Widevine

Widevine L1 (апаратний) — найзахищеніший рівень. Всі криптографічні операції виконуються всередині Trusted Execution Environment (TEE). Ключ ніколи не покидає захищену область. Пристрої з L1 можуть відтворювати контент до 4K HDR. Потрібна сертифікація Google — процедура, яку проходять флагманські пристрої.

Widevine L3 (програмний) — дешифрування виконується в основній пам'яті пристрою. Ключ може бути вилучений технічно підкованим зловмисником. Роздільна здатність обмежена 540p (960x540) для преміального контенту. Всі пристрої з Android підтримують L3, навіть якщо не сертифіковані для L1.

Widevine L2 — рідкісний проміжний рівень, де дешифрування виконується в TEE, але рендеринг — у незахищеному шляху. Використовується на деяких Smart TV. На мобільних пристроях практично не зустрічається.

Як визначити рівень Widevine на пристрої

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 — апаратний захист"
        "L3" -> "Widevine L3 — програмний захист"
        else -> "Widevine $securityLevel"
    }
}

Метод запитує у CDM властивість securityLevel через UUID Widevine. Повернене значення — рядок L1, L2 або L3, який вказує на поточний рівень захисту пристрою. Ця інформація критична для стрімінгових сервісів: якщо пристрій має лише L3, контент у 4K показувати не можна.

Apple FairPlay: архітектура та принцип роботи

FairPlay — DRM-система Apple, вбудована в усі платформи екосистеми: iOS, iPadOS, macOS, tvOS та watchOS. На відміну від Widevine, FairPlay не має рівнів безпеки — захист визначається пристроєм. На iOS з Secure Enclave FairPlay забезпечує рівень захисту, порівнянний з Widevine L1.

FairPlay працює виключно з протоколом HLS (HTTP Live Streaming). Контент упаковується в сегменти .ts (MPEG-TS) або фрагменти .m4s (fMP4). Маніфест M3U8 містить тег #EXT-X-KEY з URI сервера ліцензій (KSM — Key Server Module) та IV ініціалізації. При старті відтворення AVPlayer читає маніфест і через AVContentKeySession запитує ключ.

Інтеграція 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)
        )
    }
}

Делегат AVContentKeySession отримує запит на ключ з ідентифікатором контенту (assetId). Додаток відправляє цей ID на свій сервер ліцензій (KSM), який повертає зашифрований ключ. Виклик processContentKeyResponse передає ключ у CDM для дешифрування. Якщо ліцензія недійсна (прострочена, неоплачена), сервер повертає помилку 403, і AVPlayer не починає відтворення.

Persistent Key Loading для офлайн-контенту

FairPlay підтримує persistent keys — збереження ліцензії на пристрої для офлайн-перегляду. Після отримання ключа додаток викликає processContentKeyResponse з прапорцем allowsPersistableKey. Ключ зберігається в Keychain і може бути використаний без звернення до сервера при повторному перегляді. Однак термін дії офлайн-ліцензії обмежений — зазвичай 7–30 днів, після чого потрібне оновлення.

Офлайн-ліцензії зберігаються в захищеному сховищі iOS — Keychain. При спробі злому (jalibreak, вилучення дампу) Secure Enclave знищує ключі. За даними Apple (2025), технологія persistent keys використовується в Apple TV+, Netflix та Disney+ для завантаження контенту на iPad перед поїздкою.

Microsoft PlayReady для універсального захисту

PlayReady — DRM від Microsoft, що використовується на Windows, Xbox та застарілих Windows Phone. Хоча на мобільних пристроях PlayReady зустрічається рідше Widevine та FairPlay, вона важлива для універсальних стрімінгових рішень, що працюють на всіх платформах Microsoft. PlayReady підтримує як програмний, так і апаратний захист через TPM.

PlayReady використовує архітектуру SL (Security Level): SL2000 (програмний, аналог Widevine L3), SL3000 (апаратний, аналог L1). На Xbox Series X PlayReady SL3000 працює через TEE+TPM — ключі вилучаються тільки в захищеному середовищі. Це дозволяє відтворювати 4K Blu-ray на консолі без ризику копіювання.

За даними Microsoft Docs (2026), PlayReady підтримує CENC і може працювати з MPEG-DASH через Media Source Extensions (MSE) в браузерах Edge. Для мобільних додатків на Android та iOS PlayReady доступний через SDK, але використовується рідко — переважно для корпоративних додатків та медіа-сервісів Microsoft.

PlayReady Native SDK для Android

Microsoft надає PlayReady Native SDK для Android та iOS. Інтеграція виконується через ExoPlayer з розширенням PlayReady: розробник додає PlayReadyRenderer, який вбудовується в ланцюжок декодування. ExoPlayer автоматично перемикається між Widevine та PlayReady залежно від того, яка DRM вказана в маніфесті MPD.

Хоча PlayReady рідко зустрічається в мобільних додатках, її підтримка обов'язкова для сервісів, що входять до Microsoft ecosystem — наприклад, корпоративні навчальні платформи на SharePoint та Stream. За даними Microsoft (2025), PlayReady використовується в 23% корпоративних медіа-рішень проти 62% Widevine.

Інтеграція DRM у мобільний додаток

Інтеграція DRM у мобільний додаток не вимагає написання криптографічного коду — розробник працює з плеєром, який підтримує DRM з коробки. Розглянемо інтеграцію на Android через ExoPlayer з розширенням DRM.

Налаштування ExoPlayer з підтримкою 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 керує сесією DRM: створює MediaDrm-сесію, обробляє запити ліцензій та передає ключі декодеру. Параметр setMultiSession(true) дозволяє одночасно дешифрувати кілька потоків (аудіо + відео) в різних сесіях. MediaDrmCallback реалізує HTTP-запит до сервера ліцензій — зазвичай POST з тілом у форматі SignedRequest.

MediaDrmCallback для запиту ліцензії

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 відправляє POST-запит на сервер ліцензій з UUID Widevine в тілі. Сервер перевіряє аутентифікацію користувача (токен в заголовку) та повертає зашифрований ключ. Якщо користувач не має активної підписки, сервер повертає 403 Forbidden — ExoPlayer генерує помилку DRM, яку потрібно обробити через onPlayerError.

Обробка DRM-помилок

DRM-помилки виникають, коли ліцензія недійсна, закінчився термін дії або пристрій не підтримує необхідний рівень захисту. ExoPlayer передає помилку через Player.Listener.onPlayerError з кодом TYPE_DRM_LICENSE_EXPIRED, TYPE_DRM_UNSUPPORTED або TYPE_SOURCE. Рекомендується показувати користувачеві інформативне повідомлення: «Контент недоступний для цього пристрою» або «Продовжіть підписку для перегляду».

За даними аналітики стрімінгових сервісів (2025), до 8% невдалих стартів відтворення пов'язані з DRM-помилками. З них 60% — прострочені ліцензії, 25% — несумісність пристрою та 15% — мережеві помилки при запиті ключа. Автоматична повторна спроба через 5 секунд вирішує 40% випадків мережевих помилок.