Crittografia DB bidirezionale sicura anche dall'amministratore

Question

Ho un interessante problema di crittografia. Non so se può essere risolto ma ecco qui:

Un database deve contenere informazioni utente sensibili. In quanto tale, le informazioni dell'utente devono essere crittografate (crittografia bidirezionale). L'utente ha un login/password e questi possono essere utilizzati nella crittografia a due vie. Ora, la crittografia deve essere progettata in modo tale che anche l'amministratore che visualizza le tabelle del database non dovrebbe essere in grado di dare un senso alle informazioni dell'utente.

Tuttavia, il design deve prendersi cura dei casi in cui l'utente può dimenticare la sua password. Se la password viene utilizzata per la crittografia, dimenticando la password significa che l'informazione è persa - non voluta. Se la password utente è memorizzata nel database utilizzando un algoritmo a due vie (invece di un hash unidirezionale) con una chiave codificata nello script, l'amministratore può scoprire la chiave codificata guardando lo script (l'amministratore ha ovviamente accesso alla sceneggiatura).

Qualcuno conosce una via d'uscita?

PS: questo è un vero problema. La mia azienda è un fanatico della sicurezza assoluta (ISO 27001 e tutti) e mi è stato affidato il compito di progettare un sistema con le funzionalità sopra menzionate. A proposito, sto usando uno script PHP e MySQL.

EDIT: Forse non era chiaro in precedenza, l'utente ha bisogno di vedere/modificare queste informazioni utente su base giornaliera.

Answer 1

Quello che vuoi è un agente di recupero. Criptare tutti i dati due volte: una volta con la chiave utente, una volta con la chiave dell'agente di recupero (pubblico); almeno quest'ultimo deve essere asimmetrico. Mantieni la chiave dell'agente di recupero in una sicurezza pirata, con un protocollo di accesso formale (ad esempio il principio dei quattro occhi). Di solito, l'amministratore non può accedere ai dati crittografati, ma se l'utente perde la chiave e il recupero è autorizzato, viene ottenuta la chiave di ripristino.

Esistono anche modi per crittografare la chiave dell'agente di recupero in modo che gli utenti di m-out-of-n debbano accettare di utilizzarlo.

Modifica: Una strategia di implementazione consiste nel criptare tutto due volte. In alternativa, per ogni set di dati che deve essere recuperabile in modo indipendente, creare una nuova chiave simmetrica e crittografare solo quella chiave due volte; i dati originali vengono crittografati solo con la chiave di sessione.Tale approccio può estendersi a più lettori indipendenti; richiede chiavi asimmetriche per lettore (in modo che è possibile crittografare la chiave di sessione con le chiavi pubbliche di tutti i lettori - una è l'agente di recupero).

Ho copiato la terminologia da Microsoft Encrypting File System, che ha implementato tale schema.

Answer 2

Impossibile eseguire.

In tutti i casi, qualcuno deve essere in grado di ricreare la chiave per decodificarlo. Consideriamo le opzioni:

1. Chiave memorizzata sul server. Fallisce: l'amministratore ha accesso.
2. Chiave crittografata con la password dell'utente. Fallisce: l'utente potrebbe dimenticarlo.

La soluzione è di rilassare l'amministratore che dispone di restrizioni di accesso, e invece di impossibile, lo rende solo molto difficile. Ad esempio, se i dati sono stati crittografati con una chiave memorizzata crittografata con la password dell'utente, ma quella chiave è stata affidata a un altro sistema a cui non è possibile accedere nel normale corso degli eventi dall'amministratore (forse solo un altro amministratore ha accesso?) quindi è ancora possibile recuperare da un utente che dimentica la propria password (con l'intervento di chiunque abbia accesso alle chiavi depositate), ma l'amministratore non può semplicemente scaricare il database e leggere tutti i dati.