DRM en aplicaciones móviles: fundamentos, esquemas de protección y principio de funcionamiento

¿Qué es DRM?

DRM es un conjunto de métodos criptográficos y de software que controlan el acceso al contenido digital. A diferencia del cifrado simple, DRM incluye un sistema de licencias: el contenido está cifrado y para verlo se requiere una clave que se emite solo después de verificar los derechos del usuario.

El objetivo principal de DRM es prevenir la piratería y garantizar el cumplimiento de las restricciones regionales. Sin DRM, los propietarios de contenido (estudios de cine, sellos discográficos) no licencian su contenido para plataformas de streaming. Según la Motion Picture Association (2025), el uso de DRM redujo la distribución ilegal de películas en streaming en un 62% en comparación con la era de los DVD-rips.

En el desarrollo móvil, DRM se integra a nivel del reproductor multimedia: el desarrollador utiliza ExoPlayer (Android), AVPlayer (iOS) o Shaka Player (Web), que admiten el descifrado incorporado de flujos cifrados. El desarrollador no necesita implementar criptografía — solo integrar un SDK para licencias.

DRM y CENC (Common Encryption)

El estándar CENC (Common Encryption — ISO/IEC 23001-7) permite usar un solo archivo multimedia cifrado para todos los sistemas DRM. El contenido se cifra una vez y las claves se distribuyen a través de diferentes servidores de licencias. Esto es fundamental para servicios multiplataforma: Netflix cifra una película una vez y la entrega a Android (Widevine), iOS (FairPlay) y Windows (PlayReady) sin necesidad de recodificar.

CENC utiliza cifrado CBC con diferentes claves para pistas de audio y video. Cada clave se almacena cifrada en el manifiesto MPD (MPEG-DASH) o M3U8 (HLS). El identificador de contenido (KID) vincula el flujo cifrado con la licencia en el servidor — sin una licencia válida, la clave no se descifra.

Cómo funciona DRM en aplicaciones móviles

El proceso de reproducción con DRM consta de cuatro etapas: carga del manifiesto, obtención de licencia, descifrado del contenido y visualización. Cada etapa es realizada por diferentes componentes del sistema — el reproductor multimedia, el módulo CDM y el servidor de licencias.

• Carga del manifiesto — el reproductor recibe MPD (DASH) o M3U8 (HLS) con metadatos sobre segmentos cifrados, el esquema de cifrado y la URL del servidor de licencias.
• Solicitud de licencia — el reproductor pasa el identificador de contenido (KID) al Módulo de Descifrado de Contenido (CDM), que genera una solicitud al servidor de licencias.
• Obtención de clave — el servidor verifica los derechos del usuario (suscripción, región, dispositivo) y devuelve una clave cifrada con la clave pública del dispositivo.
• Descifrado del flujo — el CDM descifra la clave usando la clave privada del dispositivo y la pasa al reproductor multimedia para el descifrado en tiempo real de los segmentos de video.

Módulo de Descifrado de Contenido (CDM)

CDM es un módulo protegido de software o hardware que realiza el descifrado de contenido. En Android, CDM está implementado a nivel de la API MediaDrm; en iOS, está integrado en AVFoundation a través de AVContentKeySession. El CDM nunca expone la clave a la aplicación — todas las operaciones criptográficas se realizan dentro de un entorno seguro (TEE — Trusted Execution Environment).

En dispositivos con soporte de hardware (Secure Level 1), el CDM opera dentro del TEE — la clave nunca ingresa a la memoria principal del dispositivo. Este es un requisito de los estudios para reproducir contenido 4K HDR. En dispositivos sin TEE, las claves se descifran por software (L3), lo que reduce la seguridad y limita la calidad máxima a 540p.

Esquemas principales de DRM

Tres sistemas DRM dominan las plataformas móviles. Cada uno es exclusivo de su ecosistema, pero todos admiten CENC, lo que permite usar un solo flujo de contenido cifrado en todas las plataformas.

Elección de DRM para un servicio multiplataforma

Para un servicio de streaming que funcione en todas las plataformas, se requiere soporte para los tres sistemas DRM. Una solución práctica es usar una CDN con soporte multi-DRM (Muvi, Vualto, Axinom), que enruta automáticamente las solicitudes de licencia al servidor adecuado según el dispositivo del usuario. Según Streaming Learning Center (2025), el 78% de los servicios de streaming utilizan el enfoque Multi-DRM.

El estándar MPEG-DASH con CENC simplifica la arquitectura: el contenido se cifra una vez con una clave compartida y el sistema DRM se selecciona en el cliente. El servidor de licencias recibe una solicitud con el identificador del dispositivo y devuelve una clave cifrada para el CDM específico. Sin diferencia en el contenido para diferentes plataformas — solo un servidor de licencias diferente.

Widevine: niveles y características

Widevine es el sistema DRM de Google, el estándar de facto en Android. Admite tres niveles de seguridad que determinan dónde y cómo se realiza el descifrado de contenido. El nivel de seguridad depende de las capacidades de hardware del dispositivo y determina la resolución máxima del contenido.

Niveles de seguridad de Widevine

Widevine L1 (hardware) — el nivel más seguro. Todas las operaciones criptográficas se realizan dentro del Trusted Execution Environment (TEE). La clave nunca sale del área segura. Los dispositivos con L1 pueden reproducir contenido hasta 4K HDR. Se requiere certificación de Google — un proceso que siguen los dispositivos emblemáticos.

Widevine L3 (software) — el descifrado se realiza en la memoria principal del dispositivo. Un atacante con conocimientos técnicos puede extraer la clave. La resolución está limitada a 540p (960x540) para contenido premium. Todos los dispositivos Android admiten L3, incluso si no están certificados para L1.

Widevine L2 — un nivel intermedio poco común donde el descifrado se realiza en el TEE, pero la representación sigue una ruta no protegida. Se utiliza en algunos Smart TV. Prácticamente nunca se encuentra en dispositivos móviles.

Cómo determinar el nivel de Widevine en 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 — protección por hardware"
        "L3" -> "Widevine L3 — protección por software"
        else -> "Widevine $securityLevel"
    }
}

El método consulta al CDM la propiedad securityLevel a través del UUID de Widevine. El valor devuelto es una cadena L1, L2 o L3, que indica el nivel de protección actual del dispositivo. Esta información es crítica para los servicios de streaming: si un dispositivo solo tiene L3, no se puede mostrar contenido 4K.

Apple FairPlay: arquitectura y principio de funcionamiento

FairPlay es el sistema DRM de Apple, integrado en todas las plataformas del ecosistema: iOS, iPadOS, macOS, tvOS y watchOS. A diferencia de Widevine, FairPlay no tiene niveles de seguridad — la protección está determinada por el dispositivo. En iOS con Secure Enclave, FairPlay proporciona un nivel de protección comparable a Widevine L1.

FairPlay funciona exclusivamente con el protocolo HLS (HTTP Live Streaming). El contenido se empaqueta en segmentos .ts (MPEG-TS) o fragmentos .m4s (fMP4). El manifiesto M3U8 contiene la etiqueta #EXT-X-KEY con la URI del servidor de licencias (KSM — Key Server Module) y el IV de inicialización. Al iniciar la reproducción, AVPlayer lee el manifiesto y solicita la clave a través de AVContentKeySession.

Integración 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)
        )
    }
}

El delegado de AVContentKeySession recibe una solicitud de clave con el identificador de contenido (assetId). La aplicación envía este ID a su servidor de licencias (KSM), que devuelve la clave cifrada. La llamada a processContentKeyResponse pasa la clave al CDM para su descifrado. Si la licencia no es válida (expirada, no pagada), el servidor devuelve un error 403 y AVPlayer no inicia la reproducción.

Carga de claves persistentes para contenido offline

FairPlay admite claves persistentes — guardar la licencia en el dispositivo para visualización offline. Después de recibir la clave, la aplicación llama a processContentKeyResponse con el indicador allowsPersistableKey. La clave se almacena en el Keychain y se puede usar sin contactar al servidor en reproducciones posteriores. Sin embargo, la licencia offline tiene un período de validez limitado — generalmente de 7 a 30 días, después del cual se requiere renovación.

Las licencias offline se almacenan en el almacenamiento protegido de iOS — el Keychain. Si se intenta un jailbreak o extracción de volcado, el Secure Enclave destruye las claves. Según Apple (2025), la tecnología de claves persistentes se utiliza en Apple TV+, Netflix y Disney+ para descargar contenido en un iPad antes de un viaje.

Microsoft PlayReady para protección universal

PlayReady es el DRM de Microsoft, utilizado en Windows, Xbox y Windows Phone heredado. Aunque PlayReady es menos común en dispositivos móviles que Widevine y FairPlay, es importante para soluciones de streaming universales que funcionan en todas las plataformas de Microsoft. PlayReady admite protección tanto por software como por hardware a través de TPM.

PlayReady utiliza la arquitectura SL (Security Level): SL2000 (software, similar a Widevine L3), SL3000 (hardware, similar a L1). En Xbox Series X, PlayReady SL3000 funciona a través de TEE+TPM — las claves se extraen solo en un entorno protegido. Esto permite reproducir Blu-ray 4K en la consola sin riesgo de copia.

Según Microsoft Docs (2026), PlayReady admite CENC y puede funcionar con MPEG-DASH a través de Media Source Extensions (MSE) en navegadores Edge. Para aplicaciones móviles en Android e iOS, PlayReady está disponible a través de SDK, pero se usa raramente — principalmente para aplicaciones empresariales y servicios multimedia de Microsoft.

PlayReady Native SDK para Android

Microsoft proporciona el PlayReady Native SDK para Android e iOS. La integración se realiza a través de ExoPlayer con la extensión PlayReady: el desarrollador agrega PlayReadyRenderer, que se integra en la cadena de decodificación. ExoPlayer cambia automáticamente entre Widevine y PlayReady según qué DRM esté especificado en el manifiesto MPD.

Aunque PlayReady rara vez se usa en aplicaciones móviles, su soporte es obligatorio para servicios dentro del ecosistema de Microsoft — por ejemplo, plataformas de capacitación empresarial en SharePoint y Stream. Según Microsoft (2025), PlayReady se utiliza en el 23% de las soluciones multimedia empresariales frente al 62% de Widevine.

Integración de DRM en una aplicación móvil

La integración de DRM en una aplicación móvil no requiere escribir código criptográfico — el desarrollador trabaja con un reproductor que admite DRM de forma nativa. Veamos la integración en Android a través de ExoPlayer con la extensión DRM.

Configuración de ExoPlayer con soporte 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 gestiona la sesión DRM: crea una sesión MediaDrm, maneja solicitudes de licencia y pasa las claves al decodificador. El parámetro setMultiSession(true) permite descifrar múltiples flujos (audio + video) simultáneamente en diferentes sesiones. MediaDrmCallback implementa la solicitud HTTP al servidor de licencias — generalmente un POST con un cuerpo SignedRequest.

MediaDrmCallback para solicitud de licencia

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
}

El callback envía una solicitud POST al servidor de licencias con el UUID de Widevine en el cuerpo. El servidor verifica la autenticación del usuario (token en el encabezado) y devuelve la clave cifrada. Si el usuario no tiene una suscripción activa, el servidor devuelve 403 Forbidden — ExoPlayer genera un error DRM, que debe manejarse a través de onPlayerError.

Manejo de errores DRM

Los errores DRM ocurren cuando una licencia no es válida, ha expirado o el dispositivo no admite el nivel de protección requerido. ExoPlayer pasa el error a través de Player.Listener.onPlayerError con códigos TYPE_DRM_LICENSE_EXPIRED, TYPE_DRM_UNSUPPORTED o TYPE_SOURCE. Se recomienda mostrar al usuario un mensaje informativo: “El contenido no está disponible para este dispositivo” o “Renueve su suscripción para verlo.”

Según análisis de servicios de streaming (2025), hasta el 8% de los inicios de reproducción fallidos están relacionados con errores DRM. De estos, el 60% son licencias expiradas, el 25% incompatibilidad del dispositivo y el 15% errores de red durante la solicitud de clave. Un reintento automático después de 5 segundos resuelve el 40% de los casos de errores de red.