DRM dans les applications mobiles : principes fondamentaux, schémas de protection et principe de fonctionnement

Qu'est-ce que le DRM ?

DRM est un ensemble de méthodes cryptographiques et logicielles qui contrôlent l'accès au contenu numérique. Contrairement au chiffrement simple, le DRM inclut un système de licence : le contenu est chiffré et sa visualisation nécessite une clé qui n'est délivrée qu'après vérification des droits de l'utilisateur.

L'objectif principal du DRM est de prévenir le piratage et d'assurer le respect des restrictions régionales. Sans DRM, les propriétaires de contenu (studios de cinéma, maisons de disques) ne concèdent pas leur contenu sous licence pour les plateformes de streaming. Selon la Motion Picture Association (2025), l'utilisation du DRM a réduit la distribution illégale de films en streaming de 62 % par rapport à l'ère des DVD-rips.

Dans le développement mobile, le DRM est intégré au niveau du lecteur multimédia : le développeur utilise ExoPlayer (Android), AVPlayer (iOS) ou Shaka Player (Web), qui prennent en charge le déchiffrement intégré du flux chiffré. Le développeur n'a pas besoin d'implémenter la cryptographie — il lui suffit d'intégrer un SDK pour la gestion des licences.

DRM et CENC (Common Encryption)

La norme CENC (Common Encryption — ISO/IEC 23001-7) permet d'utiliser un seul fichier multimédia chiffré pour tous les systèmes DRM. Le contenu est chiffré une fois et les clés sont distribuées via différents serveurs de licences. C'est essentiel pour les services multiplateformes : Netflix chiffre un film une fois et le livre sur Android (Widevine), iOS (FairPlay) et Windows (PlayReady) sans recodage.

CENC utilise le chiffrement CBC avec des clés différentes pour les pistes audio et vidéo. Chaque clé est stockée chiffrée dans le manifeste MPD (MPEG-DASH) ou M3U8 (HLS). L'identifiant de contenu (KID) relie le flux chiffré à la licence sur le serveur — sans licence valide, la clé ne peut pas être déchiffrée.

Comment le DRM fonctionne dans les applications mobiles

Le processus de lecture DRM comprend quatre étapes : chargement du manifeste, obtention de la licence, déchiffrement du contenu et affichage. Chaque étape est exécutée par différents composants du système — le lecteur multimédia, le module CDM et le serveur de licences.

• Chargement du manifeste — le lecteur reçoit le MPD (DASH) ou M3U8 (HLS) avec des métadonnées sur les segments chiffrés, le schéma de chiffrement et l'URL du serveur de licences.
• Demande de licence — le lecteur transmet l'identifiant de contenu (KID) au Module de Déchiffrement de Contenu (CDM), qui génère une demande au serveur de licences.
• Obtention de la clé — le serveur vérifie les droits de l'utilisateur (abonnement, région, appareil) et renvoie une clé chiffrée avec la clé publique de l'appareil.
• Déchiffrement du flux — le CDM déchiffre la clé à l'aide de la clé privée de l'appareil et la transmet au lecteur multimédia pour le déchiffrement en temps réel des segments vidéo.

Module de Déchiffrement de Contenu (CDM)

Le CDM est un module logiciel ou matériel protégé qui effectue le déchiffrement du contenu. Sur Android, le CDM est implémenté au niveau de l'API MediaDrm ; sur iOS, il est intégré dans AVFoundation via AVContentKeySession. Le CDM n'expose jamais la clé à l'application — toutes les opérations cryptographiques sont effectuées dans un environnement sécurisé (TEE — Trusted Execution Environment).

Sur les appareils avec support matériel (Secure Level 1), le CDM fonctionne dans le TEE — la clé ne pénètre jamais dans la mémoire principale de l'appareil. C'est une exigence des studios pour la lecture de contenu 4K HDR. Sur les appareils sans TEE, les clés sont déchiffrées par logiciel (L3), ce qui réduit la sécurité et limite la qualité maximale à 540p.

Principaux schémas DRM

Trois systèmes DRM dominent les plates-formes mobiles. Chacun est exclusif à son écosystème, mais tous prennent en charge CENC, permettant d'utiliser un seul flux de contenu chiffré sur toutes les plates-formes.

Choix du DRM pour un service multiplateforme

Pour un service de streaming fonctionnant sur toutes les plates-formes, la prise en charge des trois systèmes DRM est nécessaire. Une solution pratique consiste à utiliser un CDN avec support multi-DRM (Muvi, Vualto, Axinom), qui achemine automatiquement les demandes de licence vers le serveur approprié en fonction de l'appareil de l'utilisateur. Selon le Streaming Learning Center (2025), 78 % des services de streaming utilisent l'approche Multi-DRM.

La norme MPEG-DASH avec CENC simplifie l'architecture : le contenu est chiffré une fois avec une clé partagée et le système DRM est sélectionné côté client. Le serveur de licences reçoit une demande avec l'identifiant de l'appareil et renvoie une clé chiffrée pour le CDM spécifique. Aucune différence de contenu pour les différentes plates-formes — seulement un serveur de licences différent.

Widevine : niveaux et caractéristiques

Widevine est le système DRM de Google, la norme de facto sur Android. Il prend en charge trois niveaux de sécurité qui déterminent où et comment le déchiffrement du contenu est effectué. Le niveau de sécurité dépend des capacités matérielles de l'appareil et détermine la résolution maximale du contenu.

Niveaux de sécurité Widevine

Widevine L1 (matériel) — le niveau le plus sécurisé. Toutes les opérations cryptographiques sont effectuées dans le Trusted Execution Environment (TEE). La clé ne quitte jamais la zone sécurisée. Les appareils L1 peuvent lire du contenu jusqu'en 4K HDR. Une certification Google est requise — un processus que subissent les appareils phares.

Widevine L3 (logiciel) — le déchiffrement est effectué dans la mémoire principale de l'appareil. Un attaquant techniquement compétent peut extraire la clé. La résolution est limitée à 540p (960x540) pour le contenu premium. Tous les appareils Android prennent en charge L3, même s'ils ne sont pas certifiés pour L1.

Widevine L2 — un niveau intermédiaire rare où le déchiffrement est effectué dans le TEE, mais le rendement emprunte un chemin non protégé. Utilisé sur certains téléviseurs intelligents. Pratiquement jamais trouvé sur les appareils mobiles.

Comment déterminer le niveau Widevine sur un appareil

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 — protection matérielle"
        "L3" -> "Widevine L3 — protection logicielle"
        else -> "Widevine $securityLevel"
    }
}

La méthode interroge le CDM pour la propriété securityLevel via l'UUID Widevine. La valeur renvoyée est une chaîne L1, L2 ou L3, indiquant le niveau de protection actuel de l'appareil. Cette information est cruciale pour les services de streaming : si un appareil n'a que L3, le contenu 4K ne peut pas être affiché.

Apple FairPlay : architecture et principe de fonctionnement

FairPlay est le système DRM d'Apple, intégré dans toutes les plates-formes de l'écosystème : iOS, iPadOS, macOS, tvOS et watchOS. Contrairement à Widevine, FairPlay n'a pas de niveaux de sécurité — la protection est déterminée par l'appareil. Sur iOS avec Secure Enclave, FairPlay offre un niveau de protection comparable à Widevine L1.

FairPlay fonctionne exclusivement avec le protocole HLS (HTTP Live Streaming). Le contenu est conditionné en segments .ts (MPEG-TS) ou fragments .m4s (fMP4). Le manifeste M3U8 contient la balise #EXT-X-KEY avec l'URI du serveur de licences (KSM — Key Server Module) et le IV d'initialisation. Au début de la lecture, AVPlayer lit le manifeste et demande la clé via AVContentKeySession.

Intégration de 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)
        )
    }
}

Le délégué AVContentKeySession reçoit une demande de clé avec l'identifiant de contenu (assetId). L'application envoie cet ID à son serveur de licences (KSM), qui renvoie la clé chiffrée. L'appel de processContentKeyResponse transmet la clé au CDM pour déchiffrement. Si la licence est invalide (expirée, non payée), le serveur renvoie une erreur 403 et AVPlayer ne démarre pas la lecture.

Chargement de clés persistantes pour le contenu hors ligne

FairPlay prend en charge les clés persistantes — la sauvegarde de la licence sur l'appareil pour une visualisation hors ligne. Après réception de la clé, l'application appelle processContentKeyResponse avec l'indicateur allowsPersistableKey. La clé est stockée dans le Keychain et peut être utilisée sans contacter le serveur lors des lectures ultérieures. Cependant, la licence hors ligne a une durée de validité limitée — généralement 7 à 30 jours, après quoi un renouvellement est nécessaire.

Les licences hors ligne sont stockées dans le stockage protégé d'iOS — le Keychain. En cas de tentative de jailbreak ou d'extraction de dump, la Secure Enclave détruit les clés. Selon Apple (2025), la technologie des clés persistantes est utilisée dans Apple TV+, Netflix et Disney+ pour télécharger du contenu sur un iPad avant un voyage.

Microsoft PlayReady pour une protection universelle

PlayReady est le DRM de Microsoft, utilisé sur Windows, Xbox et Windows Phone hérité. Bien que PlayReady soit moins courant sur les appareils mobiles que Widevine et FairPlay, il est important pour les solutions de streaming universelles qui fonctionnent sur toutes les plates-formes Microsoft. PlayReady prend en charge à la fois la protection logicielle et matérielle via TPM.

PlayReady utilise l'architecture SL (Security Level) : SL2000 (logiciel, similaire à Widevine L3), SL3000 (matériel, similaire à L1). Sur Xbox Series X, PlayReady SL3000 fonctionne via TEE+TPM — les clés sont extraites uniquement dans un environnement protégé. Cela permet de lire des Blu-ray 4K sur la console sans risque de copie.

Selon Microsoft Docs (2026), PlayReady prend en charge CENC et peut fonctionner avec MPEG-DASH via Media Source Extensions (MSE) dans les navigateurs Edge. Pour les applications mobiles sur Android et iOS, PlayReady est disponible via SDK mais est rarement utilisé — principalement pour les applications d'entreprise et les services multimédia Microsoft.

PlayReady Native SDK pour Android

Microsoft fournit le PlayReady Native SDK pour Android et iOS. L'intégration se fait via ExoPlayer avec l'extension PlayReady : le développeur ajoute PlayReadyRenderer, qui est intégré dans la chaîne de décodage. ExoPlayer bascule automatiquement entre Widevine et PlayReady en fonction du DRM spécifié dans le manifeste MPD.

Bien que PlayReady soit rarement utilisé dans les applications mobiles, son support est obligatoire pour les services de l'écosystème Microsoft — par exemple, les plateformes de formation d'entreprise sur SharePoint et Stream. Selon Microsoft (2025), PlayReady est utilisé dans 23 % des solutions médias d'entreprise contre 62 % pour Widevine.

Intégration du DRM dans une application mobile

L'intégration du DRM dans une application mobile ne nécessite pas d'écrire de code cryptographique — le développeur travaille avec un lecteur qui prend en charge le DRM nativement. Voyons l'intégration sur Android via ExoPlayer avec l'extension DRM.

Configuration d'ExoPlayer avec support 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 gère la session DRM : crée une session MediaDrm, traite les demandes de licence et transmet les clés au décodeur. Le paramètre setMultiSession(true) permet de déchiffrer plusieurs flux (audio + vidéo) simultanément dans différentes sessions. MediaDrmCallback implémente la requête HTTP au serveur de licences — généralement un POST avec un corps SignedRequest.

MediaDrmCallback pour demande de licence

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
}

Le callback envoie une requête POST au serveur de licences avec l'UUID Widevine dans le corps. Le serveur vérifie l'authentification de l'utilisateur (jeton dans l'en-tête) et renvoie la clé chiffrée. Si l'utilisateur n'a pas d'abonnement actif, le serveur renvoie 403 Forbidden — ExoPlayer génère une erreur DRM, qui doit être traitée via onPlayerError.

Gestion des erreurs DRM

Les erreurs DRM se produisent lorsqu'une licence est invalide, expirée ou que l'appareil ne prend pas en charge le niveau de protection requis. ExoPlayer transmet l'erreur via Player.Listener.onPlayerError avec les codes TYPE_DRM_LICENSE_EXPIRED, TYPE_DRM_UNSUPPORTED ou TYPE_SOURCE. Il est recommandé d'afficher un message informatif à l'utilisateur : « Le contenu n'est pas disponible pour cet appareil » ou « Renouvelez votre abonnement pour visionner. »

Selon les analyses des services de streaming (2025), jusqu'à 8 % des échecs de démarrage de lecture sont liés à des erreurs DRM. Parmi ceux-ci, 60 % sont des licences expirées, 25 % une incompatibilité de l'appareil et 15 % des erreurs réseau lors de la demande de clé. Une nouvelle tentative automatique après 5 secondes résout 40 % des cas d'erreurs réseau.