Práticas recomendadas para políticas de licença
Esta seção descreve as práticas recomendadas para políticas de licença de programação ao usar tecnologias PlayReady.
Usando BeginDate com EndDate
Um dos muitos modelos de negócios que o PlayReady dá suporte é o aluguel de conteúdo — conteúdo que só pode ser usado por um período limitado (por exemplo, o conteúdo pode ser usado até 17h EST, 15 de outubro de 2018). Isso é feito emitindo aos clientes uma licença PlayReady com o EndDate definido como a hora e a data em que a licença deve expirar.
Um EndDate é suficiente para criar uma licença de aluguel; no entanto, é uma prática melhor também incluir um BeginDate na licença. Um BeginDate especifica que o conteúdo associado não pode ser usado antes da data especificada. A combinação de um BeginDate com o EndDate é uma impedância natural para ataques de reversão de relógio, em que os usuários backup e restauram todo o repositório de dados Do PlayReady para evitar eventos de reversão de relógio.
Considere o exemplo a seguir:
A data é 08/01/18 – o usuário adquire License1 para Content1. License1 tem EndDate=30/08/18.
A data é 01/09/18 – o usuário adquire Licença2 para Content2. License2 tem EndDate=30/09/18.
O usuário faz uma cópia do armazenamento de dados do PlayReady.
Antes de reproduzir Content1 ou Content2, o usuário define o relógio como 08/01/18, restaura a cópia do repositório de dados do PlayReady. Ambas as partes do conteúdo podem ser reproduzidas.
Agora considere o mesmo exemplo básico, mas com BeginDates nas licenças:
A data é 08/01/18 – o usuário adquire License1 para Content1. License1 tem BeginDate=08/01/18, EndDate=08/30/18.
A data é 01/09/18 – o usuário adquire License2 para Content2. License2 tem BeginDate=09/01/18, EndDate=09/30/18.
O usuário faz uma cópia do armazenamento de dados do PlayReady.
Antes de reproduzir Content1 ou Content2, o usuário define de volta o relógio para uma data antes de 08/01/18, restaura a cópia do repositório de dados do PlayReady. Somente Content1 será reproduzido.
Este exemplo mostra como o BeginDate naturalmente ajuda a reduzir a viabilidade do armazenamento de dados que está sendo restaurado para contornar a política de licença. Um usuário pode fazer mais cópias do armazenamento de dados para contornar BeginDate, mas à medida que o número de arquivos de conteúdo aumenta, o gerenciamento de todos os armazenamentos de dados necessários para contornar a política de licença aumenta proporcionalmente, tornando um ataque muito menos viável.
Em resumo, ao especificar um EndDate em uma licença do PlayReady, é melhor também incluir um BeginDate.
Definindo um valor BeginDate que funciona para o cliente
Ao adicionar um BeginDate a uma licença, é uma boa prática defini-lo um pouco no passado, para o PlayReady Clients versão 1 ou 2. O motivo é que pode haver uma pequena diferença de relógio entre o servidor que gera essa licença e o cliente que a recebe, e a intenção do Servidor é que o cliente possa usar a licença assim que o cliente a receber.
Para Clientes PlayReady 3 e superiores, o cliente envia seu valor de relógio para o Servidor de Licença ao longo da solicitação de licença, e o servidor pode definir BeginDate e outras restrições de tempo em relação a esse valor, sob a condição de que ele esteja próximo do valor de tempo conhecido pelo Servidor de Licença.
Um exemplo típico com um Cliente PlayReady versão 2 seria:
Um usuário aluga conteúdo na sexta-feira, 5 de janeiro de 2018, por volta das 20h, em um telefone Android executando um aplicativo criado no PlayReady 2.5.
O aplicativo Android inicia uma solicitação de licença para o Servidor de Licença. O relógio do telefone indica 19h56 e o relógio do Servidor de Licenças é às 20h.
O Servidor de Licença recebe a solicitação de licença, detecta que o cliente é a versão 2 e gera a licença com:
Reproduzir à direita
Hora de Início = hora do servidor local menos 5 minutos = 5 de janeiro de 2018 às 19h55
Tempo de expiração, expiração após o primeiro jogo, outras restrições corretas, como Proteções de Saída
O Servidor de Licença envia a licença de volta para o cliente.
O cliente inicia a reprodução. O relógio do telefone ainda é 19h56 e já passou do BeginDate da licença, que é 19h55, portanto, a reprodução pode realmente começar imediatamente.
Um exemplo típico com um Cliente PlayReady versão 3 seria:
Um usuário aluga conteúdo na sexta-feira, 5 de janeiro de 2018, por volta das 20h, em um computador Windows 10 que executa um aplicativo UWP.
O aplicativo UWP inicia uma solicitação de licença para o Servidor de Licença. O relógio do computador indica 19h56 e o relógio do Servidor de Licenças é às 20h.
O Servidor de Licença recebe a solicitação de licença, detecta que o Cliente PlayReady é a versão 3 e verifica o valor do relógio do cliente:
Se o valor do relógio do cliente não estiver mais distante do que o valor do relógio do Servidor de Licenças que 1 hora, prossiga e gere a licença.
Caso contrário, negue a solicitação de licença e envie uma mensagem ao aplicativo cliente para solicitar que o relógio seja definido como o valor certo.
O Servidor de Licença gera a licença com:
Reproduzir à direita
Hora de Início = Hora do cliente contida na solicitação de licença = 5 de janeiro de 2018 às 19h56
Tempo de expiração, expiração após o primeiro jogo, outras restrições corretas, como Proteções de Saída
O Servidor de Licença envia a licença de volta para o cliente.
O cliente inicia a reprodução. O relógio do computador ainda é 19h56 e é igual ou anterior ao BeginDate da licença, que é 19h56, portanto, a reprodução pode realmente começar imediatamente.
Restrições de tempo em licenças de assinatura
O PlayReady dá suporte a um modelo de negócios de assinatura no qual os usuários pagam uma taxa mensal em troca do acesso a um catálogo de conteúdo grande oferecido pelo serviço.
Nesse cenário, os Servidores de Licença do PlayReady emitem licenças folha para cada arquivo de conteúdo e uma única licença raiz. Para que o PlayReady acesse o conteúdo, sua licença folha e a licença raiz (a cadeia de licenças) são necessárias. Ambas as licenças devem conter a ação que está sendo executada no conteúdo (por exemplo, reproduzir) e ambas as licenças devem ser válidas (não expiradas e assim por diante).
Como há apenas uma licença raiz, e potencialmente centenas ou milhares de licenças folha para qualquer catálogo de conteúdo específico, as licenças folha devem incluir muito poucas restrições (se houver) e a licença raiz deve conter restrições de tempo e ser atualizada periodicamente (por exemplo, mensalmente). Quando uma assinatura está prestes a expirar, o Servidor de Licenças só precisa emitir uma licença e todo o conteúdo será atualizado com a nova data de validade efetiva. Se a política nas licenças folha contiver uma política baseada em tempo, todas as licenças folha precisarão ser emitidas novamente para impedir que o conteúdo expire, o que seria um grande requisito de desempenho para servidores.
Em resumo, se o conteúdo deve expirar usando cadeias de licenças, somente a licença raiz deverá conter a política baseada em tempo.