BR112016001608B1

BR112016001608B1 - Método através do qual um dispositivo de cliente comprova sua autenticidade para um cliente de mídia a ser instalado por usuário no dispositivo de cliente e dispositivo de cliente

Info

Publication number: BR112016001608B1
Application number: BR112016001608-4A
Authority: BR
Inventors: Raj Nair; Mikhail Mikhailov
Original assignee: Ericsson Ab
Priority date: 2013-07-23
Filing date: 2014-07-23
Publication date: 2022-11-01
Also published as: BR112016001608A2; KR20160105380A; CN105706048B; US20180211016A1; MX2016000881A; CN105706048A; EP3025226A4; EP3025226A1; CA2919106C; MX359837B; US10395012B2; US20160162669A1; US9922178B2; CN110287654A; KR101763084B1; EP3025226B1; CA2919106A1; WO2015013412A1; CN110287654B

Abstract

AUTENTICAÇÃO DE DISPOSITIVO DE CLIENTE DE MÍDIA COM O USO DE RAIZ DE CONFIABILIDADE DE HARDWARE. Trata-se de um dispositivo de cliente para reprodução de mídia que inclui um aplicativo de cliente de mídia instalável por usuário que implanta o lado de cliente de um sistema de gerenciamento de direitos digitais (DRM). O dispositivo de cliente emprega a inicialização segura e verifica o aplicativo instalado por usuário. O aplicativo é reforçado contra engenharia reversa e o mesmo utiliza uma API especial fornecida pelo dispositivo de cliente para se unir à inicialização segura, ligando a lacuna entre a inicialização segura e o lado de cliente do sistema de DRM contido dentro do aplicativo.

Description

SUMÁRIO

[0001] É revelada uma técnica para estabelecer confiabilidade entre um dispositivo de cliente e um servidor, por meio de um aplicativo instalado no dispositivo de cliente. O dispositivo de cliente é adaptado para renderização ou reprodução de mídia. Poderia ser um Decodificador de Sinais (STB) que tem conectividade de IP. Poderia ser, também, um dispositivo móvel, tal como um telefone inteligente, ou qualquer outro tipo de dispositivo de cliente. O sistema operacional que é executado no dispositivo de cliente poderia ser Android, Linux, Windows 8 ou qualquer outro sistema operacional.

[0002] O dispositivo de cliente tem um ou mais valores secretos gravados no hardware, de modo que os mesmos estejam sempre presentes e não possam ser removidos ou alterados. Um processo de inicialização segura conta com esses valores secretos para garantir que determinados componentes de armazenamento não voláteis, persistentes, tais como segredos adicionais, um carregador de inicialização, o próprio sistema operacional e seus vários componentes, possam ser verificados no momento de inicialização e possam se mostrar genuínos, visto que os mesmos foram instalados na fábrica ou durante um processo de atualização autorizado e não temperados.

[0003] Uma vez que a integridade do dispositivo e do sistema operacional é verificada, o aplicativo (iniciado automaticamente ou por um usuário), estabelece confiabilidade entre o dispositivo de cliente e um servidor com uso de uma interface de programação de aplicativo especial (API), fornecida pelo sistema que utiliza os valores secretos disponíveis no dispositivo e verificado durante o processo de inicialização segura.

[0004] O aplicativo, que implanta o lado de cliente de um sistema de gerenciamento de direitos digital (DRM), é renovável/ instalável por usuário no dispositivo de cliente. O dispositivo de cliente emprega inicialização segura e verifica o aplicativo instalado por usuário. O aplicativo pode ser reforçado contra engenharia reversa e usa uma API especial, fornecida pelo dispositivo de cliente, para unir-se na inicialização segura, ligando a lacuna entre a inicialização segura e o lado de cliente do sistema de DRM contido no aplicativo.

BREVE DESCRIÇÃO DOS DESENHOS

[0005] A descrição antecedente e outros objetivos, recursos e vantagens serão evidentes, a partir da descrição a seguir de modalidades particulares da invenção, conforme ilustrado nos desenhos anexos, em que caracteres de referência semelhante se referem às mesmas partes ao longo das diferentes vistas.

[0006] A Figura 1 é um diagrama de blocos de um sistema em rede para a reprodução e entrega de conteúdo; a Figura 2 é um diagrama de blocos de uma organização de hardware de um dispositivo computadorizado; a Figura 3 é um diagrama esquemático de uma organização de software/firmware de um dispositivo de cliente.

[0007] A Figura 4 é um diagrama esquemático do conteúdo de um processador seguro e memória (rápida) rapidamente programável em um dispositivo de cliente.

[0008] A Figura 5 é um fluxograma de alto nível de um processo de inicialização segura.

[0009] A Figura 6 é um fluxograma de mensagem para um processo de registro de dispositivo.

[0010] A Figura 7 é um gráfico que representa relações em uma técnica de ofuscação de código.

[0011] A Figura 8 é um fluxograma de mensagem para uma técnica de ofuscação de código.

DESCRIÇÃO DETALHADA

[0012] A Figura 1 é uma vista simplificada que mostra componentes pertinentes de um sistema em rede para armazenar, entregar e reproduzir conteúdo protegido, tal como arquivos de vídeo descriptografados. Nessa vista simplificada, o sistema inclui um conjunto de servidores de retaguarda ou "retaguarda" 10 conectado a um dispositivo de cliente 12, por meio de uma rede 14. A retaguarda 10 é descrita em mais detalhes abaixo. O dispositivo de cliente 12 é, de modo geral, um dispositivo computadorizado que tem capacidade de reprodução que inclui a descriptografia de arquivos de conteúdo criptografado. Os exemplos de dispositivos de cliente incluem um computador pessoal, um computador do tipo tablet, telefone inteligente, etc. As chaves de descriptografia usadas para descriptografar os arquivos de conteúdo criptografados são fornecidas para o dispositivo de cliente 12, pela retaguarda 10. Em operação, conforme descrito mais abaixo, o dispositivo de cliente 12 se autentica à retaguarda 10 e fornece informações que estabelecem sua autorização para reproduzir conteúdo criptografado identificado (por exemplo, um vídeo particular). A retaguarda 10 responde através do fornecimento de uma ou mais chaves de descriptografia que viabiliza que o dispositivo de cliente 12 descriptografe o(s) arquivo(s) de conteúdo para o vídeo. O dispositivo de cliente 12 obtém os arquivos de conteúdo criptografados a partir de um servidor de conteúdo (não mostrado) da retaguarda 10, descriptografa os arquivos com uso das chaves de descriptografia e, então, renderiza (reproduz) o conteúdo descriptografado.

[0013] A retaguarda 10 pode ser implantada com uso de um ou mais computadores de servidor, que podem ser colocalizados (por exemplo, em um centro de dados) ou distribuídos, de alguma maneira, sobre múltiplos locais. Alguns ou todos dentre os servidores podem ser parte de uma rede de entrega de conteúdo (CDN). Em operação, o conteúdo de um editor de conteúdo pode ser ingerido e, então, segmentado para entrega, com base em segmento, aos dispositivos de cliente 12. Um mecanismo motor de preparação de mídia obtém chaves de criptografia/descriptografia de conteúdo, a partir de um servidor de gerenciamento de direitos digital (DRM) da retaguarda 10, e usa as chaves para criptografar o conteúdo para armazenamento e posterior entrega na forma criptografada. A retaguarda 10 pode empregar um servidor de direitos como ponto focal para comunicações e operações relacionadas ao DRM, caso em que o servidor de DRM pode ser mais especificamente adaptado para a geração, armazenamento e restauração de chave de criptografia, com uso de protocolos de rede apropriados.

[0014] A Figura 2 é uma retratação generalizada de um dispositivo computadorizado, tal como pode ser usado para concretizar o dispositivo de cliente 12 e um servidor da retaguarda 10. O mesmo inclui um ou mais processadores 20, memória 22, armazenamento local 24 e conjunto de circuitos 26 de interface de entrada/saída (I/O) acoplados juntos por um ou mais barramentos de dados 28. O conjunto circuitos 26 de interface de I/O acopla o dispositivo a uma ou mais redes externas (tal como a rede 14), a dispositivos de armazenamento adicionais ou sistemas e a outros dispositivos de entrada/saída, conforme, de modo geral, conhecido na técnica. A funcionalidade no nível do sistema do dispositivo, conforme descrito no presente documento, é fornecida pelo hardware que executa instruções de programa de computador (software), tipicamente armazenadas na memória 22 e recuperadas e executadas pelo(s) processador(es) 20. Qualquer descrição, no presente documento, de um componente de software que realiza uma função deve ser compreendida como uma referência abreviada para a operação de um computador ou dispositivo computadorizado, ao executar as instruções do componente de software. Além disso, a coleção de componentes, na Figura 2, pode ser denominada "conjunto de circuitos de processamento" e, ao executar um determinado componente de software, pode ser vista como um circuito de função especializada, por exemplo, como um "circuito de reprodução", ao executar um componente de software que implanta uma função de reprodução de conteúdo. Conforme descrito abaixo, o dispositivo de cliente 12 inclui uma organização de hardware mais especializada, para propósitos de segurança.

[0015] Em uma modalidade, o dispositivo de cliente 12 tem uma organização especializada que empresta a si mesma para detectar aplicativos que incluem os aspectos de DRM de reprodução e entrega de mídia. Em particular, o dispositivo de cliente 12 pode fracionar o conjunto de circuitos e a funcionalidade entre um ambiente de execução seguro e um ambiente não seguro ou normal. Os componentes de hardware podem incluir um processador de aplicativo no ambiente não seguro e um processador seguro separado no ambiente seguro. Operar o software no ambiente não seguro pode incluir um sistema operacional (O/S) e um aplicativo reprodutor de conteúdo (denominado "app"). Em uma modalidade, o sistema operacional é o sistema operacional Android® para dispositivos móveis. Os componentes no ambiente seguro são responsáveis por estabelecer uma raiz de confiabilidade com a retaguarda 10 (Figura 1) para viabilizar que o dispositivo de cliente 12 obtenha chaves de descriptografia para descriptografar o conteúdo. O ambiente seguro inclui um kernel seguro e uma memória segura. O dispositivo de cliente também inclui um cliente de mídia que envia solicitações para a retaguarda 10, a fim de registrar o dispositivo 12, obter objetos de direitos para reprodução de objetos de mídia e realizar outras funções que viabilizem a descriptografia e a reprodução de objetos de mídia. Consequentemente, o cliente de mídia pode ter porções não seguras e seguras separadas fracionadas entre os ambientes não seguro e seguro.

[0016] Em uma modalidade, o ambiente seguro do dispositivo de cliente 12 pode empregar componentes da, assim chamada, família de Zona de Confiabilidade, que incluem o processador seguro concretizado, de acordo com a arquitetura de ARM, bem como o kernel seguro e a memória segura, que são especialmente adaptados para usos relacionados à segurança. O estabelecimento de uma raiz de confiabilidade pode ser baseado, parcialmente, nos recursos de segurança oferecidos pelo hardware de processamento seguro que é embutido em uma placa de circuito usada para construir um dispositivo 12 (por exemplo, fone de telefone móvel). Um fabricante de chipset fornece o hardware, e um fabricante de dispositivo (OEM) carrega certo firmware (código), tal como descrito mais abaixo.

[0017] A Figura 3 mostra uma organização do dispositivo de cliente 12, a partir de uma perspectiva de software, que também reflete o fracionamento descrito acima entre ambientes não seguro e seguro. O mesmo inclui um reprodutor de mídia 30, um cliente de mídia 32, um kernel 34 de sistema operacional (OS) e um firmware seguro 36. O cliente de mídia 32 tem uma conexão funcional 38 com a retaguarda 10. Em operação, o reprodutor de mídia 30 renderiza a mídia, tal como vídeo, em uma instalação adequada do dispositivo de cliente 12, tal como um monitor. O reprodutor de mídia 30 também inclui uma interface de usuário gráfica, que viabiliza que um usuário controle a seleção e reprodução de mídia, conforme, de modo geral, conhecido na técnica. O cliente de mídia 32 realiza várias funções relacionadas à transferência de mídia para reprodução (renderização), que inclui controle geral de registro de dispositivo, entrega de chaves de criptografia e transferência de mídia (conteúdo) a partir da rede 14. A funcionalidade de registro de dispositivo é descrita, mais especificamente, abaixo, junto com a funcionalidade pertinente do kernel de OS 34 e do firmware seguro 36.

[0018] A Figura 4 mostra certa estrutura e itens de dados no dispositivo de cliente 12, que inclui um processador seguro 40 e uma memória não volátil (rápida) rapidamente programável 42. Na operação descrita abaixo, o processador seguro 40 executa o código e acessa os itens de dados armazenados no flash 42. Entretanto, o processador seguro 40 também tem operações e componentes relevantes de nível inferior (hardware). Especificamente, o processador 40 inclui uma memória apenas de leitura (ROM) que armazena uma rotina 44 de inicialização de processador pequena (PROC BOOT), que é automaticamente executada mediante uma reinicialização ou um ciclo de energia. O mesmo também inclui um armazenamento programável uma vez (OTP) 46 para armazenamento no nível de hardware permanente de certos itens de dados fundamentais, que incluem uma chave pública de raiz (PuK) KEY1, uma chave de raiz BL KEY4 e uma chave de fração de chave (frac.) KEY5. O armazenamento de OTP pode ser concretizado com uso de uma matriz de fusíveis que são seletivamente abertos ("soprados") em um momento de fabricação do dispositivo de cliente 12, por exemplo.

[0019] O flash 42 armazena os itens a seguir, junto com as assinaturas respectivas (SIG) 50: 1. Chave pública de raiz externa 48 (KEY2) e assinatura 50-1 2. Código de inicialização rápida 52 e assinatura 50-2 3. Chave simétrica de criptografia 54 (KEY3) e assinatura 50-3 4. Argumentos de inicialização 56 e assinatura 50-4 5. Código de recuperação 58 e assinatura 50-5 6. Código de kernel 60 e assinatura 50-6 7. Código de sistema 62 e assinatura 50-7

[0020] A Figura 5 esboça o processo de inicialização segura.

[0021] Em 70, o código de inicialização de processador 44 verifica a assinatura 50-1 da KEY2, com uso das operações específicas a seguir: 1. Computar um hash seguro H2 (por exemplo, hash SHA-256) de soma de verificação de chave pública de raiz externa (KEY2) 2. Ler a chave pública de raiz (KEY1) no OTP 46 e usar a KEY1 para descriptografar a assinatura 50-1 da KEY2 e comparar a H2

[0022] Em 72, o código de inicialização de processador 44 verifica a assinatura 50-2 da imagem de Inicialização Rápida 52, com uso da KEY2. Isso é feito através de descriptografia da assinatura 50-2, com a KEY2 e através de comparação do resultado com um seguro calculado que tem o hash da imagem de Inicialização Rápida 52.

[0023] Nesse estágio, a imagem de Inicialização Rápida 52 é carregada na memória e começa a execução. Devido ao fato de que as etapas subsequentes exigem acessar o OTP 46, o que pode apenas ser feito pelo processador seguro, a Inicialização Rápida é executada pelo processador seguro.

[0024] Em 74, a KEY3 54 criptografada é descriptografada e sua assinatura é verificada. As etapas a seguir são usadas: a. Primeiro, a KEY3 criptografada é descriptografada com uso da chave de raiz BL KEY4 armazenada no OTP 46 b. Posteriormente, uma assinatura AES CBC-MAC da KEY3 descriptografada é calculada com uso de uma chave intermediária derivada da KEY4 e da KEY5 c. A assinatura armazenada 50-3 da KEY3 é descriptografada com uso da chave de fração de chave KEY5 d. As respectivas saídas das etapas b e c são comparadas para verificar a integridade da KEY3

[0025] Em 76, a Inicialização Rápida verifica as frações restantes do flash 42, com uso da KEY3: 1. Verificar a assinatura 50-4 dos argumentos de inicialização 56 2. Verificar a assinatura 50-5 do código de recuperação 58 3. Verificar a assinatura 50-6 do kernel 60 4. Verificar a assinatura 50-7 do código de sistema 62

[0026] Após o processo de inicialização segura acima, o controle é passado para o kernel 60.

[0027] Em uma modalidade, as chaves KEY1 e KEY2 têm o comprimento de 2.048 bits. As mesmas podem ser fornecidas por um fornecedor específico de infraestrutura de DRM, tal como o assinante desta patente. Um dispositivo de cliente, de outro modo, convencional 12 tal como um telefone, inteligente pode precisar ser modificado apenas para permitir a execução de aplicativos assinados com uso de certificados a partir de autoridades de certificado especificadas, que incluem do assinante.

[0028] A Figura 6 ilustra um processo de registro de dispositivo subsequente, conforme a seguir: 1. O cliente de mídia 32 solicita e obtém o número de série de dispositivo (S), com uso de uma chamada de kernel especial. Em uma modalidade o número de série S é formado como a concatenação de manufacturer_id(4 bytes) + device_model(4 bytes) + batch no (8 bytes) + serial_no (8 bytes) 2. O cliente de mídia 32 envia, até a retaguarda 10, uma solicitação de autenticação que contém: S + App_Id (4 bytes) + Android_Time_Stamp (14 bytes) + random nonce l (16 bytes) 3. A retaguarda 10 criptografa as informações recebidas, com uso da chave privada de 2.048 bits, que corresponde à chave pública de raiz externa (KEY2) 4. A mensagem criptografada é enviada, pela retaguarda 10, abaixo do dispositivo 12 5. O cliente de mídia 32 solicita a KEY2 a partir do kernel 34 6. O cliente de mídia 32 usa a KEY2 para descriptografar a mensagem da retaguarda 10 e, então, verifica o timbre de data e hora, o valor de uso único, etc. 7. O cliente de mídia 32 solicita uma mensagem de registro de dispositivo, a partir do kernel 34 8. O kernel 34 recorre ao firmware seguro 36 para criar a mensagem de registro de dispositivo, que, em uma modalidade, inclui (autenticação de id de dispositivo + '#' + Android_Time_Stamp + '#' + random_nonce_l) criptografada com KEY2, em que a autenticação de id de dispositivo é um hash seguro de S + ChipID (4 bytes) + IN (24 bytes), sendo que IN é um número de individualização que é o chipset_manufacturer_id (4 bytes) + batch_no (8 bytes) + serial_no (12 bytes)) 9. A mensagem de registro de dispositivo é enviada para a retaguarda 10. 10. A retaguarda 10 descriptografa a mensagem com a chave privada que corresponde à KEY2, verifica o timbre de data e hora e o valor de uso único e usa a autenticação de id do dispositivo como identificação de dispositivo para o registro de dispositivo. 11. A retaguarda 10 retorna o resultado do registro de dispositivo para o cliente de mídia 32

Ofuscação Robusta Para Autenticação De App

[0029] As Figuras 7 e 8 são usadas para descrever uma técnica de autenticação de um aplicativo sensível, tal como o cliente de mídia 32, com base na ofuscação do código, de uma maneira que é difícil de replicar.

[0030] A autenticação de app é alcançada por uma combinação de um descriptografador de caixa branca para descriptografar uma chave privada que é usada para estabelecer um canal seguro autenticado de 2 vias. Um ofuscador provavelmente rígido é usado contra a engenharia reversa e por incorruptibilidade de extensão. O ofuscador usa um achatamento de fluxo de controle em combinação com um problema difícil conhecido, tal como 3 SAT, que é o NP-concluído que pode ser reduzido para o problema de capacidade de alcance no fluxo de controle achatado. Em outras palavras, o conhecimento do fluxo de controle é equivalente a solucionar o problema difícil conhecido.

Procedimento De Ofuscação (Feito No Tempo De Desenvolvimento De Código)

[0031] As porções do código de cliente de mídia 32 envolvidas na restauração de chave de licença e na reprodução de mídia são ofuscadas com uso desse procedimento, que inclui as etapas a seguir, realizadas pelo desenvolvedor de código em seu ambiente de desenvolvimento.

[0032] Etapa 1: Selecionar uma família de predicados opacos. Esses são usados para criar o código condicional, conforme mostrado na etapa 5 abaixo. Tais condicionais são usados no procedimento de achatamento de código descrito posteriormente, que obtém o código linear e cria uma estrutura de ramificação grande. As famílias disponíveis são:

Raiz De Resíduo Primário (RPR):

[0033] Esta é definida conforme a seguir -Para qualquer P=4X+3 primário e qualquer A < P, o predicado que gera o modelo é “{(A(x+1))2 em que a % denota a operação de mod. Isso gera uma família de predicados através da variação de A e X que todos avaliam para 0 ou FALSO.

[0034] Similarmente, quando P=8X+5, o modelo correspondente é "{((4*A)(x+1)/2)2 - A}%P".

[0035] Em geral, esses predicados têm a forma de "L-R" em que L é ((4*A)(x+1)/2)2 e R é A. Foram selecionados aleatoriamente duas ocorrências dessa família com o mesmo resíduo primário e usadas duas partes esquerdas, como em L - L' em que L' é de uma família com um A' e P' diferentes, em que A%P =A'%P'. Está claro que L-L' avalia a 0.

[0036] Os predicados também podem ser misturados em uma expressão em que A%P não é igual a A'%P', a fim de obter uma expressão não zero. Outro modo de conseguir uma expressão não zero é usar identidades que não sejam sempre confiáveis, conforme mostrado posteriormente.

Polinômio Quadrático Simples (SQP):

[0037] Este é definido conforme a seguir -"7*Y2-1-X2" nunca é 0 para quaisquer números inteiros X e Y.

[0038] Aqui, esse predicado é usado como L-R, que é uma expressão não zero. Esse tipo de predicado é usado para introduzir condicionais.

[0039] Etapa 2: Posteriormente, uma coleção de variáveis ofuscantes é criada, a qual é, então, usada para construir uma ocorrência de uma estrutura de gráfico que é, então, embutida na ofuscação de código, conforme descrito na etapa 3 abaixo. Um exemplo esquemático de tal estrutura de gráfico é mostrado na Figura 7. Pode haver alguma quantidade selecionada de variáveis, tal como 1.024 por exemplo. Essas são arbitrariamente divididas em dois grupos G_1 e G_2, com uso de uma seleção do tipo cara ou coroa, com as propriedades de criptografia de CTR DRBG. A seleção é com base na paridade do número gerado; obtendo apenas os números ímpares em G_1. A condição de membro em G_1 ou G_2 nunca é revelada e é conhecida apenas ao programador. Deve-se observar que não há declaração no código que declare a condição de membro em ambos os conjuntos; apenas o programador usa a condição de membro para construir a ocorrência do problema 3 SAT, sendo que 3SATm, consiste em cláusulas k, conforme descrito abaixo.

em que k > 3, conforme necessário para a prova abaixo.em que k é o tamanho do conjunto G_1 e cada um dentre s; é delineado a partir do conjunto G_1 e definido como VERDADEIRO. O restante a e t1 através de tk_i são definidos para valores booleanos aleatórios, calculados no tempo de execução. Essa definição satisfaria sempre 3SATm.

[0040] As definições reais das variáveis são escondidas, com uso de predicados opacos, conforme mostrado abaixo.

[0041] Por exemplo, ao contrário da definição Si=VERDADEIRO, usa-se RPR para fazer o seguinte

[0042] Os literais restantes tj são definidos para valores aleatórios, com uso do mesmo modelo gerador, mas selecionar Aj para que seja menor do que ou maior do que Pj, com uso de um procedimento do tipo cara ou coroa, como acima.

[0043] A computação dos literais é distribuída, ao longo do código, pelo desenvolvedor de software. A distribuição das definições é feita a fim de alcançar a propriedade de não localidade, que é considerada importante para a ofuscação de código.

[0044] Posteriormente, um gráfico G é computado com uso dos literais de 3SATm. Os vértices podem ser coloridos com cores k+1, de modo que nenhuma borda tenha a mesma cor em sua extremidade, se, e apenas se, 3SATm for satisfatório. Então, visto que a definição de desses i como VERDADEIRO satisfaz 3SATm, sabe-se, também, que o gráfico pode ser colorido por (k+1). Esse conhecimento é apenas conhecido ao desenvolvedor e, então, pode ser usado para verificar as cores das extremidades de bordas aleatórias no gráfico, a fim de determinar o estado da coloração que é, então, usada para proteger os segmentos de código.

[0045] O gráfico G é construído conforme a seguir: • Cada literal

a e a são nós no gráfico G • Cada cláusula Ci é um nó que é colorido i e conectado aos literais que não estão em Ci • Cada nó si é colorido i e conectado a todos os outros nós s e a todos os literais tj e ti em que j = i

[0046] Cada um dos nós ti e ti; são conectados por uma borda. Cada um dos nós ti são coloridos i, e os nós ti; são coloridos k+1. Do mesmo modo, os nós a e a são conectados por uma borda e coloridos 1 e k+1 respectivamente. Deve-se referir ao ti e si como nós "VERDADEIRO". Deve-se observar que, durante a execução do programa, os valores do ti e ti são, aleatoriamente, variados, a coloração correspondente é alterada de i para (k+1), dependendo de se o valor é VERDADEIRO ou FALSO respectivamente. (Nota: Deve-se referir à cor k+1 como a cor FALSA.]

[0047] Lema: O Gráfico G pode ser colorido como (k+1).Prova:

[0048] Visto que cada cláusula Q tem no máximo 3 literais e há pelo menos 4 cláusulas, cada cláusula precisa ser conectada tanto a tj quanto tj por pelo menos um j. Assim, nenhuma cláusula pode ser colorida com a cor k+1.

[0049] Assim, o gráfico G colorido com (k+1) se houver um nó VERDADEIRO em cada Q, cuja cor é i. Visto que se sabe que os si são sempre VERDADEIRO, o gráfico G pode ser colorido com (k+1). [Deve-se observar que, cada cláusula precisa ser colorida com uma das cores de 1 a k, isto é, a cor de um dentre os nós VERDADEIRO].

[0050] Etapa 3: Posteriormente, várias porções do código ofuscado são marcadas para processamento. Isso é feito manualmente, durante a criação de código. Essas porções são identificadas com uso de indicadores de comentário especiais que são, posteriormente, lidos para o achatamento de código, conforme descrito posteriormente. Deve-se observar que o processo de achatamento de código é para introduzir o código de ramificação junto com uma questão para a ocorrência embutida, de modo que o processo de recuperação do fluxo de controle correto é equivalente a solucionar uma ocorrência geral de coloração de gráfico - um problema de NP-concluído. A ocorrência é construída com uso dos literais descritos na etapa 2 acima. Além disso, conforme mostrado acima, a ocorrência pode ser colorida com cores k+1, mesmo com a atribuição de cor aleatória e a religação dos nós t. Em outras palavras, pode-se migrar entre os grupos 2 e 3 no gráfico G, devido à simetria, conforme mostrado na Figura. Essa propriedade é explorada na ofuscação, através do uso de algumas manipulações de coloração segura definidas abaixo - Manipulações De Coloração Segura 1. Em momentos aleatórios, trocar os nós entre os grupos 2 e 3 e os grupos 1 e C e, consequentemente, ajustar os indicadores; 2. Mover os indicadores através dos grupos 1, 2, 3, e C e dentro de 1, de uma maneira isomórfica para a coloração.

[0051] Nota: As manipulações devem apenas direcionar os nós específicos no gráfico, e a lógica para a seleção de nó é feita na criação de código. Em outras palavras, a condição de membro de grupo nunca é explícita no código.

[0052] Na implantação, os nós alocados fora de uma matriz, com um mapeamento aleatório entre os nós e os grupos do gráfico G. Apenas o programa gerador de ofuscação de código conhece sobre a ocorrência de 3-SAT. O programa ofuscado tem apenas o gráfico G de ocorrência de cor (k+1). Em outras palavras, a disponibilidade de uma solução para G é apenas conhecida ao desenvolvedor e nunca é revelada a um monitor.

[0053] Etapa 4: O achatamento de código é alcançado através da transformação de uma sequência linear de declarações para uma forma ramificada. Assim, começando com a sequência X1; X2; X3; ...; Xn

[0054] Nota: O código morto pode ser introduzido para aumentar o comprimento do segmento, com uso de predicados opacos, tal como a partir de SQP, conforme a seguir:

[0055] “Se (L-R) == 0, então, definir qualquer um dos literais para valores aleatórios, conforme descrito anteriormente, com uso do modelo gerador” .

[0056] Um deles consegue a estrutura seguir- Atribuição condicional S = {Li, Lj, ... } ((color(t_a) == color(not t_a)) (color(t_m) color(s n)) ...)) /** Isso significa se (color(t_a) == color(not t_a)), então S = Li; se (color(t_m) == color(t_n)) então S = Lj; e assim por diante. Apenas um desses levará ao valor correto de S **/ L* Alternância (S) {

[0057] Caso 1: Protegido por predicados opacos( X1. Computar novo S por meio de atribuição condicional; Ir para L;

[0058] Caso 2: Protegido por predicados opacos( X2 Computar novo S por meio de atribuição condicional; Ir para L; Etc. }

[0059] Exemplo: Obter o código a seguir, para que seja ofuscado:

[0060] Func 123 (a, b, c):

[0061] Isso é estendido com o código morto, conforme a seguir- X1: Se (Ll-Rl), então { Func_123 (a, c, b) /** alguma coisa que lembre, mas levemente diferente do correto, sob Xn **/ Definir s_k para 1-L2-R2 } X2: se (L2-R2), então { Func_123 (a, b, b) Definir s_m para L5-R5 } ...assim por diante... Xn se (Ln==Rn) então /** em que n é um múltiplo do dito 3, isto é, n = 3k **/ { Func_123 (a,b,c); /** O código original **/ Definir s_x para Lm-Rm }

[0062] Isso se torna achatado na estrutura a seguir. /** Dividir as etapas de n execução em m <= n sequências. **/ /** selecionar aleatoriamente um conjunto de C de N rótulos e escolher uma permutação, P=P1..Pm desses rótulos **/ /** Agora, selecionar uma permutação aleatória R (embutindo P) como a ordem de "execução" na estrutura achatada **/ /** Deve-se observar que, em cada tempo, através da estrutura, apenas uma dentre as sequências m é executada **/ Definir o rótulo de início S = atribuição condicional {004, 120, ... } (cor t1 == cor t5, cor C50 != cor t50, ...) /** Isso define o S para o 120, mas uma análise estática não pode determinar que **/ L: alternância (S) { caso 0: { /** segmento seguido pela atribuição condicional até o próximo valor S **/ } ***etc.***. caso 1: { /** Essa é a ação, se o valor S for FALSO; no caso, é uma armadilha**/ X5' /** Fazer alguma coisa que lembre a sequência X5 **/ selecionar alguns nós t_i e variar aleatoriamente os mesmos, e ajustar os indicadores. Atribuição Condicional de S Ir para L } ***etc.***. caso P1: /** Corrigir o caso para a clause_num(P1) **/ { X1 /** Se isso for a sequência correta para essa cor **/ Atribuição condicional de S Ir para L } } } ***assim por diante para cobrir até N casos ** }

[0063] Conforme mostrado no exemplo, uma permutação particular dos rótulos N é selecionada. Iniciando com o primeiro rótulo na permutação, um valor é computado para corresponder a uma definição correta da variável de alternância que é usada para alternar para o seu corpo de caso, que computa o código que gera o valor da definição correta do próximo elemento na permutação, e assim por diante. A definição dessa variável é protegida pelo código condicional que testa a definição de nós do gráfico mapeado pela ocorrência 3SATm. Apenas o conhecimento da definição da solução para o problema de coloração permitiria corrigir a seleção dos casos, sem recorrer a uma busca por força bruta.

[0064] Assim, o valor do próximo endereço (rótulo do caso) que será executado é apenas conhecido pela computação, dentro da declaração de caso. Adicionalmente, cada um desses casos computa o valor do próximo rótulo dentro de outra declaração protegida, conforme descrito posteriormente. Há N casos em que, em cada mudança de um lugar para o outro, define-se o próximo rótulo de caso e apenas para a combinação correta garantir-se á a definição correta para cada uma dentre as cores k. Para as definições erradas dos rótulos, a declaração de caso computará um valor errado de S para a próxima iteração. Além disso, há apenas uma passagem correta através dos valores dos rótulos e será provado, posteriormente, que a passagem correta é prova de conhecimento da solução do problema de colocação e, por sua vez, o problema 3 SAT. Em outras palavras, apenas o outro modo é adivinhação aleatória, o que é NP-difícil.

[0065] Etapa 5: A proteção com predicados opacos (X) é alcançada através do uso da estrutura a seguir. Se (A-B = 0), então { Código a ser ofuscado } ainda, { Atrair o código que parece o código correto com variações pequenas que o tornem incorreto. }

[0066] Uma forma alternativa é, Se (A-B+C = 0), então /** em que C é uma das literais de G1**/ { Código a ser ofuscado } ainda, { Atrair o código que parece o código correto com variações pequenas que o tornem incorreto. }

Protocolo De Autenticação

[0067] O protocolo de autenticação é esboçado na Figura 8 e descrito conforme a seguir: 1. O desenvolvedor cria o código que inclui: a. a chave pública de 2.048 bits (PUB) (2.048 bits de comprimento e gerados no servidor de desenvolvimento com uso de /dev/random) que é criptografado com uma chave AES de 128 bits (WB-AES-key-2) bem como b. um descriptografador de caixa branca (cuja chave é WB-AES-key-2) (Nota: A razão para criptografar a chave pública é para garantir sua autenticidade, conforme explicado abaixo.] 2. [O que é descrito a seguir pode ter especificidades para a plataforma Android®]. Uma chave de assinatura privada de 2.048 bits de comprimento (APP PRK), específica para o APP, é gerada com uso de /dev/random em um servidor seguro que é compatível com os critérios de segurança do servidor de desenvolvimento. A chave pública correspondente (APP PUB) é usada para gerar um certificado X.509 (APP CERT) que é assinado com APP PRK (isto é, autoassinado). Esse certificado é seguramente transportado para o desenvolvedor por meio de email, com uso de PGP, a fim de garantir a transmissão. APP CERT é criptografado com WB-AES-key-2 e armazenado no AMC. 3. O app é ofuscado, conforme descrito acima, e preparado para a distribuição por meio do armazenamento de app, conforme indicado na próxima etapa. 4. [Também Android] O provedor de conteúdo (ou desenvolvedor de app, em nome do provedor de conteúdo) submete o app assinado com uso de seu ou sua conta de Console de Desenvolvedor de Google play Android. O certificado assinado autentica a id de quem submete. O provedor de conteúdo/desenvolvedor de app precisa armazenar o APP CERT em um "KeyStore" com uso do utilitário "Keytool". Finalmente, o app é empacotado com o APP CERT para distribuição por meio de da loja do app Google Play, com uso do utilitário "jarsigner" que obtém como entrada o KeyStore e o alias de chave e insere o APP CERT no pacote de app. 5. [Também Android] O usuário baixa, instala e carrega o app em seu dispositivo. No momento da instalação, o Android OS verifica a validade do certificado anexado ao App. Isso é feito como parte do processo de instalação. Além disso, realiza-se uma verificação da autenticidade do certificado, conforme descrito posteriormente. 6. Para cada carregamento do app, o certificado anexado ao app precisa ser verificado. A ocorrência do app (também conhecido como "cliente") se inicia e usa o descriptografador de caixa branca para descriptografar o APP CERT criptografada, armazenado no AMC. A partir dessa cadeia descriptografada, o cliente usa o APP PUB* (o qual é confiável) para autenticar a assinatura do app, conforme a seguir.

[0068] O certificado anexado ao app é validado através da obtenção da assinatura, por meio do packagelnfo api, conforme mostrado abaixo. Primeiro, a chave pública no certificado é comparada com o APP PUB* e se esse for compatível, procede-se à verificação da assinatura. A assinatura anexada ao certificado é descriptografada com uso do APP PUB*, para obter o hash criptográfico da soma de verificação do certificado que pode, então, ser diretamente verificado. Se essa assinatura for autenticada, o cliente procede à configuração da sessão de SSl mutuamente autenticada com a retaguarda. Deve-se observar que essa etapa é feita com cada carregamento do app.

[0069] [Também Android] O packagelnfo. signatures api pode ser usado para conseguir a chave pública a partir da assinatura de app. O mesmo é usado apenas para autenticar a id do desenvolvedor e pode ser comparado contra o valor de confiança de APP PUB*. espaço vazio público onCreate(Bundle savedlnstanceState) { super.onCreate(savedlnstanceState); PackageManager pm = this.getPackageManager(); String packageName = this.getPackageName(); int field = PackageManager.GET SIGNATURES; Packagelnfo packagelnfo = pm.getPackageInfo(packageName, field); Signature[] signatures = packagelnfo. signatures; // e, aqui, tem-se o certificado DER decodificado X.509. byte[] certificate = signatures[0].toByteArray(); } 7. O cliente usa um certificado X.509 (CERT de cliente) assinado pelo desenvolvedor com uma chave de 2.048 bits, que é gerada no servidor de desenvolvimento, com uso de /dev/random para entropia. O CERT de cliente é embutido no app. O estabelecimento de um canal seguro autenticado de 2 vias é alcançado com uso de um descriptografador de caixa branca AES-128 para descriptografar uma chave de SSL privada (SSL) e usar a mesma para estabelecer o canal seguro. O SSL tem 2.048 bits de comprimento e é gerado no servidor de desenvolvimento com uso de /dev/random para entropia. A SSL é criptografada e armazenada (a criptografia é necessária para proteger a confidencialidade da chave privada SSL), com a chave de caixa branca WB-AES-key2 (a mesma descrita anteriormente no documento, sob a seção chamada "registro de dispositivo") e seria considerada segura, dada a força da criptografia AES e da Ofuscação Robusta. O servidor usa seu próprio certificado para autenticar com o cliente. 8. A retaguarda autentica o cliente em virtude da autenticação mútua, por meio de SSL. 9. Posteriormente, o cliente faz um registro de dispositivo, conforme descrito acima. Nenhuma notificação de ação ou valor de uso único de ação pode ser necessária. 10. A retaguarda envia, então, a chave de conteúdo criptografada com WB-AES-key-2. 11. A chave é descriptografada apenas na memória estática e nunca é armazenada em disco não criptografado. Além do mais, a chave é descriptografada apenas para descriptografia de conteúdo e a memória é seguramente apagada através de sobregravação com um padrão de bit robusto e seguro, conforme descrito abaixo. 12. A WB_AES-key-2 e o APP PUB são renovados por atualizações de app forçadas.

Outras Medidas

[0070] As memórias de armazenamento temporário que contêm chaves de sessão descriptografadas são sobregravadas com um padrão de bit robusto e seguro após o uso. Não se precisa usar memória de memória de alocação dinâmica e apenas usar memórias de armazenamento temporário locais (isto é, em variáveis de pilha) e, para apagar seguramente as mesmas quando o controle passa fora da rotina. Vários padrões de bits (0xF6, 0x00, 0xFF, aleatório, 0x00, 0xFF, aleatório) são gravados em sequência para a memória de armazenamento temporário. As chaves não criptografadas nunca são gravadas fora do disco.

Equivalência De Revelação De Execução Para Coloração De Gráfico:

[0071] A técnica é caracterizada, em parte, pelas duas asserções a seguir: 1. Uma sequência correta de execução das declarações XL.Xn implica o conhecimento das respostas corretas para as condicionais (usadas nas proteções) que são baseadas na coloração de G. 2. Um conjunto correto de respostas às condicionais sobre a coloração de G encontrado por meio de uma execução através da estrutura achatada resulta na sequência de execução correta XL.Xn.

[0072] A primeira asserção segue a partir da construção da ofuscação. Em outras palavras, a sequência de execução correta XL.Xm mostra, o conhecimento pressuposto da solução para a ocorrência G do problema de coloração do gráfico. Isso é devido ao fato de que a estrutura e a coloração do gráfico não são conhecidas, antes do tempo, por inspeção. Isso varia em partes diferentes do código que inclui dentro da sequência XL.Xn. Sem o conhecimento pressuposto da solução, alguém teria que saber como solucionar o problema de coloração geral, que é, de modo computacional, difícil.

[0073] Para a segunda asserção, é suficiente mostrar que qualquer sequência de execução ligada a uma definição correta das condicionais precisas produzir a ordem correta de execução. Isso estabeleceria a equivalência da revelação de execução para o problema de coloração do gráfico, em que a solução do que é descrito posteriormente é conhecida para que seja NP-concluída.

[0074] Base: E=1 A proposição é trivialmente verdadeira devido ao fato de que há apenas uma ordem para essa sequência.

[0075] Hipótese de Indução (I.H.): Presume-se que a proposição seja verdadeira para algum E=m em que m>1, isto é, qualquer sequência de execução que responda corretamente as condicionais sobre a coloração de gráfico de G também é uma execução correta de XL.Xn.

[0076] É, então, mostrado que a proposição suporta E=m+1. Considerar uma ocorrência do problema, cuja sequência de execução Y é de comprimento m+1.

[0077] A estrutura de qualquer elemento da sequência Y é conforme a seguir - A1 A2 A3 A4 A5 (1) em que 1. A1 e A3 são uma ou mais ocorrências de código de armadilha protegido por predicados opacos falsos; 2. A2 é o código real que precisa ser executado; 3. A4 é a atribuição condicional do próximo valor S da declaração de alternância; e 4. A5 é o Ir Para

[0078] Permitir que os dois últimos elementos de Y sejam y' e y". Agora, verificou-se um modo de combinar esses elementos, a fim de produzir uma execução de comprimento m, que é isomórfico para o gráfico de execução da sequência de execução Y prévia, isto é, é uma sequência de execução correta de XL.Xn. Define-se tal combinação, conforme a seguir: A1 'A1 " A2' A2" A3 'A3" Combined(A4', A4") A5" (2) em que os componentes A que pertencem a y' e y' ' respectivamente são indicados pela notação primária.

[0079] Combined(U,V) é a atribuição condicional que resulta da agregação das condições das condições individuais em U e V e as declarações de atribuição correspondentes. Claramente, a combinação em (2) acima tem a mesma estrutura de (1). Consequentemente, pode substituir o elemento y' e y", que resulta em uma sequência de execução de comprimento m.

[0080] A partir de I.H., sabe-se que qualquer tal sequência de execução (de comprimento m), cujas condicionais satisfaçam corretamente a coloração de G, é uma execução correta de XL.Xn. Sabe-se também que as condicionais de tal sequência mapeiam para a execução correspondente de Y em que as condicionais são divididas através de etapas y' e y". É necessário apenas mostrar que essa sequência de execução também está correta.

[0081] Em particular, sabe-se que a sequência combinada estava correta. Então, é necessário mostrar como a decomposição nas sequências originais de Y manteria a correção da execução. Excluindo o caso em que y'' é nulo, observa-se que, se houver condicionais em y'' que satisfaçam as questões sobre a coloração, então esses precisam incluir uma etapa correta da execução por construção. Deve-se observar que os outros componentes de y' e y' ' são de coloração segura, isto é, os mesmos não alteram os resultados das questões relacionadas à cor nas condicionais.

[0082] A Figura 8 diagrama a técnica descrita acima, que inclui as operações a seguir: 1. Criar um par de chaves de 2.048 bits (APP PUB, APP PRK); Gerar APP CERT; 2. X=Criptografar (PUB) com WB-AES-key-2; Y=Descriptografador de Caixa Branca para WB-AES-Key-2; Embutir X & Y no app; Ofuscar o app com uso da ocorrência 3-SAT; 3. Enviar app ofuscado. 4. Assinar o app com APP CERT e submeter à Loja de App 5. Baixar; instalar; carregar o app 6. No carregamento, AMC usa Y para descriptografar X a fim de conseguir a APP PUB*; Usar APP PUB* para validar a assinatura de app; Usar Y para descriptografar SSL 7. Criar mutuamente uma sessão de SSl autenticada com retaguarda. Enviar a solicitação de registro de dispositivo com id única. 8. Na solicitação de reprodução, perguntar à retaguarda pela chave de conteúdo 9. Enviar a chave de conteúdo criptografada com WB-AES-key-2

[0083] Na Figura 8, as linhas pontilhadas para os itens 7 a 9 indicam uma sessão de SSL com chave de 2.048 bits.

[0084] Em breve sumário, as descrições a seguir são aspectos importantes do aparelho e dos métodos revelados no momento:

[0085] O aplicativo, que implanta o lado de cliente do sistema de DRM, é renovável/ instalável por usuário no dispositivo de cliente.

[0086] O dispositivo de cliente emprega a inicialização segura e verifica o aplicativo instalado por usuário

[0087] O aplicativo é reforçado contra engenharia reversa

[0088] O aplicativo utiliza uma API especial fornecida pelo dispositivo de cliente para se unir à inicialização segura, ligando a lacuna entre a inicialização segura e o lado de cliente do sistema de DRM contido no aplicativo.

[0089] Embora várias modalidades da invenção tenham sido particularmente mostradas e descritas, será compreendido por aqueles versados na técnica que várias mudanças na forma e nos detalhes podem ser feitas no mesmo, sem se afastar do espírito e do escopo da invenção, conforme definido pelas reivindicações anexas.

Claims

1. Método através do qual um dispositivo de cliente comprova sua autenticidade para um cliente de mídia a ser instalado por usuário no dispositivo de cliente, assim como um servidor de gerenciamento de direitos acoplado de modo comunicativo ao dispositivo de cliente caracterizado pelo fato de compreender: entrar em um processo de inicialização segura para confirmar que uma imagem persistentemente armazenada no dispositivo de cliente e que inclui firmware para execução é, especificamente, inserida para uso em um esquema de gerenciamento de direitos que emprega uma chave de criptografia privada no servidor de gerenciamento de direitos e uma chave de criptografia pública correspondente armazenada de modo seguro na imagem, sendo que o firmware é configurado e operativo mediante a execução para responder a uma solicitação do cliente de mídia através do retorno de uma mensagem de registro de dispositivo criptografada com o uso da chave de criptografia pública, em que o processo de inicialização segura inclui (1) verificar uma assinatura da chave de criptografia pública armazenada com o uso de uma primeira chave de verificação armazenada de modo seguro no armazenamento programável uma vez (OTP) do dispositivo de cliente, (2) descriptografar uma chave simétrica criptografada contida na imagem e verificar uma assinatura da chave simétrica de descriptografada com o uso de uma ou mais segundas chaves de verificação armazenadas de modo seguro no armazenamento OTP e (3) verificar uma assinatura da imagem persistentemente armazenada com o uso da chave simétrica descriptografada; carregar e executar o firmware mediante a conclusão bem-sucedida do processo de inicialização segura; e através do firmware durante a operação subsequente e em resposta à solicitação do cliente de mídia, usar a chave de criptografia pública persistentemente armazenada para criar a mensagem de registro de dispositivo criptografada e retornar a mensagem de registro de dispositivo criptografada para o cliente de mídia para encaminhar para o servidor de gerenciamento de direitos como parte de um processo de autenticação de dispositivo

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o processo de inicialização segura inclui uma inicialização no nível do processador e uma inicialização no nível do firmware subsequente com o uso de uma rotina de inicialização de firmware contida na imagem, sendo que a inicialização no nível do firmware realiza a descriptografia da chave simétrica criptografada e a verificação da assinatura da imagem persistentemente armazenada e inclui, adicionalmente, através da inicialização no nível do processador, verificar uma assinatura da rotina de inicialização de firmware e, mediante a verificação bem sucedida da assinatura, então, iniciar a inicialização de firmware.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a imagem armazena as respectivas assinaturas armazenadas para a chave de criptografia pública armazenada, a chave simétrica criptografada e os componentes de firmware da imagem, e em que a verificação de uma assinatura para uma dada chave ou componente de firmware inclui (1) calcular uma assinatura para a dada chave ou componente de firmware e (2) comparar a assinatura calculada com uma respectiva assinatura das assinaturas armazenadas.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o cliente de mídia implanta um lado de cliente de um sistema de gerenciamento de direitos digitais (DRM) e é instalado por usuário no dispositivo de cliente.

5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que o firmware do dispositivo de cliente verifica o cliente de mídia instalado por usuário no dispositivo de cliente.

6. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que o cliente de mídia utiliza uma API especial fornecida pelo dispositivo de cliente para se unir à inicialização segura, ligando a lacuna entre a inicialização segura e o lado de cliente do sistema de DRM contido dentro do aplicativo.

7. Dispositivo de cliente caracterizado pelo fato de compreender: um ou mais processadores; memória; conjunto de circuitos de interface de entrada/saída; e um ou mais barramentos de dados que acoplam os processadores, memória e conjunto de circuitos de entrada/saída, em conjunto, para a transferência de dados de alta velocidade entre os mesmos, sendo que memória armazena instruções que, quando executadas pelos processadores fazem com que o dispositivo de cliente comprove sua autenticidade para um cliente de mídia a ser instalado por usuário no dispositivo de cliente assim como para um servidor de gerenciamento de direitos acoplado de modo comunicativo ao dispositivo de cliente, o dispositivo de cliente é operável para comprovar a sua autenticidade para um cliente de mídia e ao servidor de gerenciamento de direitos através de entrar em um processo de inicialização segura para confirmar que uma imagem persistentemente armazenada no dispositivo de cliente e que inclui firmware para execução é especificamente inserida para uso em um esquema de gerenciamento de direitos que emprega uma chave de criptografia privada no servidor de gerenciamento de direitos e uma chave de criptografia pública correspondente armazenada de modo seguro na imagem, sendo que o firmware é configurado e é operativo mediante a execução para responder a uma solicitação do cliente de mídia através do retorno de uma mensagem de registro de dispositivo criptografada com o uso da chave de criptografia pública, o processo de inicialização segura inclui (1) verificar uma assinatura da chave de criptografia pública armazenada com o uso de uma primeira chave de verificação armazenada de modo seguro no armazenamento programável uma vez (OTP) do dispositivo de cliente, (2) descriptografar uma chave simétrica criptografada contida na imagem e verificar uma assinatura da chave simétrica descriptografada com o uso de uma ou mais segundas chaves de verificação armazenadas de modo seguro no armazenamento OTP e (3) verificar uma assinatura da imagem persistentemente armazenada com o uso da chave simétrica descriptografada; carregar e executar o firmware mediante a conclusão bem-sucedida do processo de inicialização segura; e através do firmware, durante a operação subsequente e em resposta à solicitação do cliente de mídia, usar a chave de criptografia pública persistentemente armazenada para criar a mensagem de registro de dispositivo criptografada e retornar a mensagem de registro de dispositivo criptografada para o cliente de mídia para encaminhar para o servidor de gerenciamento de direitos como parte de um processo de autenticação de dispositivo.

8. Dispositivo de cliente, de acordo com a reivindicação 7, caracterizado pelo fato de que o processo de inicialização segura inclui uma inicialização no nível do processador e uma inicialização no nível do firmware subsequente com o uso de uma rotina de inicialização de firmware contida na imagem, sendo que a inicialização no nível do firmware realiza a descriptografia da chave simétrica criptografada e a verificação da assinatura da imagem persistentemente armazenada, e em que o método inclui, adicionalmente, através da inicialização no nível do processador, verificar uma assinatura da rotina de inicialização de firmware e, mediante a verificação bem-sucedida da assinatura, então, iniciar a inicialização de firmware.

9. Dispositivo de cliente, de acordo com a reivindicação 7, caracterizado pelo fato de que a imagem armazena as respectivas assinaturas armazenadas para a chave de criptografia pública armazenada, a chave simétrica criptografada e os componentes de firmware da imagem, e em que a verificação de uma assinatura para uma dada chave ou componente de firmware inclui (1) calcular uma assinatura para a dada chave ou componente de firmware, e (2) comparar a assinatura calculada com uma respectiva assinatura das assinaturas armazenadas.

10. Dispositivo de cliente, de acordo com a reivindicação 7, caracterizado pelo fato de que o cliente de mídia implanta um lado de cliente de um sistema de gerenciamento de direitos digitais (DRM) e é instalado por usuário no dispositivo de cliente.

11. Dispositivo de cliente, de acordo com a reivindicação 10, caracterizado pelo fato de que o firmware do dispositivo de cliente verifica o cliente de mídia instalado por usuário no dispositivo de cliente.

12. Dispositivo de cliente, de acordo com a reivindicação 10, caracterizado pelo fato de que o cliente de mídia utiliza uma API especial fornecida pelo dispositivo de cliente para se unir a inicialização segura, ligar a lacuna entre a inicialização segura e o lado de cliente do sistema de DRM contido no aplicativo.