È sicuro memorizzare una sola chiave simmetrica cifrata con diverse chiavi pubbliche RSA diverse?

8

Per la crittografia basata su campo di un database contenente informazioni sensibili, stavo pensando al seguente progetto:

  • Ogni utente ha una smartcard utilizzata per l'accesso al certificato del cliente.
  • Dopo l'accesso l'utente ottiene la chiave simmetrica (ad esempio AES) crittografata con la chiave pubblica della sua smartcard.
  • L'utente decrittografa la chiave e la utilizza per crittografare / decrittografare qualsiasi dato sensibile sul client.

Nel database c'è una tabella contenente tutte le chiavi pubbliche delle smartcard utente e la chiave simmetrica globale crittografata con la chiave pubblica di ciascun utente. Il resto dei dati sensibili è crittografato con la chiave simmetrica.

I dati sono sicuri se il database viene compromesso?

Un'altra possibile soluzione potrebbe essere quella di memorizzare in aggiunta la stessa chiave RSA globale su tutte le smartcard e utilizzare questa chiave con RSA-KEM per crittografare tutti i dati sensibili. Lo svantaggio sarebbe che questo rende più difficile cambiare la chiave globale nella configurazione di produzione poiché tutte le smardcard dovrebbero essere sostituite / riprogrammate.

Che ne pensi?

    
posta st_dx 27.02.2012 - 13:20
fonte

3 risposte

6

Memorizzare la stessa chiave simmetrica crittografata in più modi non è un problema, ma utilizzare la stessa chiave per ogni client, a meno che non si abbia un grado insolitamente alto di fiducia tra i client, in quanto consente ai client di decrittografare la reciproca comunicazione con server.

Sarebbe più sicuro generare una nuova chiave simmetrica per ogni sessione, che viene quindi crittografata utilizzando la chiave asimmetrica dei client e archiviata per la durata della sessione.

    
risposta data 27.02.2012 - 18:48
fonte
5

Un segreto condiviso da più di due persone non è più un segreto.

Crittografare i dati con una chiave simmetrica K e quindi crittografare K con la chiave asimmetrica (RSA) di ciascun destinatario, significa dare accesso al destinatario a tutti i dati crittografati con K ; "tutti i dati" include ciò che sarà crittografato con K . Questo metodo di crittografia è la normale situazione per le e-mail sicure (ad esempio con OpenPGP ), ma un punto cruciale è che una e-mail è " one shot "e ogni e-mail è crittografata con il proprio K specifico, casuale

Con un database , le cose sono più complicate, perché un database è un insieme di dati che evolve nel tempo. Fornendo K a ciascun utente, è possibile consentire loro di leggere il contenuto del database non solo in questo momento, ma anche i contenuti futuri che verranno aggiunti in seguito. Questo non è necessariamente un problema: finché un determinato utente ha accesso a un database, può (almeno teoricamente) scaricare tutti i dati in un file a sé stante, e non c'è modo di farlo "dimenticare" i dati . Tuttavia, a lungo termine, questo richiede aggiornamenti chiave.

Ad esempio, supponiamo che, a un certo punto, vuoi concedere l'accesso al database a un nuovo utente. Questo è semplice: basta crittografare K con la chiave RSA di quel nuovo utente. La doppia operazione di rimozione di un utente è più complessa. Poiché non puoi costringere gli utenti a dimenticare i dati, il meglio che puoi ottenere è negare l'accesso a nuovi dati (dati che vengono aggiunti dopo la rimozione dell'utente), e questo implica scegliere un nuovo K ' distinto da K (e K ' non deve essere computabile da K , quindi stiamo parlando di selezionare un nuovo casuale > K ' da zero). Quindi ci sono due scelte:

  1. Imposta il tuo formato di database in modo che ogni record possa essere taggato con un identificatore per il tasto K che viene usato per quel record. Ogni aggiornamento di chiave implica la creazione di un nuovo K con un nuovo identificatore e l'utilizzo di tale nuovo identificativo in ogni record appena aggiunto o modificato. Viene mantenuto un repository per tutto il K crittografato (indicizzato dall'identificatore e dall'utente). Al momento dell'utilizzo, ciascun utente accede al repository utilizzando il tag sul record di destinazione, in modo da ottenere la chiave K che deve essere utilizzata per decrittografare il record.

  2. Quando la chiave viene aggiornata, tutti i dati nel database vengono decodificati con il vecchio K e reencrittati con il nuovo K . Viene mantenuto un repository per la versione crittografata di ciascun K (indicizzato dall'utente).

Il secondo metodo semplifica l'archiviazione e offre il vantaggio di "eliminare" gli utenti rimossi (nel modello di attacco, supponiamo che un utente rimosso si sia preso cura di copiare tutti i dati che poteva, ma se non , poi buttarlo fuori esplicitamente cis bello). Tuttavia, gli aggiornamenti chiave con il secondo metodo possono essere piuttosto costosi, a seconda della loro frequenza e delle dimensioni del database. Il primo metodo è più generico e consente il controllo dell'accesso a grana fine (ad esempio rendendo i dati accessibili ad alcuni sottoinsiemi di utenti).

Microsoft SQL Server ha molte funzioni di supporto (come il livello di linguaggio SQL) a implementare tali cose (tuttavia, si avvisa che la documentazione Microsoft sugli elementi crittografici ha una fastidiosa tendenza a ridefinire la terminologia, a volte improvvisamente nel mezzo della documentazione stessa).

    
risposta data 15.09.2012 - 18:56
fonte
1

La mia comprensione è che OpenPGP e molti altri crittosistemi fanno esattamente questo - memorizzano un'unica chiave simmetrica in molti luoghi, ogni luogo crittografato con una chiave pubblica diversa. Ogni persona utilizza la propria chiave privata univoca per estrarre la chiave simmetrica monouso e quindi utilizza la chiave simmetrica per decodificare altre cose.

" "

" Dimensione del file GPG con più destinatari? "

" link "

" "

Tuttavia, questi sistemi presumono che sia OK se chiunque che estrae quella chiave simmetrica può leggere tutto crittografato con quella chiave.

Non sembra essere il caso della tua situazione, quindi sono d'accordo con JGWeissman: generare una nuova chiave simmetrica fresca per ogni sessione, che viene quindi crittografata utilizzando la chiave pubblica della smartcard dell'utente e inviata all'utente. Memorizza la nuova chiave simmetrica su entrambe le estremità solo per la durata della sessione.

Non mi è chiaro se questi "dati sensibili" siano solo alcuni file condivisi, ognuno dei quali dovrebbe essere in grado di leggere molti ma non tutti gli utenti; o se questi "dati sensibili" sono uno o più campi nel tuo database, ognuno dei quali dovrebbe essere in grado di leggere solo l'utente (e forse una o due altre persone).

Supponendo che si tratti di dati per utente non condivisi che sono effettivamente campi nel database, ogni volta che quei campi sono cambiati vorrei

  • crea una nuova chiave simmetrica nuova
  • crittografare la nuova versione dei dati di quel campo (i) con la nuova chiave simmetrica. (Idealmente, preferiremmo fare questa crittografia alla fine dell'utente, quindi il server di database non vede mai i dati in chiaro o la chiave simmetrica).
  • memorizza i dati crittografati nella colonna "dati crittografati" del database nella riga dell'utente
  • crittografa la nuova chiave simmetrica con la chiave pubblica dell'utente e memorizza quella chiave crittografata nel database nella riga dell'utente
  • (facoltativo) crittografare la nuova chiave simmetrica con la chiave pubblica dell'altra persona autorizzata a leggere tali dati e archiviare quella chiave crittografata in un'altra colonna nella riga di quell'utente.
  • distrugge tutte le copie in testo normale della nuova chiave simmetrica
risposta data 18.06.2012 - 23:43
fonte

Leggi altre domande sui tag