Idee sbagliate relative a KEK e DEK
Il KEK non è pensato per essere archiviato, solo l'eDEK (DEK crittografato) lo è. KEK viene immesso una sola volta e viene utilizzato per decodificare l'eDEK. Il DEK viene quindi tenuto in memoria da qualunque processo lo richieda, in quanto è fondamentalmente necessario che una chiave sia presente in memoria per poter essere utilizzata per la decodifica. Il KEK dovrebbe essere tenuto in memoria solo per il tempo sufficiente a decodificare l'eDEK, quindi dovrebbe essere sovrascritto (per evitare che si fermi nella memoria liberata). Poiché la gestione delle chiavi in memoria può essere difficile, con molti modi per rovinare le cose, io consiglio vivamente di utilizzare il software esistente progettato per questo scopo. Se non sai come e perché dovresti bloccare la memoria che manterrà il materiale chiave oppure su come garantire che le chiamate di memset non siano ottimizzato durante la cancellazione del materiale chiave dalla memoria, non dovresti implementare i crittosistemi da solo. Utilizzare una soluzione esistente o, per lo meno, una libreria crittografica di fascia alta e di facile utilizzo.
Memoria condivisa
Per quanto riguarda la tua affermazione sulla memoria condivisa, ciò dipende da cosa intendi per memoria condivisa. memoria condivisa POSIX (shmem) è un metodo di archiviazione di oggetti in memoria che qualsiasi processo con le autorizzazioni appropriate possono accedere. È simile alla tua idea di memorizzare i dati in tmpfs, tranne che la memoria condivisa POSIX utilizza un'API speciale per accedere agli oggetti. In tal caso, la memorizzazione di qualcosa di sensibile per un determinato utente nella memoria condivisa potrebbe non essere una buona idea.
L'altra definizione di memoria condivisa è la memoria presente nello spazio degli indirizzi di più di un processo. Un processo deve scegliere di condividere una determinata area di memoria con un altro processo, passando il MAP_SHARED flag su mmap quando si richiede memoria dal kernel. Di solito questo viene fatto da un processo genitore che poi si biforca in due processi che condividono una specifica regione di memoria. In questo caso, la memoria è condivisa solo da processi che lo consentono esplicitamente.
Modellazione delle minacce
È necessario definire il modello di minaccia. Da chi stai proteggendo questi dati? Dove sono posizionati rispetto ai dati? Che livello di accesso hanno? In generale, un sistema operativo fornirà già controlli di accesso a livello di software, rendendo la crittografia uno strumento sbagliato per impedire a un processo dannoso di accedere ai dati utilizzati altrove. Lo storage crittografato è progettato per fornire sicurezza data-at-rest , proteggendo i dati sul disco rigido guidare, dovrebbe essere rubato o altrimenti cadere nelle mani sbagliate. Per questo modello di minaccia in cui si intende utilizzare la crittografia, non è necessario fornire la chiave a un numero maggiore di processi di quelli necessari per la lettura effettiva del database. In particolare, è necessario consentire al software del database di eseguire la crittografia e la decrittografia, consentendo a chiunque disponga dell'autorizzazione di connettersi al server di database la possibilità di leggere i contenuti, in base alle autorizzazioni a livello di software.