DRM nelle app mobili: fondamenti, schemi di protezione e principio di funzionamento

Cos'è il DRM?

DRM è un insieme di metodi crittografici e software che controllano l'accesso ai contenuti digitali. A differenza della semplice crittografia, il DRM include un sistema di licenze: il contenuto è crittografato e per visualizzarlo è necessaria una chiave che viene rilasciata solo dopo la verifica dei diritti dell'utente.

L'obiettivo principale del DRM è prevenire la pirateria e garantire il rispetto delle restrizioni regionali. Senza DRM, i proprietari di contenuti (studi cinematografici, etichette discografiche) non concedono in licenza i propri contenuti per le piattaforme di streaming. Secondo la Motion Picture Association (2025), l'uso del DRM ha ridotto la distribuzione illegale di film in streaming del 62% rispetto all'era dei DVD-rip.

Nello sviluppo mobile, il DRM è integrato a livello di lettore multimediale: lo sviluppatore utilizza ExoPlayer (Android), AVPlayer (iOS) o Shaka Player (Web), che supportano la decodifica integrata del flusso crittografato. Lo sviluppatore non deve implementare la crittografia — basta integrare un SDK per la gestione delle licenze.

DRM e CENC (Common Encryption)

Lo standard CENC (Common Encryption — ISO/IEC 23001-7) consente di utilizzare un unico file multimediale crittografato per tutti i sistemi DRM. Il contenuto viene crittografato una volta e le chiavi vengono distribuite tramite diversi server di licenze. Questo è fondamentale per i servizi multipiattaforma: Netflix crittografa un film una volta e lo distribuisce ad Android (Widevine), iOS (FairPlay) e Windows (PlayReady) senza necessità di ricodifica.

CENC utilizza la crittografia CBC con chiavi diverse per le tracce audio e video. Ogni chiave viene memorizzata crittografata nel manifesto MPD (MPEG-DASH) o M3U8 (HLS). L'identificatore del contenuto (KID) collega il flusso crittografato alla licenza sul server — senza una licenza valida, la chiave non può essere decodificata.

Come funziona il DRM nelle applicazioni mobili

Il processo di riproduzione DRM si compone di quattro fasi: caricamento del manifesto, ottenimento della licenza, decodifica del contenuto e visualizzazione. Ogni fase è eseguita da diversi componenti del sistema — il lettore multimediale, il modulo CDM e il server di licenze.

• Caricamento del manifesto — il lettore riceve MPD (DASH) o M3U8 (HLS) con metadati sui segmenti crittografati, lo schema di crittografia e l'URL del server di licenze.
• Richiesta di licenza — il lettore passa l'identificatore del contenuto (KID) al Modulo di Decodifica del Contenuto (CDM), che genera una richiesta al server di licenze.
• Ottenimento della chiave — il server verifica i diritti dell'utente (abbonamento, regione, dispositivo) e restituisce una chiave crittografata con la chiave pubblica del dispositivo.
• Decodifica del flusso — il CDM decodifica la chiave utilizzando la chiave privata del dispositivo e la passa al lettore multimediale per la decodifica in tempo reale dei segmenti video.

Modulo di Decodifica del Contenuto (CDM)

CDM è un modulo software o hardware protetto che esegue la decodifica del contenuto. Su Android, il CDM è implementato a livello di API MediaDrm; su iOS, è integrato in AVFoundation tramite AVContentKeySession. Il CDM non espone mai la chiave all'applicazione — tutte le operazioni crittografiche vengono eseguite all'interno di un ambiente sicuro (TEE — Trusted Execution Environment).

Sui dispositivi con supporto hardware (Livello di sicurezza 1), il CDM opera all'interno del TEE — la chiave non entra mai nella memoria principale del dispositivo. Questo è un requisito degli studi per la riproduzione di contenuti 4K HDR. Sui dispositivi senza TEE, le chiavi vengono decodificate tramite software (L3), riducendo la sicurezza e limitando la qualità massima a 540p.

Principali schemi DRM

Tre sistemi DRM dominano le piattaforme mobili. Ciascuno è esclusivo per il proprio ecosistema, ma tutti supportano CENC, consentendo di utilizzare un unico flusso di contenuti crittografati su tutte le piattaforme.

Scelta del DRM per un servizio multipiattaforma

Per un servizio di streaming che funzioni su tutte le piattaforme, è necessario il supporto di tutti e tre i sistemi DRM. Una soluzione pratica è utilizzare una CDN con supporto multi-DRM (Muvi, Vualto, Axinom), che instrada automaticamente le richieste di licenza al server appropriato in base al dispositivo dell'utente. Secondo Streaming Learning Center (2025), il 78% dei servizi di streaming utilizza l'approccio Multi-DRM.

Lo standard MPEG-DASH con CENC semplifica l'architettura: il contenuto viene crittografato una volta con una chiave condivisa e il sistema DRM viene selezionato lato client. Il server di licenze riceve una richiesta con l'identificatore del dispositivo e restituisce una chiave crittografata per il CDM specifico. Nessuna differenza nel contenuto per diverse piattaforme — solo un server di licenze diverso.

Widevine: livelli e caratteristiche

Widevine è il sistema DRM di Google, lo standard de facto su Android. Supporta tre livelli di sicurezza che determinano dove e come viene eseguita la decodifica del contenuto. Il livello di sicurezza dipende dalle capacità hardware del dispositivo e determina la risoluzione massima del contenuto.

Livelli di sicurezza di Widevine

Widevine L1 (hardware) — il livello più sicuro. Tutte le operazioni crittografiche vengono eseguite all'interno del Trusted Execution Environment (TEE). La chiave non lascia mai l'area sicura. I dispositivi L1 possono riprodurre contenuti fino a 4K HDR. È richiesta la certificazione Google — un processo che i dispositivi di punta seguono.

Widevine L3 (software) — la decodifica viene eseguita nella memoria principale del dispositivo. Un utente malintenzionato tecnicamente competente può estrarre la chiave. La risoluzione è limitata a 540p (960x540) per i contenuti premium. Tutti i dispositivi Android supportano L3, anche se non certificati per L1.

Widevine L2 — un raro livello intermedio in cui la decodifica viene eseguita nel TEE, ma il rendering segue un percorso non protetto. Utilizzato su alcuni Smart TV. Praticamente mai presente sui dispositivi mobili.

Come determinare il livello Widevine su un dispositivo

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

Il metodo interroga il CDM per la proprietà securityLevel tramite l'UUID di Widevine. Il valore restituito è una stringa L1, L2 o L3, che indica il livello di protezione attuale del dispositivo. Questa informazione è fondamentale per i servizi di streaming: se un dispositivo ha solo L3, il contenuto 4K non può essere visualizzato.

Apple FairPlay: architettura e principio di funzionamento

FairPlay è il sistema DRM di Apple, integrato in tutte le piattaforme dell'ecosistema: iOS, iPadOS, macOS, tvOS e watchOS. A differenza di Widevine, FairPlay non ha livelli di sicurezza — la protezione è determinata dal dispositivo. Su iOS con Secure Enclave, FairPlay offre un livello di protezione paragonabile a Widevine L1.

FairPlay funziona esclusivamente con il protocollo HLS (HTTP Live Streaming). Il contenuto viene impacchettato in segmenti .ts (MPEG-TS) o frammenti .m4s (fMP4). Il manifesto M3U8 contiene il tag #EXT-X-KEY con l'URI del server di licenze (KSM — Key Server Module) e il IV di inizializzazione. All'avvio della riproduzione, AVPlayer legge il manifesto e richiede la chiave tramite AVContentKeySession.

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

Il delegato di AVContentKeySession riceve una richiesta di chiave con l'identificatore del contenuto (assetId). L'applicazione invia questo ID al proprio server di licenze (KSM), che restituisce la chiave crittografata. La chiamata processContentKeyResponse passa la chiave al CDM per la decodifica. Se la licenza non è valida (scaduta, non pagata), il server restituisce un errore 403 e AVPlayer non avvia la riproduzione.

Caricamento di chiavi persistenti per contenuti offline

FairPlay supporta le chiavi persistenti — il salvataggio della licenza sul dispositivo per la visualizzazione offline. Dopo aver ricevuto la chiave, l'applicazione chiama processContentKeyResponse con il flag allowsPersistableKey. La chiave viene memorizzata nel Keychain e può essere utilizzata senza contattare il server durante le riproduzioni successive. Tuttavia, la licenza offline ha un periodo di validità limitato — generalmente 7-30 giorni, dopo il quale è necessario il rinnovo.

Le licenze offline sono memorizzate nell'archivio protetto di iOS — il Keychain. In caso di tentativo di jailbreak o estrazione di dump, Secure Enclave distrugge le chiavi. Secondo Apple (2025), la tecnologia delle chiavi persistenti viene utilizzata in Apple TV+, Netflix e Disney+ per scaricare contenuti su un iPad prima di un viaggio.

Microsoft PlayReady per la protezione universale

PlayReady è il DRM di Microsoft, utilizzato su Windows, Xbox e Windows Phone legacy. Sebbene PlayReady sia meno comune sui dispositivi mobili rispetto a Widevine e FairPlay, è importante per soluzioni di streaming universali che funzionano su tutte le piattaforme Microsoft. PlayReady supporta sia la protezione software che hardware tramite TPM.

PlayReady utilizza l'architettura SL (Security Level): SL2000 (software, simile a Widevine L3), SL3000 (hardware, simile a L1). Su Xbox Series X, PlayReady SL3000 funziona tramite TEE+TPM — le chiavi vengono estratte solo in un ambiente protetto. Ciò consente di riprodurre 4K Blu-ray sulla console senza rischio di copia.

Secondo Microsoft Docs (2026), PlayReady supporta CENC e può funzionare con MPEG-DASH tramite Media Source Extensions (MSE) nei browser Edge. Per le applicazioni mobili su Android e iOS, PlayReady è disponibile tramite SDK ma è usato raramente — principalmente per applicazioni aziendali e servizi multimediali Microsoft.

PlayReady Native SDK per Android

Microsoft fornisce il PlayReady Native SDK per Android e iOS. L'integrazione viene eseguita tramite ExoPlayer con l'estensione PlayReady: lo sviluppatore aggiunge PlayReadyRenderer, che viene incorporato nella catena di decodifica. ExoPlayer passa automaticamente tra Widevine e PlayReady a seconda del DRM specificato nel manifesto MPD.

Sebbene PlayReady sia raramente utilizzato nelle applicazioni mobili, il suo supporto è obbligatorio per i servizi all'interno dell'ecosistema Microsoft — ad esempio, piattaforme di formazione aziendale su SharePoint e Stream. Secondo Microsoft (2025), PlayReady è utilizzato nel 23% delle soluzioni multimediali aziendali contro il 62% di Widevine.

Integrazione del DRM in un'applicazione mobile

Integrare il DRM in un'applicazione mobile non richiede la scrittura di codice crittografico — lo sviluppatore lavora con un lettore che supporta il DRM nativamente. Vediamo l'integrazione su Android tramite ExoPlayer con l'estensione DRM.

Configurazione di ExoPlayer con supporto 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 gestisce la sessione DRM: crea una sessione MediaDrm, gestisce le richieste di licenza e passa le chiavi al decoder. Il parametro setMultiSession(true) consente di decodificare più flussi (audio + video) simultaneamente in sessioni diverse. MediaDrmCallback implementa la richiesta HTTP al server di licenze — solitamente un POST con corpo SignedRequest.

MediaDrmCallback per richiesta di licenza

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
}

Il callback invia una richiesta POST al server di licenze con l'UUID di Widevine nel corpo. Il server verifica l'autenticazione dell'utente (token nell'intestazione) e restituisce la chiave crittografata. Se l'utente non ha un abbonamento attivo, il server restituisce 403 Forbidden — ExoPlayer genera un errore DRM, che deve essere gestito tramite onPlayerError.

Gestione degli errori DRM

Gli errori DRM si verificano quando una licenza non è valida, è scaduta o il dispositivo non supporta il livello di protezione richiesto. ExoPlayer passa l'errore tramite Player.Listener.onPlayerError con codici TYPE_DRM_LICENSE_EXPIRED, TYPE_DRM_UNSUPPORTED o TYPE_SOURCE. Si consiglia di mostrare all'utente un messaggio informativo: “Il contenuto non è disponibile per questo dispositivo” o “Rinnova il tuo abbonamento per visualizzare.”

Secondo le analisi dei servizi di streaming (2025), fino all'8% degli avvii di riproduzione falliti sono correlati a errori DRM. Di questi, il 60% sono licenze scadute, il 25% incompatibilità del dispositivo e il 15% errori di rete durante la richiesta della chiave. Un tentativo automatico dopo 5 secondi risolve il 40% dei casi di errore di rete.