Strategia per API pubbliche / private, dati crittografati (o tratteggiati) e compromissione del server

3

In questo scenario semplicistico ma realistico, ho 2 server web / database combo (A) dietro un bilanciatore del carico e un singolo indirizzo IP. Permettono anche l'accesso solo da un indirizzo IP - il client (B) . Su ciascun server di database, è necessario memorizzare informazioni sull'identità segreta di sola lettura (come indirizzo email, nome utente, ecc.) .

Ho bisogno di una soluzione che impedisca a un hacker che può avere un server compromesso (A) di essere in grado di fare qualsiasi cosa con i dati a meno che non ottenga l'accesso al server (B).

Ho bisogno di una strategia in cui il client server (B) utilizza una chiave pubblica da una coppia di chiavi API privata / pubblica per trovare una corrispondenza per queste informazioni di identità (come un indirizzo di posta elettronica) sul server (A), e quindi, senza server (A) valutando quel risultato, riporta il risultato a (B) per la valutazione usando la sua chiave privata. La teoria è che se l'hacker ottiene l'accesso a livello root al server (A), non può fare nulla con esso per decodificare i dati, nemmeno con attacchi a forza bruta su md5 (), sha1 (), sha256 () o contro qualsiasi algoritmo di hashing.

Ecco una strategia che non funzionerà, ad esempio. Immagina di avere una libsodium di PHP (un sistema a chiave pubblica / privata comune). Lo usi per crittografare i dati e memorizzarli su (A). Quindi, quando (B) vuole effettuare una ricerca, inviano la chiave pubblica, viene accoppiato con la chiave privata su (A), viene generato un hash e tale hash viene confrontato con un hash nel database. (Quindi, si trova se la richiesta di posta elettronica con hash corrisponde a un indirizzo email con hash nel database.) Il problema con questa strategia è che se il server (A) è compromesso per l'accesso a livello root, tutto ciò che l'utente malintenzionato deve fare è intercettare il traffico web per trovare la chiave pubblica da (B), combinarla con la chiave privata da (A) negli script del server PHP e quindi utilizzare tali informazioni per eseguire un potente script di forza bruta per interrompere l'hash in modo che l'intero database possa essere decifrati. Questo attacco a forza bruta è stato usato per rompere md5 () e sha1 (), ma può essere usato per rompere anche sha256 di qualcuno o altra API di hash.

Giusto, quindi non funzionerà. Sarebbe meglio se ci fosse un modo in cui il risultato della partita non può essere interpretato sul server (A) e deve essere inviato al server (B) per la valutazione finale, che richiede quindi la chiave privata del server (B) per decrittografare il risultato.

Utilizzando PHP , puoi spiegare una strategia chiave dell'API del programmatore in cui un archivio dati compromesso non fornirà informazioni utili a un hacker a meno che non abbia la chiave privata della coppia di chiavi pubblica / privata del programmatore?

    
posta Volomike 12.01.2016 - 21:39
fonte

1 risposta

4

Come ho detto in un commento, farei tutto il criptaggio / decrittografia su (B) e lasciare (A) non fare altro che memorizzare i dati.

Ad esempio:

Questo succede su (B)

string encryptedKey = encrypt('John Smith');
string encryptedData = encrypt('121 Main Street');

(B) invia le 2 stringhe crittografate a (A).

(A) memorizza le 2 stringhe crittografate in un database di chiavi / valori.

Successivamente, (B) può richiedere i dati inviando un messaggio a (A) send me the value associated with the key "xxx" dove xxx è l'output della chiamata encrypt('John Smith') .

(A) non ha alcuna conoscenza della crittografia. (A) inoltre non sa cosa viene memorizzato - solo una "stringa opaca" per la chiave e un'altra "stringa opaca" per il valore.

(B) può usare la crittografia simmetrica se lo si desidera - non importa.

    
risposta data 13.01.2016 - 22:55
fonte

Leggi altre domande sui tag