Gestione delle chiavi private in memoria

3

Sono uno sviluppatore che sta lavorando su un protocollo di rete che include la crittografia. Non ha molta importanza, ma solo per ragioni di contesto, menzionerò che sto usando la libreria crittografica libsodium . Ora c'è un sacco di codice asincrono nella mia implementazione e tendo a copiare semplicemente la chiave privata che viene utilizzata per crittografare i pacchetti. La chiave privata è un array a 32 byte, quindi la copia dovrebbe essere economica per la CPU.

Alcuni dicono che dovrei conservare il minor numero possibile di copie, forse anche solo una, e usare un puntatore condiviso nella mia applicazione. D'altra parte, se l'hacker rileva questa specifica posizione di memoria, potrebbe sostituire la chiave privata con qualcos'altro. Quindi avere più copie sparse nella memoria dovrebbe renderlo più complesso, ma apre anche più buchi per cercare la chiave privata.

Quali sono le buone pratiche per gestire le chiavi private / segrete in memoria?

    
posta PovilasB 20.11.2018 - 10:11
fonte

2 risposte

3

La migliore pratica per gestire le chiavi private / segrete in memoria è di usare una memoria fisicamente fuori dalla portata degli attaccanti, come un HSM, Smart Card, Trusted Platform Module o Secure Element.

Il problema è che si tratta di hardware e su macchine moderne (server, cloud, PC, dispositivi mobili), l'hardware affidabile non è facilmente utilizzabile (anche se spesso presente, in particolare vedo un rinnovato interesse per TPM 2.0 in server / cloud).

Le opzioni solo software sono un compromesso. Un ragionevole a

  • Confidate nel sistema hardware + OS per mantenere almeno il contenuto della memoria di un processo privato, e mantenere le chiavi private / segrete è un processo separato che fa la crittografia, scambiando messaggi con il processo utilizzando the crypto.
  • E si attaccano agli algoritmi che hanno una protezione intrinseca contro le perdite di canale laterale / processo trasversale, perché gli attacchi su questo fronte sono in abbondanza. Libsodium è una buona scelta da questo punto di vista.

La combinazione almeno fa sì che una perdita di una chiave privata / segreta non sia il risultato di vulnerabilità nel processo che utilizza la crittografia (a causa di errori praticamente inevitabili nello stack di software complesso e ingestibilmente coinvolto in un'applicazione tipica). Uno svantaggio è che l'accesso al processo che esegue la crittografia deve essere gestito in modo sicuro (ad esempio attraverso i diritti di accesso imposti dal sistema operativo), il che aggiunge complessità.

Un modo per vedere le cosiddette "enclaves" è come un'implementazione standardizzata di quel principio di progettazione.

La mia opinione sull'argomento di moltiplicare il segreto contro l'uso di indicatori in un'area centralizzata è che è secondario dal punto di vista della sicurezza, rispetto all'isolamento del processo. Tendo a preferire i puntatori, non tanto perché è leggermente più efficiente, ma perché evita il fastidio di dover azzerare le copie non più in uso per seguire le linee guida che lo richiedono. Considero tale azzeramento come tecnicamente non essenziale (di nuovo, rispetto all'isolamento del processo); ma come usare e > 2 16 in RSA, è qualcosa su cui piegarsi.

    
risposta data 20.11.2018 - 11:46
fonte
0

Puoi crittografare la tua chiave privata con una chiave TPM appena creata, il tuo modulo TPM è in grado di creare una chiave wrapper, quindi puoi archiviare quella chiave su disco o memoria.

    
risposta data 21.11.2018 - 09:55
fonte

Leggi altre domande sui tag