Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En esta sección se describen los procedimientos recomendados para programar directivas de licencia al usar tecnologías de PlayReady.
Uso de 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 a los clientes de una licencia de PlayReady, con el parámetro EndDate definido en la fecha y hora en que la licencia va a expirar.
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 realizan una copia 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 01/08/18: el usuario adquiere Licencia1 para Contenido1. 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 cambia la fecha a 08/01/18 y restaura la copia del repositorio de datos de PlayReady. Se pueden reproducir ambas partes 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 vuelve a establecer el reloj en una fecha anterior al 01/08/18 y restaura la copia del almacén de datos de PlayReady. Solo se reproducirá el Contenido1.
En este ejemplo se muestra cómo BeginDate ayuda naturalmente a reducir la probabilidad de restaurar el almacén de datos para eludir la política de licencias. Un usuario puede hacer más copias del almacén de datos para eludir la BeginDate, pero a medida que el número de archivos de contenido crece considerablemente, la administración de todos los almacenes de datos necesarios para eludir la política de licencias crece en proporción, lo que hace que un ataque sea mucho menos factible.
En resumen, al especificar un EndDate en una licencia de PlayReady, se recomienda incluir también un 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. El motivo 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.
Para 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, en 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:
Derecho de reproducción
Hora de inicio = hora local del servidor menos 5 minutos = 5 de enero de 2018 a las 7:55 p. m.
Hora de expiración, Expiración después de la primera reproducción, otras restricciones de derechos, como protecciones de salida
El servidor de licencias devuelve la licencia al cliente.
El cliente inicia la reproducción. El reloj del teléfono marca las 7:56PM y ya ha pasado la fecha de inicio de la licencia, que es a las 7:55PM, por lo que reproducción puede iniciarse 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 con 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 PC 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 se desvíe más de 1 hora respecto al valor del reloj del servidor de licencias, proceda a generar 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:
Derecho de reproducción
Hora de inicio = Hora de cliente contenida en la solicitud de licencia = 5 de enero de 2018 a las 7:56 p. m.
Hora de expiración, Expiración después de la primera reproducción, otras restricciones de derechos, como protecciones de salida
El servidor de licencias devuelve la licencia al cliente.
El cliente inicia la reproducción. El reloj del PC sigue marcando las 19:56 y es igual o posterior a la Fecha de Inicio de la licencia, que es a las 19:56, 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 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 necesita 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 expire el contenido, 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 tiempo.