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:
-
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.
-
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).