BR112013012356B1 - método para detectar um software clonado - Google Patents

método para detectar um software clonado Download PDF

Info

Publication number
BR112013012356B1
BR112013012356B1 BR112013012356-7A BR112013012356A BR112013012356B1 BR 112013012356 B1 BR112013012356 B1 BR 112013012356B1 BR 112013012356 A BR112013012356 A BR 112013012356A BR 112013012356 B1 BR112013012356 B1 BR 112013012356B1
Authority
BR
Brazil
Prior art keywords
tag value
server
customer
user unit
message
Prior art date
Application number
BR112013012356-7A
Other languages
English (en)
Other versions
BR112013012356A2 (pt
Inventor
Jean-Bernard Fischer
Patrick Marcacci
Christian Schwarz
Brecht Wyseur
Original Assignee
Nagravision S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nagravision S.A. filed Critical Nagravision S.A.
Publication of BR112013012356A2 publication Critical patent/BR112013012356A2/pt
Publication of BR112013012356B1 publication Critical patent/BR112013012356B1/pt

Links

Images

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]
    • G06F21/16—Program or content traceability, e.g. by watermarking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • 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]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • 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/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H04N21/25816—Management of client data involving client authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42684—Client identification by a unique number or address, e.g. serial number, MAC address, socket ID
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44236—Monitoring of piracy processes or activities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • 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]
    • G06F21/101—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities
    • G06F21/1014—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities to tokens

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Technology Law (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Power Engineering (AREA)
  • Computer Graphics (AREA)
  • Virology (AREA)
  • Data Mining & Analysis (AREA)
  • Bioethics (AREA)
  • Storage Device Security (AREA)
  • Semiconductor Integrated Circuits (AREA)

Abstract

MÉTODO PARA DETECTAR UM SOFTWARE CLONADO. Trata-se de um método para detectar um software clonado a ser usado em uma unidade de usuário cliente que se comunica com um servidor para solicitar um serviço enviando-se uma solicitação a partir da unidade de usuário ao servidor, sendo que o último é conectada a um banco de dados que compreende registros de cliente, sendo que cada um desses registros compreende pelo menos um valor de etiqueta (tc) como um histórico de solicitações de cliente, sendo que o dito método compreende uma fase de inicialização e uma fase de operação, a) a fase de inicialização compreende as etapas de: - definir o dito valor de etiqueta (tc) como sendo um valor aleatório inicial, então, abrir um novo registro que armazena o dito valor de etiqueta (tc) no banco de dados e introduzir o dito valor de etiqueta na unidade de usuário cliente, b) a fase de operação compreende as etapas de: - preparar, no lado da unidade de usuário, uma mensagem de cliente para o servidor que compreende a dita solicitação e um valor dependendo do dito valor de etiqueta (tc), então, enviar esta mensagem de cliente, a partir da unidade de usuário (...).

Description

Campo da técnica
A presente invenção refere-se ao campo de receptor/decodificadores integrados que recebem dados a partir de um equipamento de radiodifusão central; sendo o acesso a esses dados submetidos a um acesso condicional.
Antecedentes
Um problema principal em segurança de softwares consiste em evitar cópias e utili-zações ilegítimas de softwares.
Em uma solução de software puro, este problema é impossível de solucionar em um caso de uso desconectado. No entanto, quando uma conexão estiver disponível em uma entidade confiável (por exemplo, um servidor de verificação), esta conexão pode ser usada para implementar alguns mecanismos de segurança (tanto no caso de uma conexão contínua como no caso de uso em conexão ocasional). Apesar disto, em um caso de uso distribuído (onde uma grande população de usuários tem permissão de usar o software), ainda é difícil detectar e bloquear cópias.
Atrelar o software ao hardware de sua plataforma nem sempre é uma opção. Em primeiro lugar, isto pode não ser possível devido à falta de hardwares confiáveis ou de um mecanismo bootstrap. Em segundo lugar, um usuário deve sempre ter permissão de migrar seu software para outra plataforma, ou alterar sua configuração de hardware ou software.
Na presente configuração, um reprodutor pode ser facilmente clonado com todos os seus segredos e ser executado em milhares de computadores ao mesmo tempo. Portanto, um usuário pagando uma taxa fixa para acessar os conteúdos teria um bom incentivo para revender as cópias (clones) de seu reprodutor para outros usuários.
Sumário da invenção
Com o intuito de solucionar este problema, a presente invenção sugere um método para detectar um software clonado que seja usado em uma unidade de usuário cliente. Esta unidade de usuário se comunica com um servidor para solicitar um serviço enviando-se uma solicitação de cliente a partir da unidade de usuário cliente a este servidor. O último é conectado a um banco de dados que compreende os registros de cliente. Cada um desses registros compreende pelo menos um valor, um valor de etiqueta nomeado, que seja associado a uma unidade de usuário cliente específica. Este valor de etiqueta é usado como uma trilha do histórico de utilização de cada cliente (histórico parcial ou completo). Neste sentido, esse valor pode ser, por exemplo, um valor hash ou uma compilação resultante de uma função de compressão. Este método compreende uma fase de inicialização e uma fase de operação: a) a fase de inicialização compreende as etapas de: - definir o dito valor de etiqueta como sendo um valor aleatório inicial, - abrir um novo registro para armazenar este valor de etiqueta, - introduzir o dito valor de etiqueta (tc) na unidade de usuário cliente, b) a fase de operação compreende as etapas de: - preparar, no lado da unidade de usuário, uma mensagem de cliente para o servidor que compreende a solicitação e o valor de etiqueta, então - enviar esta mensagem de cliente, a partir da unidade de usuário ao servidor, - realizar um teste de condição de acesso, no lado do servidor, testando-se se o valor de etiqueta da mensagem de cliente corresponde ao valor de etiqueta armazenado no banco de dados, em caso negativo: negar o serviço solicitado, enquanto que em caso positivo: - enviar uma mensagem de servidor à unidade de usuário, como uma resposta à solicitação de cliente, - atualizar o valor de etiqueta, tanto no lado do servidor como no lado da unidade de usuário, substituindo-o por um novo valor de etiqueta derivado, por um lado, a partir do último valor de etiqueta e, por outro lado, a partir de outros dados conhecidos pelo cliente e pelo servidor, - armazenar o novo valor de etiqueta no lado do servidor atualizando-se o registro correspondente, e no lado do cliente atualizando-se o conteúdo de memória da unidade de usuário.
Breve descrição dos desenhos
A presente invenção será mais bem compreendida graças às figuras em anexo, em que: A Figura 1 mostra um diagrama de detecção de clonagem, que se baseia em uma verificação dinâmica de etiqueta, de acordo com uma primeira modalidade da presente in-venção, A Figura 2a ilustra uma segunda modalidade da invenção, em particular, uma au-tenticação de mensagem com base em uma credencial dinâmica para detectar clonagem. A Figura 2b ilustra outra variante da modalidade mostrada na Figura 2a. A Figura 3 ilustra uma terceira modalidade da invenção, onde uma condição de atualização de etiqueta é imposta antes da distribuição de conteúdo.
Descrição detalhada
A ideia principal da solução sugerida na presente invenção se baseia na observação que cada componente de software de cliente (por exemplo, um reprodutor de mídia) terá uma utilização de conteúdo diferente. Cada utilização de conteúdo gera um histórico exclusivo que permite investigar a legitimidade do software e facilitar a detecção de cópias ilegítimas.
De modo mais concreto, um servidor acompanhará o histórico de utilização de cada cliente através do uso do valor de etiqueta. O valor de etiqueta representa a utilização (par- cial ou completa) enquanto se preserva a privacidade do histórico. Em cada solicitação válida, este valor de etiqueta será preferencialmente atualizado, causando, assim, uma dessin- cronização entre as cópias feitas a partir desta implementação, dado que quando uma cópia for feita, este se ramificará a partir do histórico do cliente original, e sua utilização se afastará da utilização do cliente original. É precisamente esta divergência que pode ser detectada.
Referindo-se à Figura 1 que mostra uma primeira modalidade da invenção, cada cliente (C) recebe um valor de etiqueta aleatório inicial tc que pode ser incorporado ao reprodutor de software no tempo de inicialização ou que pode ser transmitido pelo servidor durante a primeira autenticação com o último. O servidor terá o valor de etiquetas de todos os clientes em um banco de dados. Este valor de etiqueta inicial tc também pode se enviado ao cliente da unidade de usuário através de qualquer meio de comunicação convencional, tal como, mas sem limitar-se a, uma carta, um SMS, uma chamada telefônica, um e-mail, uma página da web, ou qualquer combinação destes. Em seu lado, o servidor abriu um novo registro em seu banco de dados para armazenar este valor de etiqueta tc. Portanto, tanto a unidade de usuário como o servidor possuem o mesmo valor de etiqueta tc ao fim desta primeira fase, nomeada fase de inicialização.
Com a finalidade e implementar esta fase de inicialização, adotaram-se as seguintes etapas: - definir o valor de etiqueta (tc) como sendo igual a um valor aleatório inicial, - abrir um novo registro que armazena o dito valor de etiqueta (tc) no banco de dados do servidor, - introduzir este valor de etiqueta (tc) na unidade de usuário cliente.
A etapa que visa definir o valor de etiqueta como sendo um valor aleatório inicial visa adotar um valor imprevisível como o primeiro valor de etiqueta.
Durante uma fase de operação e ainda com referência à Figura 1, quando um cliente solicitar um serviço a partir do servidor, através de uma rede de comunicação comum que conecta a unidade de usuário cliente a este servidor, seu valor de etiqueta tc será enviado junto a uma mensagem nomeada mensagem de cliente. O servidor verificará se o valor de etiqueta, incluído na mensagem de cliente, também está presente em seu banco de dados se tal comparação fornecer um resultado correto, o servidor concederá o serviço solicitado (ou procederá com a verificação de outros requerimentos). Se o valor de etiqueta enviado dentro da mensagem de cliente não for listado no banco de dados ou se não puder ser verificado corretamente, então, o serviço solicitado será recusado.
O valor de etiqueta tc pode ser a compilação de uma função de compressão, tal como uma função hash criptográfica, aplicada à solicitação de cliente. Embora boas funções de derivação proporcionem compilações que sejam difíceis de descobrir, um atacante, tal como um homem-no-meio, conhecido por um indivíduo versado na técnica, ainda poderia tentar obter acesso a um serviço seja apropriando-se ou adivinhando-se os valores de etiqueta.
A fim de evitar quaisquer ataques, uma primeira solução consiste em assegurar as comunicações entre o cliente e o servidor através de um canal protegido (isto é, por meio de uma comunicação criptografada e autenticada entre o cliente e o servidor). Neste caso, o valor de etiqueta pode ser diretamente anexado à solicitação, e, logo, o servidor pode realizar uma verificação direta verificando-se se a etiqueta está compreendida no banco de dados do servidor (conforme mostrado na Figura 1).
Além disso, se uma função hash criptográfica for usada para derivar uma nova etiqueta a partir de da etiqueta antiga e do histórico de utilização, então, este valor de etiqueta é exclusivo por usuário e pode, portanto, ser usado como um identificador que serve para identificar cada cliente. Isto facilita uma verificação anticlonagem sem a necessidade de associar as solicitações a indivíduos e, portanto, levar a verificações transparentes, mais rápidas e anônimas (no entanto, isto não exclui anexar um identificador exclusivo de cliente à solicitação na mensagem de cliente). Descrito na Figura 1, este caso de uso é um protocolo de atestação remota que deveria apenas ser usado em casos onde uma pessoa mal- intencionada não é capaz de ativamente ludibriar e violar a conexão entre o cliente e o servidor (por exemplo, em um domínio domiciliar seguro ou quando a comunicação entre o cliente e o servidor estiver em um canal seguro autenticado).
Correspondente a cada solicitação válida, tanto o cliente como o servidor atualizarão o valor de etiqueta. O novo valor de etiqueta t’c será derivado a partir dos dados que são conhecidos tanto pelo cliente como pelo servidor: por exemplo, o valor de etiqueta antigo e as informações obtidas pelo menos a partir de uma parte do conteúdo da mensagem de servidor que é fornecida como resposta à solicitação de cliente. Alternativamente, o novo valor de etiqueta t’c pode derivar a partir do último valor de etiqueta tc e a partir de pelo menos uma parte do conteúdo da mensagem de cliente. A mensagem de servidor ou a mensagem de cliente (ou uma parte de seu conteúdo) podem ser um carimbo de data/hora que esteja incorporado no fluxo de mídia ou quaisquer outras informações de cabeçalho, chaves criptográficas sobre-criptogafadas que sejam enviadas juntamente, quadros específicos, etc. O novo valor de etiqueta t’c é destinado a substituir o valor de etiqueta antigo tc.
Neste sentido, esta fase de operação requer as etapas de: - preparar, no lado da unidade de usuário, uma mensagem de cliente que compreende uma solicitação junto ao valor de etiqueta tc, então - enviar esta mensagem de cliente, a partir da unidade de usuário ao servidor, - realizar um teste de condição de acesso, no lado do servidor, visando testar se este valor de etiqueta tc está compreendido no banco de dados do servidor. Em resultado negativo (isto é, em caso negativo): negar o serviço solicitado, enquanto que em resultado po- sitivo (isto é, caso positivo): - enviar uma mensagem de servidor à unidade de usuário, como resposta à solicitação de cliente, - atualizar o valor de etiqueta tc, tanto no lado do servidor como no lado da unidade de usuário, substituindo-se este valor tc por um novo valor de etiqueta t’c. Este novo valor de etiqueta t’c é derivado a partir do último valor de etiqueta tc e a partir de outros dados conhecidos tanto pelo cliente como pelo servidor, - armazenar o novo valor de etiqueta t’c na unidade de usuário (isto é, em uma me-mória) e no registro do banco de dados conectado ao servidor (por exemplo, substituindo-se o valor de etiqueta antigo tc).
Se uma cópia da implementação de software de cliente for feita, ocorrerá uma des- sincronização quando uma delas (seja a original ou a cópia) solicitar um serviço. Logo, um usuário autêntico não tem incentivos para compartilhar sua implementação de software de cliente, visto que o uso da cópia eventualmente negaria seu original para que seja capaz de ter acesso concedido.
De modo vantajoso, um usuário ainda pode migrar sua implementação de software para outra plataforma sem quaisquer problemas.
Referindo-se à Figura 2a, descreve-se outra modalidade da invenção que é útil em evitar quaisquer ataques enquanto se usa um canal inseguro. A solução sugerida nesta mo-dalidade visa assinar a solicitação de cliente utilizando-se uma chave, derivando direta ou indiretamente a partir do valor de etiqueta tc, obtido por uma função de derivação de chave de assinatura. Portanto, durante a fase de operação, quando um cliente solicitar um serviço a partir do servidor (por exemplo, através de um canal de comunicação inseguro), uma assinatura da solicitação será enviada junto à solicitação contida na mensagem de cliente. Conforme mostrado na Figura 2a, esta assinatura pode ser anexada à solicitação como um código de autenticação da mensagem de cliente. Esta assinatura é obtida primeiramente aplicando-se uma função de compressão à solicitação de cliente com a finalidade de obter uma compilação da solicitação, então, criptografando-se esta compilação com uma chave de assinatura que é derivada a partir do valor de etiqueta e obtida utilizando-se a função de derivação de chave de assinatura. Por exemplo, a função de compressão pode ser uma função hash ou uma função HMAC que adota como chave o valor de etiqueta tc, ou um valor derivado da mesma. Desta forma, o valor da assinatura depende do valor de etiqueta. O servidor é capaz de verificar a autenticação da solicitação de cliente comparando-se a assinatura compreendida na mensagem de cliente com uma assinatura computada pelo servidor de maneira similar àquela determinada pela unidade de usuário cliente. Neste sentido, o servidor usa a mesma chave de assinatura (obtida a partir da mesma função de derivação de assinatura e do valor de etiqueta armazenado em seu banco de dados) para descriptografar a assinatura anexada à solicitação e, então, obter a compilação desta solicitação. Então, o servidor computa uma compilação a partir da solicitação utilizando-se a mesma função de compressão usada pela unidade de usuário. Se esta compilação for idêntica à compilação descriptogafada, portanto, a comparação fornece um resultado correto e a assinatura é definida como sendo válida. Se a assinatura for válida, o servidor concederá o serviço solicitado (ou procederá com a verificação de outros requerimentos) e o valor de etiqueta pode ser atualizado conforme mencionado anteriormente com referência à Figura 1. Se a assinatura enviada dentro da mensagem de cliente não puder ser verificada corretamente, portanto, o serviço solicitado será recusado (outras etapas também podem ser realizadas pelo servidor como consequência de um serviço negado).
Com a finalidade de implementar a modalidade mostrada na Figura 2a, a fase de inicialização descrita com a modalidade mostrada na Figura 1 precisa ser corrigida adotando-se as etapas adicionais a seguir: - definir uma função de assinatura (por exemplo, uma função HMAC) e uma função de derivação de chave de assinatura para obter uma chave de assinatura (derivada prefe-rencialmente a partir do dito valor de etiqueta tc) para criptografar uma compilação resultante a partir desta função de assinatura, - compartilhar a definição desta função de assinatura e a definição da função de de-rivação de chave de assinatura entre a unidade de usuário e o servidor.
Conforme descrito previamente com referência à Figura 1, compartilhar esses dados durante esta fase de inicialização pode ser alcançado através de muitas maneiras diferentes, desde que o valor e/ou a função possa ser introduzida, ao fim desta etapa, na unidade de usuário cliente. Ao fim desta fase de inicialização, a unidade de usuário e o servidor possuem os mesmos dados iniciais.
A fase de operação da modalidade ilustrada pela Figura 2a requer, ainda, as etapas a seguir, além ou ao invés daquelas referentes à primeira modalidade (mesma fase): - calcular um código de autenticação aplicando-se a função de assinatura à solicitação de cliente e utilizando-se a chave de assinatura para criptografar a compilação resultante a partir da dita função de assinatura, então, corrigindo-se a etapa de preparação da mensagem de cliente preparando-se uma mensagem de cliente que compreende o código de autenticação e a solicitação de cliente, - corrigir a condição de acesso verificando-se se o código de autenticação recebido contido na mensagem de cliente é igual a um código de autenticação calculado pelo servidor aplicando-se a mesma função de assinatura à solicitação de cliente e utilizando-se a mesma chave de assinatura para descriptografar a dita compilação; onde a chave de assinatura é preferencialmente derivada a partir do valor de etiqueta esperado que esteja armazenado no servidor banco de dados.
Referindo-se agora à Figura 2b, esta mostra uma variante da modalidade mostrada na Figura 2a. Durante a fase de inicialização, cada implementação de software de cliente instalou um identificador exclusivo IDc, e um valor de etiqueta aleatório inicial tc. O servidor armazena os tuplos (IDc, tc) de todos os seus clientes legítimos. Portanto, em relação à fase de inicialização da modalidade mostra na Figura 2a, adotam-se as etapas adicionais a seguir: - alocar um identificador exclusivo IDc ao cliente e armazenar este identificador de cliente IDc no novo registro atribuído a este cliente, - compartilhar este identificador IDc entre a unidade de usuário e o servidor (de pre-ferência, junto à definição da função de assinatura).
Conforme previamente mencionado, compartilhar ou obter esses dados durante esta fase de inicialização podem ser alcançados através de várias maneiras, desde que os dados possam ser introduzidos, ao fim desta etapa, na unidade de usuário cliente. O objetivo desta etapa é o mesmo das modalidades anteriores, isto é, que a unidade de usuário e o servidor possuam os mesmos dados iniciais.
Quando um cliente solicitar um serviço, ele envia seu identificador e uma assinatura da solicitação, que autentica sua solicitação. De preferência, a assinatura usa o valor de etiqueta armazenado como uma chave (ou a chave é derivada a partir deste valor de etiqueta).
O servidor é capaz de verificar a assinatura, visto que ele conhece a função de as-sinatura e é capaz de derivar a chave de assinatura que é usada a partir do tuplo correspondente ao identificador do cliente. Somente quando a assinatura estiver correta, um serviço será concedido.
Correspondente a cada solicitação válida, o cliente e o servidor atualizarão o valor de etiqueta tc da mesma forma descrita nas modalidades anteriores. Portanto, um novo valor de etiqueta t’c será computado a partir do valor de etiqueta antigo tc por um lado, e a partir das informações obtidas a partir do conteúdo que é proporcionado por outro lado. No banco de dados do servidor, a etiqueta nova substituirá a etiqueta antiga.
A partir disto, deve-se notar que a fase de operação da modalidade ilustrada pela Figura 2b requer, ainda, as etapas a seguir, além ou ao invés daquelas referentes à primeira modalidade mostrada na Figura 2a (mesma fase): - corrigir a etapa de preparação da mensagem de cliente incluindo-se o identificador de cliente IDc na mensagem de cliente.
Opcionalmente, o servidor pode enviar uma atualização de software a um cliente, alterar a função de assinatura e/ou os parâmetros usados, ou pode decidir substituir o valor de etiqueta tc por um novo valor de etiqueta t’c. Esta técnica pode ser aplicada a qualquer modalidade e poderia ser usada para incapacitar hackers que eram capazes de buscar por um valor de etiqueta e/ou aplicar engenharia reversa na função de assinatura usada ou na função para computar um novo valor de etiqueta (por exemplo, a função hash criptográfica). Visto que neste caso, eles poderiam tentar combater a dessincronização, que ocorre quando clones são usados, implementando-se um serviço de ‘ressincronização’ central ou um proxy entre os clones e o servidor.
O uso de uma função hash é recomendado para alcançar a invenção de acordo com a primeira modalidade mostrada na Figura 1. Isto segue a partir do fato de que os valores de etiqueta (isto é, os valores hash) armazenados no servidor banco de dados devem ser difíceis de descobrir e precisam permanecer diferentes quando forem atualizados. Não devem ocorrer colisões entre duas implementações de cliente autênticas. Ou seja, se todos os clientes autênticos iniciarem com um valor de etiqueta inicial, uma colisão nos valores hash implicaria que a função hash criptográfica mostrada seja insegura (em relação à propriedade de resistência à colisão que é necessária para funções hash criptográficas).
No entanto, de acordo com a modalidade mostrada na Figura 2b, esta recomendação pode ser cedida visto que cada valor de etiqueta é ligado a um identificador exclusivo, isto é, ao identificador de cliente IDc. A única recomendação é que a chave de assinatura, que é idêntica ao valor de etiqueta tc ou, de preferência, derivada a partir deste valor de etiqueta, permanece imprevisível para usuários mal-intencionados não tendo nenhum conhecimento do valor de etiqueta tc. Logo, uma entropia suficiente deve permanecer a partir da entrada. A função de derivação de etiqueta calcula o novo valor de etiqueta t’c com base no valor de etiqueta (antigo) tc e pelo menos uma parte do conteúdo da mensagem. Desta maneira, realiza-se uma cadeia que detém informações obtidas ao longo de todo o histórico passado.
Um mecanismo de retrocesso também é sugerido pela presente invenção no caso de dessincronização acidental, por exemplo, quando um cliente precisar retroceder para um backup anterior após seu sistema ter entrado em colapso, ou quando seu software tiver sido clonado de modo não-intencional. Um procedimento de retrocesso pode ser implementado através de um processo de autenticação convencional, por exemplo, apresentando-se cre-denciais corretas. Ao fim deste procedimento, o valor de etiqueta correspondente ao identifi-cador de cliente exclusivo pode ser substituído no lado do cliente (na unidade de usuário) e no lado do servidor (na memória do servidor). Isto tornará cada clone que usa o mesmo identificador imprestável.
Para executar tal mecanismo de retrocesso, a fase de operação de qualquer moda-lidade compreenderá uma etapa de ressincronização que corrige a etapa de atualização pelas etapas a seguir: - substituir o valor de etiqueta tc por um novo valor de etiqueta t’c igual a um valor aleatório novo, - então, enviar o dito novo valor de etiqueta t’c à unidade de usuário.
Referindo-se à Figura 3, sugere-se uma terceira modalidade principal para a presente invenção. De acordo com esta variante, a unidade de usuário cliente anexará a cada solicitação uma assinatura conforme também é realizado na segunda modalidade desta invenção (vide a Figura 2a e a Figura 2b). Uma vez que o servidor tiver verificado a assinatura como sendo válida, o servidor pode decidir executar uma atualização da etiqueta (forçando o cliente a solicitar novamente o serviço, permitindo, assim, que o servidor prove que o valor de etiqueta da unidade de usuário cliente foi atualizado), ou não fazer isso e enviar diretamente o conteúdo em resposta à solicitação. Em contrapartida às modalidades anteriores desta invenção, o novo valor de etiqueta t’c não é mais atualizado com base no conteúdo que é enviado. A decisão quanto a executar uma atualização de etiqueta depende da lógica de negócio. A verificação se o valor de etiqueta tc precisa ser atualizado pode ser realizada por um teste baseado em um parâmetro temporal ou em uma característica que pode depender da significância da solicitação de cliente, por exemplo. Uma atualização de etiqueta pode ser executada para cada solicitação de conteúdo, ou apenas para o conteúdo valioso, ou uma vez ao dia, ou dependendo de quaisquer outros parâmetros imagináveis. A decisão se executa uma atualização do valor de etiqueta também poderia ser aplicada às outras modalidades mostradas nas Figuras 1, 2a e 2b adicionando-se, à fase de operação, uma etapa que visa tomar tal decisão. Neste caso, a unidade de usuário cliente deve ser informada, sempre que uma mensagem de servidor for enviada como uma resposta a uma solicitação de cliente, tenha sido o valor de etiqueta atualizado ou não pelo servidor. Por exemplo, um valor específico poderia ser adicionado ou anexado à mensagem de servidor com a finalidade de proporcionar tais informações à unidade de usuário cliente.
Voltando-se à modalidade mostrada na Figura 3, para executar uma atualização de etiqueta, o servidor enviará à unidade de usuário cliente uma mensagem específica (isto é, uma mensagem de atualização) que inclui um valor de atualização (denotado pela letra X nesta figura) que será usado ao derivar o novo valor de etiqueta t’c. Por exemplo, este valor de atualização (X) pode ser um valor aleatório, uma informação de cabeçalho ou uma informação de metadados. Após esta etapa, o servidor esperará que a unidade de usuário cliente inicie o procedimento de solicitação novamente a partir do início, isto é, logo após a fase de inicialização e após ter introduzido o novo valor de etiqueta t’c que deriva, por um lado, a partir do valor de etiqueta anterior tc e, por outro lado, a partir do valor de atualização (X) compreendido na mensagem de atualização. Desta forma, o servidor pode facilmente verificar se a etiqueta foi atualizada ou não. Desde que não tenha sido recebida nenhuma assinatura que corresponda ao novo valor de etiqueta, o servidor utilizará a etiqueta antiga e manterá a repetição da etapa de aplicação da atualização de etiqueta. Alternativamente, o serviço solicitado pode ser negado, por exemplo, após um determinado número de tentativas falhas. Portanto, um teste que visa contar (por meio de um contador específico) o número de tentativas malsucedidas, até um limite predefinido, pode ser realizado para decidir enviar uma mensagem de servidor à unidade de usuário sem atualizar o valor de etiqueta tc, ou negar o serviço solicitado. Uma vez que uma assinatura que corresponda à etiqueta nova tiver sido recebida, o serviço solicitado pode ser distribuído ao cliente.
Esta terceira modalidade principal, conforme mostrado na Figura 3, requer, ainda: a) substituir as etapas no resultado positivo do teste de condição de acesso realizado dentro da fase de operação por uma etapa condicional que visa verificar se o valor de etiqueta (tc) precisa ser atualizado: - em caso positivo: em primeiro lugar, atualizar o valor de etiqueta tc, tanto no lado do servidor como no lado da unidade de usuário, enviando-se a partir do servidor à unidade de usuário uma mensagem de atualização incluindo um valor de atualização X e substituindo-se o valor de etiqueta tc por um novo valor de etiqueta t’c derivado a partir do último valor de etiqueta tc e a partir do valor de atualização X, então, armazenar o novo valor de etiqueta t’c no registro do banco de dados do servidor e na memória da unidade de usuário, - em caso negativo: enviar diretamente a mensagem de servidor à unidade de usuário, como uma resposta à solicitação de cliente (neste último caso, o valor de etiqueta tc não é atualizado), b) substituir as etapas no resultado negativo do dito teste de condição de acesso por um teste que visa, por meio de um contador de tentativas malsucedidas usado para contar um número de resultados negativos sucessivos relacionados à dita condição de acesso, verificar se este número alcançou um limite predeterminado: - em caso negativo: enviar uma mensagem de servidor à unidade de usuário sem atualizar o valor de etiqueta (tc), - em caso positivo: negar o serviço solicitado.
Considerando o caso positivo da etapa condicional que visa verificar se o valor de etiqueta precisa ser atualizado (conforme mencionado anteriormente sob a parte denotada como a) dentro da), deve-se notar que a unidade de usuário cliente é forçada a reenviar a solicitação de cliente enquanto usa o valor de etiqueta atualizado. De acordo com outra variante apropriada, uma mensagem pode ser enviada à unidade de usuário cliente com a finalidade de requerer o último para solicitar o serviço novamente utilizando-se o valor de etiqueta atualizado. Isto permite que o servidor garanta que o valor de etiqueta tenha sido atualizado no lado do cliente.
Muito embora a modalidade ilustrada pela Figura 3 seja mostrada como uma variante das modalidades mostradas nas Figuras 2a e 2b, deve-se notar que as etapas supra-mencionadas realizadas nesses casos positivos e negativos também podem ser aplicadas ao método de acordo com a primeira modalidade, substituindo-se as etapas realizadas sob os resultados positivos e negativos do teste de condição de acesso da primeira modalidade.
Qualquer que seja a modalidade, deve-se notar que o valor de etiqueta que é associado a cada cliente captura o histórico de utilização do cliente (e é inicializado com um valor aleatório). De preferência, é necessário que seja exclusivo para cada cliente, em particular se nenhum identificador IDc for atribuído ao cliente, e alterará após cada solicitação válida. Logo, pode ser usado como uma fonte de aleatoriedade para derivar outras chaves (por exemplo, uma chave de sessão para comunicações seguras entre o cliente e o servidor), ou permitir uma diversidade de software de tempo de execução.
Os valores aleatórios podem ser proporcionados pelo servidor, por exemplo, durante a primeira comunicação com o cliente, ou pelo software, por exemplo, durante seu primeiro uso e/ou a primeira comunicação com o servidor.
De preferência, as mensagens e/ou valores enviados entre o servidor e a unidade de usuário cliente no método da presente invenção são trocados em um canal de comunicação seguro, independentemente da modalidade usada. Esse canal de comunicação seguro pode ser obtido por criptografia de pelo menos parte de conteúdos/comunicações trocadas. Por exemplo, pelo menos parte do conteúdo de uma mensagem pode ser criptografada. Adicionalmente, as comunicações trocadas podem ser assinadas. Além disso, o valor de etiqueta tc, t’c pode ser usado para derivar pelo menos uma chave de criptografia que serve para criptografar os ditos conteúdos trocados.
De modo vantajoso, a presente invenção permite, primeiramente para produzir cópias de software idênticas a serem distribuídas a consumidores individuais, e em segundo lugar, após a fase de inicialização, para proporcionar uma individualização de cada implementação de software que levará a sua própria vida tendo dados exclusivos a sua disposição que possam ser usados para permitir uma diversidade espacial.
Dependendo da lógica de negócios, pode-se desejar, algumas vezes, permitir uma quantidade limitada de clones de software. Os usuários têm permissão para copiar uma im-plementação de software cliente em outro dispositivo, e ter uma quantidade limitada de clones sendo executados independentemente. Para alcançar isto, o servidor ramificará um tu- plo novo (IDc1, tc1) a partir do tuplo original (IDc, tc) assim que uma etiqueta incorreta tiver sido detectada e as políticas permitirem um clone novo. O identificador apresentado precisa ser um identificador correto IDc. O tuplo novo pode ser associado à identidade original, por exemplo, armazenando-se o identificador de cliente novo clonado IDc1 em um registro específico do identificador de cliente original IDc (dentro do banco de dados do servidor), para manter uma associação entre o tuplo novo clonado e o identificador de cliente original IDc (ou o registro de usuário cliente original). Proporcionando-se um meio de contagem (por exemplo, um meio para incrementar por uma unidade) que serve para conter o número de associações, isto é, o número de registros específicos que são associados a um identifica- dor de cliente original, isto permite monitorar quantos clones este identificador original tem e conhecer o identificador (IDc1, IDc2, ...) desses clones autorizados. O meio de comparação pode ser proporcionado para comparar o número desses registros específicos com um limite predefinido que determina o número máximo de clones autorizados para um determinado identificador de cliente original. Se o resultado desta comparação for igual ou maior que este limite, a solicitação será negada e nenhum clone novo autorizado será permitido a este iden-tificador de cliente original. Em contrapartida, se o limite não for alcançado (ou se não exce-dido), um identificador novo IDc1 e uma etiqueta nova tc1 serão, então, executados na unidade de usuário cliente clonada, utilizando-se um comando dedicado ou qualquer operação adequada para proporcionar estes novos dados a esta unidade de usuário cliente nova. A partir daí, o clone pode ser visto como uma unidade de usuário autêntica nova.
De acordo com uma forma ligeiramente diferente, com a finalidade de monitorar quantos clones uma determinada identidade tem, cada registro de cliente (identificado por seu identificador de cliente IDc), pode incluir um valor de contagem. Este valor é incrementado (ou decrementado) por um sempre que um clone de software for derivado a partir deste cliente. Portanto, o servidor sabe, em qualquer momento, quantos clones de software podem ter sido gerados por um determinado cliente.
A fim de evitar que um identificador de cliente clonado gere outros clones de software em sua vez, cada registro resultante de uma geração de clone de software será dotado de uma etiqueta de clonagem usada para identificar qual identificador de cliente é um autodenominado “identificador clonado” e qual identificador de cliente é um identificador inicial. A mesma função proporcionada por tal etiqueta de clonagem pode ser obtida armazenando-se, no registro novo correspondente ao autodenominado “identificador de cliente clo- nado”, um valor de contagem que alcança imediatamente o limite supramencionado.
Limitar a quantidade de clones de software é uma variante aplicável às modalidades mostradas nas Figuras 2b e 3. Para realizar tal limitação de clones de software, as etapas abaixo referentes à modalidade mostrada na Figura 2b precisam ser levadas em consideração em relação ao resultado negativo do teste de condição de acesso do método. O resultado negativo será substituído (ou também incluirá) pela etapa condicional a seguir junto a outras etapas seguintes: - (ou) verificar se o identificador de cliente IDc incluído à mensagem de cliente já está armazenado em um dos registros do banco de dados: em caso negativo, negar o serviço solicitado, enquanto que em caso positivo: - incrementar por uma unidade um valor de contagem de um contador de cliente associado ao dito identificador de cliente IDc em seu registro, então, verificar se este contador de cliente alcança um limite predeterminado, em caso positivo: negar o serviço solicitado, enquanto que em caso negativo (a geração de um clone novo é autorizada): - armazenar o valor de contagem do contador de cliente incrementado no dito registro, - atribuir um identificador de cliente exclusivo novo IDc ao cliente armazenando-se, em um registro novo do banco de dados, esse identificador de cliente exclusivo novo IDc junto a um novo valor de etiqueta t’c (valor aleatório) e com um valor de contagem, armazenado como contador de cliente, que alcança o dito limite predeterminado, - enviar uma mensagem de servidor à unidade de usuário, como uma resposta à solicitação de cliente, - proporcionar um identificador de cliente exclusivo novo IDc e o novo valor de etiqueta t’c ao cliente (unidade de usuário cliente), - armazenar o novo valor de etiqueta t’c no registro do banco de dados do servidor e na unidade de usuário cliente (isto é, na memória da unidade de usuário cliente).
Com a finalidade e proporcionar o IDc cliente novo e o novo valor de etiqueta à unidade de usuário cliente nova, esta operação (etapa) pode ser alcançada através de qualquer meio de comunicação convencional, tal como, mas sem se limitar a, uma carta, um SMS, uma chamada telefônica, um e-mail, uma página da web, ou qualquer combinação destes. Alternativamente, estas informações podem ser transmitidas ao cliente incluindo-se o identificador de cliente exclusivo novo e o novo valor de etiqueta na mensagem de servidor enviada à unidade de usuário cliente. Estas informações também podem ser anexadas à mensagem de servidor ou enviadas separadamente.
Deve-se notar que o método da presente invenção não evita que clones reproduzam conteúdos já comprados: este evita apenas que clones possam solicitar novos serviços. Esta é uma questão inerente aos reprodutores de mídia de cliente que podem ser usados offline, visto que apenas uma verificação do lado do servidor pode ser realizada quando o componente de software de cliente se conectar ao serviço online.
A implementação de software cliente precisa ser estável.
Em termos de questões de privacidade, o método sugerido nesta invenção revela que os valores de etiqueta são derivados a partir do histórico de utilização e a partir do valor de etiqueta inicial. No entanto, quando as funções hash criptográficas forem usadas para derivar valores de etiqueta novos, estes valores não expõem nenhuma informação de histórico de utilização (devido à propriedade de resistência de pré-imagem das funções hash criptográficas).
Ademais, é possível incluir informações adicionais que sejam enviadas a partir do servidor ao cliente; por exemplo, um deslocamento aleatório que pode ser incluído no processo de atualização, ou em um valor hash criptografado novo.

Claims (13)

1. Método para detectar um software clonado a ser usado em uma unidade de usuário cliente em comunicação com um servidor para solicitar um serviço pelo envio de uma solicitação a partir da unidade de usuário para o servidor, sendo este último conectado a um banco de dados que compreende registros de clientes, cada um desses registros compre-endendo pelo menos um valor de etiqueta (tc), o dito método CARACTERIZADO por compreender uma fase de inicialização e uma fase de operação, - ) a fase de inicialização compreendendo as etapas de: - definir o dito valor de etiqueta (tc) como sendo igual a um valor inicial, - abrir um novo registro armazenando o dito valor de etiqueta (tc) no servidor, - introduzir o dito valor de etiqueta (tc) na unidade de usuário cliente, - ) a fase de operação compreendendo as etapas de: - preparar, no lado de unidade de usuário, uma mensagem de cliente para o ser-vidor que compreende a dita solicitação e o dito valor de etiqueta (tc), então - enviar esta mensagem de cliente, a partir da unidade de usuário para o servidor, - realizar um teste de condição de acesso, no lado de servidor, verificando se o valor de etiqueta (tc) da dita mensagem de cliente está compreendido no banco de dados, em caso negativo: - negar o serviço solicitado, em caso positivo: - enviar uma mensagem de servidor à unidade de usuário, como uma resposta à dita solicitação, - calcular no lado de servidor e no lado de unidade de usuário um novo valor de etiqueta (t’c) usando uma função de hash configurada para usar o último valor de etiqueta (tc) e pelo menos uma parte da mensagem de cliente ou uma parte da mensagem de servidor com dados de entrada da dita função de hash e para proporcionar o dito novo valor de etiqueta (t’c) como dados de saída da dita função de hash, - atualizar o dito valor de etiqueta (tc), tanto no lado de servidor como no lado de unidade de usuário, substituindo-o pelo novo valor de etiqueta (t’c), - armazenar o novo valor de etiqueta (t’c) no registro do banco de dados do servidor e da unidade de usuário.
2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que dita parte da mensagem é um carimbo temporal.
3. Método, de acordo com a reivindicação 1 ou 2, CARACTERIZADO pelo fato de que a mensagem de cliente adicionalmente compreende um identificador exclusivo (IDc) atribuído ao cliente.
4. Método, de acordo com qualquer uma das reivindicações anteriores, CARACTERIZADO pelo fato de que: a) a fase inicial adicionalmente compreende as etapas de: - definir uma função de assinatura e uma função de derivação de chave de assi-natura para criptografar um resultado compilado a partir da dita função de assinatura, - compartilhar a definição da dita função de assinatura e da dita função de deri-vação de chave de assinatura entre a unidade de usuário e o servidor, b) a fase de operação adicionalmente compreende as etapas de: - calcular um código de autenticação através da aplicação da dita função de as-sinatura à solicitação e usar a chave de assinatura para criptografar o resultado compilado a partir da dita função de assinatura, em seguida alterar a etapa de preparar da mensagem de cliente pela preparação de uma mensagem de cliente compreendendo o dito código de au-tenticação e a dita solicitação, - alterar a condição de acesso, testando se o código de autenticação recebido dentro da mensagem de cliente é igual ao código de autenticação calculado pelo servidor pela aplicação da mesma função de assinatura à solicitação compreendida na mensagem de cliente e usar a mesma chave de assinatura para processar o dito compilado; essa chave de assinatura sendo preferencialmente derivada a partir do valor de etiqueta esperado que está armazenado no banco de dados do servidor.
5. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de que: a) a fase de inicialização adicionalmente compreende as etapas de: - especificar um identificador exclusivo (IDc) para o cliente e armazenar esse identificador no dito novo registro, - compartilhar o dito identificador (IDc) entre a unidade de usuário e o servidor, b) a fase de operação adicionalmente compreende a etapa de: - alterar a etapa de preparar da mensagem de cliente pela inclusão do identificador de cliente (IDc) dentro da mensagem de cliente.
6. Método, de acordo com qualquer uma das reivindicações anteriores, CARACTERIZADO pelo fato de que a fase de operação compreende em uma etapa de res- sincronização que substitui o valor de etiqueta (tc) por um novo valor de etiqueta (t’c) igual a um valor aleatório novo, então envia o dito novo valor de etiqueta (t’c) para a unidade de usuário.
7. Método, de acordo com a reivindicação 4 ou 5, CARACTERIZADO pelo fato de que a dita chave de assinatura é idêntica ao valor de etiqueta (tc) do cliente.
8. Método, de acordo com a reivindicação 4 ou 5, CARACTERIZADO pelo fato de que a dita chave de assinatura é derivada do valor de etiqueta (tc) do cliente.
9. Método, de acordo com qualquer uma das reivindicações anteriores CARACTERIZADO pelo fato de que as ditas mensagens e/ou valores enviados entre o servidor e a unidade de usuário são trocados dentro de um canal de comunicação seguro.
10. Método, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que a dita comunicação segura é obtida pela criptografia de pelo menos uma parte de conteúdos trocados.
11. Método, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que o valor de etiqueta (tc, t’c) é usado para derivar pelo menos uma chave de criptografia para criptografar os ditos conteúdos trocados.
12. Método, de acordo com qualquer uma das reivindicações anteriores, CARACTERIZADO pelo fato de que: o resultado positivo originado do teste de condição de acesso realizado na fase de operação é substituído pela realização de uma etapa condicional que visa verificar se o valor de etiqueta (tc) tem que ser atualizado: - em caso positivo: em primeiro lugar, atualizar o valor de etiqueta (tc), tanto no lado de servidor como no lado de unidade de usuário, pelo envio a partir do servidor à unidade de usuário de uma mensagem de atualização incluindo um valor de atualização (X) e pela substituição do dito valor de etiqueta (tc) por um novo valor de etiqueta (t’c) derivado a partir do último valor de etiqueta (tc) e a partir do dito valor de atualização (X), e armazenar o novo valor de etiqueta (t’c) no registro do banco de dados do servidor e na unidade de usuário, - em caso negativo: enviar diretamente a dita mensagem de servidor à unidade de usuário, como uma resposta à dita solicitação, e em que o resultado negativo originado do dito teste de condição de acesso é substituído da seguinte forma: - realizar uma etapa condicional que visa, por meio de um contador de tentativas malsucedidas usado para contar um número de resultados negativos sucessivos relacionados à dita condição de acesso, verificar se este número alcançou um limite predeterminado: - em caso negativo: enviar uma mensagem de servidor à unidade de usuário sem atualizar o valor de etiqueta (tc), - em caso positivo: negar o serviço solicitado.
13. Método, de acordo com qualquer uma das reivindicações 5 a 12, CARACTERIZADO pelo fato de que o resultado negativo originado do dito teste de condição de acesso adicionalmente compreende as seguintes etapas: - verificar se o identificador de cliente (IDc) incluído na mensagem de cliente já está armazenado em um dos registros do banco de dados: em caso negativo, negar o serviço solicitado, enquanto que em caso positivo: - incrementar em uma unidade o valor de contagem de um contador de cliente as-sociado ao dito identificador de cliente (IDc) em seu registro, então, verificar se este contador de cliente alcança um limite predeterminado, em caso positivo: negar o serviço solicita- 5 do, enquanto que em caso negativo: - armazenar o valor de contagem do contador de cliente incrementado no dito regis-tro, - atribuir um identificador de cliente exclusivo novo (IDc) ao cliente, armazenando, em um registro novo do banco de dados, esse identificador de cliente exclusivo novo (IDc) 10 junto com um novo valor de etiqueta (t’c) e com um valor, armazenado como contador de cliente, que alcança o dito limite predeterminado, - enviar uma mensagem de servidor à unidade de usuário, como uma resposta à di-ta solicitação, - proporcionar o dito identificador de cliente exclusivo novo (IDc) e o dito novo valor 15 de etiqueta (t’c) à sua unidade de usuário cliente, - armazenar o novo valor de etiqueta (t’c) no registro do banco de dados do servidor e na unidade de usuário cliente.
BR112013012356-7A 2010-11-19 2011-11-15 método para detectar um software clonado BR112013012356B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US41536310P 2010-11-19 2010-11-19
US61/415,363 2010-11-19
PCT/IB2011/055083 WO2012066471A1 (en) 2010-11-19 2011-11-15 Method to detect cloned software

Publications (2)

Publication Number Publication Date
BR112013012356A2 BR112013012356A2 (pt) 2020-05-12
BR112013012356B1 true BR112013012356B1 (pt) 2021-03-09

Family

ID=45496213

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112013012356-7A BR112013012356B1 (pt) 2010-11-19 2011-11-15 método para detectar um software clonado

Country Status (6)

Country Link
US (2) US9582685B2 (pt)
EP (1) EP2641208B1 (pt)
BR (1) BR112013012356B1 (pt)
ES (1) ES2806261T3 (pt)
WO (1) WO2012066471A1 (pt)
ZA (1) ZA201303272B (pt)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10769586B2 (en) * 2018-11-29 2020-09-08 Red Hat, Inc. Implementation of rolling key to identify systems inventories

Family Cites Families (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4578530A (en) 1981-06-26 1986-03-25 Visa U.S.A., Inc. End-to-end encryption system and method of operation
US4672533A (en) 1984-12-19 1987-06-09 Noble Richard G Electronic linkage interface control security system and method
JP2662430B2 (ja) 1988-11-29 1997-10-15 富士通株式会社 Ｃａｔｖシステムのセンタ装置および端末装置
US5029207A (en) 1990-02-01 1991-07-02 Scientific-Atlanta, Inc. External security module for a television signal decoder
US5237610A (en) 1990-02-01 1993-08-17 Scientific-Atlanta, Inc. Independent external security module for a digitally upgradeable television signal decoder
FI88842C (fi) 1990-03-22 1993-07-12 Nokia Mobile Phones Ltd Kontroll av kortsanslutning
US5036461A (en) 1990-05-16 1991-07-30 Elliott John C Two-way authentication system between user's smart card and issuer-specific plug-in application modules in multi-issued transaction device
JP3136665B2 (ja) 1991-07-25 2001-02-19 日本電気株式会社 Ｃａｔｖ向け端末装置
DE4129067C2 (de) 1991-09-02 1995-04-13 Grundig Emv Elektronisches Gerät zur Durchführung einer Vielzahl von Funktionen
FR2681165B1 (fr) 1991-09-05 1998-09-18 Gemplus Card Int Procede de transmission d'information confidentielle entre deux cartes a puces.
ES2129043T3 (es) 1991-10-03 1999-06-01 Thomson Multimedia Sa Metodo para personalizar un dispositivo con una tarjeta inteligente.
JPH06197104A (ja) 1992-12-25 1994-07-15 Sony Corp デコーダ装置
US5365587A (en) 1993-03-11 1994-11-15 International Business Machines Corporation Self modifying access code for altering capabilities
JP3052244B2 (ja) 1993-11-10 2000-06-12 富士通株式会社 移動通信システムにおける移動機の登録方法とｉｃカードの登録方法、及びそれらを実現するための移動機、ｉｃカード、及びｉｃカード挿入型移動機
DE4342641A1 (de) 1993-12-14 1995-06-22 Siemens Ag Verfahren zur Authentifikation zwischen einem mobilen Datenträger und einer stationären Datenstation
US5434919A (en) 1994-01-11 1995-07-18 Chaum; David Compact endorsement signature systems
EP0675626B1 (en) 1994-03-28 2003-01-22 BRITISH TELECOMMUNICATIONS public limited company Security system
FR2718312B1 (fr) 1994-03-29 1996-06-07 Rola Nevoux Procédé d'authentification combinée d'un terminal de télécommunication et d'un module d'utilisateur.
FR2725537B1 (fr) 1994-10-11 1996-11-22 Bull Cp8 Procede de chargement d'une zone memoire protegee d'un dispositif de traitement de l'information et dispositif associe
US5748737A (en) 1994-11-14 1998-05-05 Daggar; Robert N. Multimedia electronic wallet with generic card
IL113375A (en) 1995-04-13 1997-09-30 Fortress U & T Ltd Internationally regulated system for one to one cryptographic communications with national sovereignty without key escrow
US5633914A (en) 1995-08-22 1997-05-27 Rosa; Stephen P. Method for foiling cellular telephone cloning
US5937068A (en) 1996-03-22 1999-08-10 Activcard System and method for user authentication employing dynamic encryption variables
US5887253A (en) 1996-03-22 1999-03-23 Bellsouth Corporation Method for activating and servicing a cellular telephone
SE506584C2 (sv) 1996-05-13 1998-01-19 Ericsson Telefon Ab L M Förfarande och anordning vid övervakning av mobilkommunikationsenhet
US6072870A (en) 1996-06-17 2000-06-06 Verifone Inc. System, method and article of manufacture for a gateway payment architecture utilizing a multichannel, extensible, flexible architecture
US6253027B1 (en) 1996-06-17 2001-06-26 Hewlett-Packard Company System, method and article of manufacture for exchanging software and configuration data over a multichannel, extensible, flexible architecture
US5991411A (en) 1996-10-08 1999-11-23 International Business Machines Corporation Method and means for limiting adverse use of counterfeit credit cards, access badges, electronic accounts or the like
US5729896A (en) 1996-10-31 1998-03-24 International Business Machines Corporation Method for attaching a flip chip on flexible circuit carrier using chip with metallic cap on solder
US6575372B1 (en) 1997-02-21 2003-06-10 Mondex International Limited Secure multi-application IC card system having selective loading and deleting capability
FR2762118B1 (fr) 1997-04-11 1999-07-16 Gemplus Card Int Procedure securisee de controle de transfert d'unites de valeur dans un systeme de jeu a carte a puce
US5933785A (en) 1997-05-20 1999-08-03 Motorola, Inc. Telephone and method for concurrent registration of two identification numbers using multi-number sim card
FI105637B (fi) 1997-07-02 2000-09-15 Sonera Oyj Menetelmä tilaajaidentiteettimoduulille tallennettujen sovellusten hallintaan
RU2000111530A (ru) 1997-10-02 2002-05-27 Каналь+Сосьетэ Аноним Способ и устройство для шифрованной трансляции потока данных
US6976171B1 (en) 1997-11-07 2005-12-13 Swisscom Mobile Ag Identification card and identification procedure
US6246771B1 (en) 1997-11-26 2001-06-12 V-One Corporation Session key recovery system and method
US6199113B1 (en) 1998-04-15 2001-03-06 Sun Microsystems, Inc. Apparatus and method for providing trusted network security
US6118873A (en) 1998-04-24 2000-09-12 International Business Machines Corporation System for encrypting broadcast programs in the presence of compromised receiver devices
TW412909B (en) 1998-05-07 2000-11-21 Kudelski Sa Mechanism of matching between a receiver and a security module
US6070171A (en) * 1998-05-15 2000-05-30 Palantir Software, Inc. Method and system for copy-tracking distributed software featuring tokens containing a key field and a usage field
US6567915B1 (en) 1998-10-23 2003-05-20 Microsoft Corporation Integrated circuit card with identity authentication table and authorization tables defining access rights based on Boolean expressions of authenticated identities
DE19850308B4 (de) 1998-10-30 2006-07-13 T-Mobile Deutschland Gmbh Verfahren zum Schutz von Chipkarten vor missbräuchlicher Verwendung in Fremdgeräten
US6584326B1 (en) 1998-12-08 2003-06-24 Alliedsignal Inc. Multiple subscriber interface and simplified provisioning process for installation of multiple cellular and/or mobile SatCom services
GB9828093D0 (en) 1998-12-18 1999-02-17 Jarman David M Electronic data storage and display apparatus
US6463537B1 (en) 1999-01-04 2002-10-08 Codex Technologies, Inc. Modified computer motherboard security and identification system
EP1026898A1 (en) 1999-02-04 2000-08-09 CANAL+ Société Anonyme Method and apparatus for encrypted transmission
US6434403B1 (en) 1999-02-19 2002-08-13 Bodycom, Inc. Personal digital assistant with wireless telephone
US6697489B1 (en) 1999-03-30 2004-02-24 Sony Corporation Method and apparatus for securing control words
US6772331B1 (en) 1999-05-21 2004-08-03 International Business Machines Corporation Method and apparatus for exclusively pairing wireless devices
US6799272B1 (en) 1999-05-26 2004-09-28 Lucent Technologies Inc. Remote device authentication system
US6501946B1 (en) 1999-06-03 2002-12-31 At&T Corp. Multiple uniquely distinguishable wireless handsets using a single mobile identification number
FI108908B (fi) 1999-06-15 2002-04-15 Nokia Corp Kopioidun päätelaitetunnuksen paljastaminen
US6739504B2 (en) 1999-06-23 2004-05-25 Tellabs Denmark A/S Method and system for ensuring connection of a module to an electronic apparatus
DE19947986A1 (de) 1999-10-05 2001-04-12 Ibm System und Verfahren zum Herunterladen von Anwendungsteilen auf eine Chipkarte
US6662299B1 (en) 1999-10-28 2003-12-09 Pgp Corporation Method and apparatus for reconstituting an encryption key based on multiple user responses
EP1108630B1 (de) 1999-12-16 2006-07-05 Siemens Aktiengesellschaft Vorrichtung zur Aktivierung und/oder Deaktivierung einer Sicherheitseinrichtung
US7278017B2 (en) 2000-06-07 2007-10-02 Anoto Ab Method and device for secure wireless transmission of information
US7228427B2 (en) * 2000-06-16 2007-06-05 Entriq Inc. Method and system to securely distribute content via a network
US7203311B1 (en) 2000-07-21 2007-04-10 The Directv Group, Inc. Super encrypted storage and retrieval of media programs in a hard-paired receiver and storage device
US20020062452A1 (en) 2000-08-18 2002-05-23 Warwick Ford Countering credentials copying
US6857067B2 (en) 2000-09-01 2005-02-15 Martin S. Edelman System and method for preventing unauthorized access to electronic data
US7577846B2 (en) 2000-10-04 2009-08-18 Nagravision Sa Mechanism of matching between a receiver and a security module
US7171565B1 (en) 2000-10-10 2007-01-30 International Business Machines Corporation Method and system for producing wise cards
US6591098B1 (en) 2000-11-07 2003-07-08 At&T Wireless Services, Inc. System and method for using a temporary electronic serial number for over-the-air activation of a mobile device
US20030135471A1 (en) 2000-12-22 2003-07-17 Jean-Luc Jaquier Match control method
KR20030063446A (ko) 2000-12-22 2003-07-28 나그라비젼 에스에이 복제 방지 방법
US20060059544A1 (en) 2004-09-14 2006-03-16 Guthrie Paul D Distributed secure repository
US7151831B2 (en) 2001-06-06 2006-12-19 Sony Corporation Partial encryption and PID mapping
US7409562B2 (en) 2001-09-21 2008-08-05 The Directv Group, Inc. Method and apparatus for encrypting media programs for later purchase and viewing
EP1436943B1 (en) 2001-09-21 2016-11-02 The DIRECTV Group, Inc. Method and apparatus for controlling paired operation of a conditional access module and an integrated receiver and decoder
US6845097B2 (en) 2001-11-21 2005-01-18 Ixi Mobile (Israel) Ltd. Device, system, method and computer readable medium for pairing of devices in a short distance wireless network
US7177844B2 (en) 2002-01-16 2007-02-13 General Instrument Corporation Apparatus and method for activation of a security module in a set-top retail environment
US7370111B2 (en) 2002-03-27 2008-05-06 Intel Corporation System, protocol and related methods for providing secure manageability
US7305555B2 (en) 2002-03-27 2007-12-04 General Instrument Corporation Smart card mating protocol
GB2410847A (en) 2004-02-05 2005-08-10 Dyson Ltd Control of motor winding energisation according to rotor angle
WO2006012058A1 (en) * 2004-06-28 2006-02-02 Japan Communications, Inc. Systems and methods for mutual authentication of network
US20060107323A1 (en) * 2004-11-16 2006-05-18 Mclean Ivan H System and method for using a dynamic credential to identify a cloned device
WO2006091654A2 (en) 2005-02-23 2006-08-31 Trans World New York Llc Digital content distribution systems and methods
US7706778B2 (en) * 2005-04-05 2010-04-27 Assa Abloy Ab System and method for remotely assigning and revoking access credentials using a near field communication equipped mobile phone
WO2007084973A2 (en) * 2006-01-20 2007-07-26 Verimatrix, Inc. Network security system and method
US8793509B1 (en) * 2008-02-12 2014-07-29 Google Inc. Web authorization with reduced user interaction
US8745401B1 (en) * 2010-11-12 2014-06-03 Google Inc. Authorizing actions performed by an online service provider

Also Published As

Publication number Publication date
WO2012066471A1 (en) 2012-05-24
US9582685B2 (en) 2017-02-28
ZA201303272B (en) 2014-07-30
US20170161472A1 (en) 2017-06-08
US20130312119A1 (en) 2013-11-21
US9946855B2 (en) 2018-04-17
ES2806261T3 (es) 2021-02-17
EP2641208A1 (en) 2013-09-25
BR112013012356A2 (pt) 2020-05-12
EP2641208B1 (en) 2020-04-29

Similar Documents

Publication Publication Date Title
US11533297B2 (en) Secure communication channel with token renewal mechanism
US8156333B2 (en) Username based authentication security
US9219607B2 (en) Provisioning sensitive data into third party
US9537658B2 (en) Password-based authentication
CN108418691B (zh) 基于sgx的动态网络身份认证方法
US8196186B2 (en) Security architecture for peer-to-peer storage system
US8059818B2 (en) Accessing protected data on network storage from multiple devices
WO2016141856A1 (zh) 一种用于网络应用访问的验证方法、装置和系统
US9225702B2 (en) Transparent client authentication
BRPI0617286A2 (pt) métodos para estabelecer uma associação de segurança entre um nó de serviço e um cliente, para estabelecer uma associação de segurança entre primeiro e segundo clientes, e para proteger um nó contra ataques de repetição, nó de serviço, terminal de cliente, e, função de geração de código
BRPI0615053A2 (pt) serviço de autenticação única distribuìdo
WO2009062451A1 (fr) Procédé, système et équipement de distribution de clé
US20160065366A1 (en) Password-Based Generation and Management of Secret Cryptographic Keys
US20210390533A1 (en) User-Centric, Blockchain-Based and End-to-End Secure Home IP Camera System
KR20150135032A (ko) Puf를 이용한 비밀키 업데이트 시스템 및 방법
US20120155647A1 (en) Cryptographic devices & methods
Keleman et al. Secure firmware update in embedded systems
US20090164782A1 (en) Method and apparatus for authentication of service application processes in high availability clusters
BR112013012356B1 (pt) método para detectar um software clonado
Heilman et al. OpenPubkey: Augmenting OpenID connect with user held signing keys
WO2023144500A1 (en) Methods, systems, and devices for server control of client authorization proof of possession
WO2023144499A1 (en) Methods, systems, and devices for server control of client authorization proof of possession
Sriramulu et al. A Secure Network Communication Based on Kerberos & MD5
Shukla A daemon for secure smart card support in the encrypted file system transcrypt

Legal Events

Date Code Title Description
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 15/11/2011, OBSERVADAS AS CONDICOES LEGAIS.