ES2806261T3 - Método para detectar software clonado - Google Patents
Método para detectar software clonado Download PDFInfo
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 34
- 230000004044 response Effects 0.000 claims abstract description 10
- 238000004891 communication Methods 0.000 claims description 22
- 230000008859 change Effects 0.000 claims description 9
- 238000009795 derivation Methods 0.000 claims description 8
- 238000002360 preparation method Methods 0.000 claims description 3
- 230000008569 process Effects 0.000 claims description 3
- 230000006870 function Effects 0.000 description 35
- 238000010367 cloning Methods 0.000 description 5
- 230000006835 compression Effects 0.000 description 4
- 238000007906 compression Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 238000012795 verification Methods 0.000 description 4
- 238000011084 recovery Methods 0.000 description 3
- 238000001514 detection method Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- 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 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)
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.
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)
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)
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 | 富士通株式会社 | Catvシステムのセンタ装置および端末装置 |
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 | 日本電気株式会社 | Catv向け端末装置 |
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 | 富士通株式会社 | 移動通信システムにおける移動機の登録方法とicカードの登録方法、及びそれらを実現するための移動機、icカード、及びicカード挿入型移動機 |
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 |
ES2191020T3 (es) | 1994-03-28 | 2003-09-01 | British Telecomm | Sistema de seguridad. |
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 | Каналь+Сосьетэ Аноним | Способ и устройство для шифрованной трансляции потока данных |
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 |
WO2000034877A1 (en) | 1998-12-08 | 2000-06-15 | Alliedsignal Inc. | Enhanced uart interface circuit in satcom system |
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 |
WO2002052515A1 (fr) | 2000-12-22 | 2002-07-04 | Nagravision Sa | Méthode de contrôle d'appariement |
WO2002052389A2 (fr) | 2000-12-22 | 2002-07-04 | Nagravision Sa | Methode anti-clonage d'un module de securite |
US20060059544A1 (en) | 2004-09-14 | 2006-03-16 | Guthrie Paul D | Distributed secure repository |
US7124303B2 (en) | 2001-06-06 | 2006-10-17 | Sony Corporation | Elementary stream partial encryption |
US7409562B2 (en) | 2001-09-21 | 2008-08-05 | The Directv Group, Inc. | Method and apparatus for encrypting media programs for later purchase and viewing |
WO2003028287A1 (en) | 2001-09-21 | 2003-04-03 | Hughes Electronics Corporation | 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 |
US7305555B2 (en) | 2002-03-27 | 2007-12-04 | General Instrument Corporation | Smart card mating protocol |
US7370111B2 (en) | 2002-03-27 | 2008-05-06 | Intel Corporation | System, protocol and related methods for providing secure manageability |
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 |
US20060190413A1 (en) | 2005-02-23 | 2006-08-24 | 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 |
US20070174472A1 (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 |
-
2011
- 2011-11-15 WO PCT/IB2011/055083 patent/WO2012066471A1/en active Application Filing
- 2011-11-15 US US13/988,292 patent/US9582685B2/en active Active
- 2011-11-15 ES ES11808938T patent/ES2806261T3/es active Active
- 2011-11-15 EP EP11808938.2A patent/EP2641208B1/en active Active
- 2011-11-15 BR BR112013012356-7A patent/BR112013012356B1/pt active IP Right Grant
-
2013
- 2013-05-06 ZA ZA2013/03272A patent/ZA201303272B/en unknown
-
2017
- 2017-02-21 US US15/438,381 patent/US9946855B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
US20130312119A1 (en) | 2013-11-21 |
EP2641208A1 (en) | 2013-09-25 |
US20170161472A1 (en) | 2017-06-08 |
BR112013012356A2 (pt) | 2020-05-12 |
WO2012066471A1 (en) | 2012-05-24 |
BR112013012356B1 (pt) | 2021-03-09 |
US9582685B2 (en) | 2017-02-28 |
US9946855B2 (en) | 2018-04-17 |
EP2641208B1 (en) | 2020-04-29 |
ZA201303272B (en) | 2014-07-30 |
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 | |
US20050193199A1 (en) | Accessing protected data on network storage from multiple devices | |
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 |