8

I'm writing a Java program that stores sensitive data (password and private keys) in memory. It will be deployed freely to any OS. I know that a user can create a memory dump manually on almost any system, but I am worried about a dump being created by the OS or JVM implementation (including, but not limited to some segfault of the JVM itself) that would compromise the privacy of the sensitive data.

Are there any steps that could be taken to reduce these risks? This question is POSIX specific but gives me an answer for these platforms. I had one non-platform specific idea that included setting an UncaughtExceptionHandler (like this) to a class that would overwrite sensitive data. But what about if memory is swapped out? What if the JVM crashes (e.g. segmentation fault) due to a JVM/JNI bug? I know Linux can stop data from being swapped to disk but is there a Java code to do this cross-platform? Mostly I'm worried about the potential for recovery of data on magnetic storage devices so any help is appreciated.

Community
  • 1
  • 1
Hut8
  • 6,080
  • 4
  • 42
  • 59

2 Answers2

3

If you do not have control of the operating system, you basically cannot prohibit the user from accessing what you have in memory.

Hence, you need to keep the amount of sensitive data you hold onto to an absolute minimum. Just imagine that the knowledgeable user attaches a debugger, halts your program and snoops in your datastructures cherry-picking whatever they need to know.

So, when done using passwords, set all references to null. When done using keys, set their references to null. Note that this will not help for the determined knowledgeable user, but it will at least minimize the chance for accidental discovery.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
  • This is all true whether using the JVM or not. – Nick May 20 '11 at 17:00
  • Thanks Thorbjørn. I know that I can't stop a user from doing this but in this case I'm not worried about users (just the VM/OS "taking a dump"). Unfortunately the program needs these keys for the duration of its execution. I've already zeroed out passwords. – Hut8 May 21 '11 at 03:41
2

If you are trying to stop casual users, then you don't really need to do anything. if you are trying to stop knowledgeable/determined users, and you are running the code on their computer, then there is nothing you can do.

if the only thing you are worried about is the program writing stuff to disk "accidentally", then, again, there isn't much you can do. java programs don't generate heap dumps unless you specifically tell them to. any stack traces which get output from an uncaught exception are highly unlikely to include anything sensitive in them. the file which gets written when a jvm segfaults in a controlled manner also will not likely have anything sensitive in it. the only potentially problematic thing would be a core dump on some variant of a unix system. and, unfortunately, i don't believe you can control that at the program level, only at the system/user configuration level (which was mentioned in the first question you linked to).

jtahlborn
  • 52,909
  • 5
  • 76
  • 118
  • And thank goodness for that! If it's their computer, they have every right to know what is on it. – erickson May 20 '11 at 17:00
  • I'm not trying to stop users at all, thank goodness :-) Just the VM and OS from dumping the process's memory regardless of the platform in case of a segfault or something similar as I wrote in my question. I don't want to restrict the users at all, but instead prohibit the OS/JVM from compromising their privacy. – Hut8 May 21 '11 at 03:43