Crypto asimmetrico: decripta i propri messaggi senza avere la chiave privata

OpenPGP

Il modo standard di gestirlo è archiviare i messaggi crittografati nel formato standard OpenPGP . C'è qualche ragione per non usare una libreria pronta all'uso che implementa RFC 4880 e RFC 3156 ?

(Esistono molte discussioni pratiche su OpenPGP su questo sito di sicurezza IT e discussioni più teoriche su OpenPGP nel sito Cryptography StackExchange ).

Il messaggio crittografato in formato OpenPGP può essere archiviato come un file, un BLOB SQL, ecc.

informazioni

OpenPGP funziona esattamente come spiegato fin1te (per quanto posso dire, openssl_seal () funziona esattamente allo stesso modo):

• Per ogni messaggio, il sistema genera una nuova, casuale chiave di sessione che nessun altro potrebbe indovinare. Dopo aver memorizzato il messaggio BLOB completo cifrato, il sistema dimentica immediatamente quella chiave.
• Il testo in chiaro del messaggio viene crittografato con quella chiave di sessione e memorizzato nel pacchetto di dati crittografato simmetricamente all'interno del BLOB.
• Diversi pacchetti di chiavi di sessione crittografate sono memorizzati all'interno del BLOB, ognuno dei quali contiene un'altra copia identica della chiave di sessione per questo messaggio, ognuno crittografato con una chiave pubblica diversa. In questo caso, una copia viene crittografata con la chiave pubblica del mittente e un'altra copia viene crittografata con la chiave pubblica dell'amministratore.

Quando qualcuno (l'utente o l'amministratore di sistema) desidera leggere un messaggio crittografato, quella persona dà il messaggio crittografato e la sua passphrase a un pezzo di software che la decrittografa e le mostra il testo in chiaro. Tipicamente quel software:

• Alimenta la passphrase in una funzione di derivazione della chiave. Il software utilizza la chiave risultante per decodificare un file keyring per ottenere la chiave privata dell'utente e la relativa chiave pubblica corrispondente. (In alternativa, suppongo che si possa usare una funzione di derivazione della chiave direttamente genera una chiave privata da una passphrase , quindi genera la chiave pubblica da quella chiave privata).
• cerca tutti i pacchetti di chiavi di sessione crittografati all'interno del BLOB finché non ne trova uno con una chiave pubblica corrispondente.
• Utilizza la chiave privata per decrittografare la chiave di sessione. Quindi utilizza la chiave di sessione per decrittografare il messaggio in chiaro.

Finché si evita di inviare la password su HTTP o altri protocolli in chiaro, questo sembra sicuro contro gli attacchi passivi (guardando ciò che succede sul filo, leggendo i nastri di backup del server, incluse tutte le chiavi pubbliche e il portachiavi crittografato dell'amministratore).

EDIT:

where should I save encrypted keypair?

Questa è una domanda eccellente, degna di una pagina di domande / risposte completamente nuova.

In un mondo ideale, assegneresti a ciascun utente un token di sicurezza che, una volta acceso, generava una nuova coppia di chiavi e ti dava la chiave pubblica, ma la chiave privata non avrebbe mai lasciato il token.

Nel nostro mondo tutt'altro che ideale, molte persone usano Gnome Keyring o qualche software simile per archiviare la coppia di chiavi criptata sul proprio laptop o smartphone personale, come discusso a "formati standard di archiviazione delle chiavi private?" .

Sospetto che preferiresti un sistema in cui non devi acquistare un certo numero di token di sicurezza e in cui gli utenti potrebbero comunque accedere ai propri file sul server anche se il loro smartphone è stato accidentalmente perso, danneggiato o distrutto in alcuni altro modo. Questo praticamente ti costringe a memorizzare un keyring crittografato sul server - "Questo modello di crittografia lato client è sicuro?" discute alcune delle implicazioni.

Se crittografate il messaggio utilizzando un algoritmo simmetrico (AES), memorizzate questa chiave due volte, una volta crittografata con la chiave pubblica admins e l'altra con la chiave pubblica dell'utente.

In questo modo quando l'amministratore vuole visualizzare il messaggio, decrittografa la prima chiave e l'utente utilizza la seconda.

Penso che una domanda migliore sia: "Che problema stai cercando di risolvere usando questa crittografia?"

In pratica, la crittografia a chiave pubblica viene utilizzata su canali non sicuri per garantire sia l'integrità dei dati che la non ripudiabilità (il messaggio è intatto, invariato e proviene da chi ha affermato di essere venuto). È plausibile che l'unica ragione per cui posso pensare che tu stia criptando le informazioni prima che entri nel database è perché il database stesso è il mezzo insicuro - per cui direi sicuro il mezzo prima che tu ti assicuri i dati.

Sebbene tu abbia assolutamente intenzione di proteggere queste informazioni usando la chiave pubblica, allora adotterei un approccio simile a quello che @ fin1te ha trovato. Cripta il messaggio in due punti, una volta (nella casella di posta dell'amministratore) utilizzando la chiave pubblica dell'amministratore, in modo che solo l'amministratore possa leggerlo; e una seconda volta (nella casella Invia dell'utente) simmetricamente utilizzando la password dell'utente come chiave AES (o consentendo all'utente di scegliere una password di crittografia separata). In questo modo l'utente ha ancora accesso mentre garantisce che solo l'amministratore abbia accesso a quelli a lui inviati.

L'unica avvertenza di cui sarei a conoscenza è che se l'utente cambia la password, dovrai percorrere tutti i messaggi inviati e ricodificarli con la nuova password.

EDIT: Non vedo alcun difetto matematico nell'algoritmo proposto sopra a cui non si è già parlato in la domanda di riferimento , una cosa da notare però, che PHP OpenSSL_Seal genera una chiave simmetrica casuale e crittografa che utilizzando le coppie di chiavi pubbliche fornite. Dovrai memorizzare anche quella chiave nel database per poter invertire la procedura.

Il tuo processo inverso sarà simile a:

1. L'utente fornisce la password estesa come seme a PRNG
2. Utilizza PRNG per "seed" per generare chiavi private
3. Decifra la chiave simmetrica memorizzata utilizzando la chiave privata derivata
4. Decifra i messaggi utilizzando la chiave asimmetrica decrittografata.

Tutto sommato sembra un bel po 'di lavoro e dispendioso dal punto di vista computazionale se lo fai su ogni aggiornamento di pagina , solo per leggere alcuni messaggi inviati.

Poiché openssl_seal utilizza comunque le chiavi simmetriche, perché non cortocircuitare e utilizzare la password dell'utente?

Suppongo che tu stia facendo come @Sean Madden descrive nei passaggi precedenti - che ci sono due copie dei dati memorizzati - 1 copia crittografata con la chiave privata dell'amministratore e 1 copia crittografata con la chiave privata dell'utente generata da la sua password di crittografia.

Sì, dovrebbe funzionare.

In termini di confronto, i compromessi sarebbero:

• non si memorizza il segreto critico (la chiave privata) sul sistema operativo in questo modo. Se l'hacking della memoria persistente è la tua principale preoccupazione, allora questo lo risolve.

• con la crittografia asimmetrica, è probabile che si aggiunga un fattore temporale alla decrittografia, sia per l'amministratore che per l'utente. La crittografia / decrittografia asimmetrica è un costo della CPU più elevato rispetto a quello simmetrico e può avere molto a che fare con il modo in cui il tuo motore è implementato. Aspettatevi qui alcuni dolori in crescita: dove e come eseguite il calcolo avrà un grande impatto sulla soddisfazione dell'utente.

• in entrambi i casi - senza hardware spiffy, le tue chiavi private saranno gestite dal sistema operativo durante il processo di crittografia. Diventa più difficile hackerare quando non sono archiviati in un file da qualche parte nel sistema operativo, ma nulla è impossibile - questo dipende strongmente dalla natura della minaccia che stai cercando di proteggere.

• Quanto sei sicuro che gli utenti possano ricordare le loro password in modo conforme alla sicurezza? Se stanno registrando le password ai loro schermi, si ha un altro tipo di rischio. Con il sistema che descrivi, un utente ha libero accesso a tutta la posta inviata nella sua cartella se dimentica la sua password. Se gli offri un meccanismo di recupero password, devi proteggerlo più pesantemente di quanto hai protetto le chiavi simmetriche originali. Ogni volta che aggreghi i segreti di sicurezza in un posto, crei un obiettivo di valore più alto per gli autori di attacchi e devi proteggerli di conseguenza.