I want to be able to add, remove, and update: the users (especially their passwords/key-encrypting-keys), the groups, the data-encrypting keys, and the data.
Penso che si possa ottenere l'indipendenza necessaria tra le entità usando una combinazione di crittografia asimmetrica e simmetrica. I requisiti di archiviazione dei dati sono piuttosto alti, ma è necessario proteggere solo pochi dati.
Puoi avere:
User Public Key Private Key
lserni PUB XXXXXXX
Group Group Encryption Key
poponi ZZZZZZZ symmetrically encrypted with YYYY
ZZZZZZ è la chiave crittografica utilizzata per crittografare simmetricamente i dati del gruppo poponi; questo valore è simmetricamente crittografato con la chiave crittografica YYYY, che è la "password di gruppo".
Mapping
lserni poponi YYYY encrypted with lserni's public key
Quando crei un gruppo e assegni ad esso un amministratore, viene generata una chiave di crittografia simmetrica casuale ZZZZZZ che viene utilizzata per crittografare i dati di quel gruppo. Questo valore non viene memorizzato in chiaro, ma crittografato con un'altra password casuale YYYY, che verrà associata agli utenti.
Questo disaccoppiamento di YYYY e ZZZZZZ consente di rendere inaccessibili i dati semplicemente cambiando YYYY (che interessa solo una colonna) invece di dover modificare ZZZZZZ (che richiede la decrittazione e la reencryption di qualunque dato il gruppo abbia). Naturalmente, se i dati crittografati non sono molto più di una singola colonna del database, c'è poco da guadagnare da questo secondo livello di riferimento indiretto, e si può eliminare del tutto YYYY e memorizzare la crittografia di ZZZZZZZ nella mappatura dell'utente tabella invece della crittografia di YYYY.
Ogni utente ha anche una coppia di chiavi pubblica / privata assegnata, con la chiave privata crittografata simmetricamente con la password dell'utente.
Ciò consente a terzi (amministratori di gruppo, ecc.) di fornire a qualsiasi utente un'informazione, YYYY, che solo lui sarà in grado di rileggere.
Quando l'utente effettua il login, decrittografa la sua chiave privata usando la sua password, usa la chiave privata per accedere al valore YYYY per la password del gruppo e recupera ZZZZZZZ. Ora può leggere e scrivere il gruppo (e dimenticare del tutto YYYY).
La cancellazione di utenti e gruppi è semplice. Tranne che un gruppo senza utenti è perso per sempre e potrebbe anche essere eliminato. Per questo motivo, la cancellazione dell'utente dovrebbe garantire che almeno un utente amministrativo sia sempre presente.
Anche l'aggiunta di utenti semplici è semplice (generiamo la coppia di chiavi e la memorizziamo, la chiave privata crittografata con la password temporanea utilizzata per il primo accesso). A questo punto l'utente non è assegnato a nessun gruppo, quindi non è richiesto altro.
Quando l'utente cambia la sua password, la sua chiave privata viene decifrata con la vecchia password e reencriptata con la nuova password.
Per assegnare un utente a un gruppo, la password del gruppo deve essere conosciuta dall'applicazione, che richiede l'accesso di un utente con accesso di gruppo. Questo utente può creare una linea di mappatura poiché la chiave pubblica dell'assegnatario è in chiaro .
Quando la password del gruppo viene cambiata, tutti gli utenti di quel gruppo ottengono i loro dati aggiornati, e questo può essere fatto senza conoscere la password dell'utente. L'operazione è eseguita da qualcuno che ha accesso al gruppo, quindi ha la password del gruppo.
user group pwd_of_group_encrypted_with_user_privkey
lserni poponi *****
Per reencriptare i dati del gruppo, tutti i dati devono essere decifrati con la vecchia chiave e reencrittati con la nuova chiave, e la riga di informazioni sul gruppo deve essere aggiornata. La password di gruppo, con cui è stata crittografata la vecchia chiave, viene utilizzata per crittografare la nuova chiave e memorizzarla nella riga di informazioni del gruppo.
Questa operazione non dovrebbe mai essere necessaria poiché la chiave di crittografia di gruppo ZZZZZZZ non viene mai divulgata all'esterno (né la password del gruppo YYYY).
Questa architettura garantisce anche che qualcuno senza accesso a un gruppo non possa mai aggiungere nessun altro (o se stesso) a detto gruppo. Se un utente riesce a rubare l'intero database, sarà comunque in grado di ottenere solo i dati a cui aveva diritto.
Chi assegna un utente a un gruppo?
Per assegnare un utente a un gruppo, è necessario avere accesso al gruppo, il che significa conoscere la password. Se c'è un amministratore di gruppo che decide chi appartiene a quale gruppo, va bene.
Ma cosa succede se un utente deve essere assegnato automaticamente al gruppo committer ? Quindi l'applicazione deve avere accesso alla password, il che significa che il sistema non può essere autonomo e sicuro.
Possiamo avere che non è autonomo, memorizzando la password in un sistema diverso con accesso limitato e una superficie di attacco molto piccola. Anche se qualcuno ha rubato il database, la password del gruppo non sarebbe lì.
Non penso che il problema possa essere risolto, perché chiunque possa concedere l'accesso a un gruppo può farlo in tutte le circostanze; se il "chiunque" risiede nel sistema, poiché è l'applicazione stessa, catturare il sistema richiederà l'accesso ai dati di tutti i gruppi.