Procedimientos recomendados para las directivas de licencia
En esta sección se describen los procedimientos recomendados para programar directivas de licencia al usar tecnologías de PlayReady.
Usar BeginDate con EndDate
Uno de los muchos modelos de negocio compatibles con PlayReady es el alquiler de contenido, contenido que solo se puede usar durante un período limitado (por ejemplo, el contenido se puede usar hasta las 5 p.m. EST, 15 de octubre de 2018). Esto se logra mediante la emisión de una licencia de PlayReady con EndDate establecido en la hora y la fecha en que expirará la licencia.
EndDate es suficiente para crear una licencia de alquiler; sin embargo, es recomendable incluir también beginDate en la licencia. BeginDate especifica que el contenido asociado no se puede usar antes de la fecha especificada. La combinación de beginDate con EndDate es una impedancia natural a los ataques de reversión del reloj, donde los usuarios copian de seguridad y restauran todo el almacén de datos de PlayReady para evitar eventos de reversión del reloj.
Considere el ejemplo siguiente:
La fecha es 08/01/18: el usuario adquiere licencia1 para Content1. License1 tiene EndDate=08/30/18.
La fecha es 09/01/18: el usuario adquiere licencia2 para Content2. License2 tiene EndDate=09/30/18.
El usuario realiza una copia del almacén de datos de PlayReady.
Antes de reproducir Content1 o Content2, el usuario establece el reloj en 08/01/18, restaura la copia del almacén de datos de PlayReady. Se pueden reproducir ambos elementos de contenido.
Ahora considere el mismo ejemplo básico, pero con BeginDates en las licencias:
La fecha es 08/01/18: el usuario adquiere License1 para Content1. License1 tiene BeginDate=08/01/18, EndDate=08/30/18.
La fecha es 09/01/18: el usuario adquiere License2 para Content2. License2 tiene BeginDate=09/01/18, EndDate=09/30/18.
El usuario realiza una copia del almacén de datos de PlayReady.
Antes de reproducir Content1 o Content2, el usuario establece el reloj en una fecha anterior al 08/01/18, restaura la copia del almacén de datos de PlayReady. Solo se reproducirá Content1.
En este ejemplo se muestra cómo BeginDate ayuda naturalmente a reducir la viabilidad del almacén de datos que se restaura para eludir la directiva de licencia. Un usuario puede hacer más copias del almacén de datos para solucionar BeginDate, pero a medida que el número de archivos de contenido crece en gran tamaño, la administración de todos los almacenes de datos necesarios para evitar la directiva de licencia crece en proporción, lo que hace que un ataque sea mucho menos factible.
En resumen, al especificar endDate en una licencia de PlayReady, se recomienda incluir también BeginDate.
Establecer un valor BeginDate que funcione para el cliente
Al agregar beginDate a una licencia, se recomienda establecerlo un poco en el pasado, para los clientes de PlayReady versión 1 o 2. La razón es que puede haber una diferencia de reloj menor entre el servidor que genera esta licencia y el cliente que lo recibe, y la intención del servidor es que el cliente pueda usar la licencia tan pronto como el cliente lo reciba.
En el caso de los clientes de PlayReady 3 y versiones posteriores, el cliente envía su valor de reloj al servidor de licencias a lo largo de la solicitud de licencia, y el servidor puede establecer BeginDate y otras restricciones de hora con respecto a ese valor, bajo la condición de que esté cerca del valor de hora conocido para el servidor de licencias.
Un ejemplo típico con una versión 2 de PlayReady Client sería:
Un usuario alquila contenido el viernes 5 de enero de 2018 alrededor de las 8 p.m., en un teléfono Android que ejecuta una aplicación basada en PlayReady 2.5.
La aplicación Android inicia una solicitud de licencia al servidor de licencias. El reloj del teléfono indica las 7:56PM y el reloj del servidor de licencias está a las 8:00 p. m.
El servidor de licencias recibe la solicitud de licencia, detecta que el cliente es la versión 2 y genera la licencia con:
Reproducir a la derecha
Hora de inicio = hora del servidor local menos 5 minutos = 5 de enero de 2018 a las 7:55 p. m.
Tiempo de expiración, Expiración después de la primera reproducción, otras restricciones correctas, como protecciones de salida
El servidor de licencias devuelve la licencia al cliente.
El cliente inicia la reproducción. El reloj del teléfono sigue siendo 7:56PM y ha pasado el BeginDate de la licencia, que es de 7:55 p.m., por lo que la reproducción realmente se puede iniciar inmediatamente.
Un ejemplo típico con una versión 3 de PlayReady Client sería:
Un usuario alquila contenido el viernes 5 de enero de 2018 alrededor de las 8 p.m., en un equipo Windows 10 que ejecuta una aplicación para UWP.
La aplicación para UWP inicia una solicitud de licencia al servidor de licencias. El reloj del equipo indica las 7:56 p.m. y el reloj del servidor de licencias está a las 8:00 p. m.
El servidor de licencias recibe la solicitud de licencia, detecta que el cliente de PlayReady es la versión 3 y comprueba el valor del reloj del cliente:
Si el valor del reloj del cliente no está más allá del valor del reloj del servidor de licencias de 1 hora, continúe y genere la licencia.
Si no es así, deniegue la solicitud de licencia y envíe un mensaje a la aplicación cliente para solicitar que el reloj se establezca en el valor correcto.
El servidor de licencias genera la licencia con:
Reproducir a la derecha
Hora de inicio = Hora de cliente contenida en la solicitud de licencia = 5 de enero de 2018 a las 7:56 p. m.
Tiempo de expiración, Expiración después de la primera reproducción, otras restricciones correctas, como protecciones de salida
El servidor de licencias devuelve la licencia al cliente.
El cliente inicia la reproducción. El reloj del equipo sigue siendo de 7:56PM y es igual o anterior a beginDate de la licencia, que es de 7:56 p.m., por lo que la reproducción puede iniciarse inmediatamente.
Restricciones de tiempo en licencias de suscripción
PlayReady admite un modelo de negocio de suscripción en el que los usuarios pagan una cuota mensual a cambio de acceso a un catálogo de contenido grande ofrecido por el servicio.
En este escenario, los servidores de licencias de PlayReady emiten licencias hoja para cada archivo de contenido y una única licencia raíz. Para que PlayReady acceda al contenido, tanto su licencia hoja como la licencia raíz (la cadena de licencias) son necesarias. Ambas licencias deben contener la acción que se realiza en el contenido (por ejemplo, reproducir) y ambas licencias deben ser válidas (no expiradas, etc.).
Dado que solo hay una licencia raíz, y potencialmente cientos o miles de licencias hoja para cualquier catálogo de contenido determinado, las licencias de hoja deben incluir muy pocas restricciones (si las hay) y la licencia raíz debe contener restricciones de tiempo y actualizarse periódicamente (por ejemplo, mensual). Cuando una suscripción está a punto de expirar, el servidor de licencias solo debe emitir una licencia y todo el contenido se actualizará con la nueva fecha de expiración efectiva. Si la directiva de las licencias hoja contiene una directiva basada en el tiempo, todas las licencias hoja deberán volver a emitirse para evitar que el contenido expire, lo que sería un requisito de rendimiento grande para los servidores.
En resumen, si se supone que el contenido expira mediante cadenas de licencias, solo la licencia raíz debe contener la directiva basada en el tiempo.