Nascondi la password del keystore/truststore JKS durante l'esecuzione del processo Java

Question

Possiedo un numero di applicazioni Java che si collegano ad altre applicazioni e servizi tramite connessioni protette con SSL. Durante lo sviluppo, posso specificare l'archivio di chiavi/truststore da utilizzare e la password utilizzando i args JVM:

-Djavax.net.ssl.trustStore=certificate.jks 
-Djavax.net.ssl.trustStorePassword=mypassword 
-Djavax.net.ssl.keyStore=certificate.jks 
-Djavax.net.ssl.keyStorePassword=mypassword 
-Djavax.net.ssl.keyStoreType=jks 

Questo funziona perfettamente. Tuttavia, quando si entra in produzione è necessario nascondere la password, usando JVM args significa che chiunque visiti l'elenco dei processi sarà in grado di vedere la password in chiaro.

C'è un modo semplice per aggirare questo? Ho preso in considerazione l'importazione dei certificati nel file lib/security/cacerts di JRE, ma la mia comprensione è che questo richiederà ancora una password. Un'opzione sarebbe quella di memorizzare la password, crittografata, in un file e quindi far sì che le applicazioni possano leggere e decifrare al volo, ma ciò comporterà il cambiamento e il rilasciando tutte le applicazioni (ce ne sono molte) quindi preferirei evitare questo se possibile. La libreria javax.net.ssl ​​dispone di un supporto nativo integrato per le password crittografate (anche se è qualcosa di semplice come codecase64 o qualcosa che rende le password non-clear-text)?

Eventuali suggerimenti molto apprezzati.

Answer 1

In primo luogo, si potrebbe prendere in considerazione che nasconde l'uscita ps da altri utenti, vedere queste domande:

• I don't want other users see my processes in ps aux. I have root. It's Debian. How to use grsec?
• Hide processes from other users based on groups (under Linux)?
• How to make a process invisible to other users?

In secondo luogo, l'importazione dei certificati (assumendo con chiavi private) in lib/security/cacerts sarebbe inutile: è il truststore predefinito, ma non il keystore predefinito (per r che non esiste un valore predefinito).

In terzo luogo, non è mai possibile "crittografare" realmente la password che verrà utilizzata dall'applicazione (in modalità non interattiva). Deve essere usato, quindi se fosse criptato, la sua chiave di crittografia dovrebbe essere resa disponibile in chiaro ad un certo punto. Quindi, è un po 'inutile.

La codifica Base 64, come suggerito, è solo una codifica. Di nuovo, è abbastanza inutile poiché chiunque può decodificarlo (ad esempio based64 -d). Alcuni strumenti, come Jetty, possono memorizzare la password in una modalità offuscata, ma non è molto più resistente della codifica base 64. È utile se qualcuno ti guarda da dietro le spalle, ma è tutto.

È possibile adattare l'applicazione per leggere le password da un file (in testo normale o offuscato). Dovresti certamente assicurarti che questo file non sia leggibile da parti non autorizzate.

Ciò che importa è assicurarsi che il file del keystore stesso sia protetto dagli utenti che non intendono leggerlo. La sua password è pensata per proteggere il contenitore nei casi in cui potrebbe essere letto da altri o quando si desidera proteggere l'accesso in modalità interattiva. Dal momento che non si può davvero evitare di usare la password in chiaro su una macchina in modalità non presidiata, non ha molto senso avere una password difficile, piuttosto è più importante proteggere il file stesso. (Non è chiaro se le tue applicazioni siano interattive o meno, ma immagino che pochi utenti dovrebbero digitare -Djavax.net.ssl....=... in modo interattivo.)

Se non è possibile adattare il codice per leggere da un file, modificare il keystore e le password delle chiavi con una password che non si vuole rivelare come "ABCD" e assicurarsi di proteggere l'accesso in lettura da questo file di archivio chiavi. : questo è ciò che conta davvero alla fine. La lettura della password stessa da un file secondario sta semplicemente rimandando il problema di un passo, dal momento che il file delle password e il file del keystore possono essere memorizzati l'uno accanto all'altro (e copiati insieme da una parte non autorizzata).