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 — например корпоративните платформи за обучение на 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% от случаите на мрежови грешки.