Pasando datos entre 3 partes con cifrado de clave pública

0

Hay tres partes involucradas en un proceso repetido de transferencia de datos: Cliente C, Broker B y Proveedor P. Puede haber múltiples clientes C.

El agente B gestiona la base de datos de clientes de P. Cada cliente tiene un número de identificación nacional único.

El cliente C puede enviar solicitudes para recuperar información de un ID de cliente de la base de datos de clientes de P (que B gestiona).

El requisito es: B no debe conocer los ID de los clientes, incluso si B las solicitudes de información de la base de datos P y de C.

En otras palabras:

  1. P puede compartir datos con el Broker B sin revelar ID de clientes (por ejemplo, cifrar la ID de cliente con una clave pública).

  2. C puede consultar los datos de P que B administra, mediante el envío de la identificación del cliente cifrada a B.

  3. B puede hacer coincidir la identificación cifrada de C con la clave cifrada de P para ubicar un registro de consumidor.

  4. B no puede atacar con fuerza bruta el cifrado para obtener información sobre las ID de los verdaderos clientes.

Planeamos asignar a P una clave pública. P usa esta clave para cifrar las ID de los clientes de los datos que B administra. C usa esta clave para cifrar las ID de los clientes que deben ser consultas.

El número de ID de clientes únicos es de ~ 10 mil millones de números. Por lo tanto, es bastante rápido atacar por fuerza bruta a esta lista de 10 mil millones de números.

Mi pregunta es: ¿Existe una solución determinista de clave pública que satisfaga (1), (2), (3) y (4).

    
pregunta AdamNYC 07.06.2015 - 18:45
fuente

1 respuesta

2

Si no es necesario que pueda descifrar el ID de cliente, creo que puede usar un HMAC . Usted crea un secreto compartido entre C y P. Este debe ser un secreto compartido largo y agradable. Cuando va a almacenar un ID de cliente, almacena HMAC(SECRET, CustomerID) . Cuando C quiere buscar un registro, realiza el HMAC y le pasa el resultado a B, que puede hacer la búsqueda de DB.

Estás protegido de los ataques previos al cómputo porque has usado un secreto compartido muy largo (digamos 1024 bits pero menos puede ser seguro, otros pueden ayudarte)

Del mismo modo, el largo secreto te protege de los ataques de fuerza bruta.

Creo que esto satisface de forma segura (1), (2), (3) y (4). Por supuesto, si necesita poder retroceder desde el ID de hash al ID real, esto no funciona. Sé que no especificas ese requisito en tu pregunta, pero quizás asumiste que era obvio.

    
respondido por el Neil Smithline 08.06.2015 - 00:14
fuente

Lea otras preguntas en las etiquetas