Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
No uso típico, o Microsoft PlayReady protege o conteúdo fornecendo licenças para arquivos de mídia. Não há necessidade de ocultar arquivos, torná-los inacessíveis ou colocar proteção especial quando os arquivos são transmitidos de sistema para sistema. Em outras palavras, não há requisitos de sistema operacional ou mecanismos de transporte de arquivos de alta segurança necessários. No entanto, copiar um ficheiro e entregá-lo a um amigo não permitirá que esse amigo utilize o ficheiro se estiver protegido pelo PlayReady. Para usar um arquivo de mídia, os usuários precisam de uma licença. Esta licença é o principal meio de exercer controle sobre o conteúdo (o arquivo de mídia). Uma licença é concedida a um único cliente (como um media player) ou a um domínio. A licença não funcionará em outros clientes ou outros domínios.
Cada licença contém direitos e restrições, definindo exatamente como o conteúdo pode ser usado e em que condições. Por exemplo, uma licença de arquivo de música pode habilitar um "direito de reprodução", mas restringir o nível de segurança do aplicativo no qual o conteúdo pode ser reproduzido. A licença pode ser válida para o período entre 1 de outubro de 2017 e 1 de novembro de 2017. Pode haver várias licenças para um único arquivo. Um utilizador poderá aceder e utilizar o seu conteúdo, desde que uma das licenças conceda os direitos apropriados e as restrições não impeçam o acesso.
Visão geral de um serviço de vídeo de ponta a ponta
A ilustração a seguir contém uma visão de alto nível de um serviço de vídeo de ponta a ponta, incluindo o back-end do serviço à esquerda e os clientes à direita.
No lado esquerdo da ilustração você pode ver que o serviço tem alguns servidores para transmitir o vídeo (rede de distribuição de conteúdo). Existem também alguns servidores que permitem que os usuários naveguem pelo conteúdo e escolham o conteúdo que desejam reproduzir (interface do usuário). Além disso, existem alguns Servidores que permitem aos utilizadores iniciar sessão e ser autenticados, bem como pagar pelo conteúdo (autenticar, pagar). E há também um servidor de licenças PlayReady.
No lado direito da ilustração estão os clientes. Os clientes podem ser aplicativos do Windows, aplicativos de smartphone ou dispositivos específicos, como decodificadores, recetores de rede e assim por diante. Alguns desses clientes podem vir com um cliente integrado PlayReady em seus players, por exemplo, o OEM pode ter integrado PlayReady no sistema operacional ou no hardware. Outros podem vir com um cliente integrado no aplicativo que é publicado na loja de aplicativos. Existem muitas opções diferentes para os jogadores integrarem o PlayReady no lado do cliente.
Este tópico se concentrará no que o PlayReady faz por um serviço, conforme mostrado na figura a seguir.
O que o PlayReady fornece é uma maneira de um cliente solicitar licenças de um servidor, que então entrega as chaves que protegem o conteúdo de forma protegida em uma rede aberta. A segunda coisa que a PlayReady faz é entregar direitos e restrições de direitos ao cliente. Com o PlayReady, o serviço tem a capacidade de fornecer uma chave para reprodução de conteúdo, mas, por exemplo, só permite que o cliente use essa chave por dois dias em um cenário de aluguel. Assim, PlayReady fornece uma maneira de declarar direitos e restrições de direitos com a chave.
O PlayReady também fornece uma maneira de armazenar com mais segurança a chave de conteúdo no lado do cliente para que o cliente possa usar essa chave do cliente para descriptografar o conteúdo para renderização, mas não permitir salvar o conteúdo de forma clara e compartilhá-lo com outros usuários.
Para garantir que os Clientes PlayReady se comportem de maneira correta, o PlayReady requer implementações de hardware e software para seguir as Regras de Conformidade e Robustez. Essas regras regem como um cliente deve se comportar quando descriptografa ou processa conteúdo PlayReady. Eles também exigem que os clientes processem as restrições encontradas em uma licença corretamente. Assim, se um cliente receber instruções para usar a chave de conteúdo por não mais de 48 horas, o cliente deve seguir essas instruções. Essas regras são fornecidas pela Microsoft nas Regras de Conformidade e Robustez, e cabe ao desenvolvedor cliente aplicar essas regras em seus clientes.
Processo básico de encriptação e licenciamento
As etapas a seguir ilustram o processo de criptografia e licenciamento de ponta a ponta para conteúdo e como o PlayReady está envolvido no processo.
A figura a seguir contém um ativo - um arquivo de áudio/vídeo - que não foi criptografado. O método usado para criptografar o conteúdo é inteiramente de responsabilidade do provedor de conteúdo e não é fornecido como parte do PlayReady.
Para criptografar esse arquivo, o serviço precisa usar um gerador de chaves em seu criptografador de conteúdo que gera uma nova chave de conteúdo que será usada para criptografar o conteúdo. Essa chave de conteúdo será posteriormente entregue do PlayReady License Server ao cliente para permitir a descriptografia do conteúdo e a renderização para o usuário. Junto com a chave de conteúdo, que é um valor privado, os serviços de criptografia também associam um identificador de chave (KeyID) - que é um GUID - à chave de conteúdo. O KeyID é um valor público.
A chave e o KeyID são projetados no momento da criptografia e são armazenados em um sistema de gerenciamento de chaves, que normalmente é algum tipo de banco de dados. A PlayReady não fornece o sistema de gestão de chaves, pelo que cabe ao serviço ou parceiro que constrói o serviço com a emissora fornecer o sistema de gestão de chaves.
Além de armazenar a chave e o KeyID no sistema de gestão de chaves, você também precisará associar o KeyID a um empacotador, que então gera um cabeçalho. Este cabeçalho é formatado pelo serviço ou parceiro de acordo com a especificação de cabeçalho PlayReady e, depois, inserido de forma clara no cabeçalho do arquivo de conteúdo.
Neste ponto, o áudio e o vídeo serão criptografados usando o KeyID e você terá um arquivo de conteúdo criptografado pronto para ser entregue a um cliente.
Agora, o cliente pode começar a consumir o conteúdo. A primeira coisa que o cliente provavelmente vai fazer é autenticar o usuário no serviço, normalmente fornecendo um nome de login e senha, mas qualquer outro mecanismo para autenticar o usuário e o dispositivo é bom. Normalmente, um token de sessão é retornado ao cliente assim que o usuário é verificado. Observe que, qualquer que seja o mecanismo usado para autenticação do usuário, cabe inteiramente ao serviço como o usuário é autenticado; A PlayReady não fornece esta tecnologia.
Em seguida, o conteúdo é entregue ao cliente (por exemplo, o cliente começou a baixar parte do fluxo de dados que compõe o conteúdo). O cliente então começa a analisar esse conteúdo e descobre que ele é criptografado e usa uma chave que é desconhecida, mas contém um KeyID.
Nesse ponto, o cliente enviará uma solicitação de aquisição de licença para o Servidor de Licenças.
Em seguida, o Servidor de Licenças faz interface com o serviço de autenticação para verificar o usuário. Normalmente, a primeira coisa que o Servidor de Licenças faz é verificar se o cliente/usuário tem o direito para essa licença específica. E novamente, PlayReady não fornece esse layout (autenticação), nós apenas fornecemos o Servidor de Licenças. O serviço de autenticação normalmente responderá com sim ou não, ou talvez sim com restrições (por exemplo, esse usuário tem o direito para este filme em particular, mas apenas com uma qualidade inferior de vídeo porque o usuário não tem o nível de assinatura de qualidade mais alta - com base no valor que o usuário paga por mês).
Em seguida, o Servidor de Licenças solicita o valor da chave, com base no KeyID, do sistema de gerenciamento de chaves que armazena as chaves, e o sistema de gerenciamento de chaves responde a essa solicitação. Apenas para reiterar, o PlayReady não fornece os componentes do sistema de gerenciamento de chaves, portanto, haverá uma solicitação vinda do PlayReady License Server para qualquer componente que o serviço tenha construído para armazenar as chaves.
A chave é recebida pelo Servidor de Licenças e o Servidor de Licenças pode entregar a licença. A resposta de licença protegida do PlayReady inclui o valor da chave e uma lista de direitos e restrições de direitos para o cliente aplicar.
Embora esta demonstração mostre o PlayReady License Server entregando apenas uma chave, é possível que o License Server entregue uma pilha de licenças em uma resposta de licença. Várias licenças podem ser incluídas em uma transação, com cada licença fornecendo uma chave se o conteúdo estiver protegido com várias chaves ou se o serviço quiser entregar várias chaves com antecedência porque, por exemplo, o serviço sabe que o usuário vai ouvir oito faixas seguidas.
A outra peça de tecnologia que PlayReady fornece é uma maneira de armazenar a chave e os direitos no cliente, que é chamado de Loja de Licenças.
The License Store is typically called the HDS because the structure of the License Store is a *hashed data store*. There can be multiple types of License Stores on a device — one application could contain its own HDS just to ensure that one company's HDS is not in the same file as another company's HDS. It is entirely up to the client developer to make this design choice. For example, using PlayReady on Windows, Microsoft chose to have one HDS for Internet Explorer and another for Microsoft Edge per site, as well as one for each Windows Universal App.
The HDS can be stored in a persistent way, such as on the hard drive or persistent memory of the device, or it can be stored in a non-persistent way, such as in non-persistent memory. Therefore, when the License Server issues a license, it could set a property of the license indicating that the license should not be stored on the hard drive of the client, or in the case of a set top box or phone, that it should not be stored in persistent memory because, as a service, you don't want to have your licenses stored in persistent memory. In that case, just store the HDS in memory in the context of the player application, so as soon as the user closes the player application, the license and its rights will vanish.