Hallo ihr, ich habe ein kleines Problem mit Java und GnuPG. Ich bin gerade dabei, einen Java-GnuPG-Wrapper zu schreiben, weil ich sowas für 2 kleinere Projekte brauche. Ich habs auch schon zum Laufen gekriegt, aber mir machen da ein paar sicherheitstechnische Aspekte Bauchschmerzen, so wie ich sie bisher gelöst habe. Vielleicht hat ja jemand eine Idee dazu.. (GnuPG rufe ich als Betriebssystem-Prozess auf über ProcessBuilder usw.):
Momentan übergebe ich das Kennwort für den Schlüssel an gpg über den Standard-Eingabestrom (mittels der GnuPG-Option "--passphrase-fd 0"), damit man es nicht einfach so mitlesen kann oder so.
Es gibt noch die Optionen "--passphrase-file" und "--passphrase", bei denen man das Kennwort im Klartext entweder über die Kommandozeile oder über eine Datei übergeben kann - dabei kann man aber entweder über "ps" oder mit Zugriff auf die Datei die Passphrase lesen, deshalb hab ich das gelassen. Dass ein Benutzer direkt nach dem Kennwort gefragt wird per Popup (vom gpg-agent oder sowas) kommt nicht in Frage, da das Programm als Daemon laufen soll.
Das Problem ist jetzt, dass der Standardeingabestrom von gpg schon durch die Passwortübergabe belegt ist, und ich den Klartext, den ich verschlüsseln möchte, so nicht übergeben kann.
Momentan erstelle ich eine temporäre Datei, schreibe da den Klartext rein, und lese die verschlüsselte Nachricht ebenso wieder aus einer Datei. Beim Entschlüsseln läuft das natürlich genau andersrum. Dabei wird ja der Klartext auf die Festplatte geschrieben, und man könnte den ebenso mit Zugriff auf die Festplatte (in dem Moment wo die Datei existiert, oder später indem man die komplette Festplatte durchrödelt), den Klartext rekonstruieren. Blöd, das. Das würde ich gern anders haben, weiß aber nicht, wie.
Meine erste Idee war, einfach eine "named pipe" zu nehmen und die mit "--passphrase-file" anzugeben. Dabei geht natürlich die Plattformunabhängigkeit total flöten, und außerdem kann ich mit Java-eigenen Mitteln keine named pipes erstellen, das müsste ich wieder mit Betriebssystemaufruf und "mkfifo" machen. Irgendwie unelegant, aber im Moment tendiere ich dazu.
Ich habe schon herausgefunden, dass ich gpg mit "--passphrase-fd 3" dazu bringen kann, das Kennwort von File Descriptor 3 zu lesen. Dann bleibt der Standardeingabestrom frei. Über die Bash kann ich dann gpg so mit einem Kennwort füttern:
echo "ganz geheimer Text" | gpg --batch --no-tty --passphrase-fd 3 3< <(echo "ganz geheimes Kennwort")
(Dabei sollte man natürlich nicht gerade echo nehmen, weil man dann das Kenwort wieder mit ps sehen könnte, nur so als Beispiel) Auch das ist nicht so wirklich betriebssystemunabhängig, finde ich aber schon wesentlich eleganter. Ich hab nur keine Ahnung, wie ich Java anweisen kann, in File Descriptor 3 zu schreiben. Wahrscheinlich geht das auch nicht wirklich, eben weils nicht betriebssystemunabhängig ist, denk ich.
Hat jemand ne Idee, wie ich das lösen kann? In kurz nochmal: Ich will gpg sowohl mit einem Kennwort, als auch mit Klartext füttern, ohne dass man am Ende das Kennwort oder den Klartext woanders (Festplatte, mit ps, ...) rauslesen könnte (Szenarien wie den kompletten Speicher auslesen klammere ich jetzt mal aus).
LG, Lena