Come @whoami ha menzionato, sposta semplicemente il problema in un altro posto. Come hai detto, ti consente di spostarlo fuori codice (se lo hai codificato in modo hard), proteggerlo con password (se originariamente era solo un PEM o qualsiasi altra cosa sul disco) e farlo ACL con le autorizzazioni necessarie.
Il problema è che devi conoscere la chiave per sbloccarlo, e questo ovviamente richiede una certa protezione, e beh, hai le tartarughe fino in fondo.
Ciò che stai facendo in pratica è spostare la barra per gli aggressori in modo che debbano impegnarsi maggiormente per rompere il problema. A un certo punto dicono solo di fottere e andare avanti. Puoi renderlo più difficile introducendo la complessità alla generazione delle chiavi, ma se gli aggressori sanno come funziona possono farlo da soli abbastanza facilmente, o peggio possono semplicemente rubare il file e provare a forzare la chiave bruta in quanto non particolarmente casuale. In alcuni casi il sistema operativo fornisce un meccanismo per proteggere le chiavi casuali, ma in questo caso avresti bisogno di qualcosa che è esposto alla JVM.
Altre soluzioni pratiche implicano il trasferimento della chiave in aree meglio protette e questo di solito significa hardware di qualche tipo. In alcuni casi parliamo di TPM, HSM o semplicemente di smart card (sebbene siano tutte la stessa cosa, ma con caratteristiche diverse). Il principio di base è che la chiave non lascia mai l'hardware, quindi è impossibile rubarla. Un effetto collaterale di questo è che tutta la crittografia di solito si verifica nell'hardware stesso, quindi tutto ciò che si sta facendo è spingere i dati e ottenere i dati, senza doversi preoccupare della cripto stessa.
Questo significa che è necessario proteggere l'interfaccia per l'hardware in modo che solo i sistemi autorizzati possano parlarci. Vedi le tartarughe ancora?