Convalida la chiave utilizzata per crittografare i dati senza inviare la chiave

1

Dati: alcuni dati ( D ) crittografati con la chiave ( K ), che risulta nel carico utile crittografato ( E ). È possibile inviare E (insieme a qualsiasi altra cosa necessaria) a un server da memorizzare e successivamente verificare che K sia stato utilizzato per crittografare i dati originali risultanti in E , senza inviare K in formato testo semplice?

Lo scopo di questo è che un utente che non conosce i dati originali vuole avere accesso ad esso e conosce solo K (gli è stato fornito). Devono mostrare al server che sanno che K è stato utilizzato per crittografare i dati prima che il server restituisca E a questi ultimi per la decrittografia effettiva. Ovviamente l'intero processo non dovrebbe rivelare il testo semplice K al server o essere inviato attraverso la rete. In modo che chiunque guardi la rete o stia seduto sul server non ottiene l'accesso gratuito a K .

Una possibile soluzione che ho trovato è di inviare una versione localmente hash di K con E per l'archiviazione sul server che può essere verificata con un'altra versione localmente con hash di K più tardi. Se i due valori hash di K (quello inviato nella richiesta e quello memorizzato sul server) corrispondono, allora K era corretto per quanto riguarda il server .

Riesci a vedere qualche problema con la soluzione di cui sopra o puoi suggerire un approccio più sicuro?

Modifica: in questo ipotetico sistema, gli utenti sono anonimi, quindi l'autenticazione dell'utente non può far parte della soluzione. Un utente dovrà semplicemente fornire al server una qualche forma di token che mostri di essere a conoscenza di ciò che K è. Se corretto, il server risponderà con E , se non è corretto, non restituirà nulla.

    
posta Speedy 10.01.2017 - 02:29
fonte

3 risposte

1

Questa sembra essere una domanda di autenticazione e autorizzazione, a meno che non mi sbagli. Desideri sia autenticare che autorizzare gli utenti utilizzando un singolo codice / stringa / chiave.

Le chiavi di crittografia sono progettate per essere tenute segrete, vengono chiamate "chiavi segrete" per un motivo. Non vi è alcun motivo per un intermediario (il server) di memorizzare qualsiasi forma di esso. Questo alla fine aumenterebbe la superficie di attacco senza necessità.

Suggerirei di utilizzare due segreti alternativi, in cui gli hash sono memorizzati sul server. Il primo sarebbe dei dati, in modo che solo gli utenti che possono provare la conoscenza dei dati tramite un hash possano essere autorizzati. Il secondo sarebbe il segreto alternativo, tale che se fosse compromesso (come leggere i dati da un file system), l'hacker non avrebbe ancora idea di quale sia il vero segreto.

Questo non solo ha il vantaggio di una maggiore sicurezza (revoca il segreto alternativo) ma aggiunge anche un livello di autorizzazione, in quanto solo quelli autorizzati dovrebbero conoscere l'hash dei dati.

    
risposta data 10.01.2017 - 02:52
fonte
1

Raccomando anche che ci siano due chiavi. La prima chiave (K ') serve per l'autenticazione (stabilire la conoscenza di una chiave). La seconda chiave è utilizzata per la decrittazione di E. Poiché il server non restituisce D e non ha bisogno di conoscere K, il server non ha bisogno di conoscere K.

L'utente presenta K 'al server. Il server conserva una copia hash di K 'per la verifica. In questo modo K non passa mai in rete. Anche se qualcuno ha ottenuto K 'ed E, non possono ancora decrittografare E senza K.

    
risposta data 10.01.2017 - 06:28
fonte
1

Il problema nell'algoritmo è che gli stessi dati verranno scambiati molte volte. Se un utente malintenzionato può ottenere una volta la versione hash della chiave, sarà in grado di inviarlo a volontà e riceverà E.

Almeno, il server dovrebbe inviare una stringa casuale e l'utente dovrebbe restituire la stringa codificata con K (o un hash di esso). In questo modo dovresti essere immune da replay attack a condizione che la stringa casuale utilizzi un generatore casuale crittograficamente sicuro.

Ma in generale, una chiave simmetrica dovrebbe essere un segreto, e un segreto condiviso tra più di due persone non è più segreto. Forse potresti dare un'occhiata a crittografia a chiave pubblica che viene utilizzata ad esempio nelle e-mail crittografate:

  • i dati sono crittografati con una chiave casuale
  • la chiave è crittografata con le chiavi pubbliche di tutti i destinatari
  • il carico utile è i dati criptati con tutte le versioni crittografate della chiave

In questo modo, la chiave segreta viene utilizzata solo una volta: anche se è stata compromessa, non verrà mai riutilizzata e solo le persone che dispongono delle chiavi private possono decodificare il messaggio

    
risposta data 10.01.2017 - 08:35
fonte

Leggi altre domande sui tag