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 использует CBС-шифрование с разными ключами для аудио- и видеодорожек. Каждый ключ хранится в зашифрованном виде в манифесте 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. Practical решение — использовать 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, но рендеринг — в unprotected пути. Используется на некоторых 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% случаев сетевых ошибок.