DRM in Mobile Apps: Fundamentals, Protection Schemes, and How It Works

What is DRM?

DRM is a set of cryptographic and software methods that control access to digital content. Unlike simple encryption, DRM includes a licensing system: content is encrypted, and viewing it requires a key that is issued only after verifying the user's rights.

The main purpose of DRM is to prevent piracy and enforce regional restrictions. Without DRM, content owners (film studios, record labels) do not license their content for streaming platforms. According to the Motion Picture Association (2025), DRM reduced illegal distribution of films in streaming by 62% compared to the DVD-rip era.

In mobile development, DRM is embedded at the media player level: the developer uses ExoPlayer (Android), AVPlayer (iOS), or Shaka Player (Web), which support built-in decryption of the encrypted stream. The developer does not need to implement cryptography — just integrate an SDK for licensing.

DRM and CENC (Common Encryption)

The CENC standard (Common Encryption — ISO/IEC 23001-7) allows using one encrypted media file for all DRM systems. Content is encrypted once, and keys are distributed through different license servers. This is critical for multi-platform services: Netflix encrypts a movie once and delivers it to Android (Widevine), iOS (FairPlay), and Windows (PlayReady) without re-encoding.

CENC uses CBC encryption with different keys for audio and video tracks. Each key is stored encrypted in the MPD (MPEG-DASH) or M3U8 (HLS) manifest. The content identifier (KID) links the encrypted stream to the license on the server — without a valid license, the key cannot be decrypted.

How DRM Works in Mobile Applications

The DRM playback process consists of four stages: manifest loading, license acquisition, content decryption, and rendering. Each stage is performed by different system components — the media player, the CDM module, and the license server.

• Manifest loading — the player receives MPD (DASH) or M3U8 (HLS) with metadata about encrypted segments, the encryption scheme, and the license server URL.
• License request — the player passes the content identifier (KID) to the Content Decryption Module (CDM), which generates a request to the license server.
• Key acquisition — the server verifies the user's rights (subscription, region, device) and returns a key encrypted with the device's public key.
• Stream decryption — the CDM decrypts the key using the device's private key and passes it to the media player for real-time decryption of video segments.

Content Decryption Module (CDM)

CDM is a protected software or hardware module that performs content decryption. On Android, CDM is implemented at the MediaDrm API level; on iOS, it is built into AVFoundation via AVContentKeySession. The CDM never exposes the key to the application — all cryptographic operations are performed inside a secure environment (TEE — Trusted Execution Environment).

On devices with hardware support (Secure Level 1), the CDM operates inside the TEE — the key never enters the device's main memory. This is a requirement from studios for playing 4K HDR content. On devices without TEE, keys are decrypted in software (L3), which reduces security and limits maximum quality to 540p.

Major DRM Schemes

Three DRM systems dominate mobile platforms. Each is exclusive to its ecosystem, but all support CENC, allowing a single encrypted content stream to be used across all platforms.

Choosing DRM for a Multi-Platform Service

For a streaming service running on all platforms, support for all three DRM systems is required. A practical solution is to use a CDN with multi-DRM support (Muvi, Vualto, Axinom), which automatically routes license requests to the appropriate server based on the user's device. According to the Streaming Learning Center (2025), 78% of streaming services use the Multi-DRM approach.

The MPEG-DASH standard with CENC simplifies the architecture: content is encrypted once with a shared key, and the DRM system is selected on the client side. The license server receives a request with the device identifier and returns a key encrypted for the specific CDM. No difference in content for different platforms — only a different license server.

Widevine: Levels and Features

Widevine is Google's DRM system, the de facto standard on Android. It supports three security levels that determine where and how content decryption is performed. The security level depends on the device's hardware capabilities and determines the maximum content resolution.

Widevine Security Levels

Widevine L1 (hardware) — the most secure level. All cryptographic operations are performed inside the Trusted Execution Environment (TEE). The key never leaves the secure area. L1 devices can play content up to 4K HDR. Google certification is required — a process that flagship devices undergo.

Widevine L3 (software) — decryption is performed in the device's main memory. The key can be extracted by a technically skilled attacker. Resolution is limited to 540p (960x540) for premium content. All Android devices support L3, even if not certified for L1.

Widevine L2 — a rare intermediate level where decryption is performed in the TEE, but rendering takes an unprotected path. Used on some Smart TVs. Practically never found on mobile devices.

How to Determine the Widevine Level on a Device

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 protection"
        "L3" -> "Widevine L3 — software protection"
        else -> "Widevine $securityLevel"
    }
}

The method queries the CDM for the securityLevel property via the Widevine UUID. The return value is a string L1, L2, or L3, indicating the device's current protection level. This information is critical for streaming services: if a device only has L3, 4K content cannot be displayed.

Apple FairPlay: Architecture and How It Works

FairPlay is Apple's DRM system, built into all ecosystem platforms: iOS, iPadOS, macOS, tvOS, and watchOS. Unlike Widevine, FairPlay does not have security levels — protection is determined by the device. On iOS with Secure Enclave, FairPlay provides a level of protection comparable to Widevine L1.

FairPlay works exclusively with the HLS (HTTP Live Streaming) protocol. Content is packaged into .ts segments (MPEG-TS) or .m4s fragments (fMP4). The M3U8 manifest contains the #EXT-X-KEY tag with the license server URI (KSM — Key Server Module) and the initialization IV. At playback start, AVPlayer reads the manifest and requests the key via AVContentKeySession.

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

The AVContentKeySession delegate receives a key request with the content identifier (assetId). The application sends this ID to its license server (KSM), which returns the encrypted key. Calling processContentKeyResponse passes the key to the CDM for decryption. If the license is invalid (expired, unpaid), the server returns a 403 error, and AVPlayer does not start playback.

Persistent Key Loading for Offline Content

FairPlay supports persistent keys — saving the license on the device for offline viewing. After receiving the key, the application calls processContentKeyResponse with the allowsPersistableKey flag. The key is stored in the Keychain and can be used without contacting the server on subsequent plays. However, the offline license has a limited validity period — typically 7–30 days, after which renewal is required.

Offline licenses are stored in iOS's protected storage — the Keychain. If a jailbreak or dump extraction is attempted, the Secure Enclave destroys the keys. According to Apple (2025), persistent key technology is used in Apple TV+, Netflix, and Disney+ for downloading content to an iPad before a trip.

Microsoft PlayReady for Universal Protection

PlayReady is Microsoft's DRM, used on Windows, Xbox, and legacy Windows Phone. Although PlayReady is less common on mobile devices than Widevine and FairPlay, it is important for universal streaming solutions that work across all Microsoft platforms. PlayReady supports both software and hardware protection via TPM.

PlayReady uses the SL (Security Level) architecture: SL2000 (software, similar to Widevine L3), SL3000 (hardware, similar to L1). On Xbox Series X, PlayReady SL3000 works through TEE+TPM — keys are extracted only in a protected environment. This allows playing 4K Blu-ray on the console without the risk of copying.

According to Microsoft Docs (2026), PlayReady supports CENC and can work with MPEG-DASH via Media Source Extensions (MSE) in Edge browsers. For mobile applications on Android and iOS, PlayReady is available via SDK but is rarely used — primarily for enterprise applications and Microsoft media services.

PlayReady Native SDK for Android

Microsoft provides the PlayReady Native SDK for Android and iOS. Integration is done via ExoPlayer with the PlayReady extension: the developer adds PlayReadyRenderer, which is embedded into the decoding chain. ExoPlayer automatically switches between Widevine and PlayReady depending on which DRM is specified in the MPD manifest.

Although PlayReady is rarely used in mobile applications, its support is mandatory for services within the Microsoft ecosystem — for example, enterprise training platforms on SharePoint and Stream. According to Microsoft (2025), PlayReady is used in 23% of enterprise media solutions compared to 62% for Widevine.

Integrating DRM into a Mobile Application

Integrating DRM into a mobile application does not require writing cryptographic code — the developer works with a player that supports DRM out of the box. Let's look at integration on Android via ExoPlayer with the DRM extension.

Setting Up ExoPlayer with Widevine Support

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 manages the DRM session: creates a MediaDrm session, handles license requests, and passes keys to the decoder. The setMultiSession(true) parameter allows decrypting multiple streams (audio + video) simultaneously in different sessions. MediaDrmCallback implements the HTTP request to the license server — typically a POST with a SignedRequest body.

MediaDrmCallback for License Request

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
}

The callback sends a POST request to the license server with the Widevine UUID in the body. The server verifies the user's authentication (token in the header) and returns the encrypted key. If the user does not have an active subscription, the server returns 403 Forbidden — ExoPlayer generates a DRM error, which must be handled via onPlayerError.

Handling DRM Errors

DRM errors occur when a license is invalid, expired, or the device does not support the required protection level. ExoPlayer passes the error via Player.Listener.onPlayerError with codes TYPE_DRM_LICENSE_EXPIRED, TYPE_DRM_UNSUPPORTED, or TYPE_SOURCE. It is recommended to show the user an informative message: “Content is not available for this device” or “Renew your subscription to view.”

According to streaming service analytics (2025), up to 8% of failed playback starts are related to DRM errors. Of these, 60% are expired licenses, 25% are device incompatibility, and 15% are network errors during key requests. Automatic retry after 5 seconds resolves 40% of network error cases.