Digital Rights Management (DRM) controls access and usage of digital content. DRM systems encrypt content and enforce licensing rules by requiring authentication before decryption. These technologies block unauthorized copying, sharing, and modification while allowing secure distribution.
DRM works on encryption, key management, and license control. Content is encrypted, and authorized users get the key to unlock and play it. A license server sends this key, and the DRM software on the user’s device enforces how the content can be used.
Core DRM Components
Encryption and Key Management
DRM-protected content uses AES encryption for media files. The encryption process generates a content key, which the system encrypts using a public key from the license server. The encrypted content key is embedded into the media container or manifest.
AESKey contentKey = generateAESKey();
byte[] encryptedMedia = AES.encrypt(mediaData, contentKey);
byte[] encryptedContentKey = RSA.encrypt(contentKey, publicKey);
manifest.addKey(encryptedContentKey);
Explanation:
- AESKey contentKey: Symmetric key for encrypting the media.
- byte[] encryptedMedia: Output ciphertext after AES encryption.
- RSA.encrypt: Asymmetric encryption for securing the content key.
- manifest.addKey: Embeds the encrypted key for client retrieval.
License Acquisition and Rights Enforcement
When a client requests playback, the DRM system contacts a license server to obtain the decryption key. The server validates the client’s rights before issuing a license. The license contains the decryption key and usage rules.
DRM Technologies
The three DRM systems are Widevine (Google), PlayReady (Microsoft), and FairPlay (Apple). Each integrates with streaming protocols and supports different encryption standards.
| DRM Technology | Owner | Key Encryption | Common Use Cases |
| Widevine | AES-128/CENC | Android, Chrome, DASH | |
| PlayReady | Microsoft | AES-128/CBCS | Windows, Xbox, Silverlight |
| FairPlay | Apple | AES-128 | iOS, macOS, HLS |
All three support Common Encryption (CENC), which allows multi-DRM workflows where a single encrypted stream works across platforms.
DRM in Video Protection for Mobile
Mobile platforms impose unique challenges for DRM, including fragmented device support and performance constraints. Widevine (Android) and FairPlay (iOS) dominate mobile video protection.
Widevine on Android
Widevine is a DRM technology that protects video content. It has 3 security levels: L1 (uses hardware for the highest security), L2 (uses both hardware and software), and L3 (software-only, less secure). L1 is the most secure as it stores keys in a protected area called the Trusted Execution Environment (TEE).
To use Widevine, apps configure MediaDrm to request decryption keys from a license server. Then, these keys are handled securely through MediaDrm’s CryptoSession to play the protected content.
MediaDrm drm = new MediaDrm(WIDEVINE_UUID);
byte[] keyRequest = drm.getKeyRequest(sessionId, keyData, mimeType, KEY_TYPE_STREAMING, optionalParams);
byte[] licenseResponse = fetchLicense(keyRequest);
drm.provideKeyResponse(sessionId, licenseResponse);
Explanation:
- WIDEVINE_UUID: Unique identifier for Widevine DRM.
- keyData: Contains the encrypted content key from the manifest.
- KEY_TYPE_STREAMING: Indicates a streaming license.
- fetchLicense: Custom network call to the license server.
FairPlay on iOS
FairPlay Streaming (FPS) secures HLS content on Apple devices. It requires a certificate from Apple and uses a proprietary key derivation process. The key steps in FairPlay integration include:
Step 1: Load the FairPlay certificate.
Step 2: Extract the Content Key Context (CKC) from the license response.
NSData *certificate = [AVAssetResourceLoadingRequest streamingContentKeyRequestDataForApp:certData contentIdentifier:contentID options:nil error:&error];
NSData *ckc = [keyServer requestLicenseForSPC:spc];
[loadingRequest finishLoadingWithResponse:licenseResponse data:ckc];
Explanation:
- certData: Apple-issued FairPlay certificate.
- contentID: Unique identifier for the protected content.
- SPC: Server Playback Context, a token sent to the license server.
Mobile Playback Workflows
On mobile devices, DRM-protected content playback involves a coordinated sequence of steps between the app, device OS, DRM license server, and Content Delivery Network (CDN). The Mobile Playback Workflows follow these stages:
Encrypted Media Detection via HLS or DASH Manifests
When a user initiates playback, the media player retrieves the streaming manifest—HLS (.m3u8) on iOS or MPEG-DASH (.mpd) on Android. These manifests include metadata indicating that the media segments are encrypted and specify the DRM system to be used. The player parses this manifest and obtains a license before playback can begin.
DRM System Triggers a License Request
Based on the DRM scheme declared in the manifest, the player invokes Widevine through the MediaDrm API on Android. The player uses Apple’s FairPlay via AVFoundation or AVPlayer on iOS.
License Acquisition, Validation, and Content Decryption
Upon successful authentication, the license server issues a license containing decryption keys and playback rights (e.g., whether the user can download and how long the license is valid). The app or media player validates the license and content and decrypts the media segments in real-time.
Secure Rendering via Hardware-Backed Pipelines
Once decrypted, you must render the content to prevent piracy or screen capture:
- On Android, this is handled through MediaCodec in conjunction with Widevine Level 1, where both decryption and rendering occur inside a Trusted Execution Environment.
- On iOS, AVFoundation and FairPlay Streaming ensure secure rendering using hardware-level protection and Secure Video Path.
Hardware-backed decryption ensures keys are never exposed to app memory, mitigating runtime attacks.
