Re: [GNU Crypto] Passwords Immutable?

[Matthew Sackman]

On Mon, Apr 12, 2004 at 10:17:34AM -0700, Casey Marshall wrote:
> >>>>> "Bryan" == Bryan Hoover <address@hidden> writes:
> 
> Bryan> The question of String immutability came up -- Java String
> Bryan> hangs around in memory indefinitly and this supposedly makes it
> Bryan> vulnerable to memory sniffing.
> 
> Not quite indefinitely -- garbage collection should eventually free
> them. That is, unless all the silly optimizations Sun did for the
> String class prevents this.

That's true, but you can never guarentee that the garbage collector will
run so you shouldn't ever rely on it doing so. (Therefore never rely on
finalise either)

What do you mean by memory sniffing? If another process can read your
memory then you have major problems that can't be solved in any
language. If you mean memory effect where the RAM (and in fact, cache
on the CPU) can be encouraged to switch on in the same state that it was
when it was switched off, then that can be reasonably effectively dealt
with by rapidly changing XOR pairs (see the link later on). You can't do
this in Java because you have very little control over memory.

> Bryan> I'm playing around with the code at the moment, thinking about
> Bryan> setting the property as a StringBuffer, or char array, and then
> Bryan> doing the necessary conversion when the property is read by the
> Bryan> lower level routines.  Would be easy enough.
> 
> Bryan> OR, perhaps there's a way around this I've missed?
> 
> Bryan> I hope I havn't touched a nerve with this, as I'm joining the
> Bryan> group blindly, without having read any of the messages for
> Bryan> context or anything.  I'm new to Java, so sorry if I'm off base
> Bryan> with the String question.
> 
> That's actually a good question, and it brings up more serious issues
> that I've been pondering. First I think you're right, the password
> parameter in SRP should be passed as a char array, or at least a
> mutable wrapper around an array, so it can be zeroed out when it isn't
> needed any longer.

You can't guarentee that that'll work. A heavily optimised JVM may well
see that the char array is never accessed after the zeroing so therefore
it's unnecessary to execute that code. At a guess, I think live variable
analysis will show that such code is unnecessary (in terms of the JVM
bothering to execute it).

If your code has a number of for loops in it which all iterate over the
same array then some other process could do some statistics on your
memory (assuming it had access) and guess the length of this array
because there are lots of loop variants lying around which all have the
same value. So you decide that at the end of the loop, you'll set the
loop variant back to zero. Except I doubt any JVM would actually execute
that code.

> But there is always the issue of where sensitive objects are kept in
> the JVM -- we essentially have no control over the memory management,
> so we have no idea if cryptographic keys are swapped out to disk, or
> if some other process is accessing them, etc.

Well yes, and that's the big problem with keys in Java: the spec makes
it plain that you simply have no control over memory so the idea of
trying to deal with sensitive data in memory is a bad one. Before I knew
this, I wrote what I thought was a secure key store class which is
available at http://www.wellquite.org/keystorage.tgz I wouldn't suggest
that anyone actually uses it because of the fact that whilst it may have
the desired effect on some JVMs, there's no guarentee that it will do
anything at all useful.

> Usually we at least want to prevent disk swapping, and would do that
> via mlock, but would this be available to a Java program?

Volatile says don't cache (at least, it's almost that simple in 1.5) but
I'm not aware of an equivalent of mlock.

Cheers,

Matthew
-- 
Matthew Sackman

BOFH excuse #441:
Hash table has woodworm