Trasmissione dei dati tra 3 parti con crittografia a chiave pubblica

0

Ci sono tre parti coinvolte in un processo di trasferimento dati ripetuto: Client C, Broker B e Provider P. Potrebbero esserci più client C.

Il broker B gestisce il database dei clienti di P. Ogni cliente ha un numero ID univoco.

Il cliente C può inviare richieste per recuperare le informazioni di un ID cliente dal database clienti di P (che B gestisce).

Il requisito è: B non deve conoscere gli ID cliente, anche se le richieste di informazioni e del database P di B gestiscono da C.

In altre parole:

  1. P può condividere i dati con il broker B senza rivelare gli ID cliente (ad es., codificare l'ID cliente con una chiave pubblica).

  2. C può interrogare i dati di P che B gestisce, inviando l'ID cliente crittografato a B.

  3. B può abbinare l'ID criptato di C alla chiave crittografata di P per individuare un record di consumatore.

  4. B non può eseguire brute-force attaccare la crittografia per conoscere i veri ID cliente.

Abbiamo in programma di assegnare a P una chiave pubblica. P utilizza questa chiave per crittografare gli ID cliente dei dati che B gestisce. C utilizza questa chiave per crittografare gli ID cliente che devono essere richiesti.

Il numero di ID cliente univoci è di circa 10 miliardi di numeri. Pertanto, è abbastanza veloce per attacco a forza bruta questo elenco di 10 miliardi di numeri.

La mia domanda è: esiste una soluzione deterministica a chiave pubblica che soddisfi (1), (2), (3) e (4).

    
posta AdamNYC 07.06.2015 - 18:45
fonte

1 risposta

2

Se non è necessario decifrare l'ID cliente, credo che sia possibile utilizzare un HMAC . Crei un segreto condiviso tra C e P. Questo dovrebbe essere un lungo e condiviso segreto condiviso. Quando vai a memorizzare un ID cliente, memorizzi HMAC(SECRET, CustomerID) . Quando C vuole cercare un record, esegue l'HMAC e passa il risultato a B che può fare la ricerca DB.

Sei protetto dagli attacchi di pre-computazione perché hai usato un segreto condiviso molto lungo (diciamo 1024 bit ma meno può essere sicuro - altri forse possono aiutarti)

Allo stesso modo, il lungo segreto ti protegge dagli attacchi di forza bruta.

Credo che questo soddisfi in modo sicuro (1), (2), (3) e (4). Ovviamente, se è necessario essere in grado di tornare indietro dall'ID con hash all'ID effettivo, questo non funziona. So che non specifichi questo requisito nella tua domanda, ma forse hai dato per scontato che fosse ovvio.

    
risposta data 08.06.2015 - 00:14
fonte

Leggi altre domande sui tag