ES2806261T3 - Método para detectar software clonado - Google Patents

Método para detectar software clonado Download PDF

Info

Publication number
ES2806261T3
ES2806261T3 ES11808938T ES11808938T ES2806261T3 ES 2806261 T3 ES2806261 T3 ES 2806261T3 ES 11808938 T ES11808938 T ES 11808938T ES 11808938 T ES11808938 T ES 11808938T ES 2806261 T3 ES2806261 T3 ES 2806261T3
Authority
ES
Spain
Prior art keywords
server
tag value
client
user unit
new
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
ES11808938T
Other languages
English (en)
Inventor
Jean-Bernard Fischer
Patrik Marcacci
Christian Schwarz
Brecht Wyseur
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nagravision SARL
Original Assignee
Nagravision SA
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 SA filed Critical Nagravision SA
Application granted granted Critical
Publication of ES2806261T3 publication Critical patent/ES2806261T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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

Abstract

Método para detectar un software clonado para ser usado en una unidad de usuario cliente que se comunica con un servidor para solicitar un servicio enviando una solicitud desde la unidad de usuario hasta el servidor, donde el último está conectado a una base de datos que comprende registros cliente, donde cada uno de estos registros comprenden al menos un valor de etiqueta (tc), donde dicho método incluye una fase de inicialización y una fase operativa, a) la fase de inicialización comprende los pasos de: - definir dicho valor de etiqueta (tc) como igual a un valor inicial, - abrir un nuevo almacenamiento de registro que almacena dicho valor de etiqueta (tc) en el servidor, - introducir dicho valor de etiqueta (tc) en la unidad de usuario cliente, b) la fase operativa comprende los pasos de: - preparar, en el lado de unidad de usuario, un mensaje cliente para el servidor que comprende dicha solicitud y dicho valor de etiqueta (tc), luego - enviar este mensaje cliente, desde la unidad de usuario hasta el servidor, - realizar una prueba de condición de acceso, en el lado servidor, controlando si el valor de etiqueta (tc) de dicho mensaje cliente está comprendido en la base de datos, en resultado negativo: denegar el servicio solicitado, en resultado positivo: - enviar un mensaje servidor a la unidad de usuario, como una respuesta a dicha solicitud, - calcular en el lado servidor y en el lado unidad de usuario un nuevo valor de etiqueta (t'c) usando una función hash configurada para usar el último valor de etiqueta (tc) y al menos una parte del mensaje cliente o una parte del mensaje servidor como datos de entrada de dicha función hash y para proporcionar dicho nuevo valor de etiqueta (t'c) como datos de salida de dicha función hash, - actualizar dicho valor de etiqueta (tc), tanto en el lado servidor como en el lado unidad de usuario, reemplazándolo por el nuevo valor de etiqueta (t'c), - almacenar el nuevo valor de etiqueta (t'c) en el registro de la base de datos del servidor y en la unidad de usuario.

Description

DESCRIPCIÓN
Método para detectar software clonado
CAMPO TÉCNICO
[0001] Esta invención se refiere al campo del receptor/decodificador integrado que recibe datos de un equipo de radiodifusión central; donde el acceso a estos datos está sujeto a un acceso condicional.
ANTECEDENTES
[0002] Un gran problema en la seguridad de software es evitar la copia ilegítima y el uso de software.
[0003] En una solución de software puro, este problema es imposible de resolver en un caso de uso desconectado. Sin embargo, cuando hay una conexión disponible para una entidad confiable (por ejemplo, un servidor de verificación), esta conexión se puede usar para implementar algunos mecanismos de seguridad (tanto en el caso de un caso de uso conectado continuamente como en un caso de uso conectado ocasionalmente). A pesar de esto, en un caso de uso distribuido (donde una gran población de usuarios puede usar el software), aun es difícil detectar y bloquear copias.
[0004] El bloqueo del software al hardware de su plataforma no siempre es una opción. En primer lugar, esto no puede ser factible debido a la falta de hardware confiable o un mecanismo de arranque. En segundo lugar, un usuario debería siempre poder migrar su software a otra plataforma o cambiar su configuración de hardware o software.
[0005] En la presente configuración, un reproductor puede clonarse fácilmente con todos su secretos y ejecutarse en miles de ordenadores al mismo tiempo. Por lo tanto, un usuario que paga una tarifa plana para acceder al contenido tendría un buen incentivo para revender copias (clones) de su reproductor a otros usuarios.
[0006] La WO 02/17555 A2 enumera sistemas, métodos y medios legibles por ordenador para permitir que un dispositivo servidor valide uno o más dispositivos cliente. Se genera un secreto imprevisible compartido. El secreto imprevisible compartido se almacena en el dispositivo cliente y en el dispositivo servidor. El dispositivo cliente demuestra la posesión de un secreto imprevisible compartido correcto para el dispositivo servidor. El secreto imprevisible compartido se sustituye por un secreto imprevisible compartido nuevo cada vez que el dispositivo cliente es validado por el dispositivo servidor.
[0007] La US 2006/107323 A1 enumera un sistema y un método para proporcionar comunicaciones seguras entre dispositivos de comunicación cliente y servidores. Un servidor genera un desplazamiento aleatorio. El servidor altera una credencial dinámica del dispositivo de comunicación servidor al aplicar el desplazamiento aleatorio a la credencial dinámica del dispositivo de comunicación servidor. El servidor almacena la credencial dinámica del dispositivo de comunicación servidor.
[0008] La WO 02/052389 A2 enumera un método para evitar el uso de más de un módulo de seguridad idéntico para identificar y utilizar recursos gestionados por un centro de gestión. Por lo tanto, la invención proporciona un método de anticlonación basado en el almacenamiento de números de identificación de unidades de usuario conectadas a dicho módulo de seguridad. Cuando se establece una conexión con un centro de gestión, dichos números se transmiten y comparan con los números de una transmisión precedente.
[0009] La US 7676436 menciona permitir a un usuario adquirir un artículo (por ejemplo, una canción digital, un vídeo digital, etc.) usando un dispositivo (por ejemplo, un dispositivo portátil) y mover fácilmente una copia del artículo adquirido desde el primer dispositivo hasta otro dispositivo para que un usuario del otro dispositivo pueda reproducir el artículo.
[0010] La US 2007/174472 A1 menciona un sistema de seguridad para comunicaciones de red con dispositivos cliente. Un servidor compara identificadores escondidos recibidos de los dispositivos cliente para detectar posibles clones.
RESUMEN DE LA INVENCIÓN
[0011] Mientras que la invención se define en la reivindicación independiente, otros aspectos de la invención se exponen en las reivindicaciones dependientes, los dibujos y la siguiente descripción.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0012] La presente invención se entenderá mejor gracias a las figuras adjuntas en las que:
La figura 1 muestra un diagrama de detección de clonación, que se basa en una verificación de etiqueta dinámica, según una primera forma de realización de la presente invención,
La figura 2a ilustra una segunda forma de realización de la invención, en particular, una autenticación de mensaje basada en una credencial dinámica para detectar la clonación.
La figura 2b ilustra otra variante de la forma de realización mostrada en la figura 2a.
La figura 3 ilustra una tercera forma de realización de la invención, donde se ejecuta una condición de actualización de etiqueta antes de la entrega de contenido.
DESCRIPCIÓN DETALLADA
[0013] La idea principal de la solución sugerida en la presente invención se basa en la observación de que cada componente de software cliente (por ejemplo, un reproductor multimedia) tendrá un uso de contenido diferente. Cada uso de contenido genera un historial de uso único que permite rastrear la legitimidad del software y facilitar la detección de copias ilegítimas.
[0014] Más concretamente, un servidor realizará un seguimiento del historial de uso de cada cliente mediante el uso del valor de etiqueta. El valor de etiqueta representa el uso (parcial o completamente) al tiempo que conserva la privacidad del historial. En cada solicitud válida, este valor de etiqueta se actualizará preferiblemente, lo que provocará una desincronización entre las copias realizadas a partir de esta implementación, dado que cuando se realiza una copia, este se bifurcará del historial del cliente original, y su uso se desviará del uso del cliente original. Es precisamente esta desviación la que se puede detectar.
[0015] En referencia a la figura 1, que muestra una primera forma de realización de la invención, cada cliente (C) recibe un valor de etiqueta aleatorio inicial tc , que puede insertarse en el reproductor de software en el momento de la inicialización o que puede ser transmitido por el servidor durante la primera autenticación con este último. El servidor tendrá los valores de etiqueta de todos los clientes en una base de datos. Este valor de etiqueta inicial tc también puede ser enviado al cliente de la unidad de usuario medaiante cualquier medio de comunicación convencional como, entre otros, una carta, un SMS, una llamada telefónica, un correo electrónico, una página web, o cualquier combinación de los mismos. A su lado, el servidor ha abierto un nuevo registro en su base de datos para almacenar este valor de etiqueta tc. De este modo, tanto la unidad de usuario como el servidor poseen el mismo valor de etiqueta tc al final de esta primera fase, denominada fase de inicialización.
[0016] Para implementar esta fase de inicialización, se llevan a cabo los siguientes pasos:
- definir el valor de etiqueta (tc) como igual a un valor aleatorio inicial,
- abrir un nuevo registro que almacena dicho valor de etiqueta (tc) en la base de datos del servidor,
- introducir este valor de etiqueta (tc) en la unidad de usuario cliente.
[0017] El paso destinado a definir el valor de etiqueta como un valor aleatorio inicial tiene como objetivo tomar un valor imprevisible como primer valor de etiqueta.
[0018] Durante una fase operativa y mientras se sigue haciendo referencia a la figura 1, cuando un cliente solicita un servicio del servidor, a través de una red de comunicación común que conecta la unidad de usuario cliente a este servidor, su valor de etiqueta tc se enviará, dentro de un mensaje denominado mensaje cliente. El servidor verificará si el valor de etiqueta, incluido en el mensaje cliente, también está presente en su base de datos. Si dicha comparación da un resultado correcto, el servidor otorgará el servicio solicitado (o procederá a verificar otros requisitos). Si el valor de etiqueta enviado dentro del mensaje cliente no figura en la base de datos o no se puede verificar correctamente, el servicio solicitado se rechazará.
[0019] El valor de etiqueta tc puede ser el resumen de una función de compresión, como una función hash criptográfica, aplicada a la solicitud cliente. Aunque las buenas funciones de derivación proporcionan resúmenos que son difíciles de adivinar, un atacante, tal como un intermediario, conocido por el experto en la técnica, aun podrían intentar tener acceso a un servicio cogiendo o adivinando valores de etiqueta.
[0020] Para evitar cualquier ataque, una primera solución es realizar comunicaciones entre el cliente y el servidor a través de un canal protegido (es decir, mediante una comunicación encriptada y autenticada entre el cliente y el servidor). En este caso, el valor de etiqueta se puede adjuntar directamente a la solicitud y, por lo tanto, el servidor puede realizar una verificación directa comprobando si la etiqueta está comprendida en la base de datos del servidor (como se muestra en la figura 1).
[0021] Además, si una función hash criptográfica se utiliza para derivar una nueva etiqueta de la etiqueta antigua y el historial de uso, entonces este valor de etiqueta es único por usuario y, por lo tanto, puede usarse como un identificador para identificar a cada cliente. Esto facilita una verificación anticlonación sin la necesidad de asociar solicitudes a individuos y, por lo tanto, conduce a verificaciones transparentes, más rápidas y anónimas (sin embargo, esto no excluye adjuntar un identificador cliente único a la solicitud en el mensaje cliente). Representado en la figura 1, este caso de uso es un protocolo de certificación remota que solo debería usarse en casos en los que una persona maliciosa no pueda falsificar ni alterar activamente la conexión entre el cliente y el servidor (por ejemplo, en un dominio doméstico seguro o cuando la comunicación entre el cliente y el servidor se realiza a través de un canal seguro autenticado).
[0022] Con respecto a cada solicitud válida, tanto el cliente como el servidor actualizarán el valor de etiqueta. El nuevo valor de etiqueta t'c se derivará de los datos que son conocidos por el cliente y el servidor: por ejemplo, el antiguo valor de etiqueta y la información obtenida de al menos una parte del contenido del mensaje servidor que se proporciona como respuesta a la solicitud cliente. Alternativamente, el nuevo valor de etiqueta t'c se puede derivar del último valor de etiqueta tc y de al menos una parte del contenido del mensaje cliente. El mensaje servidor o el mensaje cliente (o una parte de su contenido) puede ser una marca de tiempo que se inserta en el flujo de medios o cualquier otra información de encabezado, claves criptográficas sobreencriptadas que se envían, marcos específicos, etc. El nuevo valor de etiqueta t'c está destinado a reemplazar el antiguo valor de etiqueta tc.
[0023] Con este fin, esta fase operativa requiere los pasos de:
- preparar, en el lado de unidad de usuario, un mensaje cliente que comprende una solicitud junto con el valor de etiqueta tc , luego
- enviar este mensaje cliente, desde la unidad de usuario hasta el servidor,
- realizar una prueba de condición de acceso, en el lado servidor, con el objetivo de probar si este valor de etiqueta tc está comprendido en la base de datos del servidor. En resultado negativo (es decir, caso negativo): denegar el servicio solicitado, mientras que en resultado positivo (es decir, caso positivo):
- enviar un mensaje servidor a la unidad de usuario, como una respuesta a la solicitud cliente,
- actualizar el valor de etiqueta tc, tanto en el lado servidor como en el lado unidad de usuario, al reemplazar este valor tc por un nuevo valor de etiqueta t'c. Este nuevo valor de etiqueta t'c se deriva del último valor de etiqueta tc y de otros datos conocidos por el cliente y el servidor,
- almacenar el nuevo valor de etiqueta t'c en la unidad de usuario (es decir, en una memoria) y en el registro de la base de datos conectado al servidor (por ejemplo, al reemplazar el antiguo valor de etiqueta tc).
[0024] Si se hace una copia de la implementación de software cliente, se producirá una desincronización cuando uno de ellos (el original o la copia) solicite un servicio. Por lo tanto, un usuario auténtico no tiene ningún incentivo para compartir su implementación de software cliente, ya que el uso de la copia denegaría finalmente que su original pueda tener acceso.
[0025] Ventajosamente, un usuario aun puede migrar su implementación de software a otra plataforma sin ningún problema.
[0026] En referencia a la figura 2a, la última divulga otra forma de realización de la invención que se puede usar para prevenir cualquier ataque mientras que se usa un canal inseguro. La solución sugerida en esta forma de realización pretende firmar la solicitud cliente mediante el uso de una clave, que deriva directa o indirectamente del valor de etiqueta tc , obtenido por una función de derivación de clave de firma. Por lo tanto, durante la fase operativa, cuando un cliente solicita un servicio del servidor (por ejemplo, a través de un canal de comunicación inseguro), se enviará una firma de la solicitud junto con la solicitud dentro del mensaje cliente. Como se muestra en la figura 2a, esta firma se puede adjuntar a la solicitud como un código de autenticación del mensaje cliente. Esta firma se obtiene, en primer lugar, al aplicar una función de compresión a la solicitud cliente para obtener un resumen de la solicitud, luego al encriptar este resumen con una clave de firma que se deriva del valor de etiqueta y se obtiene al usar la función de derivación de clave de firma. Por ejemplo, la función de compresión puede ser una función hash o una función HMAC que toma como clave el valor de etiqueta tc o un valor derivado del mismo. De esta manera, el valor de la firma depende del valor de etiqueta. El servidor puede verificar la autenticación de la solicitud cliente comparando la firma comprendida en el mensaje cliente con una firma calculada por el servidor de una manera similar a la determinada por la unidad de usuario cliente. Para este fin, el servidor usa la misma clave de firma (obtenida de la misma función de derivación de firma y del valor de etiqueta almacenado en su base de datos) para desencriptar la firma adjuntada a la solicitud y luego obtener el resumen de esta solicitud. Luego, el servidor calcula un resumen de la solicitud usando la misma función de compresión que la usada para la unidad de usuario. Si este resumen es idéntico al resumen descifrado, la comparación da un resultado correcto y la firma se define como válida. Si la firma es válida, el servidor otorgará el servicio solicitado (o procederá a verificar otros requisitos) y el valor de etiqueta se puede actualizar como se ha mencionado anteriormente en referencia a la figura 1. Si la firma enviada dentro del mensaje cliente no se puede verificar correctamente, el servicio solicitado se rechazará (el servidor también puede realizar otros pasos como consecuencia de un servicio denegado).
[0027] Para implementar la forma de realización mostrada en la figura 2a, la fase de inicialización descrita con la forma de realización mostrada en la figura 1 tiene que modificarse mediante la realización de los siguientes pasos adicionales:
- definir una función de firma (por ejemplo, una función HMAC) y una función de derivación de clave de firma para obtener una clave de firma (derivada preferiblemente de dicho valor de etiqueta tc) para encriptar un resumen resultante de esta función de firma,
- compartir la definición de esta función de firma y la definición de la función de derivación de clave de firma entre la unidad de usuario y el servidor.
[0028] Como se ha descrito anteriormente con referencia a la figura 1, compartir estos datos durante esta fase de inicialización se puede lograr de muchas maneras diferentes, siempre y cuando el valor y/o la función se puedan introducir, al final de este paso, en la unidad de usuario cliente. Al final de esta fase de inicialización, la unidad de usuario y el servidor poseen los mismos datos iniciales.
[0029] La fase operativa de la forma de realización ilustrada por la figura 2a también requiere los siguientes pasos, además o en lugar de aquellos relacionados con la primera forma de realización (misma fase):
- calcular un código de autenticación aplicando la función de firma a la solicitud cliente y usando la clave de firma para encriptar el resumen resultante de dicha función de firma, luego cambiar el paso de preparación del mensaje cliente preparando un mensaje cliente que comprenda el código de autenticación y la solicitud cliente,
- cambiar la condición de acceso controlando si el código de autenticación recibido dentro del mensaje cliente es igual a un código de autenticación calculado por el servidor aplicando la misma función de firma a la solicitud cliente y usando la misma clave de firma para desencriptar dicho resumen dicho; donde la clave de firma se deriva preferiblemente del valor de etiqueta esperado que se almacena en la base de datos del servidor.
[0030] Con referencia ahora a la figura 2b, esta última muestra una variante de la forma de realización mostrada en la figura 2a. Durante la fase de inicialización, cada implementación de software cliente ha instalado un único identificador IDc y un valor de etiqueta aleatorio inicial tc . El servidor almacena las tuplas (IDc, tc) de todos su clientes legítimos. Por lo tanto, con respecto a la fase de inicialización de la forma de realización mostrada en la figura 2a, se llevan a cabo los siguientes pasos adicionales:
- asignar un identificador único IDc al cliente y almacenar este identificador cliente IDc en el nuevo registro asignado a este cliente,
- compartir este identificador IDc entre la unidad de usuario y el servidor (preferiblemente junto con la definición de la función de firma).
[0031] Como se ha mencionado previamente, compartir u obtener estos datos durante esta fase de inicialización se puede lograr de varias maneras, siempre que los datos se puedan introducir, al final de este paso, en la unidad de usuario cliente. El objetivo de este paso es el mismo que para las formas de realización precedentes, es decir, que la unidad de usuario y el servidor poseen los mismos datos iniciales.
[0032] Cuando un cliente solicita un servicio, este envía su identificador y una firma de la solicitud, que autentica su solicitud. Preferiblemente, la firma usa el valor de etiqueta almacenada como una clave (o la clave se deriva de este valor de etiqueta).
[0033] El servidor puede verificar la firma, ya que conoce la función de firma y puede derivar la clave de firma que se usa desde la tupla correspondiente hasta el identificador cliente. Solo cuando la firma es correcta se otorgará un servicio.
[0034] Con respecto a cada solicitud válida, el cliente y el servidor actualizarán el valor de etiqueta tc de la misma manera que se ha descrito para las formas de realización precedentes. Por lo tanto, un nuevo valor de etiqueta t'c se calculará a partir del antiguo valor de etiqueta tc, por un lado, y a partir de la información obtenida del contenido que se proporcona, por otro lado. En la base de datos del servidor, la nueva etiqueta reemplazará a la antigua.
[0035] De lo mencionado anteriormente debe observarse que la fase operativa de la forma de realización ilustrada por la figura 2b también requiere los siguientes pasos, además o en vez de aquellos relacionados con la primera forma de realización mostrada en la figura 2a (misma fase):
- cambiar el paso de preparación del mensaje cliente al incluir el identificador cliente IDc en el mensaje cliente.
[0036] Opcionalmente, el servidor puede enviar una actualización de software a un cliente, cambiar la función de firma usada y/o los parámetros usados, o puede decidir reemplazar el valor de etiqueta tc por un nuevo valor de etiqueta t'c . Esta técnica se puede aplicar a cualquier forma de realización y podría usarse para inhabilitar a los piratas informáticos que han podido obtener un valor de etiqueta y/o invalidar la ingeniería a la función de firma usada o a la función para calcular un nuevo valor de etiqueta (por ejemplo, la funcion hash criptográfica). Como en este caso, podrían intentar combatir la desincronización que ocurre cuando se usan clones, mediante la implementación de un servicio de "resincronización" central o un proxy entre los clones y el servidor.
[0037] Se recomenda el uso de una función hash para realizar la invención conforme a la primera forma de realización mostrada en la figura 1. Esto se deduce del hecho de que los valores de etiqueta (es decir, los valores hash) almacenados en la base de datos del servidor deben ser difíciles de adivinar y deben ser diferentes cuando se actualizan. No debería producirse ninguna colisión entre dos implementaciones de clientes auténticos. Es decir, si todos los clientes auténticos comienzan con un valor de etiqueta inicial diferente, una colisión en los valores hash implicaría que la función hash criptográfica se muestre insegura (con respecto a la propiedad de resistencia a la colisión que se requiere para las funciones hash criptográficas).
[0038] Sin embargo, según la forma de realización mostrada en la figura 2b, esta recomendación se puede relajar, ya que cada valor de etiqueta está vinculado a un identificador único, es decir, al identificador cliente IDc. La única recomendación es que la clave de firma, que es idéntica al valor de etiqueta tc o preferiblemente derivada de este valor de etiqueta, sigue siendo imprevisible para usuarios maliciosos que no tienen ningún conocimiento del valor de etiqueta tc. Por lo tanto, debería quedar suficiente entropía de la entrada. La función de derivación de etiqueta calcula el nuevo valor de etiqueta t'c basándose en el (antiguo) valor de etiqueta tc y al menos una parte del contenido del mensaje. De esta manera, se lleva a cabo una cadena que contiene información obtenida a lo largo de todo el historial anterior.
[0039] La presente invención también sugiere un mecanismo de recuperación en caso de desincronización accidental, por ejemplo, cuando un cliente necesita recurrir a una copia precedente después de que su sistema se haya bloqueado, o cuando su software se haya clonado involuntariamente. Un procedimiento de recuperación se puede implementar a través de un proceso de autenticación convencional, por ejemplo, presentando las credenciales correctas. Al final de este procedimiento, el valor de etiqueta correspondiente al identificador cliente único se puede sustituir en el lado cliente (en la unidad de usuario) y en el lado servidor (en la memoria del servidor). Este hará que cada clon que use el mismo identificador sea inútil.
[0040] Para realizar dicho mecanismo de recuperación, la fase operativa de cualquier forma de realización comprenderá un paso de resincronización que cambia el paso de actualización por los siguientes pasos:
- sustituir el valor de etiqueta tc por un nuevo valor de etiqueta t'c igual a un nuevo valor aleatorio,
- enviar luego dicho nuevo valor de etiqueta t'c a la unidad de usuario.
[0041] Con referencia a la figura 3, este último sugiere una tercera forma de realización principal para la presente invención. Según esta variante, la unidad de usuario cliente adjuntará a cada solicitud una firma, como también se hace en la segunda forma de realización de esta invención (véase la figura 2a y la figura 2b). Una vez que el servidor haya verificado que la firma es válida, el servidor puede decidir aplicar una actualización de la etiqueta (lo que obliga al cliente a solicitar el servicio de nuevo, y permite que el servidor compruebe que el valor de etiqueta de la unidad de usuario cliente se ha actualizado), o no hacerlo y enviar directamente el contenido en respuesta a la solicitud. A diferencia de las formas de realización precedentes de esta invención, el nuevo valor de etiqueta t'c ya no se actualiza en función del contenido que se envía. La decisión de ejecutar o no una actualización de etiqueta depende de la lógica empresarial. La comprobación de si el valor de etiqueta tc tiene que ser actualizado se puede llevar a cabo mediante una prueba basada en un parámetro temporal o en una característica que puede depender, por ejemplo, de la importancia de la solicitud cliente. Se puede ejecutar una actualización de etiqueta para cada solicitud de contenido, o solo para contenido valioso, o una vez al día, o dependiendo de cualquier otro parámetro imaginable. La decisión de ejecutar o no una actualización del valor de etiqueta también se podría aplicar a las otras formas de realización mostradas en las figuras 1,2a y 2b al añadir, a la fase operativa, un paso con el objetivo de tomar tal decisión. En este caso, la unidad de usuario cliente debe ser informada, cada vez que se envía un mensaje servidor como respuesta a una solicitud cliente, si el valor de etiqueta se ha actualizado o no por el servidor. Por ejemplo, se podría añadir o adjuntar un valor específico al mensaje servidor para proporcionar dicha información a la unidad de usuario cliente.
[0042] Volviendo a la forma de realización mostrada en la figura 3, para ejecutar una actualización de etiqueta, el servidor enviará a la unidad de usuario cliente un mensaje específico (es decir, un mensaje de actualización) que incluye un valor de actualización (indicado con la letra X en esta figura) que se usará al derivar el nuevo valor de etiqueta t'c . Por ejemplo, este valor de actualización (X) puede ser un valor aleatorio, una información de encabezado o información de metadatos. Después de este paso, el servidor esperará que la unidad de usuario cliente inicie el procedimiento de solicitud de nuevo desde el principio, es decir, justo después de la fase de inicialización y después de haber introducido el nuevo valor de etiqueta t'c que, por un lado, se deriva del anterior valor de etiqueta tc y, por otro lado, del valor de actualización (X) comprendido en el mensaje de actualización. De esta manera, el servidor puede verificar fácilmente si la etiqueta se ha actualizado o no. Mientras que no se haya recibido ninguna firma que corresponda al nuevo valor de etiqueta, el servidor usará la antigua etiqueta y seguirá repitiendo el paso de ejecución de la actualización de la etiqueta. Alternativamente, el servicio solicitado se puede denegar, por ejemplo después de un cierto número de intentos fallidos. Por lo tanto, se puede realizar una prueba con el objetivo de contar (por medio de un contador específico) el número de intentos fallidos, hasta un umbral predefinido, para decidir enviar un mensaje servidor a la unidad de usuario sin actualizar el valor de etiqueta tc o denegar el servicio solicitado. Una vez que se ha recibido una firma que corresponde a la nueva etiqueta, el servicio solicitado se puede entregar al cliente.
[0043] Esta tercera forma de realización principal, como se muestra en la figura 3, requiere además:
a) reemplazar los pasos en el resultado positivo de la prueba de condición de acceso realizada dentro de la fase operativa por un paso condicional con el objetivo de verificar si el valor de etiqueta (tc) debe actualizarse:
- en caso positivo: en primer lugar, actualizar el valor de etiqueta tc, tanto en el lado servidor como en el lado de unidad de usuario, enviando el servidor a la unidad de usuario un mensaje de actualización con un valor de actualización X y reemplazando el valor de etiqueta tc por un nuevo valor de etiqueta t'c derivado del último valor de etiqueta tc y del valor de actualización X, almacenar luego el nuevo valor de etiqueta t'c en el registro de la base de datos del servidor y en la memoria de la unidad de usuario,
- en caso negativo: enviar directamente el mensaje servidor a la unidad de usuario, como una respuesta a la solicitud cliente (en este ultimo caso, el valor de etiqueta tc no se actualiza),
b) reemplazar los pasos en el resultado negativo de dicha prueba de condición de acceso por una prueba que tiene como objetivo, por medio de un contador de intentos fallidos usado para contar una serie de resultados negativos sucesivos relacionados con dicha condición de acceso, verificar si este número ha alcanzado un umbral predeterminado:
- en caso negativo: enviar un mensaje servidor a la unidad de usuario sin actualizar el valor de etiqueta (tc),
- en caso positivo: denegar el servicio solicitado.
[0044] Con respecto al caso positivo del paso condicional que pretende verificar si el valor de etiqueta debe actualizarse (como se mencionó anteriormente en la parte denominada a) dentro de la fase operativa), debe observarse que la unidad de usuario cliente se ve obligada a reenviar la solicitud cliente usando el valor de etiqueta actualizado. Según otra variante apropiada, se puede enviar un mensaje a la unidad de usuario cliente para requerir que esta última solicite el servicio de nuevo usando el valor de etiqueta actualizado. Esto permite que el servidor se asegure de que el valor de etiqueta se haya actualizado en el lado cliente.
[0045] Aunque la forma de realización ilustrada por la figura 3 se muestra como una variante de las formas de realización mostradas en las figuras 2a y 2b, debe tenerse en cuenta que los pasos mencionados anteriormente realizados en estos casos positivos y negativos también se pueden aplicar al método según la primera forma de realización, reemplazando los pasos realizados en los resultados positivos y negativos de la prueba de condición de acceso de la primera forma de realización.
[0046] Independientemente de la forma de realización, debe observarse que el valor de etiqueta asociado a cada cliente captura el historial de uso del cliente (y se inicializa con un valor aleatorio). Preferiblemente, este debería ser único para cada cliente, en particular si no se asigna ningún identificador IDc al cliente y cambiará después de cada solicitud válida. Por lo tanto, este se puede usar como una fuente de aleatoriedad para derivar otras claves (por ejemplo, una clave de sesión para comunicaciones seguras entre el cliente y el servidor) o para habilitar la diversidad de software en el tiempo de ejecución.
[0047] Los valores aleatorios pueden ser proporcionados por el servidor, por ejemplo durante la primera comunicación con el cliente, o por el software, por ejemplo durante su primer uso y/o la primera comunicación con el servidor.
[0048] Preferiblemente, los mensajes y/o valores enviados entre el servidor y la unidad de usuario cliente en el método de la presente invención se intercambian dentro de un canal de comunicación seguro, independientemente de la forma de realización usada. Dicho canal de comunicación seguro se puede obtener mediante la encriptación de al menos una parte de contenidos/comunicaciones intercambiados. Por ejemplo, al menos una parte del contenido de un mensaje se puede encriptar. Además, las comunicaciones intercambiadas se pueden firmar. Asimismo, el valor de etiqueta tc, t'c se puede usar para derivar al menos una encriptación de clave para encriptar dichos contenidos intercambiados.
[0049] Ventajosamente, la presente invención permite, en primer lugar, producir copias de software idénticas destinadas a ser distribuidas a clientes individuales y, en segundo lugar, después de la fase de inicialización, proporcionar una individualización de cada implementación de software que llevará su propia vida al tener datos únicos a su disposición, que se puede usar para permitir la diversidad espacial.
[0050] Dependiendo de la lógica comercial, a veces puede desearse permitir una cantidad limitada de clones de software. Se puede permitir a los usuarios copiar una implementación de software cliente en otro dispositivo y tener una cantidad limitada de clones que se ejecutan de forma independiente. Para lograr esto, el servidor bifurcará una nueva tupla (IDc1, tc1) desde la tupla original (IDc, tc) tan pronto como se haya detectado una etiqueta incorrecta y las políticas permitan un nuevo clon. El identificador presentado debe ser un identificador IDc correcto. La nueva tupla se puede asociar con la identidad original, por ejemplo, almacenando el nuevo identificador cliente IDc1 clonado en un registro específico del identificador cliente IDc original (dentro de la base de datos del servidor), para mantener la asociación entre la nueva tupla clonada y el identificador cliente IDc original (o el registro de usuario cliente original). Al proporcionar medios de conteo (por ejemplo, medios para incrementar en una unidad) para contar el número de asociaciones, es decir, el número de aquellos registros específicos que están asociados a un identificador cliente original, esto permite controlar cuántos clones tiene este identificador original y conocer el identificador (IDc1, IDc2, ...) de estos clones autorizados. Se pueden proporcionar medios de comparación para comparar el número de estos registros específicos con un umbral predefinido que determina el número máximo de clones autorizados para un cierto identificador cliente original. Si el resultado de esta comparación es igual o superior a este umbral, se denegará la solicitud y no se permitirá ningún nuevo clon autorizado para este identificador cliente original. Al contrario, si no se alcanza el umbral (o no se excede), se aplicará un nuevo identificador IDc1 y una nueva etiqueta tc1 en la unidad de usuario cliente clonado usando un comando dedicado o cualquier operación adecuada para proporcionar estos nuevos datos a esta nueva unidad de usuario cliente . A partir de entonces, el clon puede verse como una nueva unidad de usuario auténtica.
[0051] Según una forma ligeramente diferente, para controlar cuántos clones tiene una determinada identidad, cada registro cliente (identificado por su identificador cliente IDc) puede incluir un valor de conteo. Este valor es incrementado (o disminuido) en uno cada vez que se deriva un clon de software de este cliente. De esta manera, el servido sabe, en cualquier momento, cuántos clones de software han sido generados por un determinado cliente.
[0052] Para evitar que un identificador cliente clonado genere más clones de software a su vez, cada registro resultante de una generación de clones de software recibirá una etiqueta de clonación usada para identificar qué identificador cliente es un denominado "identificador clonado" y qué identificador cliente es un identificador inicial. La misma función que la proporcionada por tal etiqueta de clonación se puede obtener al almacenar, en el nuevo registro correspondiente al denominado "identificador cliente clonado", un valor de conteo que alcanza inmediatamente el umbral anteriormente mencionado.
[0053] La cantidad de limitación de clones de software es una variante que es aplicable a las formas de realización mostradas en la figura 2b y la figura 3. Para llevar a cabo dicha limitación de clones de software, los siguientes pasos, que se refieren a la forma de realización mostrada en la figura 2b, deben tenerse en cuenta con respecto al resultado negativo de la prueba de condición de acceso del método. Este resultado negativo será sustituido por (o también incluirá) el siguiente paso condicional con los otros pasos siguientes:
- (o) verificar si el identificador cliente IDc incluido en el mensaje cliente ya está almacenado en uno de los registros de la base de datos: en caso negativo, denegar el servicio solicitado, mientras que en caso positivo:
- incrementar en una unidad un valor de conteo de un contador cliente asociado a dicho identificador cliente IDc en su registro, luego verificar si este contador cliente alcanza un umbral predeterminado, en caso positivo: denegar el servicio solicitado, mientras que en caso negativo (la generación de un nuevo clon está autorizada):
- almacenar el valor de conteo del contador cliente incrementado en dicho registro,
- asignar un nuevo identificador cliente único IDc al cliente al almacenar, en un nuevo registro de la base de datos, este nuevo identificador cliente único IDc junto con un nuevo valor de etiqueta t'c (valor aleatorio) y con un valor de conteo, almacenado como contador cliente, que alcanza dicho umbral predeterminado,
- enviar un mensaje servidor a la unidad de usuario, como una respuesta a la solicitud cliente,
- proporcionar el nuevo identificador cliente único IDc y el nuevo valor de etiqueta t'c al cliente (unidad de usuario cliente),
- almacenar el nuevo valor de etiqueta t'c en el registro de la base de datos del servidor y en la unidad de usuario cliente (es decir, en la memoria de la unidad de usuario cliente).
[0054] Para proporcionar el nuevo cliente IDc y el nuevo valor de etiqueta a la nueva unidad de usuario cliente, esta operación (este paso) se puede conseguir mediante cualquier medio de comunicación convencional, como, entre otros, una carta, un SMS, una llamada telefónica, un correo electrónico, una página web o cualquier combinación de los mismos. Alternativamente, esta información se puede transmitir al cliente, incluido el nuevo identificador cliente único y el nuevo valor de etiqueta en el mensaje servidor enviado a la unidad de usuario cliente. Esta información también puede se puede adjuntar al mensaje servidor o se puede enviar por separado.
[0055] Cabe señalar que el método de la presente invención no evita que los clones reproduzcan contenido ya comprado: solo evita que los clones puedan solicitar nuevos servicios. Esto es un problema inherente con reproductores multimedia cliente que se pueden usar desconectados, ya que solo se puede realizar una verificación del lado servidor cuando el componente de software cliente se conecta al servicio en línea.
[0056] La implementación de software cliente debe ser con estado.
[0057] En cuanto a los problemas de privacidad, el método sugerido en esta invención divulga que los valores de etiqueta se derivan del historial de uso y del valor de etiqueta inicial. Sin embargo, cuando se usan funciones hash criptográficas para derivar nuevos valores de etiqueta, estos valores no exponen ninguna información de historial de uso (debido a la propiedad de resistencia preimagen de las funciones hash criptográficas).
[0058] Además, también es posible incluir información adicional que se envía desde el servidor hasta el cliente; por ejemplo, un desplazamiento aleatorio que se puede incluir en el proceso de actualización o un nuevo valor hash encriptado.

Claims (13)

REIVINDICACIONES
1. Método para detectar un software clonado para ser usado en una unidad de usuario cliente que se comunica con un servidor para solicitar un servicio enviando una solicitud desde la unidad de usuario hasta el servidor, donde el último está conectado a una base de datos que comprende registros cliente, donde cada uno de estos registros comprenden al menos un valor de etiqueta (tc), donde dicho método incluye una fase de inicialización y una fase operativa,
a) la fase de inicialización comprende los pasos de:
- definir dicho valor de etiqueta (tc) como igual a un valor inicial,
- abrir un nuevo almacenamiento de registro que almacena dicho valor de etiqueta (tc) en el servidor, - introducir dicho valor de etiqueta (tc) en la unidad de usuario cliente,
b) la fase operativa comprende los pasos de:
- preparar, en el lado de unidad de usuario, un mensaje cliente para el servidor que comprende dicha solicitud y dicho valor de etiqueta (tc), luego
- enviar este mensaje cliente, desde la unidad de usuario hasta el servidor,
- realizar una prueba de condición de acceso, en el lado servidor, controlando si el valor de etiqueta (tc) de dicho mensaje cliente está comprendido en la base de datos, en resultado negativo: denegar el servicio solicitado,
en resultado positivo:
- enviar un mensaje servidor a la unidad de usuario, como una respuesta a dicha solicitud,
- calcular en el lado servidor y en el lado unidad de usuario un nuevo valor de etiqueta (t'c) usando una función hash configurada para usar el último valor de etiqueta (tc) y al menos una parte del mensaje cliente o una parte del mensaje servidor como datos de entrada de dicha función hash y para proporcionar dicho nuevo valor de etiqueta (t'c) como datos de salida de dicha función hash,
- actualizar dicho valor de etiqueta (tc), tanto en el lado servidor como en el lado unidad de usuario, reemplazándolo por el nuevo valor de etiqueta (t'c),
- almacenar el nuevo valor de etiqueta (t'c) en el registro de la base de datos del servidor y en la unidad de usuario.
2. Método según la reivindicación 1, donde dicha parte de mensaje es una marca de tiempo.
3. Método según cualquiera de las reivindicaciones precedentes, donde el mensaje cliente comprende además un identificador único (IDc) asignado al cliente.
4. Método según cualquiera de las reivindicaciones precedentes, donde
a) la fase de inicialización comprende además los pasos de:
- definir una función de firma y una función de derivación de clave de firma para encriptar un resumen resultante de dicha función de firma,
- compartir la definición de dicha función de firma y dicha función de derivación de clave de firma entre la unidad de usuario y el servidor,
b) la fase operativa comprende además los pasos de:
- calcular un código de autenticación aplicando dicha función de firma a la solicitud y usando la clave de firma para encriptar el resumen resultante de dicha función de firma, luego cambiar el paso de preparación del mensaje cliente al preparar un mensaje cliente que comprende dicho código de autenticación y dicha solicitud,
- cambiar la condición de acceso verificando si el código de autenticación recibido en el mensaje cliente es igual a un código de autenticación calculado por el servidor aplicando la misma función de firma a la solicitud comprendida en el mensaje cliente y usando la misma clave de firma para procesar dicho resumen; donde esta clave de firma se deriva preferiblemente del valor de etiqueta esperado que se almacena en la base de datos del servidor.
5. Método según la reivindicación 4, donde
a) la fase de inicialización comprende además los pasos de:
- asignar un identificador único (IDc) al cliente y almacenar este identificador (IDc) en dicho nuevo registro, - compartir dicho identificador (IDc) entre la unidad de usuario y el servidor,
b) la fase operativa comprende además el paso de:
- cambiar el paso de preparación del mensaje cliente al incluir el identificador cliente (IDc) en el mensaje cliente.
6. Método según cualquiera de las reivindicaciones precedentes, donde la fase operativa comprende un paso de resincronización que reemplaza el valor de etiqueta (tc) por un nuevo valor de etiqueta (t'c) igual a un nuevo valor aleatorio, luego enviar dicho nuevo valor de etiqueta (t'c) a la unidad de usuario.
7. Método según la reivindicación 4 o 5, donde dicha clave de firma es idéntica al valor de etiqueta (tc) del cliente.
8. Método según la reivindicación 4 o 5, donde dicha clave de firma se deriva del valor de etiqueta (tc) del cliente.
9. Método según cualquiera de reivindicaciones precedentes, donde dichos mensajes y/o valores enviados entre el servidor y la unidad de usuario se intercambian dentro de un canal de comunicación seguro.
10. Método según la reivindicación 9, donde dicha comunicación segura se obtiene al encriptar al menos una parte de los contenidos intercambiados.
11. Método según la reivindicación 10, donde el valor de etiqueta (tc , t'c) se usa para derivar al menos una encriptación de clave para encriptar dichos contenidos intercambiados.
12. Método según cualquiera de reivindicaciones precedentes, donde el resultado positivo en la prueba de condición de acceso realizada en la fase operativa se sustituye por la realización de un paso condicional destinado a verificar si el valor de etiqueta (tc) debe actualizarse:
- en caso positivo: en primer lugar, actualizar el valor de etiqueta (tc), tanto en el lado servidor como en el lado unidad de usuario, enviando desde el servidor hasta la unidad de usuario un mensaje de actualización con un valor de actualización (X) y sustituyendo dicho valor de etiqueta (tc) por un nuevo valor de etiqueta (t'c) derivado del último valor de etiqueta (tc) y de dicho valor de actualización (X), y almacenar el nuevo valor de etiqueta (t'c) en el registro de la base de datos del servidor y en la unidad de usuario;
- en caso negativo: enviar directamente dicho mensaje servidor a la unidad de usuario, como una respuesta a dicha solicitud;
y donde el resultado negativo en dicha prueba de condición de acceso se sustituye de la siguiente manera:
- realizar un paso condicional, por medio de un contador de intentos fallidos contador usado para contar una serie de consecuencias negativas sucesivas sobre dicha condición de acceso, para verificar si este número ha alcanzado un umbral predeterminado:
- en caso negativo: enviar un mensaje servidor a la unidad de usuario sin actualizar el valor de etiqueta (tc), - en caso positivo: denegar el servicio solicitado.
13. Método según cualquiera de las reivindicaciones 5 a 12, donde el resultado negativo en dicha prueba de condición de acceso comprende además los siguientes pasos:
- verificar si el identificador cliente (IDc) incluido en el mensaje cliente ya está almacenado en uno de los registros de la base de datos: en caso negativo, denegar el servicio solicitado, mientras que en caso positivo:
- incrementar en una unidad el valor de un contador cliente asociado a dicho identificador cliente (IDc) en su registro, luego verificar si este contador cliente alcanza un umbral predeterminado, en caso positivo: denegar el servicio solicitado, mientras que en caso negativo:
- almacenar el valor del contador cliente incrementado en dicho registro,
- asignar un nuevo identificador cliente único (IDc) al cliente al almacenar, en un nuevo registro de la base de datos, este nuevo identificador cliente único (IDc) junto con un nuevo valor de etiqueta (t'c) y con un valor, almacenado como contador cliente, que alcanza dicho umbral predeterminado,
- enviar un mensaje servidor a la unidad de usuario, como una respuesta a dicha solicitud,
- proporcionar dicho nuevo identificador cliente único (IDc) y dicho nuevo valor de etiqueta (t'c) a su unidad de usuario cliente,
- almacenar el nuevo valor de etiqueta (t'c) en el registro de la base de datos del servidor y en la unidad de usuario cliente.
ES11808938T 2010-11-19 2011-11-15 Método para detectar software clonado Active ES2806261T3 (es)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
ES2806261T3 true ES2806261T3 (es) 2021-02-17

Family

ID=45496213

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11808938T Active ES2806261T3 (es) 2010-11-19 2011-11-15 Método para detectar software clonado

Country Status (6)

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

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 富士通株式会社 Ｃａｔｖシステムのセンタ装置および端末装置
US5237610A (en) 1990-02-01 1993-08-17 Scientific-Atlanta, Inc. Independent external security module for a digitally upgradeable television signal decoder
US5029207A (en) 1990-02-01 1991-07-02 Scientific-Atlanta, Inc. External security module for a 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.
DE69228481T2 (de) 1991-10-03 1999-08-12 Thomson Multimedia Sa Verfahren zur individuellen anpassung eines gerätes mit einer chipkarte
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
DE69432049T2 (de) 1994-03-28 2003-11-06 British Telecomm Sicherungssystem
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
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
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
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 Каналь+Сосьетэ Аноним Способ и устройство для шифрованной трансляции потока данных
EP1029421B1 (de) 1997-11-07 2001-09-19 Swisscom Mobile AG Identifizierungskarte und identifizierungsverfahren
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
DE50013126D1 (de) 1999-12-16 2006-08-17 Siemens Ag 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
BR0116358A (pt) 2000-12-22 2003-12-23 Nagravision Sa Método anticlonagem
WO2002052515A1 (fr) 2000-12-22 2002-07-04 Nagravision Sa Méthode de contrôle d'appariement
US20060059544A1 (en) 2004-09-14 2006-03-16 Guthrie Paul D Distributed secure repository
US7139398B2 (en) 2001-06-06 2006-11-21 Sony Corporation Time division partial encryption
JP4659357B2 (ja) 2001-09-21 2011-03-30 ザ・ディレクティービー・グループ・インコーポレイテッド 条件付アクセスモジュールと、集積受信機およびデコーダの対動作を制御する方法および装置
US7409562B2 (en) 2001-09-21 2008-08-05 The Directv Group, Inc. Method and apparatus for encrypting media programs for later purchase and viewing
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
US7760882B2 (en) * 2004-06-28 2010-07-20 Japan Communications, Inc. Systems and methods for mutual authentication of network nodes
US20060107323A1 (en) 2004-11-16 2006-05-18 Mclean Ivan H System and method for using a dynamic credential to identify a cloned device
CA2599000A1 (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
BRPI0706880A2 (pt) * 2006-01-20 2011-04-12 Verimatrix Inc sistema e método para segurança de rede
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
BR112013012356B1 (pt) 2021-03-09
US9946855B2 (en) 2018-04-17
US20130312119A1 (en) 2013-11-21
US20170161472A1 (en) 2017-06-08
WO2012066471A1 (en) 2012-05-24
US9582685B2 (en) 2017-02-28
EP2641208A1 (en) 2013-09-25
ZA201303272B (en) 2014-07-30
EP2641208B1 (en) 2020-04-29
BR112013012356A2 (pt) 2020-05-12

Similar Documents

Publication Publication Date Title
Xue et al. Combining data owner-side and cloud-side access control for encrypted cloud storage
AU764909B2 (en) Server-assisted regeneration of a strong secret from a weak secret
US8196186B2 (en) Security architecture for peer-to-peer storage system
US10027631B2 (en) Securing passwords against dictionary attacks
US8966276B2 (en) System and method providing disconnected authentication
US8132020B2 (en) System and method for user authentication with exposed and hidden keys
US9118661B1 (en) Methods and apparatus for authenticating a user using multi-server one-time passcode verification
US8555361B2 (en) Dynamic cryptographic subscriber-device identity binding for subscriber mobility
EP2020797B1 (en) Client-server Opaque token passing apparatus and method
US20170142082A1 (en) System and method for secure deposit and recovery of secret data
US8775794B2 (en) System and method for end to end encryption
GB2526367A (en) Password-based authentication
Dua et al. Replay attack prevention in Kerberos authentication protocol using triple password
US20210390533A1 (en) User-Centric, Blockchain-Based and End-to-End Secure Home IP Camera System
US20160359822A1 (en) Sovereign share encryption protocol
CN109347887A (zh) 一种身份认证的方法及装置
JP2016522637A (ja) 共有秘密を含意するセキュア化されたデータチャネル認証
CN110557367A (zh) 基于证书密码学的抗量子计算保密通信的密钥更新方法和系统
Das et al. A decentralized open web cryptographic standard
CN110620668B (zh) 基于区块链的抗量子计算公钥池更新方法和系统
ES2806261T3 (es) Método para detectar software clonado
US20090164782A1 (en) Method and apparatus for authentication of service application processes in high availability clusters
Tan et al. A universal decentralized authentication and authorization protocol based on Blockchain
Chen et al. SSL/TLS session-aware user authentication using a gaa bootstrapped key
Kotiyal et al. A 5-Level Security Approach for data Storage in cloud