How can I securely wipe a confidential data in memory in java with guarantee it will not be 'optimized'?

Question

String secret="foo";
WhatILookFor.securelyWipe(secret);

And I need to know that it will not be removed by java optimizer.

Answer 1

A String cannot be "wiped". It is immutable, and short of some really dirty and dangerous tricks (using reflection, for example) you cannot alter that.

So the safest solution is to not put the data into a String in the first place. Use a StringBuilder or an array of characters instead, or some other representation that is not immutable. (And then clear it when you are done. And don't use toString() etc on the StringBuilder or you have created the String you were trying to avoid.)

Of course, the "safest" solution is rather impractical. Many Java SE and 3rd party APIs require or return text data to be provided as String objects.

---

For the record, there are a couple of ways that you can change the contents of a String's backing array. For example, you can use reflection to fish out a reference to the String object's backing array, and overwrite its contents. However, this involves doing things that the JLS states have unspecified behavior so you cannot guarantee that the optimizer won't do something unexpected. And the code to do this will be non-portable, since it depends on internal details of String that have changed over time and may change again.

---

My personal take on this is that you are better off locking down your application platform so that unauthorized people can't gain access to the memory / memory dump in the first place. After all, if the platform is not properly secured, the "bad guys" may be able to get hold of the string contents before you erase it. Steps like this might be warranted for small amounts of security critical state, but if you've got a lot of "confidential" information to process, it is going to be a major hassle to not be able to use normal strings and string handling.

Answer 2

You would need direct access to the memory.

You really wouldn't be able to do this with String, since you don't have reliable access to the string, and don't know if it's been interned somewhere, or if an object was created that you don't know about.

If you really needed to this, you'd have to do something like

public class SecureString implements CharSequence {
    char[] data;
    public void wipe() {
       for(int i = 0; i < data.length; i++) data[i] = '.'; // random char
    }
}

That being said, if you're worried about data still being in memory, you have to realize that if it was ever in memory at one point, than an attacker probably already got it. The only thing you realistically protect yourself from is if a core dump is flushed to a log file.

Regarding the optimizer, I incredibly doubt it will optimize away the operation. If you really needed it to, you could do something like this:

public int wipe() {
    // wipe the array to a random value
    java.util.Arrays.fill(data, (char)(rand.nextInt(60000));
    // compute hash to force optimizer to do the wipe
    int hash = 0;
    for(int i = 0; i < data.length; i++) {
        hash = hash * 31 + (int)data[i];
    }
    return hash;
}

This will force the compiler to do the wipe. It makes it roughly twice as long to run, but it's a pretty fast operation as it is, and doesn't increase the order of complexity.

Answer 3

Store the data off-heap using the "Unsafe" methods. You can then zero over it when done and be certain that it won't be pushed around the heap by the JVM.

Here is a good post on Unsafe:

http://highlyscalable.wordpress.com/2012/02/02/direct-memory-access-in-java/

Answer 4

If you're going to use a String then I think you are worried about it appearing in a memory dump. I suggest using String.replace() on key-characters so that when the String is used at run-time it will change and then go out of scope after it is used and won't appear correctly in a memory dump. However, I strongly recommend that you not use a String for sensitive data.