BRPI0710321A2 - administração de direitos digitais utilizando métodos de processamento confiáveis - Google Patents
administração de direitos digitais utilizando métodos de processamento confiáveis Download PDFInfo
- Publication number
- BRPI0710321A2 BRPI0710321A2 BRPI0710321-2A BRPI0710321A BRPI0710321A2 BR PI0710321 A2 BRPI0710321 A2 BR PI0710321A2 BR PI0710321 A BRPI0710321 A BR PI0710321A BR PI0710321 A2 BRPI0710321 A2 BR PI0710321A2
- Authority
- BR
- Brazil
- Prior art keywords
- drm
- integrity
- roap
- information
- protocol
- Prior art date
Links
- 238000003672 processing method Methods 0.000 title abstract description 3
- 238000000034 method Methods 0.000 claims abstract description 278
- 238000012545 processing Methods 0.000 claims abstract description 31
- 238000005728 strengthening Methods 0.000 claims abstract description 8
- 238000012795 verification Methods 0.000 claims description 51
- 230000008569 process Effects 0.000 claims description 38
- 238000003860 storage Methods 0.000 claims description 24
- 230000036541 health Effects 0.000 claims description 21
- 230000003862 health status Effects 0.000 claims description 15
- 238000004422 calculation algorithm Methods 0.000 claims description 5
- 230000008878 coupling Effects 0.000 claims 1
- 238000010168 coupling process Methods 0.000 claims 1
- 238000005859 coupling reaction Methods 0.000 claims 1
- 238000012986 modification Methods 0.000 abstract description 57
- 230000004048 modification Effects 0.000 abstract description 57
- 238000009826 distribution Methods 0.000 abstract description 5
- 230000004044 response Effects 0.000 description 43
- 101100091501 Mus musculus Ros1 gene Proteins 0.000 description 36
- 230000008901 benefit Effects 0.000 description 25
- 230000007246 mechanism Effects 0.000 description 17
- 230000001010 compromised effect Effects 0.000 description 16
- 238000010586 diagram Methods 0.000 description 10
- 230000001965 increasing effect Effects 0.000 description 10
- 238000009795 derivation Methods 0.000 description 8
- 230000003993 interaction Effects 0.000 description 8
- 230000006870 function Effects 0.000 description 6
- 238000007726 management method Methods 0.000 description 6
- 101150115391 DRM1 gene Proteins 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 5
- 230000000153 supplemental effect Effects 0.000 description 5
- 230000006399 behavior Effects 0.000 description 4
- 230000006378 damage Effects 0.000 description 4
- 230000000737 periodic effect Effects 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 101001122313 Homo sapiens Metalloendopeptidase OMA1, mitochondrial Proteins 0.000 description 3
- 102100027104 Metalloendopeptidase OMA1, mitochondrial Human genes 0.000 description 3
- 241000700605 Viruses Species 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 238000005304 joining Methods 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000007723 transport mechanism Effects 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 239000002131 composite material Substances 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 238000004806 packaging method and process Methods 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- 238000010079 rubber tapping Methods 0.000 description 2
- 238000007789 sealing Methods 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 230000009897 systematic effect Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 241000234282 Allium Species 0.000 description 1
- 235000002732 Allium cepa var. cepa Nutrition 0.000 description 1
- 101100236399 Arabidopsis thaliana MAPKKK20 gene Proteins 0.000 description 1
- 101100346155 Caenorhabditis elegans oma-2 gene Proteins 0.000 description 1
- 241000934653 Dero Species 0.000 description 1
- 101100398376 Hypocrea jecorina pki1 gene Proteins 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000007630 basic procedure Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001447 compensatory effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000002716 delivery method Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000003752 polymerase chain reaction Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Technology Law (AREA)
- Multimedia (AREA)
- Storage Device Security (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
Abstract
Administração de direitos digitais utilizando métodos de processamento confiáveis. A presente invenção descreve diversos métodos de fortalecimento da integridade de entidades, mensagens e processamento relativos à distribuição de conteúdo conforme definido pela Administração de Direitos Digitais (DRM) da Aliança Móvel Aberta (OMA). Os métodos utilizam técnicas relativas às especificações do Grupo de Computação Confiável (TCG). Uma primeira realização utiliza métodos de TCG para verificar a integridade ou a confiabilidade de software DRM e plataforma, com e sem modificações das especificações de formato de conteúdo DRM e do protocolo de obtenção de objeto de direitos (ROAP) de DRM. Uma segunda realização utiliza métodos TCG para fortalecer a integridade de mensagens ROAP, informações componentes e processamento sem alterar o prótocolo ROAP existente. Uma terceira realização utiliza métodos TCG para fortalecer a integridade do processamento, informações e mensagens ROAP com algumas alterações do protocolo ROAP existente.
Description
Administração de direitos digitais utilizando métodos de processamentoconfiáveis.
A presente invenção refere-se, de forma geral, a métodosde administração de direitos digitais (DRM) em redes de comunicação sem fio. Maisespecificamente, a presente invenção fornece métodos de aumento da segurança,integridade e confiabilidade em sistemas que operam conforme as especificações deDRM da Aliança Móvel Aberta (OMA).
Antecedentes
DRM OMA é um sistema DRM especificado pela OMA, umconsórcio de fabricantes de dispositivos e telefones móveis e provedores de serviçosmóveis. O esquema é implementado em muitos telefones móveis e destina-se a serutilizado por provedores de conteúdo móveis para adicionar DRM aos seus produtos eserviços. Foram introduzidas duas versões de DRM OMA: DRM OMA 1.0 e DRM OMA2.0.
DRM OMA 1.0 abordou esquemas de administração básicade direitos digitais para objetos de conteúdo. Desta forma, ele não forneceu proteçãoforte para o objeto de conteúdo ou o objeto de direitos. DRM OMA 1.0 especifica trêsmétodos de fornecimento: Trava Frontal (que evita que o usuário encaminhe conteúdopara outros usuários ou dispositivos), Fornecimento Combinado (um objeto de mídia eobjeto de direitos combinado) e Fornecimento Separado (objeto de mídia e objeto dedireitos separados). DRM OMA 1.0 foi projetado para manipular objetos de mídia compequeno tamanho, tais como tons de chamada ou papéis de parede para telefones.
DRM OMA 2.0 aprimora e amplia o mecanismo defornecimento de DRM OMA 1.0. Um dispositivo compatível com DRM OMA 2.0 possuium certificado individual com base em uma infra-estrutura chave pública (PKI) DRM, ouseja, cada dispositivo possui uma chave pública, uma chave privada correspondente eum certificado que verifica este fato. Cada objeto de direito (RO) é protegido paraconfidencialidade (por meio de criptografia) e integridade (por meio de assinaturasdigitais). O uso de PKI1 criptografia e verificação de integridade fortalece a segurança dosistema DRM OMA 2.0 em comparação com o sistema DRM OMA 1.0.
DRM OMA 2.0 também especifica um conjunto deprotocolos que juntos são denominados o Protocolo de Obtenção de Objeto de Direitos(ROAP) que compreende vários subprotocolos relativos a autenticação mútua e registroentre um dispositivo e um emissor de direitos (RI), ROs solicitantes, resposta aofornecimento de ROs ou recusa ao fornecimento de ROs e entrada e saída de domíniospelo dispositivo.
A seguir encontram-se algumas das entidades principaisdefinidas no DRM OMA:Ator - um ator é uma entidade externa que conduz os casosde uso.
Armazenagem remota/backup - transferência de ROs eObjetos de Conteúdo (COs) para um outro local com a intenção de transferi-los de voltapara o dispositivo original.
Fornecimento combinado - método DRM OMA 1.0 defornecimento de conteúdo protegido e RO. RO e o conteúdo protegido são fornecidosjuntos em uma única entidade, a mensagem DRM.
Confidencialidade - propriedade da informação de não serdisponibilizada nem descrita para indivíduos, entidades ou processos não autorizados.
Objeto composto - CO que contém um ou mais objetos demídia por meio de inclusão.
Dispositivo conectado - dispositivo capaz de conectar-sediretamente a um Rl utilizando um protocolo apropriado ao longo de uma interface decamada de rede/transporte de área ampla apropriada.
Conteúdo - um ou mais objetos de mídia.
Emissor de conteúdo (Cl) - entidade que disponibilizaconteúdo para o agente de DRM.
Provedor de conteúdo - entidade que é Cl ou RI.
Dispositivo - equipamento de usuário com um agente deDRM. Pode ser um dispositivo conectado ou um dispositivo não conectado, mas estadistinção é contextual e de natureza variável, pois um dispositivo conectado pode tornar-se um dispositivo não conectado ao perder a sua capacidade de conexão direta a um RI.
Revogação de dispositivo - processo de um Rl que indicaque um dispositivo não é mais confiável para a obtenção de ROs.
RO de dispositivo - RO dedicado para um dispositivoespecífico por meio da chave pública do dispositivo.
Domínio - conjunto de dispositivos que podem compartilharROs de domínios. Os dispositivos em um domínio compartilham uma chave de domínio.
Um domínio é definido e administrado por um RI.
Identificador de domínio - identificador de conjuntoexclusivo da chave de domínio.
Chave de domínio - chave cifrada simétrica com 128 bits.
Agente de DRM - entidade no dispositivo que administrapermissões para objetos de mídia no dispositivo;
Conteúdo de DRM - objetos de mídia que são consumidosconforme um conjunto de permissões em um RO.
Tempo de DRM - fonte de tempo segura inalterável pelousuário. O tempo de DRM encontra-se no formato de tempo UTC.
Integridade - propriedade dos dados de não haverem sidoalterados nem destruídos de forma não autorizada.
Domínio de união - processo de inclusão por um Rl de umdispositivo em um domínio.
Domínio de saída (desunião) - processo de exclusão por umR1 de um dispositivo não revogado de um domínio.
Objeto de mídia - um trabalho digital ou objeto composto.
Provedor de serviços de rede - entidade que fornececonectividade de rede para um dispositivo móvel.
Permissão - usos ou atividades reais permitidas pelo Rlsobre conteúdo de DRM.
Jogar - criar uma rendição perceptível transitória de umrecurso.
Conteúdo protegido - objetos de mídia que são consumidosconforme um conjunto de permissões em um RO.
Restaurar - transferir o conteúdo protegido e/ou ROs de umlocal externo de volta para o dispositivo do qual foi realizado backup.
Revogar - processo de declaração de um dispositivo oucertificado de Rl como inválido.
Emissor de direitos (RI) - entidade que emite ROs paradispositivos compatíveis com DRM OMA.
Contexto de R1 - informações que foram negociadas comum dado Rl durante o Protocolo de Registro de quatro passagens tais como ID de Rl1cadeia de certificados de RI, versão, algoritmos e outras informações. É necessário umcontexto de Rl para que um dispositivo participe com sucesso de todos os protocolos dasuíte ROAP, exceto o Protocolo de Registro.
Objeto de Direitos (RO) - coleção de permissões e outrosatributos que são ligados a conteúdo protegido.
Protocolo de Obtenção de Objetos de Direitos (ROAP) -protocolo que permite que dispositivos solicitem e obtenham ROs de um RI.
Gatilho de ROAP - documento de linhagem de marcaçãoextensível (XML) que inclui uma URL que, quando recebida pelo dispositivo, inicia ROAP.
Direitos sem Estado - ROs para os quais o dispositivo nãonecessita manter informações de estado.
Direitos com Estado - ROs para os quais o dispositivonecessita manter explicitamente informações de estado, de forma que as restrições epermissões expressas no RO possam ser executadas corretamente. RO que contémqualquer das restrições ou permissões a seguir é considerado Direito com Estado:<intervalo>, <contagem>, <contagem de tempo>, <data>, <acumulado> ou<exportação>.
Superdistribuição - mecanismo que (1) permite que umusuário distribua conteúdo protegido a outros dispositivos por meio de canaispotencialmente inseguros; e (2) permite que o usuário daquele dispositivo obtenha ROpara o conteúdo protegido superdistribuído.
Dispositivo não conectado - dispositivo que é capaz deconectar-se a um Rl por meio de um dispositivo conectado utilizando um protocoloapropriado por meio de uma tecnologia de conectividade local, tal como OBEX por IrDA(troca de objeto por infravermelho), Bluetooth ou Porta Serial Universal (USB). Umdispositivo não conectado pode sustentar Tempo de DRM.
Usuário - o usuário humano de um dispositivo. O usuárionão é necessariamente o dono do dispositivo.
A Figura 1 é uma vista geral da arquitetura funcional DRMOMA 2.0 existente 100. A arquitetura 100 consiste de um sistema DRM 102, um provedorde conteúdo 104 e um usuário 106. O sistema DRM 102 inclui um Cl 110, Rl 112,agentes DRM 114, uma loja de rede 116 e meios removíveis 118. O Cl 110 distribuiconteúdo protegido 122 e o Rl 112 distribui um RO 124. Os agentes DRM 114redistribuem o conteúdo protegido 122.
O Cl 110 é uma entidade que fornece conteúdo de DRM122. O DRM OMA define o formato do conteúdo de DRM 122 a ser fornecido paraagentes DRM 114 e a forma como o conteúdo de DRM 122 pode ser transportado do Cl110 para o agente de DRM 114 utilizando diferentes mecanismos de transporte. Opróprio Cl 110 pode realizar a embalagem real do conteúdo de DRM 122 ou podereceber conteúdo previamente embalado de alguma outra fonte.
O Rl 112 é uma entidade que atribui permissões erestrições ao conteúdo de DRM 122 e gera ROs 124. Um RO 124 é um documento XMLque expressa permissões e restrições associadas ao conteúdo de DRM 122. ROs 124regem como o conteúdo de DRM 122 pode ser utilizado; o conteúdo de DRM 122 nãopode ser utilizado sem um RO associado 124 e somente pode ser utilizado conformeespecificado pelo(s) seu(s) RO(s) associado(s). O conteúdo de DRM poderá serassociado a mais de um RO se, por exemplo, o RO possuir um prazo de vencimento (talcomo dez dias) e, após o prazo de vencimento, um novo RO for necessário para teracesso ao conteúdo.
O agente de DRM 114 é uma entidade lógica que éresponsável pela administração da execução de ponto de consumo do conteúdo de DRM122. O agente de DRM 144 incorpora um componente confiável de um dispositivo e éresponsável por executar as permissões e restrições para o conteúdo de DRM 122 nodispositivo, controlando o acesso ao conteúdo de DRM no dispositivo (que somente podeser acessado por meio do agente de DRM 114) e assim por diante.
O conteúdo de DRM 122 é embalado para protegê-lo contraacesso não autorizado antes que seja fornecido. O Cl 110 fornece o conteúdo de DRM122 e o Rl 112 gera o RO 124. O Cl 110 e o Rl 112 incorporam papéis lógicos, e nãoentidades físicas, no sistema 102. Em um desdobramento, por exemplo, os proprietáriosde conteúdo podem embalar previamente conteúdo de DRM, que é distribuído emseguida por um distribuidor de conteúdo que age como Cl e RI.
Um RO 124 rege como pode ser utilizado o conteúdo deDRM 122. O conteúdo de DRM 122 não pode ser utilizado sem um RO associado 124 esomente pode ser utilizado conforme as permissões e restrições especificadas no RO124. O DRM OMA realiza uma separação lógica de conteúdo de DRM de ROs. Oconteúdo de DRM e ROs pode ser solicitado separadamente ou em conjunto e elespodem ser fornecidos separadamente ou ao mesmo tempo. Quando forem fornecidos aomesmo tempo, eles são tipicamente fornecidos pelo Cl 110, com o RO e o conteúdoembutidos em um Formato de Conteúdo de DRM (DCF).
Um RO 124 é unido criptograficamente a um agente deDRM específico 114 por um conjunto de chaves, de tal forma que um agente de DRMespecífico 114 possa ter acesso a ele. O conteúdo de DRM 122 somente pode seracessado com um RO válido 124, de tal forma que o conteúdo 122 possa ser livrementedistribuído ou superdistribuído.
O DRM OMA 2.0 permite a união de um RO a um grupo deagentes de DRM. Esse grupo é denominado domínio. Conteúdo de DRM e ROsdistribuídos para um domínio podem ser compartilhados e acessado offline por todos osagentes de DRM pertencentes àquele domínio. Um usuário pode adquirir, por exemplo,conteúdo de DRM para uso no seu telefone e no seu PDA.
As especificações de DRM OMA definem o formato e omecanismo de proteção para conteúdo de DRM (ou DCF), o formato (linguagem deexpressão de direitos (REL)) e o mecanismo de proteção para o RO e o modelo desegurança para administração de chaves de criptografia. As especificações de DRMOMA também definem como o conteúdo de DRM e os ROs podem ser transportadospara dispositivos utilizando uma série de mecanismos de transporte, que incluem pull(HTTP pull, download de OMA), push (WAP push, MMS) e streaming. As especificaçõesde DRM OMA, entretanto, não abordam nenhuma interação entre entidades de rede, talcomo entre o Cl 110 e o Rl 112.
A seguir encontra-se uma relação não exaustiva dos casosde uso cobertos pelas especificações de DRM OMA 2.0.1. Modelo pull básico:
Um usuário seleciona conteúdo para download navegandoem um Web site e confirma as condições da compra. O Cl 110 identifica e protege oconteúdo 122, ou seja, embala-o. O conteúdo 122 é criptografado utilizando a chave decriptografia de conteúdo (CEK). As capacidades do dispositivo podem ser detectadasutilizando suporte do tipo MIME anunciado etc. O Rl 112 gera um RO 124 para oconteúdo 122 e o agente de DRM alvo 114. O RO 124 inclui as permissões para atransação de conteúdo e o CEK. Por fim, o RO 124 é protegido criptograficamente pormeio de criptografia (utilizando uma chave de criptografia RO1 ou REK) e assinaturasdigitais e é unido apenas ao agente de DRM alvo 114. O conteúdo de DRM 122 e o ROprotegido 124 são fornecidos em seguida ao agente de DRM 114.
2. Push de conteúdo de DRM:
Um modelo de distribuição alternativo é realizar push doconteúdo diretamente para um dispositivo utilizando Serviço de Mensagens Multimídia(MMS)1 WAP push ou um método similar sem um processo de descoberta anterior.Existem duas variações neste caso de uso.
2A. Push de conteúdo:
O Cl 110 e/ou o Rl 112 podem possuir um certoconhecimento anterior de um usuário e um agente de DRM específico 114, de tal formaque o conteúdo 122 e um RO 124 possam ser formatados e embalados parafornecimento.
2B. Pull iniciado por push:
Neste caso, o Cl 110 e/ou o Rl 112 podem não possuirnenhum conhecimento anterior sobre o usuário ou o seu agente de DRM 114, maspodem ainda desejar fornecer conteúdo, por exemplo, para permitir que o usuáriopreveja o conteúdo 122 para incentivá-los a adquirir o conteúdo. Em vez de realizar pushdo conteúdo de DRM 122 diretamente para um usuário, pode ser enviado um link para oconteúdo ou um link para a amostra do conteúdo. Seguir o link levará o usuário para umlocal específico e, em seguida, o procedimento continua como no modelo pull básico.
3. Streaming de conteúdo DRM:
Os dois casos de push e de pull básico consideram que oconteúdo é embalado e fornecido integralmente. Alternativamente, o conteúdo pode serreunido em pacotes e fornecido na forma de fluxo. Neste caso, o próprio fluxo éprotegido (criptografado). O formato exato da criptografia foi deixado fora do escopo deDRM OMA e pode ser selecionado a partir de padrões de criptografia existentes. Osfluxos podem ser protegidos com esquemas de criptografia que são diferentes dosespecificados por OMA para download, para abordar possível perda de pacotes etc.Após a criptografia do fluxo, entretanto, o acesso ao fluxo pode ser controlado por meiodo mesmo procedimento descrito anteriormente para conteúdo discreto. É gerado umRO, a chave de criptografia de fluxo é colocada no RO da mesma forma que seria umCEK e o RO é unido criptograficamente a um agente de DRM.
4. Domínios:
Os domínios são uma característica opcional e podem nãoser sustentados por todos os Ris. Os domínios expandem o modelo básico do DRM OMA2.0 em que os ROs e o CEK são unidos a um agente de DRM específico 114 e permitema união por um Rl 112 de direitos e CEKs a um grupo de agentes de DRM no lugar deapenas um único agente de DRM. Os usuários podem compartilhar em seguida oconteúdo de DRM 122 offline entre todos os agentes de DRM pertencentes ao mesmodomínio. Um RM12 pode utilizar o conceito de domínio para fornecer serviços novos,tais como permitir que os usuários tenham acesso a conteúdo de DRM 122 de diversosdispositivos que eles possuam ou forneçam suporte para dispositivos não conectados emque os usuários adquirem o conteúdo de DRM e direitos por meio de um dispositivo (talcomo um PC) para uso posterior em um outro dispositivo (tal como um aparelho portátil).
5. Back-up:
O conteúdo de DRM 122 pode ser armazenado em meiosremovíveis 118, em uma loja de rede 116 ou em alguma outra forma de armazenagem.O conteúdo de DRM 122 é armazenado em forma criptografada e somente pode teracesso por um agente de DRM alvo específico 114 utilizando um RO associado 124.ROs 124 podem ser armazenados para propósitos de backup caso apenas o ROsomente contenha permissões sem estado. O modelo de segurança garante que o RO124 seja protegido e somente possa ser acessado pelo agente de DRM pretendido 114,mesmo se o RO 124 for armazenado fora de dispositivo. Algumas permissõesnecessitam de manutenção de estado pelo agente de DRM 114, tal como umaquantidade limitada de jogos. Esses ROs não podem ser armazenados fora dodispositivo, pois isso poderá resultar em perda da informação de estado.
6. Superdistribuição:
O conteúdo de DRM 122 pode ser copiado e transferidopara outros agentes de DRM 114, tais como um usuário enviando o conteúdo de DRM122 para um amigo. O amigo, a fim de ter acesso ao conteúdo 122, é levado para o Rl112 por meio de um link no pacote de conteúdo de DRM para obter um RO 124.
7. Exportação (para sistemas não DRM OMA):
O conteúdo de DRM 122 pode ser exportado para outrossistemas DRM, para uso em dispositivos que não são compatíveis com DRM OMA1 massustentam algum outro mecanismo de DRM. A arquitetura de DRM OMA permite que RIs112, caso desejem, expressem permissão para agentes de DRM 114 para realizarconversões para outros sistemas DRM específicos, possivelmente conforme especificadopelo outro sistema de DRM. O Rl 112 pode limitar a exportação apenas a sistemas deDRM externos específicos.
8. Suporte de dispositivos desconectados:
O DRM OMA permite que um dispositivo conectado ajacomo intermediário para assistir um dispositivo desconectado para comprar e baixarconteúdo 122 e ROs 124. Um usuário pode possuir, por exemplo, um dispositivo portátilcompatível com DRM OMA (um dispositivo desconectado) que não possui conectividadede rede e um dispositivo móvel compatível com DRM OMA (um dispositivo conectado)que possui conectividade de rede. Após o uso do dispositivo conectado para navegar ecomprar o conteúdo de DRM 122 e baixar o conteúdo de DRM 122 para o dispositivoconectado, o usuário pode desejar executar o conteúdo de DRM 122 em seguida nodispositivo desconectado. Neste caso, o agente de DRM 114 no dispositivo conectadosolicita e baixa um RO de domínio 124 do Rl 112.
O agente de DRM 114 no dispositivo conectado embute emseguida o RO de domínio 124 no DCF. O DCF pode ser transferido em seguida para odispositivo desconectado utilizando um protocolo apropriado por meio de uma tecnologiade conectividade local, tal como Bluetooth ou USB. O dispositivo conectado e odispositivo desconectado devem ser compatíveis com DRM OMA para sustentar estafuncionalidade. Além disso, o dispositivo desconectado deve pertencer ao mesmodomínio do dispositivo conectado.
Segurança e confiança:
A seguir, encontra-se uma vista geral das medidas desegurança e confiança DRM OMA 2.0. Geralmente, qualquer solução de DRM necessitaatender duas exigências de segurança: (1) o conteúdo protegido somente deve seracessado por agentes de DRM autorizados e adequadamente autenticados; e (2) aspermissões sobre o conteúdo protegido devem ser honradas por todos os agentes deDRM. A execução das permissões e restrições associadas ao conteúdo de DRM são aprincipal preocupação das medidas de segurança e confiança de qualquer esquema deDRM. O acesso não autorizado a conteúdo de DRM além do que é estipulado pelo ROassociado e a criação de cópias ilegais e redistribuição de conteúdo de DRM constituemas principais ameaças a qualquer sistema DRM.
O sistema DRM OMA fornece os meios de distribuiçãosegura e administração de conteúdo protegido no ambiente OMA e atende às exigênciasespecificadas acima. O DRM OMA executa o uso e proteção do conteúdo e os ROs noponto de consumo utilizando um agente de DRM que garanta o uso protegido deconteúdo sob as restrições dos ROs.
As etapas básicas de distribuição de conteúdo de DRMpodem ser resumidas conforme segue:1. Embalagem de conteúdo. O conteúdo é embaladoem um recipiente de conteúdo seguro (DCF). O conteúdo de DRM é criptografado comuma chave de criptografia de conteúdo simétrico (CEK). O conteúdo pode ser embaladopreviamente, ou seja, a embalagem de conteúdo não necessita acontecer no caminho. Omesmo CEK não é utilizado para todos os casos de um conteúdo, embora não seja umaexigência no DRM OMA.
2. Autenticação de agente de DRM. Todos os agentesde DRM possuem um par de chave pública/privada exclusivo e um certificado! Ocertificado inclui informações adicionais tais como o fabricante do dispositivo, tipo dedispositivo, versão de software, números de série etc. Isso permite que os Cls e os Rlsautentiquem seguramente um agente de DRM.
3. Geração de RO. O RO contém o CEK, que garanteque o conteúdo de DRM não possa ser utilizado sem um RO associado. ROs sãocompostos de permissões (tais como tocar, exibir e executar) e restrições (tais comotocar por um mês, exibir dez vezes). ROs podem também incluir restrições quenecessitam da presença de um certo usuário (tais como determinadas por umaidentidade de usuário) quando o conteúdo é acessado. Estas permissões e restrições,junto com outras informações incorporadas no RO (tais como informações de direitosautorais), podem ser apresentadas ao usuário.
4. Proteção de RO. Antes de fornecer o RO, partessensíveis do RO (tais como o CEK) são criptografadas com uma chave de criptografia dedireitos (REK) e o RO é unido criptograficamente em seguida ao agente de DRM alvo.Isso garante que somente o agente de DRM alvo pode ter acesso ao RO, CEK econteúdo de DRM. Além disso, o Rl assina digitalmente o RO. O RO também rege oacesso ao conteúdo de DRM por meio de inclusão do CEK. A Linguagem de Expressãode Direitos de DRM OMA (REL) especifica a sintaxe (XML) e a semântica de permissõese restrições que regem o uso do conteúdo de DRM. Um RO possui o seu próprio tipo deconteúdo de MIME.
5. Fornecimento. O RO e o DCF podem agora serfornecidos para o agente de DRM alvo. Como os dois itens são inerentemente seguros,eles podem ser fornecidos utilizando qualquer mecanismo de transporte (tal comoHTTP/WSP, WAP Push, MMS). O RO e o DCF podem ser fornecidos juntos, porexemplo, em uma mensagem de múltiplas partes de MIME ou podem ser fornecidosseparadamente.
O modelo de confiança de DRM OMA para os ROs ébaseado na infra-estrutura de chave pública (PKI), por meio do quê existem grupos dediretores, verificadores e uma ou mais autoridades de autenticação reconhecidas e deconfiança de ambos. Uma única entidade pode desempenhar o papel de um diretor e umverificador, dependendo das necessidades do contexto e das soluções selecionadas. OPKI permite que um verificador autentique a identidade e outros atributos de um diretorquando se comunicam ao longo de uma rede aberta e não segura. Nesse sistema,tipicamente, o verificador não necessita manter nenhuma informação sensível sobre osdiretores com os quais interage, para fins de autenticação. Além disso, a Autoridade deCertificação (CA) não está envolvida diretamente em transações entre o diretor e overificador. Um Rl confia no comportamento correto de um agente de DRM caso ocertificado do agente de DRM possa ser verificado pelo Rl e não tenha sido revogado. Deforma similar, um agente de DRM confia no comportamento correto de um Rl caso ocertificado do Rl possa ser verificado pelo agente de DRM e não tenha sido revogado.
As entidades primárias do PKI conforme aplicado ao DRMOMA são os CAs, dispositivos e Ris. Os protocolos de transferência de chave eautenticação do DRM OMA necessitam que o Rl seja capaz de autenticar o dispositivo eo dispositivo seja capaz de autenticar o RI. Essa autenticação mútua é realizada peloROAP.
Além disso, considera-se que os dispositivos sejamprovisionados (seja no momento da fabricação ou posteriormente) com chaves públicas eprivadas de dispositivos e certificados associados assinados por um CA apropriado. Combase nas preferências de certificados expressas pelo RI, o dispositivo necessita fornecerum certificado apropriado. Necessita-se que os dispositivos armazenem as chavesprivadas em armazenagem local com proteção de confidencialidade e integridade.
Os Rls também são equipados com chaves públicas,chaves privadas e certificados assinados por um CA. A cadeia de certificado (uma cadeiade diversos certificados que incluem o certificado do dono da chave pública assinado porum CA e zero ou mais certificados adicionais de CAs assinados por outros CAs) éapresentada ao dispositivo no momento do protocolo de autenticação para validação dacadeia de certificado confiável.
Observa-se que podem existir diversos CAs no sistemaDRM. O protocolo ROAP necessita que o CA que assina os certificados Rl conduza umamensagem de resposta de Protocolo de Situação de Certificado Online (OCSP) para usodurante a execução do protocolo. Também se necessita que os CAs definam as políticasde certificado apropriadas para reger o uso dos certificados emitidos.
O abaixo descreve os aspectos principais de segurança deDRM OMA.
1. Confidencialidade, que garante que os dados nãosejam acessíveis por uma parte não autorizada. Conforme indicado acima, o conteúdoprotegido somente deve ser acessível por agentes de DRM autorizados eadequadamente autenticados. Para atingir este objetivo, o conteúdo protegido écriptografado. As chaves de criptografia são exclusivas para cada objeto de mídia e ROsconduzem as chaves e criptografia embaladas em chaves apenas acessíveis pelospacientes pretendidos.
2. Autenticação, que é o processo por meio do qualuma parte identifica-se para uma outra parte. No DRM OMA1 autenticação de Rl e agentede DRM mútua é atingida no Protocolo de Registro de quatro passagens, Protocolo deObtenção de RO de duas passagens e protocolo de união a domínio de duas passagens.Dependendo do protocolo utilizado e da mensagem enviada, atinge-se a autenticaçãopor meio de assinaturas digitais sobre nonces ou sobre marcas de tempo. O Protocolo deObtenção de RO de uma passagem atinge autenticação de Rl por meio da assinaturadigital em uma marca de tempo. Ele não autentica o agente de DRM para o Rl mas,devido ao teor protegido que é embalado com a chave pública do paciente, aautenticação é realizada indiretamente por meio de união de chaves. O Protocolo deSaída de Domínio de duas passagens autentica o agente de DRM para o Rl por meio daassinatura digital em uma marca de tempo. Ele não autentica o Rl para o agente deDRM. É necessário que Rls sejam autenticados para o agente de DRM durante ofornecimento de ROs. Isso fornece algum nível de garantia sobre a autenticidade do RI.
3. Proteção de Integridade de Dados garante acapacidade de detecção de modificação não autorizada de dados. No DRM OMA,proteção da integridade de dados, quando aplicável, é atingida por meio de assinaturasdigitais em mensagens ROAP e ROs.
4. Confirmação de chaves garante ao receptor de umamensagem que contém uma chave protegida que o remetente da mensagem conhece ovalor chave. No contexto de DRM, esta propriedade protege contra a reemissão nãoautorizada de ROs de um Rl por outro. No sistema DRM OMA, atinge-se confirmação dechave por meio de um controle de acesso a meios (MAC) sobre a chave protegida e aidentidade da parte remetente utilizando partes da chave protegida da chave de MAC.
O Rl necessita confiar no agente de DRM, tanto em termosde comportamento correto quanto em termos de implementação segura. No DRM OMA,cada agente de DRM é equipado com um par de chaves exclusivo e um certificadoassociado, que identifica o agente de DRM e certifica a união entre o agente e este parde chaves. Isso permite que os Rls autentiquem de forma segura o agente de DRMutilizando procedimentos de PKI padrão.
As informações no certificado permitem que o Rl apliqueuma política com base nas suas regras comerciais, o valor do seu conteúdo etc. Um Rlpode confiar, por exemplo, em certos fabricantes ou pode manter uma lista atualizada deagentes de DRM que são conhecidamente confiáveis ou não confiáveis conforme algunscritérios definidos pelo RI.O Formato de Conteúdo de DRM (DCF) é um pacote deconteúdo seguro para conteúdo criptografado, com o seu próprio tipo de conteúdo MIME.Além do conteúdo criptografado, ele contém informações adicionais tais como descriçãode conteúdo (tipo de conteúdo original, fornecedor, versão etc.), identificador de recursosuniformes de Rl (URI) (um local em que pode ser obtido um RO) e assim por diante.Estas informações adicionais não são criptografadas e podem ser apresentadas para ousuário antes da recuperação de um RO. O CEK necessário para destravar o conteúdode DRM no interior de um DCF está contido no RO. Não é possível, portanto, ter acessoa conteúdo de DRM sem o RO e o conteúdo de DRM somente pode ser utilizadoconforme especificado no RO. DRM OMA inclui um mecanismo que permite que umagente de DRM verifique a integridade de um DCF, protegendo-o contra modificação doconteúdo por uma entidade não autorizada.
O sistema DRM OMA assume a presença de tempo DRMno agente de DRM. Como os usuários não são capazes de alterar o tempo de DRM, édefinido um mecanismo por meio do qual o tempo de DRM pode ser sincronizado com otempo mantido por um dispositivo de resposta de OCSP. Algumas restrições (tais comorestrições de tempo absolutas), bem como alguns aspectos do protocolo de fornecimentopara ROs, dependem do fato do agente de DRM possuir uma fonte de tempo segura. Otempo de DRM no contexto das especificações de DRM OMA indica um tempo preciso,bem como um valor de tempo que não pode ser alterado por usuários. As especificaçõesde DRM OMA fornecem mecanismos para que o tempo de DRM seja sincronizadoquando necessário, tal como se o tempo de DRM for perdido após uma queda de energiaprolongada. Alguns dispositivos desconectados com capacidade limitada podem nãosustentar um relógio em tempo real e, portanto, não sustentar tempo de DRM.Dispositivos conectados, entretanto, devem sustentar tempo de DRM.
O DRM OMA protege contra ataques à proteção contrareprodução de RO. Um exemplo de ataque de reprodução de RO ocorre quando umintermediário intercepta um RO com uma quantidade limitada de execuções durante ofornecimento ao agente de DRM. Quando os direitos expirarem sobre o agente de DRM,o RO interceptado poderá ser novamente fornecido (executado) a partir do intermediário.O DRM OMA evita a ocorrência deste e de ataques similares.
O sistema DRM OMA fornece segurança de camadas deaplicação por meio da utilização dos mecanismos de segurança relacionados acima.Desta forma, ele não depende da segurança de camadas de transporte nem a assume.
O ROAP desempenha um papel central no DRM OMA 2.ao permitir a troca segura com base em autenticação de informações referentes a ROs.ROAP é o nome comum de uma suíte de protocolos de segurança de DRM entre um Rle um agente de DRM em um dispositivo. A suíte de protocolo contém váriossubprotocolos:
1. O protocolo de quatro passagens para registro deum dispositivo com um RL1 conforme exibido na Figura 2.
2. O protocolo de obtenção de RO de duas passagensinclui a solicitação e o fornecimento dé um RO, conforme exibido na Figura 3.
3. O protocolo de obtenção de RO de uma passagemrefere-se ao fornecimento de um RO de um Rl para um dispositivo (tal como envio demensagens/push), conforme exibido na Figura 4.
4. O protocolo de união a domínio de duas passagenspara que um dispositivo una-se um domínio, conforme exibido na Figura 5.
5. O protocolo de saída de domínio de duas passagenspara que um dispositivo deixe um domínio, conforme exibido na Figura 6.
A Figura 2 é um diagrama de fluxo do protocolo de registrode quatro passagens 200. O protocolo 200 utiliza um dispositivo 202, um Rl 204 e umdispositivo de reação de OCSP 206. O dispositivo 202 inicia (possivelmente medianterecebimento de um acionador de ROAP) o contato com o Rl 204 por meio do envio deuma mensagem Alô Dispositivo (etapa 210), que contém informações tais como a ID dodispositivo (hash de um certificado de dispositivo que o Rl 204 pode verificarposteriormente com o dispositivo de resposta de OCSP 206) e outras informações. ATabela 1 ilustra os principais componentes da mensagem Alô Dispositivo. Nenhuma dasinformações da mensagem Alô Dispositivo tem sua integridade protegida, ou seja, nãohá assinatura para a mensagem.
Tabela 1
Formato da Mensagem Alô Dispositivo
<table>table see original document page 14</column></row><table><table>table see original document page 15</column></row><table>
O Rl 204, em resposta à mensagem Alô Dispositivo (etapa210), envia uma mensagem Alô Rl para o dispositivo 202 (etapa 212), que contéminformações tais como as credenciais de certificado de Rl (na forma de uma ID de RI),alguns números de sessão e nonces relacionados a sessões (propósito anti-resposta) eoutras informações opcionais tais como as informações sobre a cadeia de confiançasobre o dispositivo reconhecido pelo Rl 204. A Tabela 2 ilustra o formato da mensagemAlô RI. Observa-se que nenhuma das informações da mensagem Alô Rl é protegidaintegralmente.
Tabela 2
<table>table see original document page 15</column></row><table><table>table see original document page 16</column></row><table>
Mediante verificação bem sucedida das informaçõescontidas na mensagem Alô Rl1. o dispositivo 202 envia uma mensagem de Solicitação deRegistro (etapa 214) que inclui informações obrigatórias tais como o tempo desolicitação, ID de sessão e uma assinatura e informação opcional tal como uma cadeiade certificado, âncora de autoridade Rl confiável, extensões etc. A Tabela 3 ilustra oformato da mensagem de Solicitação de Registro. A mensagem de Solicitação deRegistro contém, na sua extremidade final, uma assinatura digital de todas asmensagens trocadas entre o dispositivo 202 e o RI 204 até o campo de Assinatura namensagem de Solicitação de Registro, ou seja, toda a mensagem Alô Dispositivo, toda amensagem Alô Rl e os campos da mensagem de Solicitação de Registro até o campo deAssinatura, exclusive. Esta assinatura digital é elaborada utilizando a chave privada dodispositivo. A inclusão da assinatura digital fornece alguma proteção de integridade dasmensagens ROAP associadas.
Tabela 3
Formato da Mensagem de Solicitação de Registro
<table>table see original document page 17</column></row><table>
A menos que o dispositivo 202 indique, por meio deinformações nas Extensões, que a verificação de OCSP não é necessária nemsustentada, o Rl 204 envia uma mensagem de Solicitação de OCSP para o Dispositivode Resposta de OCSP 206 (etapa 216) para solicitar a verificação das informaçõesfornecidas para o Rl 204 pelo dispositivo 202. O Dispositivo de Resposta de OCSP 206busca a informação na mensagem de solicitação para tentar verificar a informação edevolve uma mensagem de Resposta de OCSP (etapa 218) contendo os resultados dasolicitação.
O Rl 204 envia uma mensagem de Resposta de Registropara o dispositivo 202 (etapa 220), que inclui uma indicação se o registro foi bem ou malsucedido e outras informações. A Tabela 4 ilustra o formato da mensagem de Respostade Registro. A mensagem de Resposta de Registro contém, na sua extremidade, umhash SHA-1 da mensagem de Solicitação de Registro e da mensagem de Resposta deRegistro (até o campo de Assinatura, exclusive). Esta assinatura digital é elaboradautilizando a chave privada do RI. A inclusão da assinatura digital fornece algumaproteção à integridade das mensagens de ROAP associadas. Observa-se que, embora ohash SHA-1 seja utilizado para a assinatura digital, qualquer algoritmo apropriado paraaplicação da assinatura digital poderá ser utilizado.
Tabela 4
Formato da Mensagem de Resposta de Registro
<table>table see original document page 18</column></row><table><table>table see original document page 19</column></row><table>
A Figura 3 é um diagrama de fluxo do Protocolo de
Obtenção de RO de duas passagens 300. O protocolo 300 utiliza o dispositivo 202 e o Rl204 e opera após o término do Protocolo de Registro de quatro passagens 200 e orecebimento pelo dispositivo 202 de uma cadeia de certificados válida sobre o Rl 204. Oprotocolo 300 é utilizado pelo dispositivo 202 para solicitar um RO do Rl 204. Odispositivo 202 envia uma mensagem de Solicitação de RO para o Rl 204 para solicitar oRO (etapa 310). A Tabela 5 exibe o formato da mensagem de Solicitação de RO. Amensagem de Solicitação de RO contém uma assinatura digital da mensagem (excluindoo campo de assinatura).
Tabela 5
Formato da Mensagem de Solicitação de RO<table>table see original document page 20</column></row><table>
O Rl 204, em resposta à mensagem de solicitação, enviauma mensagem de Resposta de RO para o dispositivo 202 (etapa 312). A mensagem deresposta de RO inclui um RO ou inclui uma indicação que um RO não será enviado.
A Tabela 6 exibe o formato da mensagem de resposta deRO. A mensagem de Resposta de RO1 em um caso de estado bem sucedido, contémuma assinatura digital que é um hash SHA-1 da mensagem de Solicitação de RO e amensagem de Resposta de RO que exclui o campo de Assinatura.
Tabela 6
Formato da Mensagem de Resposta de RO
<table>table see original document page 20</column></row><table><table>table see original document page 21</column></row><table>
A Figura 4 é um diagrama de fluxo do Protocolo deObtenção de RO de uma passagem 400. O protocolo 400 utiliza o dispositivo 202 e o Rl204. No protocolo 400, o Rl 204 envia unilateralmente, sem solicitação pelo dispositivo202, uma mensagem de resposta de RO para o dispositivo 202 (etapa 410) que inclui oRO. O protocolo 400 aplica-se aos casos de uso de push, por exemplo. A Tabela 7 exibeo formato da mensagem de Solicitação de RO.
Tabela 7Formato da Mensagem de Resposta de RO
<table>table see original document page 22</column></row><table>
A Figura 5 é um diagrama de fluxo do Protocolo de união adomínio de duas passagens 500. O protocolo 500 utiliza o dispositivo 202 e o Rl 204.Quando o dispositivo 202 desejar unir-se a um domínio, o dispositivo 202 envia umamensagem de Solicitação de União a Domínio para o Rl 204 (etapa 510). O Rl 204 avaliaa solicitação e envia uma mensagem de Resposta de Domínio de Junção para odispositivo 202 (etapa 512). A Tabela 8 exibe o formato da mensagem de Solicitação deUnião a Domínio e a Tabela 9 exibe o formato da mensagem de Resposta de União aDomínio.
Tabela 8
Formato da Mensagem de Solicitação de União a Domínio
<table>table see original document page 22</column></row><table><table>table see original document page 23</column></row><table>
Tabela 9
Formato da Mensagem de Resposta de União a Domínio
<table>table see original document page 23</column></row><table><table>table see original document page 24</column></row><table><table>table see original document page 25</column></row><table>
A Figura 6 é um diagrama de fluxo do Protocolo de Saída de
Domínio de duas passagens 600. O protocolo 600 utiliza o dispositivo 202 e o Rl 204.Quando o dispositivo 202 desejar deixar um domínio, o dispositivo 202 envia umamensagem de Solicitação de Saída de Domínio para o Rl 204 (etapa 610). O Rl 204avalia a solicitação e envia uma mensagem de Resposta de Saída de Domínio para odispositivo 202 (etapa 612). A Tabela 10 exibe o formato da mensagem de Solicitação deSaída de Domínio e a Tabela 11 exibe o formato da mensagem de Resposta de Saída deDomínio.
Tabela 10
Formato da Mensagem de Solicitação de Saída de Domínio
<table>table see original document page 25</column></row><table><table>table see original document page 26</column></row><table>
Tabela 11
Formato da Mensagem de Resposta de Saída de Domínio
<table>table see original document page 26</column></row><table>
Todos os protocolos incluídos na suíte ROAP, exceto oProtocolo de Obtenção de RO de uma passagem, podem ser iniciados utilizando umacionador de ROAP. O dispositivo 202 pode também iniciar os protocolos unilateralmentecomo resultado de interações de usuários. O Rl 204 gera e envia o acionador de ROAPpara o dispositivo 202, para acionar uma troca de protocolos de ROAP. Alternativamente,o Rl 204 pode delegar a geração de acionadores de ROAP para outros sistemas pormeio de fornecimento das informações necessárias (tais como identificadores de RO eidentificadores de domínios) para esses sistemas. Um acionador de ROAP (seja elegerado direta ou indiretamente pelo Rl 204) pode também ser transmitido para odispositivo 202 por outros sistemas (tal como por um Cl).
Quando o dispositivo 202 receber o acionador de ROAP, eleinicia a troca de protocolos de ROAP o mais breve possível. Deve haver sido obtido umconsentimento de usuário apropriado antes de iniciar qualquer protocolo de ROAP comoresultado do recebimento de um acionador de ROAP. Como o ROAP compreendediversos protocolos, o acionador de ROAP inclui uma indicação do protocolo real (talcomo Registro, Obtenção de RO1 Domínio de União ou Saída de Domínio) a ser iniciadapelo dispositivo 202.
As mensagens de ROAP e como as mensagens sãomanipuladas pelos protocolos fornecem não apenas os ROs e o seu processamentoassociado, mas também funções de segurança em volta dos ROs no DRM OMA 2.0.Mais especificamente, os aspectos de segurança e confiança a seguir são abordadospelos protocolos de ROAP:
1. Autenticação mútua entre o Rl e o dispositivo;
2. combate a ataques de retransmissão utilizandononces em várias mensagens;
3. proteção da integridade das mensagens de ROAP oupartes das mensagens de ROAP; e
4. verificação de Tempo de DRM seguro nasmensagens de ROAP ou partes das mensagens de ROAP.
Métodos de computação confiáveis:
Recentemente, métodos de computação confiáveis forammencionados na literatura e em produtos, a maior parte sob o guarda-chuva técnico doGrupo de Computação Confiável (TCG). As tecnologias TCG fornecem métodos pormeio dos quais entidades de computação podem estabelecer confiança para si própriase para outros dispositivos utilizando uma cadeia de confiança, de forma que oprocessamento ou a computação nesses dispositivos pode ser:
1. determinado pela confiabilidade da plataforma evários componentes de hardware (HW) e software (SW);
2. validado apenas quando o nível de confiançaapropriado é estabelecido e pode ser validado para si próprio e para outros mediantesolicitações externas; e
3. partes externas podem realizar determinações edecisões sobre a troca de informações e processamento com outros dispositivos e combase nos níveis de confiança manifestados desses dispositivos alvo.
O TCG define um módulo de processamento centraldenominado Módulo de Processamento Confiável (TPM) que possui as características aseguir:
1. proteção física do módulo e suas interfaces;
2. espaços de armazenagem voláteis e não voláteisprotegidos;
3. funções criptográficas protegidas no interior domódulo que podem realizar criptografia e sinalização digital;
4. uso de Registros de Configuração de Plataformas(PCR) que capturem consecutivamente o "estado" da plataforma e os seus componentesde SW por meio de extensão de hash;
5. existência de Chaves de Endosso (EK) específicasde dispositivo e seguras, com base em PKI que serve de raiz da autenticação dodispositivo, mas não de formas diretas. O EK nunca é exposto para fora, mas os seusaliados, denominados Chaves de Identidade de Confirmação (AIKs), são utilizados parasinalizar os valores de medição da integridade da plataforma; e
6. Uso de "vedação" de dados, em conjunto comvalores de PCR assinados por AIKs, em "bolhas" de memória, de tal forma que os dadospossam ser acessados ou extraídos somente quando a integridade de SW ou plataforma(conforme medido e verificado pelos valores de PCR coincidentes do TPM e da bolha dememória vedada) é verificada.
Métodos de computação confiáveis foram inspecionados,especialmente no contexto de dispositivos de telefonia móvel, para possível aplicação noestabelecimento da aplicação DRM nesses dispositivos móveis. Os métodos propostosanteriormente para estabelecimento da aplicação de DRM utilizando métodos de TCGincluíram certos métodos que empregam o procedimento de vedação de TPM e asbolhas de memória para armazenar seguramente os dados relativos a DRM após oprocessamento do protocolo ROAP utilizando chaves TCG no TPM e em áreas dearmazenagem com proteção de chaves.
O estado da técnica existente, entretanto, não abordaexplicitamente nem aborda de forma ordenada como estabelecer e utilizar a "confiança"sobre a plataforma e/ou o software DRM. Nem o estado da técnica aborda métodosespecíficos de garantir a integridade nas mensagens ROAP, fortalecer o processamentode integridade em sistemas DRM OMA 2.0. A presente invenção inclui novos métodoscom esses propósitos.
As especificações atuais de DRM OMA 2.0 fornecem fortesmétodos de segurança com base em PKI que envolvem CA1 Rls e o dispositivo. Existem,entretanto, vulnerabilidades relativas à segurança e à integridade das plataformas, SW,agentes e mensagens, tanto nas próprias especificações de DRM OMA 2.0 quanto comrelação à implementação não especificada dos dispositivos e Rls que são compatíveiscom DRM OMA 2.0.
As especificações DRM OMA reconheceram as váriasameaças e vulnerabilidades que qualquer dispositivo ou Rl poderá enfrentar, mesmoquando estiverem conforme as especificações DRM OMA 2.0. Estas vulnerabilidadesincluem:
1. Compromisso de entidades, em que um atacantepode tentar comprometer uma entidade do sistema DRM1 fisicamente ou de outra forma.
Tipos de ataques que comprometem entidades incluem o comprometimento do agentede DRM no dispositivo e do SW de DRM no RI. As conseqüências de compromissos deentidades incluem a revelação de chaves privadas, chaves de domínio, chaves decriptografia de RO, chaves de criptografia de conteúdo e conteúdo protegido, bem comoa perda de proteção à integridade do cache de repetição do agente de DRM1 por exemplo, e/ou a perda de proteção dos direitos armazenados internamente no agente deDRM. Além disso, poderão também ocorrer perdas de tempo de DRM. Os efeitos sobreum PKI de um CA comprometido ou Dispositivo de Resposta de OCSP é discutido emreferências tais como IETF RFC3280.
O sistema de DRM OMA depende da revogação de certificados para minimizar os danos causados por uma entidade comprometida. Agentesde DRM e Rls devem sempre verificar que a entidade com a qual estão se comunicandonão tenha sido comprometida, verificando a situação do certificado da entidade. Umataque de compromisso a entidades pode ter lugar de formas "frontal" e "reversa". Umataque de compromisso frontal é realizado sobre as entidades de DRM (o RI, o agentede DRM, o Cl, o CA ou o dispositivo de resposta de OCSP), gerando um comportamentonão autorizado. Um ataque de compromisso reverso neutraliza ou enfraquece asconfigurações, definições de integridade e segurança de um agente de DRM.
2. Remoção de mensagens, por meio do quê umatacante pode remover uma mensagem enviada entre um agente de DRM e um RI, oque resulta tipicamente em ataques de Negação de Serviço (DoS). Um ataque deremoção de mensagens pode incluir: remoção de mensagens durante o protocolo deregistro ou o protocolo de obtenção de RO, remoção de nonces de repetição, remoçãode acionador de ROAP etc.
3. Modificação de mensagens, por meio do quê um atacante pode modificar qualquer mensagem enviada entre um agente de DRM e um RI,
o que resulta tipicamente em ataques de DoS. Um ataque de modificação de mensagenspode incluir modificação durante o protocolo de registro, durante os protocolos dedomínio de união e de domínio de saída e para vários acionadores de ROAP.
4. Inserção de mensagens, por meio do quê um atacante pode inserir mensagens no canal de comunicação em qualquer ponto entre um
Rl e um agente de DRM. O atacante pode também registrar mensagens e tentarexecutá-las novamente em um momento posterior. Um ataque de inserção demensagens pode incluir mensagens inseridas enquanto no protocolo de registro, nosprotocolos de obtenção de RO de uma passagem e duas passagens e a váriosacionadores de ROAP.
5. Outros ataques tais como ataques de DoS gerais,ataques passivos como análise de tráfego e revelação de privacidade.São identificados os problemas a seguir dasimplementações e especificações de DRM OMA atuais. É definida uma noção expandidade "integridade", da forma aplicada aos esquemas de DRM OMA. No sentido tradicional,as especificações de DRM OMA abordam apenas um pequeno escopo da integridade demensagens ROAP. Na noção expandida de integridade definida na presente invenção,observa-se que local e qual tipo de integridade podem ser considerados a seguir.
1. Integridade de plataforma de DRM. Isso se refere aintegridade nas entidades de plataforma ou no seu interior, ou seja, nas entidades físicasque compreendem o dispositivo, o Rl e as funções de conteúdo. As diferentes entidadesincluem o sistema operacional (OS), o código de boot (tal como BIOS no caso de PC), oHW/firmware (FW)/SW para acesso á memória, as várias entidades de HW/FW/SW queprocessam funções relativas à segurança de processos (tais como criptografia eadministração de chaves, bem como armazenagem privilegiada de dados secretos taiscomo apólices, certificados etc.) e HW/FW/SW de conectividade local e rede. Aintegridade da plataforma determina se a plataforma é válida, genuína e inalterada,exceto por processos legítimos, e opera apenas conforme o pretendido.
2. Integridade de SW de DRM. SW de DRM designaentidades de software e componentes residentes no dispositivo, Rl ou Cl quedesempenham funções específicas para especificações de DRM OMA e seusprocedimentos. No dispositivo, o agente de DRM consiste do SW de DRM. No Rl e Cl, oSW de DRM designa coletivamente o conjunto de SW que desempenha as funçõesespecíficas de DRM tais como embalagens de RO, formatação de DCF1 criptografia deconteúdo, fornecimento de RO ou conteúdo, verificação, processamento de ROAP etc. Aintegridade de SW de DRM é mantida caso o SW de DRM seja válido, genuíno,inalterado exceto por processos legítimos e opere apenas conforme o pretendido.
3. Integridade das informações e mensagens de ROAP.A integridade das mensagens de ROAP e suas informações componentes é mantidacaso essas informações sejam validadas, genuínas e inalteradas, exceto por processoslegítimos. Nas especificações DRM OMA 2.0, certos subconjuntos de mensagens ROAPe suas informações componentes têm sua integridade protegida pelo uso de assinaturasdigitais.
4. Integridade do objeto de mídia e do conteúdo deDRM. Os objetos de mídia e o conteúdo de DRM devem também ter a sua integridadeprotegida, ou seja, não devem ser modificados, reduzidos ou falsamente inseridos, sejameles armazenados no dispositivo, no Rl oü no Cl1 ou encontrem-se em trânsito oufornecimento entre quaisquer duas partes. É de interesse específico o fornecimento deconteúdo pelo ar (OTA)1 conforme aplicável à transferência de conteúdo para umdispositivo móvel, no qual o conteúdo de DRM é fornecido utilizando essencialmentecanais abertos.
5. Integridade de informações relativas a DRM.Informações relativas a DRM tais como as IDs de entidades (ID de dispositivo, ID de Rletc.), chaves de criptografia (CEK, REK) e chaves de assinaturas, os próprios ROs1informações de contexto, certificados e outras informações relativas a cadeia deconfiança devem ser seguramente protegidas, o que significa que elas deverão serprotegidas não apenas por confidencialidade, mas também por integridade.
Observa-se que nem as especificações de DRM OMA 2.0nem o estado da técnica existente aparentemente propuseram soluções para osproblemas de integridade ou compromisso da entidade. Esta falta de soluções apresentao problema a seguir: mesmo se todos os procedimentos de ROAP forem corretamenteimplementados conforme a especificação DRM OMA 2.0, por exemplo, como umdispositivo pode realmente saber se a plataforma do Rl é compensatória? Em outraspalavras, como o dispositivo pode saber se a plataforma de Rl não abusará dos dadosenviados pelo dispositivo como parte dos protocolos de ROAP ou abusará do próprioprocessamento de DRM? O dispositivo não sabe, por exemplo, se o Rl limitará arbitráriae incorretamente os direitos de uso do dispositivo porque o SW da plataforma de Rl écomprometido e limita os direitos de uso do dispositivo que de outra forma são válidos.Questões similares surgem para o problema da integridade do software DRM. Maisespecificamente, alguns dos problemas dos sistemas DRM OMA 2.0 atuais conformeobservado a partir da noção expandida de integridade descrita acima são os seguintes.
1. Uma falta de métodos de verificação e relato daintegridade da plataforma e do SW de DRM. Com relação à ameaça de compromisso daentidade identificada acima, não existe método no estado da técnica para verificação daintegridade da plataforma estruturada e explícita e verificação da integridade de agente
SW entre o dispositivo e o RI, seja conforme detalhado pelas especificações de DRMOMA 2.0 ou como parte dos Casos de Uso TCG 1.2. Isso é particularmente verdadeiropara verificação da integridade de plataforma, e não apenas o agente de DRM.
2. Uma plataforma (tal como um PC ou PDA, comrelação ao dispositivo, ou um servidor, com relação ao RI) poderá ser comprometida deforma maliciosa, o que poderá resultar em evitar que o agente de DRM e o SW deagente de Rl apresentem desempenho correto, mesmo que sejam fornecidasinformações corretas e com confidencialidade e integridade protegidas. SW de agente deDRM de outra forma bem protegido, por exemplo, pode armazenar algumas informaçõesem formato de texto em uma memória compartilhada antes, durante ou depois doprocessamento. Uma plataforma comprometida pode, nesses casos, ter maliciosamenteacesso à memória compartilhada e remover as informações, alterar as informações ouinserir novas informações falsas que poderão ser processadas em seguida pelo SW deagente de DRM que pode interpretar essas informações falsas como genuínas. Issopode resultar em ataques de DoS, revelação não autorizada de informações privadas oufornecimento, distribuição ou consumo não autorizado de ROs de DRM ou conteúdo deDRM.
3. O SW de agente de DRM e o SW de RI, que sãoelementos de SW que processam informações relativas a DRM de processo, podemcomprometer-se por várias razões. Esse SW poderá ser alterado, por exemplo, por umvírus ou outras entidades de SW maliciosas. Um resultado deste compromisso naplataforma ou no SW de DRM seria um compromisso subseqüente na integridade dasmensagens e informações consideradas pelo DRM OMA 2.0, especialmente asmensagens de protocolo ROAP. Parcialmente porque apenas algumas, mas não todasas mensagens ROAP têm a sua integridade protegida, elas podem teoricamente sermanipuladas de formas sincronizadas entre um dispositivo comprometido e um Rlcomprometido ou falso. Mensagens poderão ser modificadas de forma sincrônica nodispositivo e no Rl e ainda podem parecer "ter a integridade verificada", pois asmensagens foram modificadas da mesma forma.
4. Proteção de integridade insuficiente das mensagensROAP. Com relação à integridade de mensagens, as mensagens ROAP e asinformações conduzidas pelos vários campos de mensagens estão sujeitas avulnerabilidades que não são solucionadas pelas especificações DRM OMA 2.0. Aproteção da integridade de mensagens ROAP atualmente detalhada na especificaçãoDRM OMA 2.0, por exemplo, deixa falhas tais como:
4A. Nem todas as mensagens ROAP têm a suaintegridade protegida. A não inclusão de assinaturas digitais em todas as mensagenspoderá impor vulnerabilidades em certos casos.
4B. Mesmo quando mensagens ROAP ou certos camposde informação tiverem sua integridade protegida por assinaturas digitais, após adecifração dessas informações, verificação da integridade e "uso" em seguida emformato de texto, entidades maliciosas poderão ter acesso às informações em formato detexto e remover, alterar ou redistribuir as informações com integridade anteriormenteverificada. Desta forma, é necessária uma proteção fortalecida da integridade.
5. Vulnerabilidades referentes à integridade doconteúdo de DRM e seu fornecimento. Mais especificamente, existem os problemas aseguir:5Α. Os mecanismos de verificação da integridade doconteúdo são incompletos. A integridade do conteúdo enquanto o conteúdo estiver emtrânsito ou em fornecimento (tal como download de OTA), por exemplo, não éespecificada. A assinatura para o DCF1 por exemplo, somente é gerada para uso nosprocedimentos de ROAP. Até o início dos procedimentos de ROAP1 não há ummecanismo de verificação de integridade que administre a integridade de conteúdodurante a armazenagem no Cl, por exemplo.
5B. A criptografia de conteúdo, mesmo para uso noprotocolo de ROAP, é obrigatória, mas a verificação de integridade é apenas opcional.
5C. Especialmente para conteúdo embalado paraserviços de streaming, o formato de PDCF possui uma questão de tempo. Os pacotesque haviam sido modificados de forma ilegítima poderão ser baixados e até consumidos(ou seja, executados em um dispositivo de mídia) antes que possa ser verificada aintegridade de todo o fluxo.
O problema central torna-se: como as várias partes (odispositivo, o Rl e o Cl) podem ter garantida a integridade da plataforma e a integridadede SW de DRM? Desta forma, é necessário um método de fortalecimento e verificaçãoda integridade da plataforma (tal como o OS, BIOS, drivers, dispositivo de mídia,software de comunicação, memória compartilhada etc.) da qual dependem o SW deagente de DM ou o SW de RI. A presente invenção aborda as deficiências do estado datécnica.
Resumo da Invenção
A presente invenção descreve vários métodos quefortalecem a integridade de entidades, mensagens e processamento referentes àespecificação DRM OMA v2.0. Os métodos utilizam técnicas comumente conhecidascomo métodos de Computação Confiável, conforme especificado pelo fórum da indústriaGrupo de Computação Confiáveis (TCG). Em uma primeira realização da presenteinvenção, são descritos métodos de verificação da plataforma e integridade ouconfiabilidade de SW de DRM1 com e sem modificações das especificações de DCF eROAP DRM. Em uma segunda realização, são realizados métodos de fortalecimento daintegridade das mensagens ROAP DRM OMA1 informações componentes eprocessamento sem alterar o protocolo de ROAP existente. Em uma terceira realização,são descritos métodos de fortalecimento da integridade de mensagens ROAP1informações e processamento com algumas alterações do protocolo de ROAP existente.
Breve Descrição das Figuras
Pode ser obtida uma compreensão mais detalhada a partirda descrição de uma realização preferida a seguir, fornecida como forma de exemplo e aser compreendida em conjunto com as figuras anexas, nas quais:- Figura 1 é um diagrama de bloco da arquitetura funcional DRM OMA 2.0;
- Figura 2 é um diagrama de fluxo do protocolo de registro de quatro passagens ROAPDRM OMA 2.0 existente;
- Figura 3 é um diagrama de fluxo do protocolo de obtenção de RO de duas passagensROAP DRM OMA 2.0 existente;
- Figura 4 é um diagrama de fluxo do protocolo de obtenção de RO de uma passagemROAP DRM OMA 2.0 existente;
- Figura 5 é um diagrama de fluxo do protocolo de união a domínio de duas passagensROAP DRM OMA 2.0 existente;
- Figura 6 é um diagrama de fluxo do protocolo de saída de domínio de uma passagemROAP DRM OMA 2.0 existente;
- Figura 7 é um diagrama de bloco de verificação de integridade de plataforma comdiversas partes entre as entidades DRM OMA 2.0;
- Figura 8 é um gráfico de fluxo de um método de realização de verificação deintegridade de plataforma entre duas entidades em que as duas entidades poderão ser
um dispositivo e um Rl ou um dispositivo e um Cl;
- Figura 9 é um diagrama de fluxo de um protocolo de registro de ROAP com quatropassagens para realizar verificação de integridade de plataforma mútua entre umdispositivo e um Rl utilizando verificação de confiabilidade anterior;
- Figura 10 é um diagrama de fluxo de um protocolo de registro de ROAP com quatropassagens para realizar verificação de integridade de plataforma mútua entre umdispositivo e um Rl utilizando mensagens Alô Dispositivo e Alô Rl modificadas;
- Figura 11 é um gráfico de fluxo de um método de realização de verificação deintegridade de software DRM entre duas entidades, em que as duas entidades poderãoser um dispositivo e um Rl ou um dispositivo e um Cl;
- Figura 12 é um diagrama de fluxo de um protocolo de obtenção de RO ROAP com duaspassagens para realizar verificação de integridade de software de DRM mútua entre umdispositivo e um RI; e
- Figura 13 é um diagrama de fluxo de um método de aumento da integridade demensagens de ROAP e processamento utilizando métodos TCG que incluem uniãovedada e bolhas de memória.
Descrição Detalhada das Realizações Preferidas
A seguir, a expressão "unidade de transmissão e recepçãosem fio" (WTRU) inclui, mas sem limitar-se a um equipamento de usuário, estaçãomóvel, unidade de assinante fixa ou móvel, pager ou qualquer outro tipo de dispositivocapaz de operar em um ambiente com fio ou sem fio. Quando indicado a seguir, aexpressão "estação base" inclui, mas sem limitar-se a um Nó B, controlador de local,ponto de acesso ou qualquer outro tipo de dispositivo de interface em um ambiente semfio.
A presente invenção descreve métodos por meio dos quaisinformações referentes ao estado de confiança ou a integridade de uma entidade DRM(por exemplo, o dispositivo, Rl ou Cl) é explícita e mutuamente solicitada e trocada entrequaisquer duas entidades DRM como requisito prévio para os procedimentos DRM OMA.
Uma arquitetura geral 700 deste método é exibida na Figura7. A arquitetura inclui quatro entidades DRM: um dispositivo 702, Rl 704, Cl 706 e umaAutoridade de Certificação Privada (PCA) 708. A verificação de integridade de plataformaconsidera que o PCA 708 possui registros das credenciais de computação confiável (talcomo TCG) para as outras entidades DRM (tais como o dispositivo 702, Rl 704 e Cl 706)e fornece uma raiz de confiança para certificação das credenciais de TCG.
Qualquer par de entidades (tais como o dispositivo 702 e oRl 704, o dispositivo 702 e o Cl 706 ou o Rl 704 e o Cl 706) que deseja uma verificaçãode integridade de plataforma mútua entre si são capazes de computação confiável (sãoequipadas, por exemplo, com Módulos de Processamento Confiável (TPMs) TCG 710).Isso significa que a entidade de DRM capaz de computação confiável não apenas possuium TPM 710 (ou equivalente), mas também recursos de TCG relacionados tais comoAIK 712, SML 714 e memória protegida utilizando bolhas 716. Também estão presentessoftware de plataforma ou OS 718 e software DRM 720.
Quando as necessidades acima forem atendidas, qualquerpar de entidades de DRM diferentes pode verificar mutuamente a sua integridade deplataforma ou estado confiável de plataforma utilizando o PCA 708 e as capacidades decomputação confiáveis. Como exemplo, os procedimentos de verificação de integridademútua entre o dispositivo 702 e o Rl 704 são conforme segue.
O dispositivo 702, o Rl 704 e o Cl 706 são todos capazes derealizar uma autoverificação do OS ou outros componentes de software de plataforma(etapa 730) e uma autoverificação do software DRM (etapa 732). As autoverificaçõespodem ser solicitadas como parte de um processo de verificação maior (conformediscutido com mais detalhes abaixo) ou podem ser processos isolados. Caso qualquerdas autoverificações falhe, isso poderá ser uma indicação que a entidade comprometeu-se e não deverá ser confiável.
O dispositivo 702 envia informações sobre as suascredenciais de TCG da plataforma para o Rl 704 (etapa 740). Exemplos das credenciaisde TCG da plataforma incluem, mas sem limitar-se a um certificado de plataforma deTCG assinado ou um certificado de TPM assinado. Como parte das credenciais, odispositivo 702 pode também enviar um Rl 704 uma marca de Estado Confiável ouIntegridade de Plataforma Verificada auto-atestada como informação suplementar. Casoo dispositivo 702 verifique a integridade da plataforma do Rl 704, a informação decredencial enviada na etapa 740 também incluirá uma indicação pelo dispositivo 702 quedeseja que o Rl 704 inicie procedimentos de verificação da sua integridade deplataforma. Observe-se que o dispositivo 702 seja capaz de tomar uma decisão referenteà verificação ou não da integridade da plataforma do Rl 704 somente se a verificação dasituação da integridade de plataforma do Rl for uma característica opcional; em umarealização, a verificação da integridade da plataforma de Rl é uma característicaobrigatória.
Mediante o recebimento da informação de credencial dodispositivo 702, o Rl 704 retransmite as informações de credenciais para o PCA 708(etapa 742) e também solicita que o PCA 708 verifique as credenciais sobre o dispositivo702, especialmente a confiabilidade mais atual do dispositivo. O PCA 708 envia emseguida as informações de confiabilidade mais atuais (tais como nível de confiança daplataforma etc.) referentes ao dispositivo 702 para o Rl 704 (etapa 744). Medianterecebimento das informações de confiabilidade da plataforma do dispositivo do PCA 708e também, opcionalmente, das informações suplementares do dispositivo 702, o Rl 704avalia o nível de confiança do dispositivo 702. O Rl 704 decide pela imposição ou não deconfiança suficiente sobre a integridade da plataforma do dispositivo para realizaradicionalmente os procedimentos de DRM tais como o protocolo de registro ou protocolode obtenção de RO.
O dispositivo 702, seja como um procedimento obrigatórioou um procedimento opcional, pode avaliar a integridade da plataforma do Rl 704 deformas similares e recíprocas às das etapas 740 a 744. Mais especificamente, o Rl 704envia informações sobre as suas credenciais de TCG de plataforma para o dispositivo702 (etapa 750). Como parte das credenciais, o Rl 704 pode também enviar para odispositivo 702 uma marca de Estado Confiável ou Integridade de Plataforma Verificadaauto-atestada como informação suplementar.
Mediante o recebimento das informações relativas a TCG doRl 704, o dispositivo 702 retransmite as informações para o PCA (etapa 752) e tambémsolicita que o PCA 708 verifique as credenciais sobre o Rl 704, especialmente aconfiabilidade mais atual do RI. O PCA 708 envia em seguida as informações deconfiabilidade mais atuais referentes ao Rl 704 para o dispositivo 702 (etapa 754).Mediante o recebimento das informações de confiabilidade da plataforma de Rl do PCA708 com referência ao Rl 704 e também opcionalmente as informações suplementaresdo próprio RI, o dispositivo 702 avalia o nível de confiança do Rl 704. O dispositivo 702decide pela imposição ou não da confiança suficiente sobre a integridade da plataformaRl para realizar adicionalmente os procedimentos de DRM tais como o protocolo deregistro ou o protocolo de obtenção de RO.
O dispositivo 702, seja como procedimento obrigatório oucomo procedimento opcional, pode avaliar a integridade da plataforma do Cl 706. O Cl706 envia informações sobre as suas credenciais de TCG de plataforma para odispositivo 702 (etapa 760). Como parte das credenciais, o Cl 706 pode também enviarpara o dispositivo 702 uma marca de Estado Confiável ou Integridade de PlataformaVerificada auto-atestada como informação suplementar.
Mediante recebimento das informações relativas a TCG doCl 706, o dispositivo 702 retransmite as informações para o PCA (etapa 762) e tambémsolicita que o PCA 708 verifique as credenciais sobre o Cl 706, especialmente aconfiabilidade mais atual do Cl. O PCA 708 envia em seguida as informações deconfiabilidade mais atuais referentes ao Cl 706 para o dispositivo 702 (etapa 764).Mediante o recebimento das informações de confiabilidade da plataforma Cl do PCA 708com referência ao Cl 706 e também opcionalmente as informações suplementares dopróprio Cl1 o dispositivo 702 avalia o nível de confiança do Cl 706. O dispositivo 702decide pela imposição de confiança suficiente sobre a integridade da plataforma de Clpara realizar adicionalmente os procedimentos de DRM.
A integridade de plataforma do dispositivo 702 pode serverificada pelo Cl 706 conforme segue. O dispositivo 702 envia informações sobre assuas credenciais de TCG de plataforma para o Cl 706 (etapa 770). Como parte dascredenciais, o dispositivo 702 pode também enviar para o Cl 706 uma marca de EstadoConfiável ou Integridade de Plataforma Verificada auto-atestada como informaçãosuplementar. Caso o dispositivo 702 verifique a integridade da plataforma do Cl 706, asinformações de credenciais enviadas na etapa 770 também incluirão uma indicação dodispositivo 702 que ele deseja que o Cl 706 inicie procedimentos para verificar a suaintegridade de plataforma. Observa-se que o dispositivo 702 será capaz de realizar umadecisão sobre a verificação ou não da integridade da plataforma do Cl 706 somente se averificação da situação da integridade de plataforma do Cl for uma característicaopcional; em uma realização, a verificação da integridade da plataforma de Cl é umacaracterística obrigatória.
Mediante o recebimento das informações de credenciais do dispositivo 702, o Cl 706 retransmite as informações de credenciais para o PCA 708(etapa 772) e também solicita ao PCA 708 que verifique as credenciais sobre odispositivo 702, especialmente a confiabilidade mais atual do dispositivo. O PCA 708envia em seguida as informações de confiabilidade mais atuais com referência aodispositivo 702 para o Cl 706 (etapa 774). Mediante recebimento das informações de confiabilidade da plataforma de dispositivo do PCA 708 e também, opcionalmente, dasinformações suplementares do dispositivo 702, o Cl 706 avalia o nível de confiança dodispositivo 702. O Cl 706 decide pela imposição ou não de confiança suficiente sobre aintegridade da plataforma do dispositivo para realizar adicionalmente os procedimentosde DRM.
Observa-se que, no exemplo acima, as etapas 740 a 744,para que o dispositivo 702 verifique a sua situação de integridade para o Rl 704, sãouma característica obrigatória da presente invenção. A verificação da integridade de plataforma do Rl 704 para o dispositivo 702 (etapas 750 a 754), a verificação daintegridade da plataforma do CI 706 para o dispositivo 702 (etapas 760 a 764) e averificação da integridade da plataforma de dispositivo para o Cl 706 (etapas 770 a 774),entretanto, são características opcionais, embora altamente recomendadas, em umsistema DRM.
Também se observa que estes procedimentos nãonecessitam ser iniciados por um início ativo pela entidade que necessita ser verificada.Os procedimentos de verificação da integridade poderão começar com uma solicitaçãoda entidade que deseja verificar a integridade da outra parte. Nestes casos, cada umadas etapas 740, 750, 760 ou 770 seria precedida por uma outra etapa, por meio do quê aentidade que deseja a verificação da integridade de plataforma da outra parte convocaou solicita à outra parte que envie informações relativas a confiança relevantes.
Em uma realização alternativa, para uma implementação desistema de DRM OMA prática, as condições ou mecanismos acionadores para osprocedimentos de verificação da integridade de plataforma propostos descritos acima podem incluir os seguintes:
1. Os procedimentos de verificação da integridade daplataforma de dispositivo (ou seja, etapas 740 a 744) poderão ser realizados por meio deum ou mais dos seguintes:
IA. Antes que um dispositivo deseje iniciar um novo protocolo de registro de ROAP de quatro passagens.
IB. Uma vez a cada RI, antes que tenha lugar o primeiroregistro com o Rl específico. Neste caso, o Rl receberá as credenciais de TCG dodispositivo uma vez antes do primeiro registro é, em seguida, o Rl protege asinformações de credenciais do dispositivo sob o seu próprio TPM por meio de união dasinformações de credenciais com uma chave de TPM. O Rl libera posteriormente acredencial de TCG armazenada e verifica, periodicamente ou mediante alguns eventos,se a credencial de TCG do dispositivo que recebeu ainda é válida, tal como por meio deconsulta com um CA OCSP.
1C. Periodicamente, sempre que houver decorrido um período de tempo especificado, tal como Tdev-pl^tform-l<\st-reg. desde que o dispositivocompletasse o último protocolo de registro com o mesmo RI.
1D. Periodicamente, sempre que houver decorrido umperíodo de tempo especificado, tal como TDEV.PLATFORM-LAST-REPORT, desde a última vez emque o dispositivo verificou a sua situação de integridade de plataforma para o mesmo RI.
2. Se e quando os procedimentos de verificação daintegridade de plataforma de Rl (ou seja, etapas 750 a 754) forem implementados, elespoderão ser realizados por meio de um ou mais dos seguintes:
2A. Uma vez a cada dispositivo, antes que tenha lugar oprimeiro registro com o dispositivo específico. Neste caso, o dispositivo receberá ascredenciais de TCG do Rl uma vez antes do primeiro registro e, em seguida, odispositivo protege as informações de credenciais de Rl sob o seu próprio TPM pôr meiode união das informações de credenciais com uma chave de TPM. O dispositivo separaposteriormente a credencial de TCG armazenada e verifica, seja periodicamente oumediante alguns eventos, se a credencial de TCG de Rl que recebeu ainda é válida, porexemplo, por meio de consulta com um CA OCSP.
2B. Sempre que um Rl receber uma indicação dodispositivo que o dispositivo deseja que o Rl verifique a sua situação de integridade parao dispositivo, seja na forma de uma mensagem isolada ou como parte de umamensagem de protocolo de ROAP.
2C. Periodicamente, toda vez em que tenha decorridouma duração de tempo segura especificada, tal como Tri-platform-last-reporti desde que oúltimo momento em que o Rl verificou a sua situação de integridade para o dispositivo.
3. Quanto à verificação da integridade de plataformaentre um dispositivo e um Cl, mecanismos similares ao acima podem ser consideradospara ocorrência periódica e/ou dirigida por eventos do processo de verificação deintegridade. Além disso, no caso da verificação de dispositivo da integridade deplataforma de Cl, ela poderá também ser realizada toda vez antes que o conteúdonecessite ser adquirido ou descarregado e, possivelmente vice-versa (ou seja, aintegridade da plataforma de dispositivo necessita ser verificada para o Cl).
O estado da técnica considerou o uso de um "boot seguro"utilizando métodos de TCG acoplados à aplicação de DRM robusto. Nesses esquemas, oOS da plataforma e outro código relativo a boot têm a sua integridade verificada sempreque um dispositivo é inicializado, realizando implicitamente uma verificação deintegridade de plataforma antes que qualquer aplicação de DRM possa ser conduzida. Apresente invenção fornece um uso mais sistemático e explícito da verificação daintegridade de plataforma de tempo de boot, bem como verificações da integridade deplataformas em outros momentos, com base em períodos de tempo previamentedeterminados, bem como mediante a ocorrência de certos eventos. A presente invençãotambém generaliza a verificação da integridade da plataforma do dispositivo para o Rl etambém para o Cl. As verificações de integridade da plataforma contínuas são benéficasporque apenas o fato de que um dispositivo tenha recebido corretamente um CO válidoespecífico não significa que o Rl ou o Cl deverão ser considerados indefinidamenteválidos para o futuro a partir daquele momento. Uma verificação contínua periódica e/oudirigida por eventos da confiabilidade fornece um bom mecanismo de proteção.
Além disso, quanto à necessidade de verificação daintegridade entre o dispositivo e o Cl1 mesmo se o conteúdo chegar antes de um RO1 oconteúdo pode ser comprometido quando a integridade da plataforma de Cl ou o SW deDRM de Cl estiver comprometido. Suponha, por exemplo, que um usuário tenhadescarregado um arquivo. Mesmo quando o RO ainda não houver sido obtido, umusuário pode clicar inadvertidamente no conteúdo ou pode realizar uma verificação devalidade sobre o conteúdo. Caso o conteúdo fosse comprometido (possua, por exemplo,um vírus ligado a ele), o conteúdo, mesmo sem um RO1 poderia causar dano aodispositivo. Além disso, nas interações antes do download entre o dispositivo e um Cl (talcomo durante a fase de descoberta), um dispositivo comprometido pode causar dano aum Cl1 por exemplo, adicionando-se um vírus ligado ao conteúdo de uma mensagemdestinada ao Cl. Além disso, do ponto de vista comercial, um Cl não desejaria enviarconteúdo para um dispositivo comprometido; um dispositivo comprometido poderáredistribuir conteúdo gratuitamente, por exemplo, para receptores não autorizados. Averificação da integridade de plataforma mútua (e SW) entre um dispositivo e um Clpossui, portanto, méritos na proteção de todo o sistema.
Também se observa que podem existir diversas formasdiferentes de realização das idéias centrais descritas nas discussões arquitetônicasacima. Dois destes exemplos são discutidos abaixo, mas observa-se que estes sãoapenas exemplos ilustrativos dos conceitos mais amplos com base na arquiteturadescrita nos parágrafos acima.
Verificação da integridade de plataforma:
A Figura 8 é um gráfico de fluxo de um método 800 dêrealização da verificação da integridade de plataforma entre duas entidades. As duasentidades podem ser um dispositivo e um Rl1 um dispositivo e um Cl ou um Rl e um Cl.O método 800 utiliza uma entidade de solicitação (RE) e uma entidade alvo (TE);observa-se que qualquer das entidades do par (dispositivo, Rl ou Cl) pode ser o RE. Ométodo 800 opera da mesma forma, independentemente de qual entidade for o RE equal entidade for o TE.
O método 800 inicia-se com o envio pelo RE de umasolicitação para o TE para relatar a sua situação de integridade de plataforma (etapa802). Em resposta à solicitação, o TE envia as seus credenciais de TCG para o RE(etapa 804). As credenciais de TCG podem incluir, por exemplo, credenciais deplataforma, credenciais de TPM ou credenciais de conformação. O RE envia em seguidaas credenciais de TCG de TE para um Dispositivo de Resposta de OCSP paraverificação das credenciais (etapa 806). O Dispositivo de Resposta de OCSP analisa ascredenciais de TCG de TE e relata a situação de verificação para o RE (etapa 808).
O RE envia uma solicitação para que o TE relate a suasituação de integridade de plataforma (etapa 810). O TE verifica a sua situação deintegridade de plataforma (etapa 812), envia uma marca de situação de integridade deplataforma para o RE (etapa 814) e o método termina (etapa 816).
O método 800 pode ser aplicado sem alterações para osprotocolos ROAP (discutidos abaixo com relação à Figura 9) ou com alterações para osprotocolos ROAP (discutidos abaixo com relação à Figura 10).
Verificação da integridade sem alterações para os protocolos ROAP:
A Figura 9 é um diagrama de fluxo de um método 900 detroca de informações relativas a integridade entre um dispositivo 902 e um Rl 904utilizando métodos de TCG (ou seja, utilizando um dispositivo de resposta de OCSP/PCA906) separadamente do protocolo ROAP. Observa-se que, no método 900, a mesmaentidade 906 é ilustrada como sendo PCA para o processamento de DRM, bem como umdispositivo de resposta de OCSP para processamento de TCG. No método 900, averificação de integridade de plataforma (conforme exibido pelo retângulo tracejado) érealizada antes do protocolo de registro de quatro passagens ROAP. A realização daverificação da integridade de plataforma antes do protocolo de registro é útil porque oprotocolo de registro não é realizado freqüentemente e o processo de verificação daintegridade de plataforma leva algum tempo para ser completado; caso a verificação daintegridade de plataforma fosse realizada com cada mensagem, a operação geral dosistema poderá ter sua velocidade desnecessariamente reduzida. Os técnicos no assuntopoderão considerar que, após a realização da verificação da integridade da plataforma,somente uma mensagem Alô Dispositivo seria recebida pelo RI, pois isso indicaria umdispositivo confiável. Caso mais de uma mensagem Alô Dispositivo fosse recebida peloRl a partir do mesmo dispositivo, isso poderia ser uma indicação de um ataque DoS. Averificação da integridade de plataforma poderá também ser realizada com relação aoprotocolo de autenticação e ao protocolo de obtenção de objeto.
O dispositivo 902, antes de iniciar o protocolo de registro dequatro passagens com o Rl 904, inicia um conjunto separado de procedimentos com o Rl904 para realizar verificação mútua da integridade de plataforma. O dispositivo 902 enviaem primeiro lugar as suas próprias credenciais de TCG (tais como credenciais deplataforma, credenciais de TPM, credenciais de conformação etc.) ou outras informaçõesque incluem ou referem-se à credencial de TCG ou Rl 904 (etapa 910). Opcionalmente, odispositivo 902 também envia uma solicitação para que o Rl 904 verifique e relate a suasituação da. integridade de plataforma para o dispositivo 902; esta solicitação é incluídacom as credenciais de dispositivos.
O RI 904 solicita que o PCA 906 verifique as credenciais deTCG do dispositivo (etapa 912). O PCA 906 responde à solicitação do RI e enviainformações sobre a credencial de TCG do dispositivo (etapa 914).
O RI 904 solicita que o dispositivo 902 relate a sua marca desituação de integridade de plataforma (etapa 916). Além disso, caso o dispositivo 902tenha solicitado que o RI 904 verifique e relate a sua situação de integridade deplataforma na etapa 910 e caso o Rl 904 deseje e seja capaz de obrigar a solicitação, oRI 904 envia a sua própria credencial de TCG ou outras informações que incluem oureferem-se à credencial de TCG para o dispositivo 902 na etapa 916. Caso o RI 904 nãopossa ou não deseje obrigar à solicitação, ele envia uma mensagem "não obrigatória"para o dispositivo. O Rl 904 pode não responder à solicitação por uma série de razões,que incluem um RI limitado por recursos (ou seja, o RI não possui recursos disponíveissuficientes para responder à solicitação) ou a verificação da credibilidade do dispositivofalha. O dispositivo pode abortar o protocolo dependendo do nível de confiança que odispositivo possui com o RI; caso o dispositivo confie no RI, ele provavelmentecontinuaria com o protocolo mesmo se o Rl se recusasse a responder à solicitação.Mediante o recebimento da solicitação do Rl 904 para verificar a situação da plataforma,o dispositivo 902 verifica a sua própria situação de integridade de plataforma (etapa 918).
O dispositivo 902 solicita que o PCA 906 verifique acredencial de TCG do Rl (etapa 920). O PCA 906, ao receber essa solicitação dodispositivo 902, devolve informações sobre a credencial de TCG do Rl (etapa 922). Odispositivo 902 envia a sua marca de situação de integridade de plataforma para o Rl 904(etapa 924). Caso o RI 904 recebesse uma solicitação do dispositivo 902 para verificar asua situação de integridade e, caso o Rl 904 deseje e seja capaz de obrigar aodispositivo, o Rl 904 verifica a sua própria integridade de plataforma (etapa 926). O RIdevolve em seguida a sua marca de situação de integridade de plataforma para odispositivo 902 (etapa 928). As etapas opcionais referentes à verificação de integridadede Rl podem ser realizadas em qualquer ordem; estas etapas não necessitam serentrelaçadas com a Verificação de integridade de dispositivo, conforme exibido na Figura9. Além disso, o Rl pode iniciar a sua própria verificação de integridade. Além disso, casoo RI recuse-se a responder completamente a solicitação com as suas própriasinformações de credencial de TCG por qualquer das possíveis razões, ele pode indicaresse fato ao dispositivo de uma forma apropriada, tal como na etapa 922.
O método 900 permite que o dispositivo 902 e o RI 904atinjam verificação de integridade de plataforma mútua. Mediante essa verificação, odispositivo pode iniciar em seguida o protocolo de registro de ROAP. As etapas doprotocolo de registro (etapas 930-940) exibidas na Figura 9 são as mesmas etapas 210-220 do método 200 descrito acima. Também se observa que esses procedimentospodem ser acionados ou repetidos em intervalos periódicos.
Verificação de integridade com alterações do protocolo deregistro de ROAP:
A Figura 10, em um outro exemplo de realização, exibe ummétodo 1000 no qual um dispositivo 1002 e um Rl 1004 trocam informações relativas àintegridade, também utilizando os serviços de um dispositivo de resposta OCSP/PCA1006. No método 1000, as mensagens Alô Dispositivo e Alô Rl do protocolo de registrode ROAP são modificadas para conduzir a credencial TCG e a solicitação para a outraparte para verificação da integridade de plataforma.
O dispositivo 1002 envia uma mensagem Alô Dispositivopara o Rl 1004 (etapa 1010), em que a mensagem inclui a credencial de TCG dodispositivo e uma solicitação opcional para que o Rl 1004 relate a sua integridade deplataforma. O Rl 1004 encaminha as credenciais de dispositivo para o PCA 1006 paraverificação (etapa 1012). O PCA 1006 devolve em seguida as credenciais de TCG dodispositivo para o Rl 1004 (etapa 1014). O Rl 1004 responde ao dispositivo 1002 comuma mensagem Alô Rl modificada (etapa 1016), em que a mensagem incluiopcionalmente a credencial de TCG do RI.
Em seguida, o dispositivo 1002 envia opcionalmente umasolicitação para o PCA 1006 para verificar a credencial de TCG do Rl (etapa 1018). OPCA 1006 verifica as credenciais de R| e relata os resultados de volta para o dispositivo1002 (etapa 1020). O dispositivo 1002 verifica a sua própria situação de integridade(etapa 1022) e relata a situação de integridade para o Rl 1004 (etapa 1024).
Caso o dispositivo 1002 tenha solicitado que o Rl 1004relate a sua situação de integridade, o Rl 1004 realiza uma verificação da integridade deplataforma (etapa 1026) e relata a situação de integridade, tal como a sua marca deestado confiável, de volta para o dispositivo 1002 (etapa 1028). As etapas 1030 a 1036são as mesmas etapas 214 a 220 exibidas na Figura 2 do protocolo de registro deROAP.
Verificação da integridade do software DRM:
A Figura 11 é um gráfico de fluxo de um método 1100 deverificação da integridade do SW de DRM (tal como o SW do agente de usuário DRMque reside no dispositivo ou o SW de DRM residente no Rl ou Cl) dentre qualquer par deentidades DRM. Uma entidade de solicitação (RE) envia uma solicitação para umaentidade alvo (TE) para realizar uma verificação de entidade SW de DRM (etapa 1102).O TE verifica a sua integridade de SW de DRM (etapa 1104), envia uma marca desituação de integridade de SW de DRM para o RE (etapa 1106) e o método termina(etapa 1108). Observa-se que, quando o TE for um dispositivo, a integridade dos driversde dispositivo e SW de dispositivo de mídia pode ser verificada separadamente daintegridade do SW de DRM1 caso esses dois componentes existam separadamente nodispositivo.
O método 1100 refere-se apenas à obtenção pelo RE deuma verificação de integridade de SW de DRM do TE. Para realizar verificação deintegridade de SW de DRM mútua, o método 1100 necessitaria ser realizado duas vezes,uma do RE para o TE e em seguida do TE para o RE (com o RE e o TE alternandopapéis). Durante uma verificação da integridade de SW de DRM mútua, as solicitaçõespodem ser interligadas (conforme exibido na Figura 12) ou podem ser separadas,conforme exibido na Figura 11. A operação do método não é alterada caso esteja sendorealizada uma verificação da integridade de SW de DRM mútua.
A especificação DRM OMA 2.0 considera, sem sugerir comoessas premissas podem ser implementadas de forma válida, que o SW do agente deusuário DRM (ou o SW de DRM de dispositivo, na terminologia utilizada na presenteinvenção), bem como o Rl (ou o SW de DRM do RI) podem ser implicitamente confiáveis.O protocolo de autenticação na especificação DRM OMA 2.0 especifica apenas, portanto,os procedimentos de autenticação reais entre entidades que já são considerados válidos.Por razões óbvias, esta premissa de confiança de SW implícita na prática não pode serautomaticamente considerada sem etapas reais de sua implementação e verificação. Osmétodos descritos neste capítulo referem-se a essas etapas concretas.
A Figura 12 é um diagrama de fluxo de um método 1200 deaplicação da verificação de SW de DRM com relação ao protocolo de obtenção de ROROAP. O método 1200 utiliza um dispositivo 1202, um Rl 1204 e um dispositivo deresposta de OCSP/PCA 1206. Em primeiro lugar, o PCA 1206 comunica-se com odispositivo 1202 e o Rl 1204 para realizar verificação da integridade de plataforma e oprotocolo de registro de ROAP (etapa 1210). O dispositivo 1202 e o Rl 1204 realizamuma verificação da integridade de plataforma mútua, uma verificação de integridade deSW de DRM unidirecional ou uma verificação de integridade de SW de DRM mútua(etapa 1212).
O RI 1204 envia uma solicitação para o dispositivo 1202para verificar e relatar a integridade de SW do agente de usuário (UA) de DRM dodispositivo (etapa 1214). O dispositivo 1202 verifica a sua última integridade de SW deUA DRM (etapa 1216). O dispositivo 1202 envia opcionalmente uma solicitação para o Rl1204 para verificar e relatar a integridade de SW de DRM do Rl (etapa 1218). Casosolicitado, o Rl 1204 verifica a sua última integridade de SW de DRM (etapa 1220). Odispositivo 1202 envia uma marca de situação de integridade de SW de DRM dedispositivo para o Rl 1204 (etapa 1222). Caso solicitado anteriormente, o Rl 1204 enviauma marca de situação de integridade de SW de DRM Rl para o dispositivo 1202 (etapa1224). Observa-se que as etapas da verificação de integridade de Rl opcional podem serrealizadas em qualquer ordem e não necessitam ser interligadas com a verificação deintegridade de dispositivo conforme exibido na Figura 12.
Observa-se que o método 1200 pode ser generalizado paraverificação da integridade de SW de DRM entre um dispositivo e um Cl1 no lugar dainteração entre Rl e dispositivo ilustrada. Ao completar-se as etapas 1210 a 1224, odispositivo 1202 pode iniciar, por exemplo, o protocolo de obtenção de RO com duaspassagens nas etapas 1226 e 1228, que são as mesmas etapas 310 e 312 conformedescrito acima com relação à Figura 3. Observa-se adicionalmente que, embora ométodo 1200 seja exibido em conjunto com o protocolo de obtenção de RO, ele pode serutilizado em conjunto com qualquer outro protocolo ROAP mas, para minimizar ocabeçalho associado ao método 1200, ele poderá ser realizado com apenas umsubconjunto apropriadamente selecionado de protocolos ROAP a qualquer dadomomento. Para uma implementação de sistema DRM OMA prática, algumas dascoridições ou mecanismos de acionamento para a plataforma proposta e/ouprocedimentos de verificação de integridade de SW de DRM descritos acima podemincluir:
1. Os procedimentos de verificação da integridade deSW de DRM do dispositivo podem ser acionados por um ou mais dos seguintes:
IA. Antes que um dispositivo deseje iniciar um novoprotocolo de registro de ROAP com duas passagens, protocolo de união a domínio deduas passagens ou o protocolo de saída de domínio de duas passagens.
IB. Periodicamente, sempre que haja decorrido umperíodo de tempo especificado, tal como Tdev-drm-last-roap desde que o dispositivocompletasse na última vez o protocolo de registro de ROAP de duas passagens,protocolo de união a domínio de duas passagens ou o protocolo de saída de domínio deduas passagens com o mesmo RI.
IC. Periodicamente, sempre que haja decorrido umperíodo de tempo especificado, tal como Tdev-drm-iast-report desde a última vez em que odispositivo houvesse verificado e relatado a sua situação de integridade de SW de DRMpara o mesmo RI.
ID. Sempre que um dispositivo atualizar o seu SW de
DRM.
1È. Sempre que o SW de plataforma for atualizado ou
alterado.
2. Os procedimentos de verificação da integridade deDRM Rl poderão ser realizados por meio de um ou mais dos seguintes:
2A. Sempre que um Rl receber uma indicação dódispositivo que o dispositivo deseja que o Rl verifique a sua situação de integridade deSW de DRM para o dispositivo, seja na forma de uma mensagem isolada ou como partede uma mensagem de protocolo ROAP modificada.
2B. Periodicamente, sempre que houver decorrido umperíodo de tempo especificado, tal como Tr|_drm-last-report, desde o último momento emque o Rl tenha verificado e relatado a sua situação de integridade de SW de DRM para odispositivo.
2C. Sempre que um Rl tenha atualizado o seu SW deDRM.
2D. Sempre que o dispositivo enviar uma solicitação deRO, em casos em que o usuário está obtendo conteúdo com freqüência, tal como comstreaming do conteúdo.
Com relação à verificação da integridade da plataformaentre um dispositivo e um Cl, mecanismos similares ao acima podem ser consideradospara ocorrência periódica e/ou dirigida por evento do processo de verificação daintegridade de SW de DRM.
Os métodos propostos de verificação de plataforma de DRMe verificação de SW de DRM podem ser realizados independentemente entre si, mastambém se contempla que esses procedimentos de verificação podem ser combinadoscomo parte de um grupo de procedimentos. Nesta realização, as etapas de verificaçãode plataforma DRM são consideradas um requisito prévio para as etapas de verificaçãode SW de DRM. Para verificação da integridade entre um dispositivo e um RI, porexemplo, o dispositivo e o Rl estabelecem em primeiro lugar a confiança na plataformacompleta um do outro por meio da realização dos procedimentos de verificação deplataforma DRM conforme descrito acima. Os mecanismos acionadores incluem ascondições de acionador de verificação da plataforma geral. Em seguida, à medida quesurgem as condições do acionador de verificação de SW de DRM, segue-se oprocedimento de verificação de SW de DRM. Observe-se que os dojs tipos deprocedimentos de verificação serão executados quando as suas condições de acionadorcorrespondentes forem atendidas. As etapas de verificação de SW de DRM serãoexecutadas, entretanto, até o término bem sucedido das etapas de verificação deplataforma DRM, ou seja, se a verificação da plataforma DRM falhar entre um dispositivoe um Rl1 o processamento adicional da verificação de SW de DRM1 bem como oprocessamento de ROAP DRM real e o processamento relativo ao uso, falhará.
União e assinatura eletrônica:
Os mecanismos existentes da especificação DRM OMA 2.0para proteger a integridade do protocolo ROAP limita-se à inclusão de assinaturasdigitais (ou verificação da integridade de mensagem) em algumas, mas não todas asmensagens ROAP. Considerando que o protocolo ROAP possui importância central naimplementação do processamento de DRM seguro, é importante salvaguardar e verificarcontinuamente a integridade das informações que são utilizadas e trocadas no protocoloROAP.
Em uma realização alternativa da presente invenção,portanto, são descritos métodos de fortalecimento da integridade do protocolo ROAP pormeio do quê as informações centrais para uma verificação da integridade e autenticaçãoconfiável entre o dispositivo DRM e um Rl podem: (1) ser armazenadas com segurançautilizando métodos de TCG; e (2) ser previamente verificadas antes da transmissão parao outro lado e antes da utilização para processamento no lado em que as informaçõessão armazenadas.
Este método envolve dois procedimentos básicos queutilizam os métodos TCG de assinatura eletrônica (ou seja, criptografia simétrica deinformações alvo e, em seguida, assinatura assimétrica da chave simétrica mais umconjunto de valores PCR que indicam a situação de integridade atual naquele momentoda plataforma ou de componentes de SW específicos) e união (criptografia assimétricade informações alvo com uma chave cuja chave de decifração privada é mantida em ummódulo protegido tal como um TPM). Assinatura eletrônica proporciona o nível mais altode segurança das informações fornecido por criptografia assimétrica, assinaturas digitaise união a um estado confiável do SW de agente de usuário de DRM de dispositivo,conforme indicado pelos valores de PCR protegidos. A união proporciona um alto nívelde proteção utilizando criptografia assimétrica em que a chave de decifração é protegidano interior do TPM.
Os princípios sistemáticos a seguir utilizam assinaturaeletrônica e união para proteger a confidencialidade e a integridade das informações quesão utilizadas nas mensagens ROAP e, desta forma, aumentam indiretamente aresistência da integridade dos próprios protocolos de ROAP. Na discussão à seguir,considera-se que tanto o dispositivo quanto o Rl (ou a parte do Rl que lida com essedispositivo específico) são equipados com um TPM e sustentam funcionalidade total deTPM.
O dispositivo e o Rl podem ambos separar e utilizar umconjunto de duas chaves de armazenagem para unir de forma criptográfica e armazenarseguramente certas informações relativas ao processamento de ROAP para a plataformaconfiável na qual reside o dispositivo ou o RI. Para o dispositivo, essas chaves sãoK_DEV_BIND_A e K_DEV_BIND_B Para o RI, essas chaves são K_RI_BIND_A eK_RI_BIND_B. Estas são chaves assimétricas mantidas por TPM (ou seja, realiza-secriptografia com chave pública e a decifração é realizada com chave privada protegida nointerior de um TPM).Cada um dentre o dispositivo e o RI utiliza um único PCR ouum conjunto de PCRs para processamento de DRM. O dispositivo e o Rl tambémreservam e utilizam uma Chave de Identidade de Confirmação (AIK) para assinareletronicamente certas informações relativas ao processamento de ROAP para aplataforma confiável e seus valores de PCR específicos. Observa-se que as chaves deAIK TCG somente são utilizadas para assinatura de valores PCR. Para o dispositivo, oseu AIK é K_DEV_AIK e, para o RI, o seu AIK é K_RI_AIK. Além disso, a assinaturaeletrônica requer uma chave de armazenagem assimétrica para a operação decriptografia dos dados alvo. Cada um dentre o dispositivo e o Rl reserva e utiliza umachave de armazenagem com este propósito. A chave de armazenagem para o dispositivoé K_DEV_STO_SEAL e a chave de armazenagem para o Rl é K_RI_STO_SEAL.
O método utiliza em seguida uma combinação de assinaturaeletrônica e união com uma medida adicional de proteção à confidencialidade, bem comointegridade, para aumentar a resistência de armazenagem dos vários elementos deinformação envolvidos no processamento de ROAP. A Figura 13, por exemplo, é umdiagrama de fluxo de um método 1300 no qual são utilizadas operações de união eassinatura eletrônica de TPM para proteger a confidencialidade e a integridade deinformação nas várias mensagens que compreendem o protocolo de registro de ROAPem quatro passagens. No método 1300, cada um dentre um dispositivo 1302 e um Rl1304 assina eletronicamente um conjunto seletivo de informações relativas a ROAP eune as informações utilizando dois conjuntos de chaves de armazenagem que cada umtransmite (para o outro lado) ou recebe (do outro lado) durante o transcurso do protocolode registro de quatro passagens.
O dispositivo 1302 assina eletronicamente em primeiro lugaro elemento de informação de ID do dispositivo (que, no caso de DRM OMA, é o hashSHA-1 da chave pública DRM OMA) com a chave de criptografia K_DEV_STO_SEAL e oAIK específico de dispositivo K_DEV_AIK (etapa 1310). Esta informação é unida(utilizando criptografia assimétrica) a outras informações destinadas à mensagem AlôDispositivo com a chave de armazenagem K_DEV_BIND_A (etapa 1310). A mensagemAlô Dispositivo é enviada em seguida do dispositivo 1302 para o Rl 1304 (etapa 1312).
Por meio de assinatura eletrônica de informações tais comoa ID do dispositivo e união das outras informações que compreendem a mensagem AlôDispositivo, o dispositivo 1302 poderá instituir úma política de transmissão da mensagemAlô Dispositivo apenas se e quando o dispositivo 1302 recuperar (ou seja, assinareletronicamente e separar) as informações previamente unidas e assinadaseletronicamente da sua armazenagem protegida, compará-las com os valores atuaisdesses elementos de informação que o SW de DRM pode utilizar e verifica agenuinidade e integridade dos valores atuais. Observa-se que a seleção dos elementosde informação a serem assinados eletronicamente contra unidos neste cenário éfornecida apenas como exemplo. Outros elementos de informação podem ser assinadoseletronicamente e unidos em diferentes combinações sem afetar a operação da presenteinvenção. Outras combinações podem ser derivadas de itens tais como tempo dosistema, qualquer elemento de informação em uma mensagem, algoritmos e nonces.Uma razão de fixação dos nonces é determinar se os nonces são verdadeiramentealeatórios, pois alguns geradores de números aleatórios, especialmente aqueles quepodem ser comprometidos de forma prejudicial, podem repetir o mesmo padrão e geraros mesmos números das suas emissões em períodos de tempo inaceitavelmente curtos.
Õ Rl 1304, mediante recebimento da mensagem AlôDispositivo, une as informações contidas na mensagem Alô Dispositivo à sua chave deunião, K_RI_BIND_A (etapa 1314). Esta etapa permite a armazenagem segura, comintegridade protegida, das informações chave que o Rl 1304 recebeu do dispositivo1302. Alternativamente, o Rl 1304 pode também extrair a ID do dispositivo (ou qualqueroutro elemento de informação) da mensagem Alô Dispositivo e assinar eletronicamenteaquele elemento de informação separadamente utilizando o AIK K_RI_AIK e a chave decriptografia K_RI_STO_SEAL.
O Rl 1304 assina eletronicamente os elementos deinformação ID de Rl e URL de Rl com a chave de criptografia K_RI_STO_SEAL e o AIKK_RI_AIK (etapa 1316). O Rl 1304 também une as outras informações contidas na suamensagem Alô Rl com a chave de armazenagem K_RI_BIND_A (etapa 1316). O Rl 1304envia em seguida a mensagem Alô Rl para o dispositivo 1302 (etapa 1318).
O Rl 1304 transmite a mensagem Alô Rl para o dispositivo1302 somente se e quando o Rl 1304 recuperar em primeiro lugar (ou seja, assinareletronicamente e desunir) as informações previamente unidas e assinadaseletronicamente da armazenagem protegida, compara-as com os valores atuais desseselementos de informação que o SW de DRM Rl pode utilizar e verifica a genuinidade eintegridade dos valores atuais.
O dispositivo 1302, mediante recebimento da mensagemAlô RI, une as informações contidas na mensagem Alô Rl com a segunda chave deunião, ou seja, K_DEV_BIND_B (etapa 1320). Esta etapa permite a armazenagemsegura e com integridade protegida das informações chave que o dispositivo recebeu doRl 1304. Alternativamente, o dispositivo 1302 pode também extrair elementos deinformação selecionados da mensagem Alô Rl recebida (tais como ID de Rl e/ou URL deRI) e os assina eletronicamente utilizando o AIK K_DEV_AIK e a chave de criptografiaK_DEV_STO_SEAL, enquanto une simplesmente o restante das informações recebidasna mensagem Alô Rl utilizando K_DEV_BIND_B.
O dispositivo 1302 assina eletronicamente a cadeia decertificados, o hash de DCF e o Tempo de Solicitação com K_DEV_AIK eK_DEV_STO_SEAL (etapa 1322). O dispositivo 1302 envia em seguida a mensagem deSolicitação de Registro para o Rl 1304 (etapa 1324). O dispositivo 1302 envia apenas amensagem de Solicitação de Registro caso o dispositivo recupere (ou seja, assineeletronicamente e separe) as informações previamente unidas e assinadaseletronicamente, compara os valores recuperados com os valores temporários atuaisutilizados na memória SW de DRM e verifica a genuinidade e integridade dos valoresatuais. Mediante recebimento da mensagem de Solicitação de Registro, o Rl 1304 une asinformações da mensagem de Solicitação de Registro com a chave de uniãoK_RI_BIND_B (etapa 1326).
O Rl 1304 assina eletronicamente as chaves, a cadeia decertificados e os ROs com K_RI_AIK e K_RI_STO_SEAL (etapa 1328). O Rl 1304 uneisso em seguida com outras informações a serem incluídas na mensagem de Respostade Registro com a chave de união K_RI_BIND_A (etapa 1328). O Rl 1304 envia emseguida a mensagem de Resposta dè Registro para o dispositivo 1302 (etapa 1330). ÒRl 1304 somente envia a mensagem de Resposta de Registro caso o Rl recupere (ouseja, assine eletronicamente e separe) as informações previamente assinadaseletronicamente e unidas, compara os valores recuperados com os valores temporáriosatuais utilizados na memória SW de DRM e verifica a genuinidade e integridade dosvalores atuais. Mediante recebimento da mensagem de Resposta de Registro, odispositivo 1302 une as informações geradas por Rl da mensagem de Resposta deRegistro com a chave de união K_DEV_BIND_B (etapa 1332).
Observa-se que a assinatura eletrônica e a união podem serutilizadas com qualquer outro protocolo ROAP. O método 1300 descrito acima é umexemplo e os seus princípios podem ser aplicados igualmente a qualquer outro protocoloROAP.
Os dados obtidos durante as trocas de mensagens deROAP DRM OMA necessitarão ser decifradas e novamente assinadas em um novo valorde PCR de configuração, caso a entidade que cifrou ou assinou eletronicamente osdados tenha atualizado o seu OS de plataforma ou o SW de DRM. Quando ocorrer esseevento, os dados relativos a ROAP DRM que haviam sido cifrados ou assinadosdigitalmente para um estado específico (ou, de forma equivalente, para um conjuntoespecífico de valores PCR) necessitarão ser primeiramente decifrados e novamentecifrados em seguida no estado mais atual do OS da plataforma atualizada. Existemmétodos no estado da técnica que abordam esta necessidade de procedimento econsidera-se que esses procedimentos terão lugar para garantir a decifração e novacifragem adequada de qualquer dado relativo a ROAP DRM que seja armazenadoutilizando cifragem ou assinatura eletrônica conforme proposto no presente.Um aprimoramento adicional é a agregação de um campoaos formatos de mensagens ROAP existentes para indicar a capacidade de TCG dodispositivo de envio. O campo de capacidade de TCG pode assistir no aumento dainteroperabilidade com dispositivos herdados realizando uma determinação inicial se aentidade receptora pode sustentar procedimentos e informações relativas a TCG.
Modificação da mensagem Alô Dispositivo e sua derivação:
Uma primeira modificação é a adição de uma novaIndicação da Capacidade de TPM (DTCI)1 que é um indicador da capacidade de TPM dodispositivo em um novo elemento do parâmetro de Extensão existente da mensagem AlôDispositivo ou, alternativa e preferencialmente, adicionar o DTCI na forma de um novoprimeiro parâmetro no cabeçalho da mensagem Alô Dispositivo. O DTCI pode ter um bit(que indica a ausência ou a presença de um TPM de dispositivo) ou alguns bits (queindicam mais informações granulares sobre a capacidade de TPM do dispositivo). Caso oDTCI seja inserido na forma de um novo parâmetro, ele deverá ser preferencialmenteinserido como o primeiro parâmetro, antes do parâmetro de ID do dispositivo, de talforma que o Rl possa saber antes de outros parâmetros que o dispositivo possui certascapacidades de TPM e processar as informações a partir dos últimos parâmetros (taiscomo a ID do dispositivo) utilizando o DTCI. O benefício das informações de DTCI é queelas permitem que o Rl avalie a confiabilidade do dispositivo na sua interação adicionalcom o dispositivo no restante dos protocolos de ROAP.
Uma segunda modificação é o uso da credencial de EKTGC específica de dispositivo ou da credencial de AIK TCG para realizar hash e derivar aID do dispositivo DRM. O benefício desta modificação é que a credencial de EK e/ou acredencial de AIK é altamente protegida pelo TPM no interior do dispositivo e, destaforma, a derivação da ID do dispositivo DRM de qualquer dessas credenciais fortalece aintegridade das informações de ID do dispositivo DRM.
Uma terceira modificação é a adição de um novo parâmetrode assinatura em que a mensagem Alô Dispositivo, até a assinatura, exclusive, éassinada com a chave privada de AIK do dispositivo, destinada a ser verificada pelo RI.O benefício desta modificação é a proteção da integridade da capacidade de TPM dodispositivo contra a primeira interação entre o dispositivo e o RI. O uso da chave privadade AIK do dispositivo, que é protegida com alta segurança pelo TPM, fortalece aintegridade da operação de assinatura.
As Tabelas 12 e 13 exibem dois formatos possíveis para amensagem Alô Dispositivo modificada. A Tabela 12 exibe o formato de uma mensagemcom o bit DTCI como o primeiro parâmetro. A Tabela 13 exibe o formato da mensagemAlô Dispositivo em.que o DTCI é um novo elemento do parâmetro de Extensão existente.
Tabela 12Formato de Mensagem Alô Dispositivo Modificada com um Parâmetro DTCISeparado
<table>table see original document page 52</column></row><table>
Tabela 13 Formato de Mensagem Alô Dispositivo Modificada com DTCI nas Extensões
<table>table see original document page 52</column></row><table><table>table see original document page 53</column></row><table>
Modificação da mensagem Alô Rl e sua derivação:
Uma primeira modificação é a adição de uma novaIndicação de Capacidade de TPM Rl (RTCI)1 que é um indicador da capacidade de TPMdo Rl na forma de um novo elemento do parâmetro de Extensão existente da mensagemAlô Rl ou, alternativa e preferencialmente, adicionar o RTCI como um novo primeiroparâmetro no cabeçalho da mensagem Alô RI. O benefício desta modificação é que elapermite que o dispositivo utilize as informações de RTCI para avaliar a confiabilidade doRl e utilize essas informações na sua interação adicional com o Rl no restante dosprocedimentos de protocolo de ROAP.
Uma segunda modificação é o uso do TPM Rl para fornecerum número pseudoaleatório para a ID da sessão. O benefício desta modificação é que oTPM fornece um gerador de números pseudoaleatórios com base em hardwarealtamente seguro. O uso do TPM para gerar um número pseudoaleatório que é utilizadocomo a ID da sessão fortalece a segurança do protocolo.
Uma terceira modificação é o uso da credencial Rl TCG EKou da credencial TCG AIK pertencente ao TPM Rl para derivar a ID de RI. O benefíciodesta modificação é que a credencial de EK e/ou a credencial de AIK é altamenteprotegida pelo TPM no interior do dispositivo e derivação da ID de dispositivo DRM dequalquer dessas credenciais fortalece a integridade da informação de ID do dispositivoDRM.
Uma quarta modificação é o uso do TPM Rl para fornecer ononce de RI. O benefício desta modificação é que o TPM fornece um gerador denúmeros pseudoaleatórios com base em hardware altamente seguro. O uso do TPMpara gerar o nonce de Rl fortalece a integridade do nonce que é utilizado na mensagemAlô RI.
Uma quinta modificação é a inclusão das credenciais deTCG de dispositivo na âncora de Rl confiável do dispositivo. As credenciais de TCG dodispositivo incluem a credencial de EK, a credencial de AIK, a credencial de plataforma eas credenciais de atendimento que o Rl adquiriu previamente de um CA TCG confiável.O benefício desta modificação é aumentar a confiança que o dispositivo pode ter sobre amensagem Alô RI.
Uma sexta modificação é a adição de uma assinatura damensagem Alô Rl até a assinatura realizada com a chave privada de AIK de RI,exclusive, em que a chave pública de AIK de Rl foi previamente distribuída para odispositivo como parte da mensagem Alô RI. O benefício desta modificação é a proteçãoda integridade do RTCI contra a primeira interação entre o Rl e o dispositivo. O uso dachave privada de AIK de RI, que é protegida de forma altamente segura pelo TPM RI,fortalece a integridade da operação de sinalização.
As Tabelas 14 e 15 exibem dois formatos possíveis para amensagem Alô Rl modificada. A Tabela 14 exibe o formato da mensagem Alô Rl com obit RTCI como o primeiro parâmetro. A Tabela 15 exibe o formato da mensagem Alô Rlem que o RTCI é um novo elemento do parâmetro de Extensão existente.
Tabela 14
Formato de Mensagem Alô Rl Modificada
<table>table see original document page 54</column></row><table><table>table see original document page 55</column></row><table>
Tabela 15
<table>table see original document page 55</column></row><table><table>table see original document page 56</column></row><table>
Modificação da mensagem Solicitação de Registro e sua derivação:
Uma primeira modificação é o uso do TPM de dispositivopara fornecer o nonce de dispositivo. O benefício desta modificação é que o TPM forneceum número pseudoaleatório seguro e confiável apropriado para uso para o nonce.
Uma segunda modificação é a inclusão das credenciais deTCG de dispositivo na cadeia de certificados. A inclusão das credenciais de TCG dedispositivo pode apresentar-se em substituição ou em adição às credenciais dedispositivo DRM OMA 2.0 existentes. O benefício da inclusão de credenciais TCG (taiscomo o credencial EK1 credenciais AIK1 credenciai de plataforma ou a credencial deatendimento) é o aumento da confiabilidade do dispositivo.
Uma terceira modificação é a inclusão de uma lista dos CAsTCG de confiança do Rl no elemento de âncora Rl confiável. A inclusão do CA TCG deconfiança pelo Rl pode apresentar-se em substituição ou em adição às listas deelementos de âncora confiáveis Rl DRM OMA 2.0 existentes. O benefício de inclusão dalista dos CAs TCG confiáveis para o Rl é o aumento da confiabilidade do dispositivo.
Uma quarta modificação é a inclusão de informações sobreο TPM do dispositivo no elemento Detalhes do Dispositivo do parâmetro de Extensões. Obenefício da inclusão desta informação é o aumento da confiabilidade sobre o dispositivopara o RI.
Uma quinta modificação é a realização da Assinatura com oAIK do dispositivo utilizado para assinar a mensagem Alô Dispositivo modificada. Obenefício desta modificação é o aumento da confiabilidade do dispositivo e da mensagemde Solicitação de Registro devido à natureza altamente protegida do AIK de dispositivo.
A Tabela 16 exibe o formato da mensagem de Solicitação
de Registro modificada.
Tabela 16
<table>table see original document page 57</column></row><table><table>table see original document page 58</column></row><table>
Modificação da mensagem de Resposta de Registro e suaderivação:
Uma primeira modificação é o uso do TPM Rl para fornecerum número pseudoaleatório para a ID de sessão. O benefício desta modificação é que oTPM fornece um gerador de números pseudoaleatórios com base em hardware com altasegurança. O uso do TPM para gerar um número pseudoaleatório que é empregadocomo a ID da sessão fortalece a segurança do protocolo.
Uma segunda modificação é o uso da credencial de EKTCG Rl ou da credencial de AIK TCG pertencente ao TPM Rl para derivar a ID de RI. Obenefício desta modificação é que a credencial de EK e/ou a credencial de AIK éaltamente protegida pelo TPM no interior do dispositivo e a derivação da ID do dispositivoDRM de qualquer destas credenciais fortalece a integridade da informação de ID dodispositivo de DRM.
Uma terceira modificação é o uso do TPM Rl para fornecero nonce de RI. O benefício desta modificação é que o TPM Rl fornece um númeropseudoaleatório seguro e confiável apropriado para uso como o nonce.
Uma quarta modificação é a inclusão de uma lista dos CAsTCG confiáveis para o dispositivo no elemento de âncora de dispositivo confiável. Ainclusão dos CAs TCG confiáveis para o dispositivo pode existir em substituição ou emadição às listas de elementos de âncora de dispositivos confiáveis DRM OMA 2.0existentes. O benefício de inclusão da lista de CAs TCG confiáveis pelo dispositivo é oaumento da confiabilidade do RI.
Uma quinta modificação é a execução da Assinatura com oAIK Rl utilizado para assinar a mensagem Alô Rl modificada: O beneficio destamodificação é o aumento da confiabilidade do Rl e da mensagem de Resposta deRegistro devido à natureza altamente protegida do AIK RI.
A Tabela 17 exibe o formato da mensagem de Resposta deRegistro modificada.
Tabela 17
Formato de Mensagem de Resposta de Registro Modificada
<table>table see original document page 58</column></row><table><table>table see original document page 59</column></row><table>
Modificação da mensagem de Solicitação de RO e suaderivação:
Uma primeira modificação é o uso do TPM para criar o. hashSHA-1 de uma credencial de TCG selecionada (uma credencial EK1 credencial AIK1credencial de plataforma ou uma credencial de atendimento) para uso como a ID dedispositivo. O benefício desta modificação é que as credenciais são altamente protegidaspelo TPM e, desta forma, derivação da ID de dispositivo de uma dessas credenciaisfortalece a integridade da informação de ID de dispositivo.
Uma segunda modificação é o uso do TPM de dispositivopara gerar o nonce de dispositivo. O benefício desta modificação é que um nonce geradopelo TPM é seguro, devido à capacidade de geração de números pseudoaleatóriosprotegidos do TPM.
Uma terceira modificação é a inclusão das credenciais deTCG de dispositivo na cadeia de certificado. A inclusão das credenciais de TCG podeocorrer em substituição ou em adição às credenciais do dispositivo DRM OMA 2.0existentes. O benefício da inclusão das credenciais de TCG é o aumento daconfiabilidade do dispositivo.
Uma quarta modificação é a assinatura do Hash DCFopcional com um AIK de dispositivo no parâmetro Extensão. O benefício destamodificação é a alta proteção dos AIKs de dispositivos, de forma a tornar a assinatura deDCF mais segura.
Uma quinta modificação é a assinatura da mensagem deSolicitação de RO com o AIK de dispositivo utilizado para assinar as respostas bemsucedidas mais recentes para uma mensagem de Solicitação de Registro. O benefíciodesta modificação é a adição à confiabilidade da mensagem de Solicitação de RO e Rldevido à natureza altamente protegida do AIK RI.
A Tabela 18 ilustra o formato da mensagem de Solicitaçãode RO modificada.
Tabela 18
Formato de Mensagem de Solicitação de RO Modificada
<table>table see original document page 60</column></row><table><table>table see original document page 61</column></row><table>
Modificação da mensagem de resposta de RO e suaderivação:
Uma modificação é o uso do TPM de Rl para assinar amensagem de Resposta de RO com o mesmo AiK TPM Rl utilizado na assinatura damensagem de Resposta de Registro bem sucedida mais recente. O benefício destamodificação é o aumento da confiabilidade do Rl e da mensagem de Resposta de ROdevido à natureza altamente protegida do AIK RI.
A Tabela 19 ilustra o formato de mensagem de Solicitaçãode RO modificada.
Tabela 19
Formato de Mensagens de Resposta de RO Modificadas
<table>table see original document page 61</column></row><table><table>table see original document page 62</column></row><table>
Embora as características e os elementos da presenteinvenção sejam descritos nas realizações preferidas em combinações específicas, cadacaracterística ou elemento pode ser utilizado isoladamente (sem as demaiscaracterísticas e elementos das realizações preferidas) ou em várias combinações comou sem outras características e elementos da presente invenção.Realizações
1. Método de realização de verificação da integridade de plataformas entre uma entidadesolicitante (RE) e uma entidade alvo (TE), que compreende as etapas de: envio de umasolicitação da RE para a TE para solicitar à TE que relate as suas credenciais de grupocomputação confiável (TCG); envio das credenciais de TCG de TE da TE para a RE;encaminhamento das credenciais de TCG de TE da RE para um dispositivo de respostade protocolo de situação de certificação online (OCSP) para verificação; relato dasituação de verificação das credenciais de TCG de TE do dispositivo de resposta deOCSP para a RE; envio de uma solicitação da RE para a TE para solicitar que a TErelate a sua própria situação de integridade da plataforma; verificação da situação deintegridade de plataforma da TE; e envio de um indicador da situação de integridade daplataforma da TE para a RE.
2. Método conforme a realização 1, em que a RE é um emissor de direitos (RI) e á TE éum dispositivo.
3. Método conforme a realização 2, em que o método é realizado antes que o dispositivoinicie um protocolo de registro de protocolo de obtenção de objetos de direitos (ROAP)com o Rl por meio de envio pelo dispositivo de um acionador para o Rl para iniciar ométodo.
4. Método conforme qualquer das realizações 2 ou 3, em que o método é realizadoperiodicamente com base em um tempo decorrido a partir do momento em que odispositivo registrou-se mais recentemente com o RI.
5. Método conforme qualquer das realizações 2 a 4, em que o método é realizadoperiodicamente com base em um tempo decorrido a partir do momento em que odispositivo verificou mais recentemente a sua situação de integridade de plataforma parao RI.
6. Método conforme a realização 1, em que a RE é um dispositivo e a TE é um emissorde direitos (RI).
7. Método conforme a realização 6, em que o método é realizado periodicamente combase no tempo decorrido a partir do momento em que o Rl verificou mais recentemente asua situação de integridade de plataforma para o dispositivo.
8. Método conforme a realização 1, em que a RE é um emissor de conteúdo (Cl) e a TEé um dispositivo.
9. Método conforme a realização 8, em que o método é realizado periodicamente combase no tempo decorrido a partir do momento em que o dispositivo verificou maisrecentemente a sua situação de integridade de plataforma para o Cl.
10. Método conforme qualquer das realizações 8 ou 9, em que o método é realizadoquando o dispositivo compra conteúdo do Cl.
11. Método conforme a realização 1, em que a RE é um dispositivo e a TE é um emissorde conteúdo (Cl).
12. Método conforme a realização 11, em que o método é realizado periodicamente combase no tempo decorrido a partir do momento em que o Cl verificou mais recentemente asua situação de integridade de plataforma para o dispositivo.
13. Método conforme qualquer das realizações 11 ou 12, em que o método é realizadoquando o dispositivo compra conteúdo do Cl.
14. Método conforme a realização 1, em que o método é realizado como parte de umprocesso de protocolo de obtenção de objeto de direitos (ROAP).
15. Método conforme a realização 14, em que o método é realizado antes do processode ROAP.
16. Método conforme qualquer das realizações 14 ou 15, em que o processo de ROAP émodificado para incorporar o método como parte do processo de ROAP.
17. Método de realização de verificação da integridade de software de administração dedireitos digitais (DRM) entre uma entidade solicitante (RE) e uma entidade alvo (TE), quecompreende as etapas de: envio de uma solicitação da RE para a TE para que a TErealize uma verificação da integridade de software DRM; verificação da integridade desoftware DRM pela TE; e envio de um indicador da situação de integridade de softwareDRM da TE para a RE.
18. Método conforme a realização 17, em que a RE é um emissor de direitos (RI) e a TEé um dispositivo.
19. Método conforme a realização 18, em que o dispositivo envia um acionador para o Rlpara iniciar o método antes que o dispositivo inicie um processo de protocolo deobtenção de objeto de direitos (ROAP).20. Método conforme a realização 19, em que o processo ROAP é selecionado a partirdo grupo que consiste de: registro de duas passagens, união a domínio de duaspassagens e saída de domínio de duas passagens.
21. Método conforme qualquer das realizações 19 ou 20, em que o método é realizado5 periodicamente após o término pelo dispositivo de um processo de protocolo de obtenção
de objeto de direitos (ROAP) com o RI.
22. Método conforme qualquer das realizações 19 a 21, em que o processo ROAP éselecionado a partir do grupo que consiste de: registro de duas passagens, união adomínio de duas passagens e saída de domínio de duas passagens.
23. Método conforme qualquer das realizações 18 a 22, em que o método é realizadoperiodicamente após a verificação e relatório pelo dispositivo da sua situação deintegridade de software DRM para o RI.
24. Método conforme qualquer das realizações 18 a 23, em que o método é realizadoapós a atualização pelo dispositivo do seu software DRM.
25. Método conforme qualquer das realizações 18 a 24, em que o Rl solicita aodispositivo que realize uma verificação da integridade de software DRM em umdispositivo de mídia no dispositivo.
26. Método conforme a realização 17, em que a RE é um dispositivo e a TE é umemissor de direitos (RI).
27. Método conforme a realização 26, em que o método é realizado mediante início pelodispositivo.
28. Método conforme qualquer das realizações 26 ou 27, em que o método é umprocesso isolado.
29. Método conforme qualquer das realizações 26 a 28, em que o método é uma parte25 de um processo de protocolo de obtenção de objeto de direitos modificado.
30. Método conforme qualquer das realizações 26 a 29, em que o método é realizadoperiodicamente após a verificação e relatório pelo Rl da sua situação de integridade desoftware DRM para o dispositivo.
31. Método conforme qualquer das realizações 26 a 30, em que o método é realizadoapós a atualização pelo Rl do seu software DRM.
32. Método conforme qualquer das realizações 26 a 31, em que o método é realizadoantes do envio pelo dispositivo de uma solicitação de objeto de direitos para o RI.
33. Método conforme qualquer das realizações 26 a 32, em que o método é realizadoperiodicamente durante uma solicitação do dispositivo para o Rl para streaming doconteúdo.
34. Método conforme a realização 17, em que a RE é um emissor de conteúdo (Cl) e aTE é um dispositivo.
35. Método conforme a realização 34, em que o dispositivo envia um acionador para o Clpara iniciar o método antes que o dispositivo inicie um processo de protocolo deobtenção de objeto de direitos (ROAP).
36. Método conforme qualquer das realizações 34 ou 35, em que o método é realizadoperiodicamente após o término pelo dispositivo de um processo de protocolo de obtençãode objetos de direitos (ROAP) com o Cl.
37. Método conforme qualquer das realizações 34 a 36, em que o método é realizadoperiodicamente após a verificação e relatório pelo dispositivo da sua situação deintegridade de software DRM para o Cl.
38. Método conforme qualquer das realizações 34 a 37, em que o método é realizadoapós a atualização pelo dispositivo do seu software DRM.
39. Método conforme qualquer das realizações 34 a 38, em que o Cl solicita aodispositivo que realize uma verificação de integridade de software DRM em umdispositivo de mídia no dispositivo.
40. Método conforme a realização 17, em que a RE é um dispositivo e a TE é umemissor de conteúdo (Cl).
41. Método conforme a realização 40, em que o método é realizado mediante início pelodispositivo.
42. Método conforme qualquer das realizações 40 ou 41, em que o método é umprocesso isolado.
43. Método conforme qualquer das realizações 40 a 42, em que o método é parte de umprocesso de protocolo de obtenção de objetos de direitos modificado.
44. Método conforme qualquer das realizações 40 a 43, em que o método é realizadoperiodicamente após a verificação e relatório pelo Cl da sua situação de integridade desoftware DRM para o dispositivo.
45. Método conforme qualquer das realizações 40 a 44, em que o método é realizadoapós a atualização pelo Cl do seu software DRM.
46. Método conforme qualquer das realizações 40 a 45, em que o método é realizadoantes do envio pelo dispositivo de uma solicitação de objeto de direitos para o Cl.
47. Método conforme qualquer das realizações 40 a 46, em que o método é realizadoperiodicamente durante uma solicitação do dispositivo para o Cl para realização destreaming de conteúdo.
48. Método de fortalecimento da integridade de mensagens de protocolo de obtenção deobjeto de direitos (ROAP) trocadas entre duas entidades, que compreende as etapas de:armazenagem segura de informações a serem utilizadas nas mensagens ROAP em cadaentidade utilizando métodos de computação confiáveis; e verificação prévia dasinformações a serem utilizadas nas mensagens ROAP antes da sua utilização comrelação à mensagem ROAP.
49. Método conforme a realização 48, em que a etapa de armazenagem inclui aassinatura digital das informações e união das informações.
50. Método conforme a realização 49, em que a etapa de assinatura digital inclui acriptografia simétrica das informações com uma chave de criptografia simétrica eassinatura assimétrica da chave de criptografia simétrica e um conjunto de valores queindicam uma situação de integridade atual de um objeto.
51. Método conforme a realização 50, em que a etapa de assinatura inclui a utilização dasituação de integridade de uma plataforma sobre a qual opera a entidade.
52. Método conforme qualquer das realizações 50 ou 51, em que a etapa de assinaturainclui o uso da situação de integridade de um componente de software da entidade.
53. Método conforme qualquer das realizações 49 a 52, em que a etapa de união inclui acriptografia assimétrica das informações com uma chave cuja chave de decifraçãoprivada é armazenada em um módulo protegido na entidade.
54. Método conforme a realização 53, em que o módulo protegido é um módulo deprocessamento confiável (TPM).
55. Método conforme a realização 54, em que o TPM é utilizado para derivar parâmetrospara uso nas mensagens ROAP.
56. Método conforme qualquer das realizações 48 a 55, em que as informações sãoselecionadas a partir do grupo que consiste de: uma identificação de dispositivo,identificador de emissor de direitos, certificado, cadeia de certificados, valor de temporelativo à administração de direitos digitais, objeto de direitos, algoritmo e nonce.
57. Método conforme qualquer das realizações 48 a 56, em que o método é aplicado atodas as mensagens ROAP.
58. Método conforme qualquer das realizações 48 a 56, em que o método é aplicadoseparadamente da mensagem ROAP.
59. Método conforme qualquer das realizações 48 a 56, em que o método é integrado àgeração e transmissão das mensagens ROAP.
60. Método conforme qualquer das realizações 48 a 56, que compreende adicionalmentea etapa de adição de um campo a mensagens ROAP existentes para indicar umacapacidade de computação confiável da entidade remetente.
61. Sistema configurado para realizar um método conforme qualquer das realizações 1 a 60.
62. Circuito integrado configurado para realizar um método conforme qualquer dasrealizações 1 a 60.
Claims (30)
1. Método de realização de verificação da integridade deplataforma entre uma entidade solicitante (RE) e uma entidade alvo (TE), caracterizadopelo fato de que compreende:- recebimento de uma solicitação da RE para a TE para relatar credenciais de grupocomputação confiável (TCG) da TE;- envio das credenciais de TCG da TE para a RE;- recebimento de uma solicitação da RE para a TE para relatar situação de integridadede plataforma da TE;- verificação da situação de integridade de plataforma da TE; e- envio de um indicador da situação de integridade da plataforma para a RE.
2. Método conforme a reivindicação 1, caracterizado pelofato de que a RE é um emissor de direitos (RI) e a TE é um dispositivo.
3. Método conforme a reivindicação 2, caracterizado pelofato de que o método é realizado antes que o dispositivo inicie um protocolo de registrode protocolo de obtenção de objetos de direitos (ROAP) com o Rl por meio de envio pelodispositivo de um acionador para o Rl para iniciar o método.
4. Método conforme a reivindicação 2, caracterizado pelofato de que o método é realizado periodicamente com base em um tempo decorrido apartir do momento em que o dispositivo registrou-se mais recentemente com o RI.
5. Método conforme a reivindicação 2, caracterizado pelofato de que o método é realizado periodicamente com base em um tempo decorrido apartir do momento em que o dispositivo verificou mais recentemente a sua situação deintegridade de plataforma para o RI.
6. Método conforme a reivindicação 1, caracterizado pelofato de que a RE é um emissor de conteúdo (Cl) e a TE é um dispositivo.
7. Método conforme a reivindicação 6, caracterizado pelofato de que o método é realizado periodicamente com base no tempo decorrido a partirdo momento em que o dispositivo verificou mais recentemente a sua situação deintegridade de plataforma para o Cl.
8. Método conforme a reivindicação 6, caracterizado pelofato de que o método é realizado quando o dispositivo compra conteúdo do Cl.
9. Método de realização de verificação da integridade desoftware de administração de direitos digitais (DRM) entre uma entidade solicitante (RE)e uma entidade alvo (TE), caracterizado pelo fato de que compreende:- recebimento de uma solicitação da RE para a TE para realizar uma verificação daintegridade de software DRM;- verificação da integridade de software DRM pela TE; e- envio de um indicador da situação de integridade de software DRM para a RE.
10. Método conforme a reivindicação 9, caracterizado pelofato de que a RE é um emissor de direitos (RI) e a TE é um dispositivo.
11. Método conforme a reivindicação 10, caracterizado pelofato de que o dispositivo envia um acionador para o Rl para iniciar o método antes que odispositivo inicie um processo de protocolo de obtenção de objeto de direitos (ROAP).
12. Método conforme a reivindicação 11, caracterizado pelofato de que o processo ROAP é selecionado a partir de um dos seguintes: registro deduas passagens, união a domínio de duas passagens e saída de domínio de duaspassagens.
13. Método conforme a reivindicação 10, caracterizado pelofato de que o método é realizado periodicamente após o término pelo dispositivo de umprocesso de protocolo de obtenção de objeto de direitos (ROAP) com o RI.
14. Método conforme a reivindicação 13, caracterizado pelofato de que o processo ROAP é selecionado a partir de pelo menos um dos seguintes:registro de duas passagens, união a domínio de duas passagens e saída de domínio deduas passagens.
15. Método conforme a reivindicação 10, caracterizado pelofato de que o método é realizado periodicamente após a verificação e relatório pelodispositivo da sua situação de integridade de software para o RI.
16. Método conforme a reivindicação 10, caracterizado pelofato de que o método é realizado após a atualização pelo dispositivo do seu softwareDRM.
17. Método conforme a reivindicação 10, caracterizado pelofato de que o Rl solicita ao dispositivo que realize uma verificação da integridade desoftware DRM em um dispositivo de mídia no dispositivo.
18. Método conforme a reivindicação 9, caracterizado pelofato de que a RE é um emissor de conteúdo (Cl) e a TE é um dispositivo.
19. Método conforme a reivindicação 18, caracterizado pelofato de que o dispositivo envia um acionador para o Cl para iniciar o método antes que odispositivo inicie um processo de protocolo de obtenção de objeto de direitos (ROAP).
20. Método conforme a reivindicação 18, caracterizado pelofato de que o método é realizado periodicamente depois que o dispositivo tenhacompletado um processo de protocolo de obtenção de objeto de direitos (ROAP) com oCl.
21. Método conforme a reivindicação 18, caracterizado pelofato de que o método é realizado periodicamente após a verificação e relatório pelodispositivo da sua situação de integridade de software DRM para o Cl.
22. Método conforme a reivindicação 18, caracterizado pelofato de que o método é realizado após a atualização pelo dispositivo do seu softwareDRM.
23. Método conforme a reivindicação 18, caracterizado pelofato de que o Cl solicita ao dispositivo que realize uma verificação de integridade desoftware DRM em um dispositivo de mídia no dispositivo.
24. Método de fortalecimento da integridade de mensagensde protocolo de obtenção de objeto de direitos (ROAP) trocadas entre duas entidades,caracterizado pelo fato de que compreende:- armazenagem segura de informações a serem utilizadas nas mensagens ROAP emcada entidade utilizando métodos de computação confiáveis; e- verificação prévia das informações a serem utilizadas nas mensagens ROAP antes dasua utilização com relação à mensagem ROAP'.
25. Método conforme a reivindicação 24, caracterizado pelofato de que a armazenagem inclui:- assinatura digital das informações; e- união das informações.
26. Método conforme a reivindicação 25, caracterizado pelofato de que a etapa de assinatura digital inclui:- criptografia simétrica das informações com uma chave de criptografia simétrica; e- assinatura assimétrica da chave de criptografia simétrica e um conjunto de valores queindicam uma situação de integridade atual de um objeto.
27. Método conforme a reivindicação 25, caracterizado pelofato de que a união inclui a criptografia assimétrica das informações com uma chave cujachave de decifração privada é armazenada em um módulo protegido na entidade.
28. Método conforme a reivindicação 27, caracterizado pelofato de que o módulo protegido é um módulo de processamento confiável (TPM) quederiva parâmetros de uso nas mensagens ROAP.
29. Método conforme a reivindicação 24, caracterizado pelofato de que as informações são selecionadas a partir de pelo menos um dos seguintes:uma identificação de dispositivo, identificador de emissor de direitos, certificado, cadeiade certificados, valor de tempo relativo à administração de direitos digitais, objeto dedireitos, algoritmo e nonce.
30. Método conforme a reivindicação 24, caracterizado pelofato de que compreende a adição de um campo a mensagens ROAP existentes paraindicar uma capacidade de computação confiável da entidade remetente.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US79815206P | 2006-05-05 | 2006-05-05 | |
| US60/798,152 | 2006-05-05 | ||
| PCT/US2007/010951 WO2008100264A2 (en) | 2006-05-05 | 2007-05-04 | Digital rights management using trusted processing techniques |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0710321A2 true BRPI0710321A2 (pt) | 2011-08-09 |
Family
ID=39679410
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0710321-2A BRPI0710321A2 (pt) | 2006-05-05 | 2007-05-04 | administração de direitos digitais utilizando métodos de processamento confiáveis |
Country Status (16)
| Country | Link |
|---|---|
| US (2) | US8769298B2 (pt) |
| EP (3) | EP2981040A1 (pt) |
| JP (3) | JP5181094B2 (pt) |
| KR (4) | KR101018368B1 (pt) |
| CN (2) | CN101573936B (pt) |
| AR (1) | AR060774A1 (pt) |
| AU (1) | AU2007347234B2 (pt) |
| BR (1) | BRPI0710321A2 (pt) |
| CA (1) | CA2651436A1 (pt) |
| HK (1) | HK1136412A1 (pt) |
| IL (1) | IL195129A (pt) |
| MX (1) | MX2008014168A (pt) |
| RU (3) | RU2419235C2 (pt) |
| SG (1) | SG171651A1 (pt) |
| TW (3) | TWI469603B (pt) |
| WO (1) | WO2008100264A2 (pt) |
Families Citing this family (93)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100619981B1 (ko) * | 2005-01-08 | 2006-09-11 | 엘지전자 주식회사 | 이동 통신 단말기의 ｄｒｍ 기능 개선 방법 |
| KR20070050712A (ko) | 2005-11-11 | 2007-05-16 | 엘지전자 주식회사 | Srm의 디지털 저작권 관리 방법 및 장치 |
| KR100834752B1 (ko) * | 2006-02-17 | 2008-06-05 | 삼성전자주식회사 | 컨텐츠의 라이센스를 전달하기 위한 장치 및 방법 |
| US20070250617A1 (en) * | 2006-04-21 | 2007-10-25 | Pantech Co., Ltd. | Method for managing user domain |
| KR101018368B1 (ko) | 2006-05-05 | 2011-03-04 | 인터디지탈 테크날러지 코포레이션 | 트러스티드 프로세싱 기술을 사용하는 디지탈 권리 관리 |
| KR100941535B1 (ko) * | 2006-06-09 | 2010-02-10 | 엘지전자 주식회사 | 디지털 저작권 관리에서 장치의 도메인 탈퇴 방법, 그 장치및 그 시스템 |
| CN100446017C (zh) * | 2006-06-13 | 2008-12-24 | 华为技术有限公司 | 数字版权备份和恢复方法及系统 |
| KR101013686B1 (ko) * | 2006-06-29 | 2011-02-10 | 엘지전자 주식회사 | Ｄｒｍ에서 유저 도메인 내의 장치 관리 방법 및 시스템 |
| US20080047006A1 (en) * | 2006-08-21 | 2008-02-21 | Pantech Co., Ltd. | Method for registering rights issuer and domain authority in digital rights management and method for implementing secure content exchange functions using the same |
| US9112874B2 (en) * | 2006-08-21 | 2015-08-18 | Pantech Co., Ltd. | Method for importing digital rights management data for user domain |
| TW200820714A (en) * | 2006-10-17 | 2008-05-01 | Sunplus Technology Co Ltd | Method of exchanging multimedia data for open mobile alliance |
| GB0701518D0 (en) * | 2007-01-26 | 2007-03-07 | Hewlett Packard Development Co | Methods, devices and data structures for protection of data |
| DE102007016117A1 (de) * | 2007-04-03 | 2008-10-16 | Siemens Ag | Verfahren und System zum Bereitstellen eines REL-Tokens |
| EP2153557A4 (en) * | 2007-04-23 | 2013-07-03 | Lg Electronics Inc | METHOD OF USE OF CONTENT, METHOD FOR THE COMMON USE OF CONTENT AND DEVICE BASED ON THE SECURITY LEVEL |
| US8612773B2 (en) * | 2007-05-03 | 2013-12-17 | International Business Machines Corporation | Method and system for software installation |
| CN101682505B (zh) * | 2007-05-07 | 2013-10-23 | Lg电子株式会社 | 用于安全通信的方法和系统 |
| US8539233B2 (en) * | 2007-05-24 | 2013-09-17 | Microsoft Corporation | Binding content licenses to portable storage devices |
| KR20080104594A (ko) * | 2007-05-28 | 2008-12-03 | 삼성전자주식회사 | 오프라인 장치를 위한 온라인 인증서 검증 장치 및 방법 |
| US8069251B2 (en) * | 2007-06-01 | 2011-11-29 | Adobe Systems Incorporated | System and/or method for client-driven server load distribution |
| KR100930695B1 (ko) * | 2007-08-06 | 2009-12-09 | 현대자동차주식회사 | 디알엠 시스템 및 디알엠 콘텐츠 관리방법 |
| KR100911556B1 (ko) * | 2007-08-06 | 2009-08-10 | 현대자동차주식회사 | 디알엠 콘텐츠의 전송방법 |
| KR101453464B1 (ko) * | 2007-11-09 | 2014-10-21 | 삼성전자주식회사 | 이동통신 단말기의 컨텐츠 권한 정보 관리 장치 및 방법 |
| CN100496025C (zh) * | 2007-11-16 | 2009-06-03 | 西安西电捷通无线网络通信有限公司 | 一种基于三元对等鉴别的可信网络接入控制方法 |
| US20090239503A1 (en) * | 2008-03-20 | 2009-09-24 | Bernard Smeets | System and Method for Securely Issuing Subscription Credentials to Communication Devices |
| US8660539B2 (en) * | 2008-04-30 | 2014-02-25 | Intertrust Technologies Corporation | Data collection and targeted advertising systems and methods |
| US8225390B2 (en) * | 2008-06-27 | 2012-07-17 | Microsoft Corporation | Licensing protected content to application sets |
| US20100058317A1 (en) * | 2008-09-02 | 2010-03-04 | Vasco Data Security, Inc. | Method for provisioning trusted software to an electronic device |
| KR100942992B1 (ko) * | 2008-12-03 | 2010-02-17 | 포항공과대학교 산학협력단 | Ｄｒｍ에서의 사업자 권리를 보장하는 호환성 제공 방법 및장치 |
| US20100146267A1 (en) * | 2008-12-10 | 2010-06-10 | David Konetski | Systems and methods for providing secure platform services |
| US9710418B2 (en) * | 2009-01-16 | 2017-07-18 | Dell Products L.P. | System and method for security configuration |
| US8869289B2 (en) | 2009-01-28 | 2014-10-21 | Microsoft Corporation | Software application verification |
| KR20100088051A (ko) * | 2009-01-29 | 2010-08-06 | 엘지전자 주식회사 | 메모리 카드에 컨텐츠에 대한 사용권리를 설치하는 방법 |
| US8307457B2 (en) * | 2009-01-29 | 2012-11-06 | Lg Electronics Inc. | Method and terminal for receiving rights object for content on behalf of memory card |
| CN102224703B (zh) * | 2009-04-27 | 2013-11-06 | 华为技术有限公司 | 发行许可的方法、装置和系统 |
| US9118462B2 (en) * | 2009-05-20 | 2015-08-25 | Nokia Corporation | Content sharing systems and methods |
| WO2010135002A2 (en) * | 2009-05-21 | 2010-11-25 | Intertrust Technologies Corporation | Ad selection systems and methods |
| WO2010135003A2 (en) * | 2009-05-21 | 2010-11-25 | Intertrust Technologies Corporation | Dynamic, local targeted advertising systems and methods |
| CN102460496B (zh) | 2009-05-21 | 2016-05-25 | 英特托拉斯技术公司 | 内容递送系统和方法 |
| US8861737B2 (en) | 2009-05-28 | 2014-10-14 | Qualcomm Incorporated | Trust establishment from forward link only to non-forward link only devices |
| CA2767368C (en) | 2009-08-14 | 2013-10-08 | Azuki Systems, Inc. | Method and system for unified mobile content protection |
| US8505103B2 (en) * | 2009-09-09 | 2013-08-06 | Fujitsu Limited | Hardware trust anchor |
| US9774630B1 (en) | 2009-09-28 | 2017-09-26 | Rockwell Collins, Inc. | Administration of multiple network system with a single trust module |
| WO2011062973A2 (en) * | 2009-11-17 | 2011-05-26 | Stc. Unm | System and methods of resource usage using an interoperable management framework |
| US8667263B2 (en) * | 2010-02-12 | 2014-03-04 | The Johns Hopkins University | System and method for measuring staleness of attestation during booting between a first and second device by generating a first and second time and calculating a difference between the first and second time to measure the staleness |
| US9727850B2 (en) * | 2010-03-29 | 2017-08-08 | Forward Pay Systems, Inc. | Secure electronic cash-less payment systems and methods |
| WO2011123329A1 (en) * | 2010-04-01 | 2011-10-06 | Research In Motion Limited | Methods and apparatus to transfer management control of a client between servers |
| KR101805602B1 (ko) * | 2010-04-02 | 2017-12-06 | 삼성전자주식회사 | 방송 서비스의 암호화 키 관리 방법 및 시스템 |
| US9208318B2 (en) * | 2010-08-20 | 2015-12-08 | Fujitsu Limited | Method and system for device integrity authentication |
| US8566596B2 (en) * | 2010-08-24 | 2013-10-22 | Cisco Technology, Inc. | Pre-association mechanism to provide detailed description of wireless services |
| US8725196B2 (en) * | 2010-11-05 | 2014-05-13 | Qualcomm Incorporated | Beacon and management information elements with integrity protection |
| TW201220804A (en) * | 2010-11-09 | 2012-05-16 | Chunghwa Telecom Co Ltd | comprising the steps of generating change information; transmitting; signing and issuing the latest message; transmitting to each web domain; sending a request message by a user end; and receiving a response message by the user end |
| PL2664098T3 (pl) * | 2011-01-12 | 2016-05-31 | Virtru Corp | Sposoby i układy do dystrybucji danych kryptograficznych do uwierzytelnionych odbiorców |
| KR20120122616A (ko) * | 2011-04-29 | 2012-11-07 | 삼성전자주식회사 | Ｄｒｍ 서비스 제공 방법 및 장치 |
| US8850216B1 (en) * | 2011-05-19 | 2014-09-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Client device and media client authentication mechanism |
| US9184917B2 (en) * | 2011-05-27 | 2015-11-10 | Google Technology Holdings LLC | Method and system for registering a DRM client |
| CN103164635A (zh) * | 2011-12-15 | 2013-06-19 | 中国银联股份有限公司 | 基于扩展参数集的安全性信息交互系统、装置及方法 |
| US9135410B2 (en) | 2011-12-21 | 2015-09-15 | At&T Intellectual Property I, L.P. | Digital rights management using a digital agent |
| US9992024B2 (en) * | 2012-01-25 | 2018-06-05 | Fujitsu Limited | Establishing a chain of trust within a virtual machine |
| CN102833745B (zh) * | 2012-07-17 | 2016-03-30 | 华为技术有限公司 | 一种软件安全升级的方法、通信设备和通信系统 |
| US9846773B2 (en) * | 2012-12-20 | 2017-12-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Technique for enabling a client to provide a server entity |
| US9081940B2 (en) * | 2013-03-13 | 2015-07-14 | Intel Corporation | Method and service for user transparent certificate verifications for web mashups and other composite applications |
| WO2015013412A1 (en) * | 2013-07-23 | 2015-01-29 | Azuki Systems, Inc. | Media client device authentication using hardware root of trust |
| US9646150B2 (en) * | 2013-10-01 | 2017-05-09 | Kalman Csaba Toth | Electronic identity and credentialing system |
| US10756906B2 (en) | 2013-10-01 | 2020-08-25 | Kalman Csaba Toth | Architecture and methods for self-sovereign digital identity |
| US20150121456A1 (en) * | 2013-10-25 | 2015-04-30 | International Business Machines Corporation | Exploiting trust level lifecycle events for master data to publish security events updating identity management |
| EP2882156B1 (en) * | 2013-12-04 | 2018-09-19 | Telefonica Digital España, S.L.U. | Computer implemented method and a computer system to prevent security problems in the use of digital certificates in code signing and a computer program product thereof |
| US9467298B1 (en) * | 2014-03-19 | 2016-10-11 | National Security Agency | Device for and method of multilevel chain of trust/revision |
| US9467299B1 (en) * | 2014-03-19 | 2016-10-11 | National Security Agency | Device for and method of controlled multilevel chain of trust/revision |
| JP6167990B2 (ja) * | 2014-05-27 | 2017-07-26 | パナソニックＩｐマネジメント株式会社 | 署名検証システム、検証装置、及び署名検証方法 |
| US10523646B2 (en) | 2015-08-24 | 2019-12-31 | Virtru Corporation | Methods and systems for distributing encrypted cryptographic data |
| US10587586B2 (en) | 2017-01-10 | 2020-03-10 | Mocana Corporation | System and method for a multi system trust chain |
| RU2658784C1 (ru) * | 2017-03-23 | 2018-06-22 | Общество с ограниченной ответственностью "БУБУКА" | Способ и система контроля за воспроизведением медиа-контента, включающего объекты интеллектуальных прав |
| RU2683616C2 (ru) * | 2017-06-29 | 2019-03-29 | Андрей Викторович Мишуренков | Система связи |
| CN108171015B (zh) * | 2018-01-15 | 2021-10-15 | 北京书生电子技术有限公司 | 时效控制的方法和装置 |
| GB2572389A (en) * | 2018-03-28 | 2019-10-02 | Sony Corp | A device, requesting device, method and computer program |
| TWI666908B (zh) * | 2018-04-27 | 2019-07-21 | 來毅數位科技股份有限公司 | 密鑰管理方法及系統 |
| CN108683747B (zh) * | 2018-06-11 | 2020-11-27 | 华为技术有限公司 | 资源获取、分发、下载方法、装置、设备及存储介质 |
| US11494757B2 (en) | 2018-10-24 | 2022-11-08 | Capital One Services, Llc | Remote commands using network of trust |
| US10588175B1 (en) | 2018-10-24 | 2020-03-10 | Capital One Services, Llc | Network of trust with blockchain |
| US11842331B2 (en) * | 2018-10-24 | 2023-12-12 | Capital One Services, Llc | Network of trust for bill splitting |
| WO2020117549A1 (en) | 2018-12-06 | 2020-06-11 | Mocana Corporation | System and method for zero touch provisioning of iot devices |
| US11531777B2 (en) | 2019-01-30 | 2022-12-20 | Virtru Corporation | Methods and systems for restricting data access based on properties of at least one of a process and a machine executing the process |
| AU2019204708B2 (en) | 2019-03-27 | 2020-08-20 | Advanced New Technologies Co., Ltd. | Retrieving public data for blockchain networks using highly available trusted execution environments |
| SG11202001944UA (en) | 2019-03-27 | 2020-04-29 | Alibaba Group Holding Ltd | Improving integrity of communications between blockchain networks and external data sources |
| EP3910907B1 (en) | 2019-03-29 | 2023-08-02 | Advanced New Technologies Co., Ltd. | Retrieving access data for blockchain networks using highly available trusted execution environments |
| US11321465B2 (en) * | 2019-04-04 | 2022-05-03 | Cisco Technology, Inc. | Network security by integrating mutual attestation |
| US11070379B2 (en) | 2019-04-18 | 2021-07-20 | Advanced New Technologies Co., Ltd. | Signature verification for a blockchain ledger |
| CN110163006B (zh) * | 2019-04-18 | 2020-07-07 | 阿里巴巴集团控股有限公司 | 一种块链式账本中的签名验证方法、系统、装置及设备 |
| US11562084B2 (en) * | 2019-12-19 | 2023-01-24 | Augustine Fou | System and method for secure, trustful internet interactions |
| CN113127344B (zh) * | 2021-04-06 | 2023-06-09 | 华东师范大学 | 一种ros底层通讯机制的形式化建模与验证方法 |
| WO2023022724A1 (en) * | 2021-08-20 | 2023-02-23 | Hewlett-Packard Development Company, L.P. | Agent-based certificate management |
| JP7492805B1 (ja) * | 2022-11-21 | 2024-05-30 | 株式会社野村総合研究所 | コンテンツ管理システム、コンテンツ管理方法、及びコンテンツ管理プログラム |
| CN117971347B (zh) * | 2024-03-28 | 2024-06-11 | 中国人民解放军国防科技大学 | 一种基于TrustZone的容器可信服务设计方法、设备及存储介质 |
Family Cites Families (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2980320B2 (ja) | 1986-10-24 | 1999-11-22 | 株式会社 アドバンス | 暗号文による通信方式における暗号鍵共有方式 |
| US20020012432A1 (en) * | 1999-03-27 | 2002-01-31 | Microsoft Corporation | Secure video card in computing device having digital rights management (DRM) system |
| EP1056010A1 (en) | 1999-05-28 | 2000-11-29 | Hewlett-Packard Company | Data integrity monitoring in trusted computing entity |
| US7406603B1 (en) * | 1999-08-31 | 2008-07-29 | Intertrust Technologies Corp. | Data protection systems and methods |
| GB9922665D0 (en) * | 1999-09-25 | 1999-11-24 | Hewlett Packard Co | A method of enforcing trusted functionality in a full function platform |
| US6996710B1 (en) * | 2000-03-31 | 2006-02-07 | Intel Corporation | Platform and method for issuing and certifying a hardware-protected attestation key |
| US6931545B1 (en) * | 2000-08-28 | 2005-08-16 | Contentguard Holdings, Inc. | Systems and methods for integrity certification and verification of content consumption environments |
| JP4281252B2 (ja) * | 2001-01-16 | 2009-06-17 | ソニー株式会社 | 情報記録装置、情報再生装置、情報記録方法、情報再生方法、および情報記録媒体、並びにプログラム記憶媒体 |
| US20020157002A1 (en) | 2001-04-18 | 2002-10-24 | Messerges Thomas S. | System and method for secure and convenient management of digital electronic content |
| TWI232392B (en) * | 2001-11-20 | 2005-05-11 | Contentguard Holdings Inc | Rights offering and granting |
| TWI225352B (en) * | 2002-01-29 | 2004-12-11 | Anytime Pte Ltd | Apparatus and method for preventing digital media piracy |
| US7509687B2 (en) * | 2002-03-16 | 2009-03-24 | Trustedflow Systems, Inc. | Remotely authenticated operation method |
| US7346780B2 (en) * | 2002-04-03 | 2008-03-18 | Microsoft Corporation | Integrity ordainment and ascertainment of computer-executable instructions |
| SE0202450D0 (sv) * | 2002-08-15 | 2002-08-15 | Ericsson Telefon Ab L M | Non-repudiation of digital content |
| US7398557B2 (en) * | 2002-09-13 | 2008-07-08 | Sun Microsystems, Inc. | Accessing in a rights locker system for digital content access control |
| US7210034B2 (en) * | 2003-01-30 | 2007-04-24 | Intel Corporation | Distributed control of integrity measurement using a trusted fixed token |
| US7634807B2 (en) * | 2003-08-08 | 2009-12-15 | Nokia Corporation | System and method to establish and maintain conditional trust by stating signal of distrust |
| US8336105B2 (en) * | 2003-10-31 | 2012-12-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and devices for the control of the usage of content |
| US20050172127A1 (en) | 2004-01-31 | 2005-08-04 | Frank Hartung | System and method for transcoding encrypted multimedia messages transmitted between two devices |
| US7318150B2 (en) * | 2004-02-25 | 2008-01-08 | Intel Corporation | System and method to support platform firmware as a trusted process |
| GB2412822A (en) | 2004-03-30 | 2005-10-05 | Hewlett Packard Development Co | Privacy preserving interaction between computing entities |
| US20050251857A1 (en) * | 2004-05-03 | 2005-11-10 | International Business Machines Corporation | Method and device for verifying the security of a computing platform |
| US20060015753A1 (en) | 2004-07-15 | 2006-01-19 | International Business Machines Corporation | Internal RAM for integrity check values |
| KR100677344B1 (ko) | 2004-07-29 | 2007-02-02 | 엘지전자 주식회사 | 권리객체 처리를 위한 메시지 및 이를 이용한 권리객체 처리 방법 및 시스템 |
| EP1632829A1 (en) | 2004-09-03 | 2006-03-08 | Canal + Technologies | Data integrity checking circuit |
| EP1635545B1 (en) * | 2004-09-14 | 2013-04-10 | Sony Ericsson Mobile Communications AB | Method and system for transferring of digital rights protected content using USB or memory cards |
| US20060236369A1 (en) * | 2005-03-24 | 2006-10-19 | Covington Michael J | Method, apparatus and system for enforcing access control policies using contextual attributes |
| US20070168293A1 (en) * | 2005-06-02 | 2007-07-19 | Alexander Medvinsky | Method and apparatus for authorizing rights issuers in a content distribution system |
| US7953980B2 (en) * | 2005-06-30 | 2011-05-31 | Intel Corporation | Signed manifest for run-time verification of software program identity and integrity |
| US8200699B2 (en) * | 2005-12-01 | 2012-06-12 | Microsoft Corporation | Secured and filtered personal information publishing |
| RU2432691C2 (ru) | 2006-01-26 | 2011-10-27 | Эл Джи Электроникс Инк. | Аппаратура и способ для передачи объекта прав из одного устройства другому устройству посредством сервера |
| KR101018368B1 (ko) | 2006-05-05 | 2011-03-04 | 인터디지탈 테크날러지 코포레이션 | 트러스티드 프로세싱 기술을 사용하는 디지탈 권리 관리 |
-
2007
- 2007-05-04 KR KR1020087029768A patent/KR101018368B1/ko not_active IP Right Cessation
- 2007-05-04 WO PCT/US2007/010951 patent/WO2008100264A2/en active Application Filing
- 2007-05-04 CA CA002651436A patent/CA2651436A1/en not_active Abandoned
- 2007-05-04 EP EP15175049.4A patent/EP2981040A1/en not_active Withdrawn
- 2007-05-04 CN CN2007800162714A patent/CN101573936B/zh not_active Expired - Fee Related
- 2007-05-04 US US11/744,304 patent/US8769298B2/en not_active Expired - Fee Related
- 2007-05-04 EP EP07872510.8A patent/EP2052524B1/en not_active Not-in-force
- 2007-05-04 EP EP12170155.1A patent/EP2495932B1/en not_active Not-in-force
- 2007-05-04 TW TW99114122A patent/TWI469603B/zh not_active IP Right Cessation
- 2007-05-04 SG SG201103188-7A patent/SG171651A1/en unknown
- 2007-05-04 RU RU2008147897/09A patent/RU2419235C2/ru not_active IP Right Cessation
- 2007-05-04 BR BRPI0710321-2A patent/BRPI0710321A2/pt not_active IP Right Cessation
- 2007-05-04 CN CN201210396259.3A patent/CN102982257B/zh not_active Expired - Fee Related
- 2007-05-04 KR KR1020127015622A patent/KR20120092675A/ko active IP Right Grant
- 2007-05-04 AU AU2007347234A patent/AU2007347234B2/en not_active Ceased
- 2007-05-04 TW TW96116006A patent/TWI467987B/zh not_active IP Right Cessation
- 2007-05-04 JP JP2009509765A patent/JP5181094B2/ja not_active Expired - Fee Related
- 2007-05-04 KR KR1020087031127A patent/KR101269698B1/ko not_active IP Right Cessation
- 2007-05-04 KR KR1020137014140A patent/KR20130080862A/ko active IP Right Grant
- 2007-05-04 MX MX2008014168A patent/MX2008014168A/es not_active Application Discontinuation
- 2007-05-04 TW TW103134309A patent/TWI562580B/zh not_active IP Right Cessation
- 2007-05-07 AR ARP070101958A patent/AR060774A1/es not_active Application Discontinuation
-
2008
- 2008-11-05 IL IL195129A patent/IL195129A/en active IP Right Grant
-
2010
- 2010-03-18 HK HK10102873.6A patent/HK1136412A1/xx not_active IP Right Cessation
- 2010-09-03 RU RU2010136920/08A patent/RU2010136920A/ru not_active Application Discontinuation
-
2012
- 2012-07-30 JP JP2012168650A patent/JP2012257292A/ja active Pending
-
2013
- 2013-05-28 RU RU2013124844/08A patent/RU2013124844A/ru not_active Application Discontinuation
-
2014
- 2014-06-30 US US14/319,659 patent/US9489498B2/en not_active Expired - Fee Related
- 2014-08-08 JP JP2014162568A patent/JP5977292B2/ja not_active Expired - Fee Related
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0710321A2 (pt) | administração de direitos digitais utilizando métodos de processamento confiáveis | |
| KR102116399B1 (ko) | 서비스 레이어에서의 콘텐츠 보안 | |
| US9177112B2 (en) | Method and device for communicating digital content | |
| BRPI0313404B1 (pt) | "method and system for monitoring the customer's use of digital content loaded or transferred in continuous provided by a content provider to a customer system through a network" | |
| KR20090133112A (ko) | 보안 통신 방법 및 시스템 | |
| JP2004342080A (ja) | 送信システムにおけるデバイスタイプ認証 | |
| EP2517431A1 (en) | Usage control of digital data exchanged between terminals of a telecommunications network | |
| Alliance | DRM Specification V2. 0 | |
| CN116707813A (zh) | 一种基于区块链的数据处理方法、设备以及可读存储介质 | |
| Platform | Trusted mobile platform | |
| KR20090036498A (ko) | 사용자 도메인에서의 키 관리 방법 및 콘텐츠 사용 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B25G | Requested change of headquarter approved |
Owner name: INTERDIGITAL TECHNOLOGY CORPORATION (US) |
|
| B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] | ||
| B08K | Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette] |