La protección avanzada de contenidos en Windows 11 se apoya en tecnologías DRM de última generación, con PlayReady como pieza central y un fuerte énfasis en el uso de hardware seguro. Cada vez más plataformas de streaming y proveedores apuestan por este enfoque para poder ofrecer vídeo en HD, 4K y hasta UHD sin miedo a que se copie o se extraiga de forma ilegal.
En este contexto, entender cómo funciona la implementación paso a paso de DRM y la reproducción segura en el ecosistema Windows (tanto en Windows 11 como en Windows 10 y Xbox) es clave para cualquier desarrollador que quiera servir contenido premium, cumplir las reglas de los estudios y, a la vez, garantizar una buena experiencia de usuario. Vamos a desgranar, con calma pero a fondo, todas las piezas implicadas: PlayReady HWDRM y SWDRM, Windows TEE, protección de salida, licencias, migración de apps UWP y más.
DRM basado en hardware con PlayReady: concepto y ventajas
El corazón de la reproducción segura en Windows moderno es PlayReady con soporte de DRM basado en hardware (HWDRM), integrado directamente en el sistema operativo como componente in-box. Frente al DRM puramente software (SWDRM), el enfoque de hardware utiliza un núcleo criptográfico protegido y un entorno de ejecución de confianza para blindar todo lo crítico: claves privadas, claves de contenido y flujos de vídeo comprimidos o sin comprimir.
Gracias a este modelo, el contenido de alta definición (1080p) y ultra alta definición (UHD) puede reproducirse en una amplia gama de dispositivos Windows. Manteniendo todo el material sensible dentro de zonas seguras del hardware. El resultado práctico es que la superficie para copias no autorizadas se reduce drásticamente, ya que las claves nunca salen en claro y el vídeo solo se «desrevuelve» en el último tramo de la canalización protegida.
PlayReady en Windows 10 y Windows 11 ya no es un simple componente AppX: forma parte del propio sistema y se expone a las aplicaciones UWP a través del espacio de nombres Windows.Media.Protection.PlayReady. Además, el SDK de Windows incluye los encabezados necesarios para manejar códigos de error específicos de PlayReady, permitiendo a las apps reaccionar con precisión ante problemas de licencias o de protección de salida.
Entre las mejoras de PlayReady para Windows modernas destaca también la capacidad de adquirir de forma proactiva varias licencias no persistentes en un único mensaje, soporte para licencias de duración limitada (LDL) con expiración en tiempo real, separación de licencias de audio y vídeo y máximos de resolución controlados (MaxResDecode) incluso cuando se dispone de claves más potentes.
Windows TEE: cómo se integra el entorno de ejecución de confianza
Para que el DRM de hardware tenga sentido, Windows se apoya en un Trusted Execution Environment (TEE) propio, conocido como Windows TrEE. Aunque los detalles internos de la implementación no son públicos en profundidad, sí se describe cómo encaja en la arquitectura de PlayReady para UWP.
Windows implementa una capa de proxy OEM que serializa las llamadas PRITEE y las envía a un controlador de modo usuario dentro del subsistema Windows Media Foundation. A partir de ahí, estas llamadas se redirigen bien al controlador TrEE de Windows, bien al controlador de gráficos del OEM, dependiendo de la configuración del dispositivo y del camino de salida elegido.
Este diseño permite que todas las protecciones de salida en HWDRM se apliquen desde el TEE de Windows. Es decir, el sistema conoce en todo momento qué salidas están conectadas, qué soportan (HDCP, tipos de conectores, Miracast, etc.) y aplica las reglas de la licencia PlayReady antes de que el contenido se materialice en un monitor o televisor.
Si un fabricante u organización necesita desarrollar un puerto específico de TEE para PlayReady en Windows, Microsoft ofrece soporte a través de canales directos (por ejemplo, contactos técnicos especializados), ya que se trata de una zona altamente sensible en términos de seguridad y cumplimiento.
Chrome, Edge y otros navegadores: soporte PlayReady y experiencia de streaming
En el ámbito del navegador, la tendencia es clara: aprovechar el DRM nativo de cada plataforma para reducir dependencias de plugins y permitir streaming seguro con la mejor calidad posible. Hasta ahora, Chrome en Windows se apoyaba principalmente en Widevine, la solución DRM de Google, que en algunos escenarios limita la resolución máxima accesible para contenido premium.
Google está trabajando para que Chrome pueda usar PlayReady DRM con soporte de hardware en Windows 11. Eso abre la puerta a reproducir vídeos 4K y UHD. De forma equivalente a como lo hace Microsoft Edge. De hecho, grandes plataformas como Netflix ya utilizan PlayReady para proteger sus títulos de gama alta en el ecosistema Windows.
El plan de Google pasa por que Chrome soporte simultáneamente PlayReady y Widevine. De modo que se pueda elegir la mejor opción en cada dispositivo. Además, el navegador incorporará un indicador de privacidad visible en la barra de direcciones cuando un sitio acceda a contenido protegido mediante PlayReady. Ofreciendo al usuario la posibilidad de permitir o bloquear ese acceso de forma informada.
Este movimiento sitúa a Chrome en una posición más competitiva en experiencia de streaming sobre Windows 11, acercando su rendimiento y calidad visual a la que ya ofrece Edge gracias a su integración profunda con el sistema y con PlayReady HWDRM.
Fundamentos de DRM en Windows: de Windows 2000 a Windows 11
El soporte de DRM para audio digital en Windows no es nuevo. Existe desde Windows 2000 y Windows 98/Me. Pero lo cierto es que la seguridad en el kernel empezó a consolidarse realmente desde Windows XP y versiones posteriores. En estas versiones, el sistema deja de permitir controladores no autorizados que poder desviar el audio protegido y grabarlo sin cifrar en disco.
La arquitectura clásica se basa en almacenar el contenido protegido en disco en formato cifrado. Durante la reproducción, el flujo se mantiene enredado (encrypted/scrambled) mientras se lee y se almacena en memoria hasta que llega al controlador DRMK (Drmk.sys). Este componente desencripta el contenido y lo envía directamente a un controlador de audio de confianza. Minimizando así la porción del camino de datos en la que el contenido aparece en claro.
Cuando se construye un grafo de filtros para reproducir una secuencia de audio no controlada, DRMK autentica los controladores de adaptador y los filtros KS que van a intervenir. Si alguno de los componentes del grafo no cumple los requisitos DRM, el sistema rechaza toda la cadena de reproducción para evitar fugas.
Un controlador compatible con DRM debe bloquear copias no autorizadas mientras reproduce el contenido digital y desactivar las salidas digitales estándar susceptibles de captura (como S/PDIF). Curiosamente, esta restricción no se aplica a dispositivos USB. Actualmente DRMK solo permite reproducir contenido seguro a través de altavoces USB que no expongan salidas digitales adicionales.
DRM de hardware vs DRM de software: diferencias clave y condiciones
Al desarrollar aplicaciones UWP orientadas a contenido de alto valor, hay que tener claro cuándo se está utilizando DRM de hardware (HWDRM) y cuándo DRM de software (SWDRM). Y es que los comportamientos cambian de forma importante. Sobre todo en lo referente a la protección de salida.
Con PlayReady HWDRM en Windows 10 y 11, el sistema aplica niveles de protección de salida (OPL) más estrictos para vídeo digital sin comprimir.
Otra diferencia importante es que, con HWDRM, las protecciones de salida se aplican a todos los monitores en función del menos capaz. Si un usuario tiene dos pantallas, una con HDCP y otra sin, y la licencia exige HDCP, la reproducción fallará aunque el contenido solo se muestre en el monitor compatible. En SWDRM, la reproducción se permitiría siempre que solo se represente en la pantalla con HDCP.
Además, en HWDRM no se admite el Protected Media Path (PMP), no se soporta el códec Windows Media Video/VC-1 y las configuraciones con varias GPU presentan limitaciones para licencias persistentes. Esto obliga a tener cuidado con los cambios de hardware gráfico en equipos de los usuarios.
Gestión de varias GPU y licencias persistentes con PlayReady
En escenarios donde un PC tiene más de una GPU (por ejemplo, gráfica integrada más una tarjeta dedicada), el manejo de licencias persistentes en HWDRM se complica. PlayReady asocia esas licencias a un almacén de datos hash (HDS) vinculado a las claves de hardware de la GPU en uso en el momento de la adquisición.
Imaginemos el flujo típico: un cliente compra un equipo con GPU integrada, usa una app que adquiere licencias persistentes bajo DRM de hardware, y más adelante instala una nueva tarjeta gráfica dedicada. En ese momento, todas las licencias del HDS ligadas a la GPU integrada no servirán con la nueva tarjeta, que tendrá su propio HDS independiente.
Para evitar que la reproducción falle porque el nuevo hardware no pueda descifrar las licencias antiguas, PlayReady mantiene un HDS separado por cada GPU detectada. Esto implica que, si la app detecta un cambio de GPU, quizá tenga que volver a adquirir licencias para contenido que, desde la perspectiva de un escenario SWDRM o sin cambios de hardware, ya estarían resueltas.
En la práctica, las aplicaciones que gestionan licencias persistentes en HWDRM deberían prever la posible “pérdida” efectiva de licencias tras cambios de tarjeta gráfica. No obstante, al ser un caso relativamente poco común, muchos proveedores optan por manejarlo vía soporte al usuario cuando, tras una modificación de hardware, el contenido deja de reproducirse correctamente.
Cómo forzar el uso de DRM de software (invalidar HWDRM)
Hay contenidos que, por su naturaleza o por las tecnologías utilizadas, no son compatibles con DRM de hardware. Es el caso de algunos contenidos tipo “cocktail”, ciertos códecs de vídeo distintos de H.264/HEVC o incluso contenido HEVC en dispositivos cuyo HWDRM no soporte ese códec.
En estos casos puede convenir desactivar el uso de HWDRM y obligar a PlayReady a usar la capa de protección software. De forma predeterminada, si el sistema soporta DRM de hardware, se utilizará. Así que hay que deshabilitarlo explícitamente antes de iniciar la reproducción. Y asegurarse de que no quede ningún objeto PlayReady en memoria.
Una forma de hacerlo consiste en crear un contenedor de configuración en ApplicationData.LocalSettings e introducir el valor SoftwareOverride = 1 en la clave PlayReady. Para volver a habilitar HWDRM, basta con establecer ese valor a 0. Además, para cada reproducción, puede configurarse el MediaProtectionManager con la propiedad Windows.Media.Protection.UseSoftwareProtectionLayer = true, forzando así el uso de la capa software.
La forma más sencilla de saber qué tipo de DRM se está usando en una app UWP es revisar la carpeta PlayReady dentro del LocalCache del paquete de la aplicación. Si aparece un archivo mspr.hds, se está trabajando con SWDRM. Si lo que vemos es otro archivo .hds distinto, estaremos bajo HWDRM. Eliminar la carpeta PlayReady y repetir la prueba permite verificar cambios de configuración.
Detección de capacidades de DRM de hardware (incluido AES128CBC y HEVC)
Antes de decidir qué tipo de contenido servir o qué licencias emitir, es muy recomendable que la aplicación compruebe qué funciones DRM de hardware soporta el dispositivo. Para ello, PlayReady ofrece el método PlayReadyStatics.CheckSupportedHardware, que recibe como parámetro un valor de la enumeración PlayReadyHardwareDRMFeatures.
Consultando, por ejemplo, la característica HardwareDRM se puede saber si hay soporte general de DRM de hardware. Preguntando por HEVC se determina si el hardware admite el códec de vídeo de alta eficiencia H.265. A partir de Windows 10 versión 1709, también es posible comprobar si el dispositivo soporta cifrado de hardware AES128CBC usando la característica Aes128Cbc.
Dado que en versiones anteriores del sistema esa enumeración puede no existir y provocar excepciones si se usa sin comprobar, hay que combinarlo con ApiInformation.IsApiContractPresent (versión 5 de Windows.Foundation.UniversalApiContract) antes de realizar la consulta. El patrón típico es verificar primero la presencia del contrato y, solo si está disponible, invocar a CheckSupportedHardware.
Complementariamente, la propiedad PlayReadyStatics.PlayReadyCertificateSecurityLevel devuelve el nivel de seguridad del certificado de cliente. Si el valor es 0, el cliente no está individualizado o aprovisionado. Si es menor de 3000, significa que no se está usando DRM de hardware. Y si es igual o superior a 3000, indica que el dispositivo cumple las condiciones para HWDRM.
Protección de salida: OPL, HDCP, Miracast y restricciones explícitas
Uno de los pilares del modelo PlayReady en Windows 10 y 11 es el control exhaustivo de las salidas de vídeo y audio. Las licencias pueden definir niveles de protección de salida (Output Protection Levels, OPL) diferenciados para vídeo digital comprimido, vídeo digital sin comprimir, conectores analógicos, HDMI, DVI, DisplayPort, MHL o Miracast.
En el caso del vídeo, un OPL 100 suele permitir que el contenido pase sin mayor restricción. Niveles más altos incorporan condiciones como interactuar con HDCP o limitar la resolución efectiva del contenido. A partir de ciertos umbrales, Windows 10 nunca envía vídeo digital comprimido a las salidas, independientemente del valor concreto, siguiendo las normas de cumplimiento de PlayReady.
La tabla de asignaciones muestra que, para OPL 270, SWDRM intentará activar HDCP y, si falla, reducirá la resolución a 520.000 píxeles. Con HWDRM, en cambio, la reproducción se bloquea en HDMI/DVI si no se logra establecer HDCP. Para OPL 300, si se define la restricción de tipo HDCP, solo se permitirá contenido con HDCP 2.2 y tipo de secuencia 1. De lo contrario, se cortará la reproducción.
Para audio, los OPL también determinan si se permite el paso de audio digital comprimido o sin comprimir, y bajo qué condiciones se necesita HDCP o SCMS configurado en CopyNever. De nuevo, a medida que aumentan los niveles, las restricciones son más duras y se puede llegar a impedir completamente la reproducción si no se cumplen.
Miracast se considera en Windows 10 como una salida digital más. PlayReady permite reproducir contenido a través de Miracast siempre que se active HDCP 2.0 o superior. Dependiendo del OPL asignado en la licencia, el dispositivo intentará establecer HDCP. Si no se consigue, directamente no pasará contenido a esa salida. Cuando se combinan OPL altos y restricción de tipo HDCP, solo se permite la reproducción si se logra HDCP 2.2 y tipo de secuencia adecuado.
Requisitos previos y migración de aplicaciones PlayReady UWP
Para crear aplicaciones UWP que aprovechen PlayReady y sus capacidades HWDRM, hay que cumplir primero algunos requisitos de entorno. Es imprescindible trabajar sobre Windows 10 o superior y, si se compilan los ejemplos oficiales de PlayReady para UWP, utilizar Visual Studio 2015 o posterior (para apps 8.1 todavía se admite VS 2013).
En el proceso de migración desde aplicaciones de la Tienda Windows 8.x a UWP en Windows 10, el cambio más evidente es el de espacio de nombres: hay que reemplazar todas las referencias a Microsoft.Media.PlayReadyClient por Windows.Media.Protection.PlayReady. Las referencias a los metadatos winmd pasan a provenir de los contratos universales del sistema (por ejemplo, windows.foundation.universalappcontract.winmd).
Si se quiere reproducir contenido HD 1080p o UHD protegido, se tiene que implementar DRM de hardware PlayReady. Para aquellos tipos de contenido que no sean compatibles con HWDRM, se recurre a la lógica de invalidación de hardware y uso de SWDRM descrita más arriba.
En cuanto al MediaProtectionManager, es esencial configurarlo con las propiedades correctas: el GUID del sistema de protección PlayReady (MediaProtectionSystemId), el mapeo de identificadores de sistema a la cadena PlayReadyWinRTTrustedInput y el GUID del contenedor (MediaProtectionContainerGuid). Esta configuración es la que permite que la pipeline multimedia de Windows asocie las peticiones de protección al motor PlayReady adecuado.
Adquisición proactiva de licencias no persistentes y cadenas de licencias
Una de las mejoras clave en las versiones recientes de PlayReady es la adquisición proactiva de licencias no persistentes antes de iniciar la reproducción. En versiones anteriores solo podían obtenerse de forma reactiva, durante el proceso de playback. Eso incrementaba el tiempo hasta el primer fotograma.
El flujo recomendado consiste en:
- Crear una sesión de reproducción donde se almacenarán las licencias no persistentes.
- Enlazar esa sesión con la clase de adquisición de licencias.
- Generar una solicitud de servicio de licencia (LAServiceRequest).
- Completar el proceso de adquisición.
- Asociar esa sesión al origen multimedia utilizado por el reproductor.
PlayReady también permite agrupar en un único mensaje la adquisición de varias licencias no persistentes. Esto ahorra roundtrips al servidor. También permite que el usuario explore una biblioteca de contenido mientras las licencias para varios fragmentos se van descargando en segundo plano. Eso reduce las esperas posteriores cuando el usuario decide qué ver.
Además, las licencias pueden incluir restricciones temporales avanzadas: expiración absoluta, expiración tras la primera reproducción o expiración en tiempo real. Combinando estos mecanismos con varias licencias en un mismo mensaje, se pueden cubrir casos en los que se adquieren inicialmente licencias de corta duración (LDL) mientras se navega y, más adelante, una licencia de mayor duración que permita reproducir sin cortes hasta el final del contenido.
Parada segura (Secure Stop) y control de sesiones
Otra funcionalidad introducida en PlayReady es la denominada parada segura (Secure Stop). Este recurso está pensado para que el dispositivo pueda informar con fiabilidad a un servicio de streaming de que la reproducción de un determinado fragmento ha concluido.
Este mecanismo permite un control mucho más preciso de las limitaciones de uso y la generación de informes de consumo en servicios multidispositivo. Hay dos escenarios típicos:
- Cuando la reproducción termina de forma natural (fin del contenido) o el usuario la detiene voluntariamente.
- Cuando una sesión previa se interrumpe de forma inesperada por un cierre forzado de la app o un crash del sistema.
La aplicación debe consultar al inicio o al cierre de la sesión por posibles paradas seguras pendientes y enviar los desafíos correspondientes de forma independiente a cualquier otra reproducción. Microsoft proporciona ejemplos concretos que muestran cómo implementar este flujo en una app UWP.
Uso de PlayReady en Xbox One y consideraciones de seguridad
Si se quiere aprovechar DRM de PlayReady en una aplicación UWP para Xbox One, el primer paso es obtener autorización para la cuenta del Centro de partners asociada a la app. Esta autorización puede tramitarse a través de un contacto en Microsoft. O enviando los datos de la cuenta y de la empresa a los canales designados.
Una vez concedido el permiso, hay que agregar manualmente una capacidad de dispositivo (DeviceCapability) en el manifiesto de la aplicación (Package.appxmanifest). Esto se hace editando el archivo en modo XML y añadiendo la entrada correspondiente dentro de la sección <Capabilities> para habilitar el uso de PlayReady en la consola.
En los kits de desarrollo de Xbox existe una limitación de nivel de seguridad: solo permiten reproducir contenido con nivel SL150, mientras que los dispositivos comerciales pueden manejar niveles superiores como SL2000 o SL3000. Para realizar pruebas en devkits, hay que usar contenido de prueba que solo requiera licencias SL150. Otra opción es implementar lógica para que determinadas cuentas de test obtengan licencias rebajadas para ciertos activos.
Con esta configuración, las aplicaciones pueden ofrecer en Xbox One una experiencia de streaming segura. Alineada con la que se obtiene en Windows 10/11 con HWDRM, combinando PlayReady, TEE y protección de salida según las mismas reglas de cumplimiento.
En conjunto, el ecosistema de DRM y reproducción segura en Windows 11 se apoya en una combinación muy madura de PlayReady, entorno de ejecución de confianza, control exhaustivo de salidas y gestión flexible de licencias, lo que permite a desarrolladores y plataformas de streaming ofrecer contenido en HD y UHD con altos niveles de seguridad sin renunciar a una experiencia fluida para el usuario final.
