C'è sempre un problema con uova e galline quando si desidera archiviare le chiavi private in modo sicuro, ma l'app ha bisogno di un accesso automatico. Se fai attenzione a questo sito, troverai molte domande correlate, ad esempio:
Chiediti che cos'è il tuo modello di minaccia ; se sei solo preoccupato per gli attaccanti remoti, concentrati sui tuoi sforzi per rafforzare il perimetro del tuo server. Se nessuno può entrare nel tuo server, allora crittografarlo con AES potrebbe già essere eccessivo.
Se il tuo modello di minaccia include utenti malintenzionati su quel sistema, gli utenti introducono malware sul server, o se qualsiasi app che il server è in esecuzione è abbastanza complessa da poter essere compromessa, quindi proteggere le chiavi a riposo diventa una buona idea. Come dici tu, niente è sicuro al 100%; un approccio basato sul software sarà sempre irrinunciabile da qualcuno con accesso root al server e abbastanza tempo per studiare i dump della memoria del tuo programma. Sembra che quello che stai facendo sia ragionevole. Alcuni miglioramenti possibili:
- Piuttosto che avere la chiave AES incorporata nel codice sorgente, è necessario che un amministratore immetta una password all'avvio del processo utilizzata per derivare la chiave AES. In questo modo un utente malintenzionato ha davvero bisogno di essere sul tuo server prendendo i dump della memoria anziché essere in grado di estrarlo dal tuo codice binario o sorgente, che presumo sia più facile da acquisire rispetto a un dump di memoria di un server prod.
- Potresti forse crittografare ogni chiave privata con il proprio tasto AES solo per aumentare la barriera tra ottenere una chiave e ottenere tutte le chiavi.
- Il prossimo passo importante sarebbe generare le chiavi su hardware crittografico dedicato in modo che le chiavi private non siano mai sul server. Opzione economica: una serie di PKI Smart Cards che pendono dal server su dongle USB. Opzione costosa: rete HSM .