Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.java.security > #255

Re: secure erasure of Java key/password buffers

Show all headers | View raw

On 17/07/2012 09:28, mortadelo allegedly wrote:
> Hi everybody,
> 
> I’ve just stumbled across some crypto interface code written in Java where buffers of (sensitive) data/keys are not explicitly erased (zeroed out) after use. Coming from a C programming background where explicit zeroing out of memory after use is highly recommended, I’m wondering whether this should also be done in Java. I understand that it’s impossible to guarantee efficient erasure of all possible instances of a data object in Java.
> 
> I’m seeing two contradictory arguments here:
> •        Explicit zeroing out of a memory object after use may considerably reduce, ideally eliminate  the likelihood/number of remaining object instances with the original content.
> •        Explicit zeroing out (i.e. alteration) of a memory object may cause the memory manager to explicitly create a new (additional) copy of the original content. Hence, this action would not catch the initial instance of the data abject, but only create additional overhead.
> 
> Does it make sense to distinguish between "simple" data types (e.g. an int array with constant size) and "complex" data types (e.g. a string object)? Do you know of any good research or reference about this? I haven’t found anything well investigated in the Internet. Both arguments exist.
> 
> 
> Thanks, Michael

I think it does make sense to distinguish between both. You have little
to no control over the life cycle of your Objects in Java. But by
zeroing an int or a char array, you can ensure at the very least that
the data does not exist on the heap any more (barring someone having
cloned the array reference).

As far as I understand, the rule of art would be to use char arrays for
passwords -- with or without zeroing after use (although the latter
would be preferable). The idea is to avoid String instances, because
strings might potentially be interned and then remain in memory
indefinitely (until your app ends). Given that opinion of mine, I've had
to notice to my dismay that a very large number of APIs (third-party --
I think Sun^H^HOracle sticks to it) do not follow that route. This has
given raise to an as of yet dim doubt in my mind whether said stance
really is the appropriate one. But I cannot find anything that would
alleviate the string internment problem.

As to your two allegedly contradictory statements:
 - What I said only applies to primitives and arrays thereof, not to
Objects. As I said, you have no control over the latter's existence or
non-existence in memory
 - The Java GC works through references; AFAIK not through access. IOW,
it doesn't matter how often you access your reference, it matters only
how many collection cycles through it remains reachable through a (chain
of) live reference(s). Which in turn does not apply to primitives, since
they are not reference types.

-- 
DF.

Back to comp.lang.java.security | Previous | Next — Previous in thread | Find similar

Thread

secure erasure of Java key/password buffers mortadelo <mortadelode@googlemail.com> - 2012-07-17 00:28 -0700
  Re: secure erasure of Java key/password buffers Bent C Dalager <bcd@pvv.ntnu.no> - 2012-07-17 14:15 +0000
  Re: secure erasure of Java key/password buffers Roedy Green <see_website@mindprod.com.invalid> - 2012-07-17 09:27 -0700
  Re: secure erasure of Java key/password buffers Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-17 21:43 +0200

csiph-web