ES2709074T3

ES2709074T3 - Comparación de una lista de contactos automatizada con una mejora de la privacidad

Info

Publication number: ES2709074T3
Application number: ES13001325T
Authority: ES
Inventors: Johannes Singler
Original assignee: ONECTIVE AG
Current assignee: ONECTIVE AG
Priority date: 2013-03-15
Filing date: 2013-03-15
Publication date: 2019-04-15
Anticipated expiration: 2033-03-15
Also published as: EP2779016B1; US20160034692A1; ES2709074T8; US9754114B2; EP2779016A1; WO2014140736A1

Abstract

Un procedimiento para comparar una primera pluralidad de conjuntos de datos privados, como una agenda de contactos privada y almacenada en un dispositivo cliente de comunicación (12) con una segunda pluralidad de conjuntos de datos, como un gran repositorio de contactos almacenado en un sistema de comunicación basado en servidor (14), que comprende las etapas de: a) dicho sistema de servidor que recibe para cada una de dicha primera pluralidad de conjuntos de datos privados un valor hash reducido (28) de dicho cliente, preferiblemente en un canal de transmisión cifrado, con una solicitud para comparar dichos conjuntos de datos privados con dicha segunda pluralidad de conjuntos de datos almacenados en dicho servidor, en el que dicho valor hash reducido tiene una longitud s que representa el número de bits de un valor hash criptográfico de una parte única, preferiblemente un número de teléfono de cada uno de los conjuntos de datos privados que se transmitirán entre el cliente y el servidor, en el que s se elige de manera que se producirán colisiones de hash en dicho sistema de comunicación basado en servidor (14), b) dicho servidor compara (240) cada uno de dichos valores hash reducidos y recibidos (28) con dicha segunda pluralidad de conjuntos de datos almacenados en dicho servidor, y encuentra los conjuntos de datos almacenados entre dicha segunda pluralidad de conjuntos de datos que tienen un valor hash reducido idéntico, c) dicho servidor enlista (245) cada uno de dichos valores hash encontrados con uno respectivo de dichos valores hash reducidos y recibidos (28), d) dicho servidor envía (250) dichos valores hash encontrados (28) a dicho dispositivo cliente.

Description

DESCRIPCION

Comparacion de una lista de contactos automatizada con una mejora de la privacidad

1. Antecedentes de la invencion

1.1. Campo de la invencion

La presente invencion se encuentra en el campo de la tecnologia de la informacion y esta relacionada con un procedimiento y un sistema para comparar una primera pluralidad de conjuntos de datos privados, por ejemplo, una agenda de contactos privado que tiene tipicamente unos pocos centenares de entradas de contactos, almacenadas en un dispositivo cliente de comunicacion, con una segunda pluralidad de conjuntos de datos, por ejemplo, un gran repositorio de contactos que tiene miles o incluso millones de entradas de contacto, almacenadas en un sistema de comunicacion basado en servidor.

1.2. Descripcion y desventajas de la tecnica anterior.

Los populares servicios de comunicacion de la tecnica anterior que se ejecutan en telefonos inteligentes como WhatsApp utilizan el numero de telefono GSM del usuario como la identidad del usuario. Proporcionan servicios como mensajes de texto, llamadas a traves de voz sobre IP y transferencia de archivos, a bajo coste, mediante la transferencia de datos a traves de la conexion a Internet del telefono. Para mostrar al usuario el subconjunto de sus contactos que tambien son miembros del mismo servicio de comunicacion, comparan la agenda de contactos del usuario con el conjunto de miembros ya registrados del servicio de comunicacion.

Hasta el momento, en la tecnica anterior esto se hace enviando la lista de numeros de telefono al proveedor de servicios sin cifrar y sin anonimizar, segun se informa en la revista de "Stiftung Warentest", volumen 6/12, publicado el 24 de mayo de 2012, recibiendo en respuesta el subconjunto de contactos que ya son miembros. Por lo tanto, cualquier persona que pueda escuchar clandestinamente la comunicacion entre el telefono y el proveedor de servicios obtiene acceso a la agenda de contactos completa del usuario. Esto incluye al propio proveedor de servicios, por supuesto. Sin embargo, una agenda de contactos constituye informacion privada y es un secreto comercial para profesionales, que revela contactos valiosos y, posiblemente, incluso estrategias comerciales.

A fin de poder proporcionar el servicio solicitado, por ejemplo, para mostrar el estado en linea de los contactos, los contactos de los miembros del usuario deben ser revelados al proveedor del servicio. Esto esta permitido porque esos contactos han aceptado los terminos y servicios del servicio de comunicacion. En cambio, los contactos que no participan en el servicio de comunicacion no deben ser revelados publicamente, ni siquiera al proveedor del servicio de comunicacion. De hecho, esto seria una violacion del derecho de autodeterminacion informativa ("Grundrecht auf informationelle Selbstbestimmung") del contacto, quien probablemente no ha aceptado que su informacion se comparta con dicho proveedor de servicios, como se informa en http://www.telemedicus.info/article/2222-LG-Berlin-Das-Facebook-Urteil-im-Detail.html.

segun se publico en Internet desde el 12 de marzo de 2012, o consulte la decision publicada de Landgericht Berlin, LG Berlin, Urteil v. 06.03.2012, Az. 160551 /10.

Una forma perfecta sensible con la privacidad seria cifrar asimetricamente la lista de numeros de telefono, entrada por entrada a ambos lados con una clave aleatoria y unica, y comparar las listas cifradas. Dado que el cifrado es biyectivo, es una biseccion en el operador de interseccion, por lo que el cliente puede transformar el resultado facilmente hacia atras. Sin embargo, cifrar todos los numeros de telefono de un miembro en cada comparacion es computacionalmente inviable, ya que podria haber millones, y se podrian producir multiples consultas por segundo. Otra forma seria enviar la lista completa de participates del servicio al cliente y compararlos alli sin mas interaccion con el servidor. Sin embargo, esto tambien es inviable porque revelaria la informacion de contacto de todos los miembros del servicio a un usuario no fiable. Mas aun, la larguisima lista de miembros tendria que enviarse al cliente, lo que daria lugar posiblemente a muchos megabytes de datos, lo cual no es factible, especialmente, para los clientes moviles.

1.3. Objetivos de la invencion

El objetivo de la presente invencion es proporcionar un procedimiento y un sistema eficaces para transmitir y comparar dichos datos privados, tal como se ha mencionado anteriormente, en el que los datos se procesan de manera que cualquier persona que escuche clandestinamente, incluido el proveedor de servicios central que realmente realiza la comparacion, tambien tenga que dedicar un intensivo trabajo computacional si quiere saber acerca de los datos, y que procedimiento no consume demasiada capacidad computacional en los dispositivos cliente y el servidor.

2. Resumen y ventajas de la invencion.

Este objetivo de la invencion se logra mediante las caracteristicas establecidas en las reivindicaciones independientes adjuntas. Otras disposiciones y realizaciones ventajosas de la invencion se exponen en las reivindicaciones dependientes respectivas. A continuacion, se debe hacer referencia a las reivindicaciones anejas. Segun una caracteristica basica de la presente invencion, se describe un procedimiento ejecutado en un servidor para comparar una primera pluralidad de conjuntos de datos privados, como una agenda de contactos privada y almacenada en un dispositivo cliente de comunicacion con una segunda pluralidad de conjuntos de datos, como un gran repositorio de contactos almacenado en dicho sistema de comunicacion, que comprende las etapas de: a) el ordenador servidor que calcula la longitud del valor hash s que representa el numero de bits de un valor hash criptografico de una parte unica (por ejemplo, el numero de telefono) de cada uno de los conjuntos de datos privados que se transmitiran entre el cliente y el servidor, y que comunica s al cliente,

b) el sistema de servidor que recibe para cada una de dicha primera pluralidad de conjuntos de datos privados un valor hash reducido de dicho cliente, preferiblemente en un canal de transmision cifrado, con una solicitud para comparar dichos conjuntos de datos privados con el segundo conjunto de datos almacenado en el servidor, c) el servidor verifica si la longitud de los hash recibidos es igual a s,

d) si la longitud de los hash es igual a s, el servidor compara cada uno de los valores hash recibidos con la segunda pluralidad de conjuntos de datos almacenados en el servidor, encontrando los conjuntos de datos almacenados que tienen un valor hash reducido identico,

e) el servidor enlista cada uno de dichos valores hash encontrados con uno respectivo de dicho valor hash recibido, por ejemplo: 10 valores hash recibidos, 23 coincidencias encontradas

f) el servidor reduce los valores hash encontrados, es decir, los valores hash completos, a una longitud predeterminada de m bits, y

g) el servidor envia para cada uno de los valores hash reducidos y recibidos la lista de valores hash reducidos al dispositivo cliente, como respuesta a la peticion anterior.

El procesamiento del parametro s en la etapa a) es una etapa menos importante, una especie de preprocesamiento. El parametro s tambien se puede configurar de forma manual o automatica de forma general o individualmente para cada ejemplo de uso. El ordenador cliente y servidor realizan los controles de verosimilitud respectivos y acuerdan un valor especifico s sin importar que parte lo propone: cliente o servidor, o acuerdan una diferencia maxima permitida entre s segun se envia desde el servidor, y s, segun se envia desde el cliente.

En la etapa b) anterior, en el caso de colisiones en la agenda de direcciones, es decir, cuando dos conjuntos de datos privados diferentes tienen accidentalmente el mismo valor hash, entonces solo se envia este valor hash unico desde el cliente al servidor.

Una funcion hash criptografica como SHA-1 (tecnica anterior) proyecta cada numero de telefono en una cadena de bits de cierta longitud, llamada hash, por ejemplo, 160 bits. Una funcion hash criptografica es una funcion unidireccional. Por lo tanto, determinar la imagen previa, es decir, el numero de telefono del hash, es computacionalmente dificil. En general, se supone que la unica forma de obtener la imagen previa de un hash es probar la mayoria de las imagenes previas posibles. De hecho, se espera encontrar una coincidencia despues de haber probado la mitad de ellas, pero en el peor de los casos, se tiene que intentar todas. En el siguiente parrafo, vamos a ignorar este pequeno factor constante de 2.

Recudir la longitud s en el sentido de la presente invencion significa seleccionar un subconjunto ordenado arbitrario pero sistematico de longitud s del hash. Por ejemplo, se podrian seleccionar los primeros (como se muestra en los dibujos) o los ultimos s bits, o bits arbitrarios, como el 1°, 4°, 3°, el 21 y asi sucesivamente. La forma como se selecciona el subconjunto no tiene influencia en la calidad de la invencion, ya que todos los bits tienen propiedades iguales, lo que es una caracteristica de una funcion hash criptografica. La unica condicion es que el servidor y el cliente acuerden el mismo subconjunto y que los dos bits de la misma posicion de bit se comparen entre si.

Las etapas a) y c) tambien pueden sustituirse por un procedimiento alternativo que produce parametros de control utilizables en el procedimiento de la invencion.

En cuanto a la etapa f), tambien se puede omitir una segunda reduccion, cuando el parametro m se establece en la longitud total del hash, por ejemplo, 160 bits en el SHA-1.

El procedimiento de la invencion se puede aplicar ventajosamente cuando los conjuntos de datos privados son datos de contacto almacenados en un dispositivo informatico movil, como un telefono inteligente o un telefono movil, ya que la capacidad computacional en dichos dispositivos es, aunque esta en constante crecimiento, todavia bastante limitada.

Cuando adicionalmente, el ordenador servidor almacena un valor hash reducido y precalculado para cada uno de los conjuntos de datos privados, el cual se ha calculado con el mismo algoritmo que se utilizo en el ordenador cliente, no se debe realizar ningun calculo de hash "sobre la marcha", es decir, cuando se recibe una solicitud de comparacion de contactos en el servidor. Esto ahorra tiempo y permite unos tiempos de respuesta cortos para dichas solicitudes. Ademas, el ordenador servidor calcula y almacena ventajosamente un valor hash de longitud media m que enviara de nuevo al cliente para cada conjunto de datos de la comparacion.

A continuacion, el cliente compara dicho valor hash de longitud media con el prefijo del valor hash completo, y para un par coincidente, el cliente puede calcular facilmente el conjunto de datos privado respectivo que ha sido comparado por el servidor. Por lo tanto, dicho valor hash de tamano medio utilizado en el servidor, tambien ahorra tiempo y permite unos tiempos de respuesta cortos para dichas solicitudes de comparacion.

Cuando el ordenador servidor vuelve a calcular repetidamente los valores hash en base a un parametro de entrada preferiblemente calculado de forma aleatoria, por ejemplo, lo que se conoce generalmente como "sal aleatoria", entonces se encuentra alguna medicion contra el uso de las llamadas tablas del arco iris por parte de un posible atacante.

De una forma analoga segun se describe para el lado del servidor, tambien para el dispositivo informatico del cliente, preferiblemente un dispositivo movil, se describe un procedimiento para comparar una primera pluralidad de conjuntos de datos privados, como una agenda de contactos privada y almacenada en un dispositivo cliente de comunicacion con un segunda pluralidad de conjuntos de datos, como un gran repositorio de contactos almacenado en un sistema de comunicacion basado en servidor, que comprende las etapas de:

a) el dispositivo cliente que procesa o calcula una longitud de valor hash predeterminada s que representa el numero de bits de un valor hash criptografico de una parte unica, por ejemplo, el numero de telefono de cada conjunto de datos privados que se transmitira entre el cliente y el servidor,

b) el dispositivo cliente que calcula el valor hash para cada uno de los conjuntos de datos privados,

c) el dispositivo cliente que reduce el valor hash para cada uno de los conjuntos de datos privados a una longitud predeterminada s,

d) el dispositivo cliente que envia, para cada uno de los conjuntos de datos privados dicho valor hash reducido al servidor, preferiblemente en un canal de transmision cifrado, que solicita al servidor que compare los conjuntos de datos privados con la segunda pluralidad de conjuntos de datos almacenados en el servidor,

e) recibir un valor hash para cada comparacion, cuyo valor hash se ha reducido a una pluralidad de un numero predeterminado de m bits por el servidor,

f) el cliente compara los valores hash recibidos y reducidos a m con los conjuntos de datos almacenados en el cliente, revelando asi informacion sobre en que conjuntos de datos privados y almacenados tanto en el cliente como en dicho servidor, la porcion unica y respectiva es identica.

Ventajosamente, el dispositivo informatico del cliente aplica de manera iterativa el calculo del valor hash de forma repetida y multiple a fin de proporcionar un mayor grado de privacidad.

El lector experto reconoce que, matematicamente hablando, el problema de comparacion resuelto aqui es encontrar la interseccion del conjunto relativamente pequeno de contactos de la agenda de contactos de un usuario con el conjunto relativamente grande de un repositorio que almacena una gran pluralidad de datos de contacto de los miembros registrados de un servicio de comunicacion respectivo, a traves de una conexion de ancho de banda limitado. El requisito especial es proteger la privacidad. Los contactos y los miembros estan identificados en este ejemplo de uso por su numero de telefono en el formato unico y estandarizado internacionalmente, por ejemplo, 4199999999.

Asi, un experto en la materia apreciara que se describe un procedimiento y un sistema ventajosos que ofrece un protocolo para comparar datos privados y, en particular, para comparar la agenda de contactos con un repositorio de contactos de un servicio de comunicacion, en el que el protocolo no revela Informacion privada ni al proveedor de servicios ni a ningun tercero. Por lo tanto, el anonimato y la privacidad de los contactos del usuario se mantienen, y los contactos no estan expuestos a escuchas clandestinas.

Segun una caracteristica opcional ventajosa adicional, todos los valores hash incluyen ademas una sal, es decir, que resulta de una cadena de bits aleatoria, pero constante, anadida al conjunto de datos privados, por ejemplo, anadida al numero de telefono, al nombre o cualquier parte del conjunto de datos privados, de manera clara que cambia deterministicamente el resultado hash. Despues de intervalos de tiempo predeterminados, el proveedor de servicios vuelve a calcular todos los hash de los miembros en base a una nueva sal aleatoria, desaprobando una posible tabla hash inversa (tabla del arco iris) calculada por un ataque de fuerza bruta. Al decirle al usuario que utilice esta nueva sal durante la comparacion de contactos, el proveedor de servicios demuestra el gran esfuerzo que necesitaria para aplicar ingenieria inversa en la agenda telefonica del usuario, incluso para ellos mismos.

Con este procedimiento de la invencion, no es practicamente viable que el proveedor de servicios ni ninguna escucha clandestina realicen una ingenieria inversa de la agenda de contactos. Aqui, practicamente inviable significa que requiere un esfuerzo computacional prohibitivo. E incluso si la escucha clandestina dedicara este esfuerzo, todavia existe la incertidumbre de si un contacto reproducido por ingenieria inversa es realmente un contacto, por ejemplo, del 50%, en funcion de ciertos parametros, que pueden configurarse y modificarse mediante parametros predeterminados adaptables a cualquier ejemplo de uso individual.

Ademas, se preserva el anonimato y la privacidad de los contactos que no son miembros del servicio de comunicacion, ya que los contactos que no participan no pueden ser conocidos con exactitud, ni siquiera por el proveedor de servicios. El proveedor de servicios conoce solo a los contactos que estan registrados para el servicio, es decir, que han aceptado los terminos y condiciones del proveedor de servicios en cualquier caso.

Por lo tanto, se describe un procedimiento de la invencion que incluye la caracteristica tecnica de aplicar hashing a las entradas de la agenda de contactos e impedir los ataques de fuerza bruta al no transmitir el hash completo, sino solamente una parte bien elegida. Esto introduce incertidumbre en cualquier ataque de fuerza bruta pero mantiene la tasa de aciertos esperada a la hora de proporcionar una comparacion de contactos fiable. Los parametros se eligen para optimizar la privacidad frente a los requisitos de ancho de banda.

Sin embargo, el procedimiento y el sistema respectivo son eficaces en terminos de calculos y comunicacion incluso para un gran numero de miembros, para posiblemente todos los numeros de telefono utilizados en la Tierra.

3. Breve descripcion de los dibujos

La presente invencion se ilustra a modo de ejemplo y no esta limitada por la forma de las figuras de los dibujos en los que:

La Figura 1 es una descripcion general esquematica del sistema implicado en el procedimiento de la invencion. La Figura 2 es un diagrama de interaccion que ilustra la interaccion entre el cliente y el servidor durante una realizacion preferida del procedimiento de la invencion.

La Figura 3 es una vista con zoom en un detalle de una etapa de la Figura 2 que es ejecutada por el cliente.

La Figura 4 es una representacion esquematica y exhaustiva que ilustra un valor hash reducido, un valor hash de tamano medio y la referencia clara del usuario, en este caso el nombre de una persona, para tres entradas distintas de la agenda de contactos.

4. Descripcion detallada de la realizacion preferida

Con referencia general a las figuras y, de nuevo, con referencia especial a la Figura 1, el procedimiento de la invencion se implementa en una arquitectura cliente-servidor tal como se representa en la Figura 1.

Un dispositivo de telefono inteligente movil cliente 12 esta conectado a traves de una conexion a Internet 10 a un ordenador servidor 14 operado por un proveedor de servicios. El ordenador servidor almacena una gran pluralidad de, por ejemplo, varios millones de registros de contactos en un gran repositorio fisico, organizado en una base de datos indexada, por ejemplo, una base de datos relacional, en la que cada conjunto de datos esta asociado con una persona individual que se ha suscrito al servicio antes de que sus datos de contacto sean almacenados. Los datos de contacto comprenden una o mas direcciones fisicas de su puesto, numeros de telefono, direcciones de correo electronico y, opcionalmente, otros datos como sexo, edad, profesion, fecha de nacimiento, salario y otros datos que puedan ser relevantes para fines de marketing, como aficiones e intereses, tamano del cuerpo, etc. El dispositivo cliente y el ordenador servidor se comunican con una conexion cifrada a traves de Internet, tal como el protocolo TLS como se conoce en la tecnica anterior o, adicionalmente, con un protocolo, por ejemplo, tal como se describe en un numero de solicitud de patente europea en tramitacion 12007079.2 presentada por el solicitante.

Ademas, se representa simbolicamente a un atacante 19 que intenta atacar la comunicacion en su camino a traves de Internet, con medios tecnicos de escucha clandestina de la tecnica anterior.

Ademas, se supone que un segundo atacante trabaja en el sitio del proveedor de servicios, tal vez un miembro del personal, por ejemplo, un operador de la base de datos malicioso 20 que tiene acceso de lectura y/o escritura al repositorio.

El procedimiento de comparacion de la invencion se refiere en la presente memoria tambien como Comparacion de Contactos Privados y se abrevia como CCP. Deje que en esta realizacion ejemplar del procedimiento de la invencion, el "cliente" sea el dispositivo informatico movil en el que el usuario ejecuta una aplicacion de comunicacion, por ejemplo, "Facebook" o "Twitter" o "WhatsApp", implementando el procedimiento CCP de la invencion incorporado en una App respectiva. Se comunica con el "servidor" del proveedor de servicios de comunicacion, implementando el procedimiento CCP equivalente y, por lo tanto, interactuando con el cliente.

La Figura 2 es un diagrama de interaccion que ilustra la interaccion entre el cliente 12 y el servidor 14 durante una realizacion preferida del procedimiento de la invencion.

La Figura 3 es una vista con zoom en un detalle de las etapas 225 y 230 de la Figura 2, ejecutado por el cliente. Como primera medida de seguridad, se prefiere cifrar la conexion de Internet 10 entre el cliente y el servidor utilizando la seguridad de la capa de transporte denominada TLS, segun se hace en la tecnica anterior. Al verificar que el certificado del servidor pertenece al proveedor de servicios, se garantiza que solo el proveedor de servicios conocido y deseado puede escuchar la comunicacion, de manera que el protocolo no puede ser escuchado facilmente de forma clandestina por un tercero, como puede ser el atacante 18 de la Figura 1.

En segundo lugar, segun una caracteristica preferida de la presente invencion, los numeros de telefono 22 de los contactos del cliente no se transmiten en texto simple, sino que se procesaran mediante un procedimiento criptografico especifico, en particular, mediante una funcion hash criptografica, tal como se conoce de la tecnica anterior, la funcion MD-5 o SHA-1, en la etapa 225, el procedimiento de la invencion proyecta cada numero de telefono en una cadena de bits, denominada hash (valor), que se reduce en la etapa 230 y posteriormente se transfiere al servidor en la etapa 235.

Mas particularmente y, preferiblemente, antes de realizar las etapas 225 a 235 mencionadas anteriormente, al iniciar sesion durante la etapa de solicitud del cliente 210 y la etapa de concesion de inicio de sesion del servidor 215, el servidor calcula el valor s = floor(log_2(n)) - u como una indicacion de cuantos bits por contacto se deben enviar en un posible procedimiento de comparacion en una etapa 216 y se lo comunica al cliente en una etapa 219. El cliente recibe dicho parametro s y verifica si este valor es razonablemente pequeno. De forma alternativa, el cliente puede decidir que valores usar en base a cualquier otro criterio.

A continuacion, en una etapa 225 y con una referencia adicional especial a la Figura 3, para cada contacto de la agenda de contactos que debe coincidir con el repositorio de contactos del servidor, el cliente calcula un valor hash criptografico del numero de telefono 22. Preferiblemente y, a modo de ejemplo, se usa el algoritmo SHA-1 y se anade una sal en una etapa 310 antes de aplicar la funcion de hash al numero de telefono con sal anadida 24 en una etapa 320. Preferiblemente, el hashing se repite un gran numero de veces, por ejemplo 1000 veces (no representado en el dibujo); cuantas mas veces, mas dificil es (directamente proporcional) calcular la imagen previa del valor hash.

En tercer lugar, los valores hash de los numeros de telefono de la agenda de direcciones se reducen a un cierto numero de bits en una etapa 330 adicional, lo que da como resultado un valor hash reducido 28, a fin de introducir incertidumbre en el caso de que el atacante aplique fuerza bruta.

En referencia a los problemas especiales de este uso de la invencion, solo el proveedor de servicios puede atacar debido a la transmision segura de TLS, pero se debe observarse que los contactos que no son miembros en el repositorio del servidor no se deben comparar, ni siquiera estar expuestos al proveedor de servicios.

Dado que el servicio de comunicacion tiene n, por ejemplo, n = 10.000.000 miembros. Deje que L=log_2(n), por lo tanto, L = 23,xxx. Si se comparan L bits de hash, se espera que un hash aleatorio coincida con aproximadamente 1 contacto. El cliente corta los hash en una etapa 330 a s=floor(L)-u bits, donde u es un parametro predeterminado y configurable por el usuario. Cuanto mayor sea u, mayor es la incertidumbre, ya que se espera que mas miembros que no sean contactos coincidan con el hash reducido. Supongamos u=1, entonces

s = floor(23,xxx - 1) = floor(22,xxx) = 22 = s. Por lo tanto, el cliente reduce el valor hash de, por ejemplo, 160 bits (en el caso de usar SHA-1) a 22 bits, lo que resulta en un valor hash reducido indicado con el signo de referencia 28 en la Figura 3. A continuacion, el cliente envia la lista de hash reducidos al servidor a traves de la conexion cifrada TLS, vease la etapa 235 en la Figura 2.

Despues de recibir dichos valores hash reducidos, a fin de evitar exponer los numeros de telefono a demasiadas colisiones de hash con falsos positivos, el programa CCP del servidor verifica si la longitud s de los hash reducidos es lo suficientemente larga segun se ha solicitado, y verifica en la etapa 238, si el numero de valores hash enviados no es inverosimilmente grande, para evitar revelar una parte inadecuadamente grande del conjunto de miembros de datos de contacto al cliente. En este sentido, se propone definir un limite maximo del numero de hash enviados al cliente a 5000, como un tamano maximo posible para la agenda de contactos.

Posteriormente, el servidor compara los hash reducidos recibidos con los miembros de su repositorio del sistema en una etapa 240. Mas particularmente, el servidor encuentra los miembros para los cuales el prefijo del hash del numero de telefono coincide con uno de los hash cortos recibidos mediante un procedimiento de comparacion respectivo. Para cada comparacion, en una etapa 245, el servidor enlista el valor hash correspondiente en una longitud de tamano medio m, preferiblemente mas larga, por ejemplo, de 64 bits, del mismo tipo, lo que hace que los resultados de la comparacion sean muy probablemente exactos, pero aun asi requiere un alto esfuerzo computacional para descifrar y revelar los numeros telefonicos de la imagen previa a la comparacion.

A continuacion, como respuesta a la solicitud de comparacion, en lugar de devolver los numeros de telefono en texto simple, el servidor envfa dichos valores hash de tamano medio, mas largos (por ejemplo, m 64 bits) al cliente, etapa 250.

Despues de que el cliente ha recibido dichos valores hash de tamano medio, en una etapa 260 el cliente compara los valores hash de tamano medio recibidos con los propios datos de contacto, es decir, encuentra los contactos para los cuales el prefijo del hash del numero de telefono coincide con uno de los hash de tamano medio recibidos. Cada coincidencia es un contacto, que tambien es miembro del servicio de comunicacion, que forma la interseccion resultante de conjuntos. A continuacion, el cliente muestra a su usuario que el procedimiento de comparacion se ha completado con exito, etapa 270.

A fin de responder de manera eficaz a las consultas de comparacion, el servidor mantiene preferiblemente el valor hash corto con cada conjunto de datos miembros de forma indexada en la base de datos, por lo que no es necesario calcular los valores hash sobre la marcha. Ademas, el valor hash de tamano medio para el resultado se almacena preferiblemente en la base de datos para una construccion rapida de la respuesta.

La Figura 4 es una representacion esquematica y exhaustiva de la tabla que ilustra en una columna de la izquierda un valor hash reducido indicado en un codigo hexadecimal ejemplar y que corresponde a 16 bits, en la columna central un valor hash de tamano medio en un codigo hexadecimal ejemplar que corresponde a 64 bits, y la columna de la derecha la referencia clara del usuario, en este caso el nombre de una persona, para tres entradas distintas de la agenda de direcciones. Las cadenas de bits identicas de los hash se denotan dentro de los cfrculos en lfneas discontinuas.

En una implementacion eficaz preferida del sistema en la parte del servidor, el servidor mantiene asociado con cada miembro del repositorio de contactos, el hash corto y el hash de tamano medio, incorporando la sal actual. Almacena el hash corto en formato hexadecimal de modo que se puede realizar una busqueda indexada eficaz. Si el numero de bits no es divisible por cuatro, los bits 0 se rellenan tanto en el hash corto como en la consulta.

Para permitir el cambio de las propiedades de hash como la longitud y la sal mientras se continua con el servicio, el nuevo calculo que consume mucho tiempo se debe realizar como tarea de fondo. Con este proposito, el servidor conserva dos

utilizando nuevos parametros como tarea de fondo. Cuando finaliza el calculo, el servidor intercambia ambas tablas y empieza a comunicar los nuevos parametros a los clientes.

Ademas, a continuacion se ofrece una breve prueba de la eficacia del procedimiento de la invencion segun se ha descrito anteriormente, junto con otras mejoras del mismo:

La conexion entre el cliente y el servidor se cifra y autentifica mediante un certificado de servidor bien conocido por el cliente. El cliente no se autentifica en el servidor, ya que se supone que el servicio esta abierto al publico en cualquier caso. Interceptar la comunicacion cifrada requerirfa acceso de escritura al cliente e instalar una version falsificada o manipulada del software cliente. Teniendo en cuenta este supuesto, el atacante podrfa simplemente leer la agenda de contactos en texto simple directamente desde el telefono del cliente y enviarlo a la parte atacante. Asf que podemos suponer que la conexion es segura.

De todos modos, el proveedor de servicios de comunicacion puede leer la comunicacion completa, y el personal no puede considerarse como completamente fiable debido al reglamento de privacidad mencionado en el capftulo introductorio. Por otro lado, el proveedor de servicios de comunicacion puede demostrar su credibilidad de privacidad al publico mediante el procedimiento de la invencion. Por lo tanto, el lector experto entiende que incluso el proveedor de servicios podrfa reconstruir la agenda de contactos solo con un esfuerzo extremo y, aun asf, solo con un grado significativo de incertidumbre, como se justifica a continuacion.

Calculamos que existen aproximadamente 10A12 (un billon) de numeros de telefono en todo el mundo (incluidos los codigos de pafs). A pesar de que el conjunto real de numeros de telefono en el mundo es, de hecho, mucho mas pequeno, no hay una lista completa legible por maquina y disponible publicamente que pueda ser de ayuda. Dado que el procedimiento de la invencion preferiblemente aplica iterativamente la funcion hash del orden de magnitud 10A3 veces, atacar la agenda de contactos requiere un esfuerzo computacional de aproximadamente 10A15 (1000 trillones) calculos de hash, lo que es muy costoso incluso en ordenadores grandes. Para el cliente, el calculo de los hash requiere bastante capacidad computacional, pero esto es aceptable (10A6, un millon de calculos de hash para 1000 contactos), ya que esto se puede producir como tarea de fondo. A medida que la capacidad computacional de los dispositivos moviles aumenta generalmente con el tiempo, tanto en los clientes como en las maquinas disponibles para el atacante, el numero de iteraciones puede aumentar.

Para el parametro u=0 mencionado anteriormente, la tasa de aciertos esperada para cada hash es 1, para u>0, es 2Au (es decir, 2 exp u). El inconveniente es que la u mas grande, la lista de resultados devueltos crece, y tambien lo hacen los requisitos de ancho de banda. Por lo tanto, seleccionar un valor para u es un compromiso entre la privacidad y los requisitos de ancho de banda. Un valor preferido es u=1, por lo que la probabilidad de que un contacto sospechoso sea realmente un contacto es del 50%.

Ademas, el numero de bits enviados al servidor en el procedimiento de la invencion sera asintoticamente menor que la entropfa de bits contenida en la agenda de contactos, por lo que a una parte independiente se le da una pista de que la agenda de contactos no se envfa por completo, con solo saber la longitud del mensaje cifrado.

Por ejemplo, para n=10A6 y u=1, una realizacion de la invencion enviarfa solo 18 bits por contacto, lo que equivale a aproximadamente 6 dfgitos decimales, que es incluso mas corto que la parte individual habitual del numero de telefono (es decir, excluido el codigo de area y de pafs).

Dado que los hash enviados por el cliente estan disenados para producir colisiones de hash, el proveedor de servicios revela algunos miembros que no son contactos hacia el cliente, como hash de tamano medio. Nuevamente, el calculo de la imagen previa todavfa esta limitado por un esfuerzo prohibitivo, e incluso si se invierte ese esfuerzo, el cliente solo conoce miembros aleatorios. Sin embargo, es posible verificar si hay un miembro con un numero de telefono especffico, ya que podrfa anadirse facilmente a la agenda de contactos de la parte interesada y esa parte podrfa convertirse en miembro. Despues de todo, exponer a un miembro que un contacto tambien es miembro del servicio, es el proposito original de todo el sistema de la invencion.

El procedimiento y el sistema de la invencion se pueden modificar y ampliar de diversas maneras:

El procedimiento de Comparacion de Contactos Privados de la invencion tambien es ventajoso cuando se utiliza con dispositivos estacionarios con una conexion a Internet de mayor ancho de banda. La alternativa desventajosa, como se ha mencionado en el capftulo introductorio, de transferir todo el conjunto de miembros del servicio de comunicacion, aun no es factible en este caso, ya que producirfa mucho trafico inesperado por parte del usuario. Gracias a una mayor capacidad computacional disponible en este entorno, el numero de iteraciones de hash podrfa incrementarse para una privacidad aun mejor.

Ademas, en caso de que el servidor desee proporcionar multiples niveles de privacidad utilizando diferentes conjuntos de parametros, si se equilibra rendimiento informatico y ancho de banda, el servidor solo puede mantener multiples conjuntos de parametros con el respectivo grado de equilibrio tal como se ha mencionado anteriormente. El procedimiento de la invencion tambien se puede utilizar con medios de identificacion de contacto distintos a los numeros de telefono mencionados anteriormente, por ejemplo, direcciones de correo electronico. Funciona incluso mejor, ya que el universo de posibles direcciones de correo electronico es mucho mayor en numero y es mas facil de administrar gracias a la ausencia de interfaces de comunicacion analogas que el universo de numeros de telefono. Por lo tanto, es menos probable que los ataques tengan exito.

Mientras que en la descripcion anterior, un usuario suele ser identificado por un solo numero de telefono, el procedimiento de la invencion tambien puede variar para admitir multiples numeros de telefono por contacto. Los diferentes numeros de telefono se tratan como contactos individuales, lo cual tambien es util para comunicarse con el destinatario en el dispositivo deseado (p. ej., telefono del trabajo frente al telefono de casa).

Para confundir todavfa mas la agenda de contactos del cliente, el cliente puede anadir contactos virtuales generados aleatoriamente, es decir, conjuntos de datos respectivos, detras de los cuales no hay una persona ffsica, e incluir los hash respectivos en la solicitud de comparacion. Sin embargo, esto no anade mucho mas al truncamiento de los hash, excepto que esta fuera de la influencia del proveedor de servicios.

Si bien la caracterfstica antes mencionada esta manchada de incertidumbre para el proveedor de servicios en que la coincidencia de un contacto sea efectivamente un contacto real en el telefono del usuario, es posible decir con alta probabilidad si un contacto sospechoso a priori es realmente el contacto de un cliente, despues de ejecutar el procedimiento de la invencion, debido a que es improbable a posteriori que otro contacto del usuario produzca el mismo hash corto.

Para hacer mas probable una coincidencia fortuita, se propone, segun una caracterfstica adicional de la invencion, elegir un parametro u mas grande, es decir, aceptar mas trafico, o hacer que la funcion hash conserve una gran parte de la informacion original, por ejemplo, combinando los primeros dfgitos del numero de telefono (codigo de pafs y area, lo cual es probable que vuelva a aparecer y no incluya informacion privada) con un hash del numero de telefono correspondiente mas corto. Esto amplfa dicho parametro u mas eficazmente.

La presente invencion se puede realizar en hardware, software o una combinacion de hardware y software. Una herramienta segun la presente invencion se puede realizar de manera centralizada en un sistema informatico, o de manera distribuida en la que diferentes elementos se extienden a traves de varios sistemas informaticos interconectados. Es adecuado cualquier tipo de sistema informatico u otro aparato adaptado para llevar a cabo los procedimientos descritos en la presente memoria. Una combinacion tfpica de hardware y software podrfa ser un sistema informatico de proposito general con un programa informatico que, al ser cargado y ejecutado, controla el sistema informatico de manera que lleve a cabo los procedimientos descritos en la presente memoria.

Los recursos de hardware de almacenamiento permanente mencionados en la presente memoria, como las unidades de disco duro, o los dispositivos opticos o magneto-opticos, como los discos compactos o los discos versatiles digitales (DVD), los dispositivos Flash ROM, son en general intercambiables en uso, a menos que se especifique explicitamente de manera diferente. Por lo tanto, para la mayoria de los propositos de almacenamiento, se puede utilizar un dispositivo de almacenamiento permanente, no volatil, como se ha mencionado anteriormente, cuando el sistema informatico en cuestion no tenga una dedicacion especial o relacion con ser utilizado como un sistema de mano o adecuado para un bolsillo. Naturalmente, en ausencia de una unidad de disco duro, se prefiere un dispositivo de almacenamiento FLASH-ROM.

La memoria volatil se utiliza generalmente para almacenar temporalmente programas o datos y, en particular, para cargar programas o submodulos de programas, y para el intercambio inmediato de datos con la unidad central de procesamiento (CPU) de un ordenador.

La presente invencion tambien puede integrarse en un producto de programa informatico que comprende todas las caracteristicas que permiten la implementacion de los procedimientos descritos en la presente memoria, y que, cuando se carga en un sistema informatico, es capaz de ejecutar estos procedimientos.

Medios de programas informaticos o programas informaticos en el contexto presente significan cualquier expresion, en cualquier lenguaje, codigo o notacion, de un conjunto de instrucciones destinadas a hacer que, un sistema que tiene una capacidad de procesamiento de informacion, realice una funcion particular ya sea directamente o despues de uno o ambos de los siguientes aspectos

a) conversion a otro idioma, codigo o notacion;

b) reproduccion en una forma material diferente.

LISTA DE SIGNOS DE REFERENCIA

10 conexion a Internet

12 dispositivo cliente movil

14 ordenador servidor proveedor de servicios

16 repositorio

18 atacante dentro de Internet

20 operador de servidor malicioso

22 numero de telefono del cliente

24 numero de telefono con sal anadida

26 valor hash de 24

28 valor hash reducido de 26

30 hash de tamano medio de 26

210 a 330: etapas del procedimiento de la invencion

Claims

REIVINDICACIONES

1. Un procedimiento para comparar una primera pluralidad de conjuntos de datos privados, como una agenda de contactos privada y almacenada en un dispositivo cliente de comunicacion (12) con una segunda pluralidad de conjuntos de datos, como un gran repositorio de contactos almacenado en un sistema de comunicacion basado en servidor (14), que comprende las etapas de:

a) dicho sistema de servidor que recibe para cada una de dicha primera pluralidad de conjuntos de datos privados un valor hash reducido (28) de dicho cliente, preferiblemente en un canal de transmision cifrado, con una solicitud para comparar dichos conjuntos de datos privados con dicha segunda pluralidad de conjuntos de datos almacenados en dicho servidor, en el que dicho valor hash reducido tiene una longitud s que representa el numero de bits de un valor hash criptografico de una parte unica, preferiblemente un numero de telefono de cada uno de los conjuntos de datos privados que se transmitiran entre el cliente y el servidor, en el que s se elige de manera que se produciran colisiones de hash en dicho sistema de comunicacion basado en servidor (14),

b) dicho servidor compara (240) cada uno de dichos valores hash reducidos y recibidos (28) con dicha segunda pluralidad de conjuntos de datos almacenados en dicho servidor, y encuentra los conjuntos de datos almacenados entre dicha segunda pluralidad de conjuntos de datos que tienen un valor hash reducido identico,

c) dicho servidor enlista (245) cada uno de dichos valores hash encontrados con uno respectivo de dichos valores hash reducidos y recibidos (28),

d) dicho servidor envia (250) dichos valores hash encontrados (28) a dicho dispositivo cliente.

2. El procedimiento segun la reivindicacion 1 en el que

a) para cada comparacion, dicho servidor enlista (245) el valor hash correspondiente en una longitud de bits de m bits, en el que dicha longitud de bits de m bits hace que dichos resultados de la comparacion sean muy probablemente exactos, y

d) dicho servidor envia (250) dichos valores hash (30) con longitud de m bits a dicho dispositivo cliente.

3. El procedimiento segun la reivindicacion 1 en el que dicho servidor comprueba (238) si la longitud s de los hash reducidos es lo suficientemente larga.

4. El procedimiento segun la reivindicacion 1 en el que dichos conjuntos de datos privados son datos de contacto de usuarios almacenados en un dispositivo informatico movil (12).

5. El procedimiento segun la reivindicacion 1 en el que el ordenador servidor (14) determina un valor s que representa el numero de bits de un valor hash criptografico (28) de una parte unica de cada uno de dichos conjuntos de datos privados que se transmitiran al cliente y

transmitir dicho valor s al cliente.

6. El procedimiento segun la reivindicacion 1 en el que dicho ordenador servidor (14) almacena un valor hash reducido precalculado (28) asociado con un conjunto de datos privados respectivos.

7. El procedimiento segun la reivindicacion 1 en el que dicho ordenador servidor (14) calcula y almacena un valor hash mas largo (30) que el recibido, asociado con un conjunto de datos privado respectivo y envia (250) dicho valor hash mas largo de nuevo al cliente para cada conjunto de datos de la comparacion.

8. El procedimiento segun la reivindicacion 1 en el que dicho ordenador servidor (14) vuelve a calcular dichos valores hash (28) en base a un parametro de entrada predeterminado, preferiblemente calculado aleatoriamente.

9. Un procedimiento para comparar una primera pluralidad de conjuntos de datos privados, como una agenda de contactos privada y almacenada en un dispositivo cliente de comunicacion (12) con una segunda pluralidad de conjuntos de datos, como un gran repositorio de contactos almacenado en un sistema de comunicacion basado en servidor (14), que comprende las etapas de:

a) para cada uno de dichos conjuntos de datos privados el dispositivo cliente calcula (225) los valores hash criptograficos,

b) dicho dispositivo cliente reduce (230) dichos valores hash a una longitud de valor hash predeterminada s que representa el numero de bits de una porcion unica de dicho valor hash de cada uno de los conjuntos de datos privados que se transmitiran entre el cliente y el servidor, en el que s es elegido de manera que se produciran colisiones de hash en dicho sistema de comunicacion basado en servidor (14),

c) dicho dispositivo cliente envia para cada uno de dichos conjuntos de datos privados dicho valor hash reducido (28) al servidor, preferiblemente en un canal de transmision cifrado, solicitando que el servidor compare, en base a dicho valor hash reducido, dichos conjuntos de datos privados con dicha segunda pluralidad de conjuntos de datos almacenados en dicho servidor,

d) recibir un valor hash para cada comparacion,

e) el cliente compara (260) los valores hash recibidos con los conjuntos de datos almacenados en el cliente, revelando asi informacion sobre en que conjuntos de datos privados y almacenados tanto en el cliente como en dicho servidor, la porcion unica y respectiva es identica.

10. El procedimiento segun la reivindicacion 9, en el que dicho valor hash recibido de dicho servidor se ha reducido a una pluralidad de m bits por el servidor, en el que dicha longitud de bits de m bits hace que dichos resultados de la comparacion sean muy probablemente exactos.

11. El procedimiento segun la reivindicacion 9 en el que dicho ordenador cliente (12) aplica iterativamente dicho calculo de valor hash de forma repetida y multiple.

12. Un sistema informatico que tiene medios para realizar las etapas de un procedimiento segun una de las reivindicaciones anteriores 1 a 11.

13. Un programa informatico para ejecutar en un sistema de procesamiento de datos basado en servidor (14) e implementado en una red cliente-servidor, la comparacion de una primera pluralidad de conjuntos de datos privados, como una agenda de contactos privada y almacenada en un dispositivo cliente de comunicacion (12) con una segunda pluralidad de conjuntos de datos, como un gran repositorio de contactos almacenado en un sistema de comunicacion basado en servidor (14), que comprende un componente funcional para realizar las etapas respectivas de:

b) dicho sistema de servidor compara (240) cada uno de dichos valores hash reducidos y recibidos (28) con dicha segunda pluralidad de conjuntos de datos almacenados en dicho servidor, y encuentra los conjuntos de datos almacenados entre dicha segunda pluralidad de conjuntos de datos que tienen un valor hash reducido identico, c) dicho sistema de servidor enlista (245) cada uno de dichos valores hash encontrados con uno respectivo de dichos valores hash reducidos y recibidos (28),

d) dicho sistema de servidor envia (250) dichos valores hash encontrados (28) a dicho dispositivo cliente, cuando dicho programa informatico se ejecuta en un ordenador.

14. Un producto de programa informatico basado en servidor almacenado en un medio utilizable por ordenador, implementable en una red cliente-servidor, para comparar una primera pluralidad de conjuntos de datos privados, como una agenda de contactos privado almacenado en un dispositivo cliente de comunicacion (12) con una segunda pluralidad de conjuntos de datos, como un gran repositorio de contactos almacenado en un sistema de comunicacion basado en servidor (14), que comprende medios de programa legibles por ordenador que incluyen un componente funcional para hacer que un ordenador realice las etapas de:

d) dicho sistema de servidor envia (250) dichos valores hash encontrados (28) a dicho dispositivo cliente, cuando dicho producto de programa informatico se ejecuta en un ordenador.

15. Un programa informatico para ejecutar en un sistema de procesamiento de datos basado en cliente (12) e implementado en una red cliente-servidor, la comparacion de una primera pluralidad de conjuntos de datos privados, como una agenda de contactos privada y almacenada en un dispositivo cliente de comunicacion (12) con una segunda pluralidad de conjuntos de datos, como un gran repositorio de contactos almacenado en un sistema de comunicacion basado en servidor (14), que comprende un componente funcional para realizar las etapas respectivas de:

c) dicho dispositivo cliente envia para cada uno de dichos conjuntos de datos privados dicho valor hash reducido (28) al servidor, preferiblemente en un canal de transmision cifrado, solicitando que el servidor compare dichos conjuntos de datos privados con dicha segunda pluralidad de conjuntos de datos almacenados en dicho servidor,

d) dicho dispositivo cliente recibe un valor hash para cada comparacion,

e) el dispositivo cliente compara (260) los valores hash recibidos con los conjuntos de datos almacenados en el cliente, revelando asi informacion sobre en que conjuntos de datos privados y almacenados tanto en el cliente como en dicho servidor, la porcion unica y respectiva es identica,

cuando dicho programa informatico se ejecuta en un ordenador.

16. Un producto de programa informatico cliente almacenado en un medio utilizable por ordenador, implementable en una red cliente-servidor, para comparar una primera pluralidad de conjuntos de datos privados, como una agenda de contactos privada y almacenada en un dispositivo cliente de comunicacion (12) con una segunda pluralidad de conjuntos de datos, como un gran repositorio de contactos almacenado en un sistema de comunicacion basado en servidor (14),

que tiene un componente funcional para ejecutar las etapas de:

c) dicho dispositivo cliente envia, para cada uno de dichos conjuntos de datos privados dicho valor hash reducido (28) al servidor, preferiblemente en un canal de transmision cifrado, que solicita al servidor que compare dichos conjuntos de datos privados con dicha segunda pluralidad de conjuntos de datos almacenados en dicho servidor, d) dicho dispositivo cliente recibe un valor hash para cada comparacion,

cuando dicho producto de programa informatico se ejecuta en un ordenador cliente.