Verbergen JKS keystore/truststore Kennwort beim Ausführen von Java-Prozess

Question

Ich habe eine Reihe von Java-Anwendungen, die Verbindung zu anderen Anwendungen und Diensten über Verbindungen mit SSL gesichert. Während der Entwicklung kann ich den Schlüsselspeicher/Trusts angeben zu verwenden und das Passwort durch die JVM args mit:

-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 

Dieses perfekt funktioniert. Es gibt jedoch eine Anforderung, wenn Sie in die Produktion gehen, um das Kennwort zu verbergen. JVM-Argumente bedeuten, dass jeder, der sich die Prozessliste ansieht, das Kennwort im Klartext sehen kann.

Gibt es einen einfachen Weg, um dies zu umgehen? Ich überlegte, die Zertifikate in die lib/security/cacerts-Datei der JRE zu importieren, aber ich gehe davon aus, dass dies immer noch ein Passwort erfordert. Eine Option wäre, das Passwort verschlüsselt in einer Datei zu speichern und dann die Anwendungen zum Lesen und Entschlüsseln im laufenden Betrieb zu bringen, aber das beinhaltet die Änderung und erneute Freigabe aller Anwendungen (es gibt einige davon), also ich würde das lieber vermeiden, wenn irgend möglich. Verfügt die Bibliothek javax.net.ssl ​​über eine integrierte native Unterstützung für verschlüsselte Kennwörter (auch wenn es so einfach ist wie base64encoding oder alles, was die Kennwörter zu einem unklaren Text macht)?

Irgendwelche Vorschläge sehr geschätzt.

Answer 1

Zum einen könnte man die PS-Ausgabe von anderen Benutzern verstecken betrachten, sehen diese Fragen:

• 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?

Zweitens Ihre Zertifikate zu importieren (vorausgesetzt, mit private Schlüssel) in lib/security/cacerts wäre sinnlos: es ist der Standard-Truststore, aber nicht der Standard-Keystore (fo r welches es keinen Standardwert gibt).

Drittens können Sie niemals das Passwort verschlüsseln, das von Ihrer Anwendung verwendet wird (in einem nicht interaktiven Modus). Es muss verwendet werden, also wenn es verschlüsselt wurde, müsste sein Verschlüsselungsschlüssel irgendwann frei verfügbar gemacht werden. Daher ist es ein bisschen sinnlos.

Base 64 Codierung, wie Sie vorschlagen, ist nur eine Codierung. Auch hier ist es ziemlich sinnlos, da jeder es dekodieren kann (z. B. based64 -d). Einige Tools, wie Jetty, können das Passwort in einem verschleierten Modus speichern, aber das ist nicht viel resistenter als die Kodierung von Base 64. Es ist nützlich, wenn jemand über deine Schulter schaut, aber das ist es.

Sie können Ihre Anwendung anpassen, um die Kennwörter aus einer Datei (im Klartext oder verschleiert) zu lesen. Sie müssen sicherstellen, dass diese Datei nicht von nicht autorisierten Parteien gelesen werden kann.

Was wirklich wichtig ist, ist sicherzustellen, dass die Keystore-Datei selbst vor Benutzern geschützt ist, die nicht dazu gedacht sind, sie zu lesen. Sein Passwort soll den Container in Fällen schützen, in denen es für andere lesbar ist oder wenn Sie den Zugriff im interaktiven Modus schützen möchten. Da Sie es nicht wirklich vermeiden können, das Kennwort im unbeaufsichtigten Modus auf einem Computer zu verwenden, ist es nicht sinnvoll, ein schweres Kennwort zu verwenden, sondern es ist wichtiger, die Datei selbst zu schützen. (Es ist nicht klar, ob Ihre Anwendungen interaktiv sind oder nicht, aber ich schätze, nur wenige Benutzer sollten interaktiv -Djavax.net.ssl....=... eingeben.)

Wenn Sie Ihren Code nicht zum Lesen aus einer Datei anpassen können, ändern Sie Ihre Schlüsselspeicher- und Schlüsselkennwörter in ein Kennwort, das Ihnen wie "ABCD" nichts ausmacht, und schützen Sie den Lesezugriff aus dieser Schlüsselspeicherdatei : Darauf kommt es am Ende wirklich an. Das Lesen des Passworts selbst aus einer sekundären Datei verzögert lediglich das Problem um einen Schritt, da die Passwortdatei und die Schlüsselspeicherdatei wahrscheinlich nebeneinander gespeichert werden (und von einer nicht autorisierten Partei zusammenkopiert werden).