Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
secure erasure of Java key/password buffers
21 views
Skip to first unread message
mortadelo
Jul 17, 2012, 3:28:23 AM7/17/12
to
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’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
Bent C Dalager
Jul 17, 2012, 10:15:51 AM7/17/12
to
On 2012-07-17, mortadelo <morta...@googlemail.com> 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.
If you are going to pursue this then you should first decide what
> 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.
degree of perfection you demand. Even C cannot guarantee that a
deleted piece of information is in fact deleted, because the language
cannot know of any copies that might exist in page files, swap files,
caches, etc. You need the active participation of the OS to make sure
such copies are deleted, and even the OS cannot know if its various
storage devices contain extraneous copies of the information (such as
routinely happens on an SSD for instance). For /this/ you would need
the active participation of the hardware drivers and ultimately the
hardware itself.
Security can be infinitely expensive depending on your demands, so
having a clear idea what exactly your demands are is essential.
Personally I never quite understood the purpose of the char[]
replacement for JPasswordField.getText() because with all the object
copying, paging, caching and other shenanigans that happen all the
time in a modern computer, zeroing out the char array seems like such
a very very weak form of security. But perhaps very very weak is just
exactly what is called for in some area or other that I am not
familiar with.
Cheers,
Bent D
--
Bent Dalager - b...@pvv.org - http://www.pvv.org/~bcd
powered by emacs
Roedy Green
Jul 17, 2012, 12:27:46 PM7/17/12
to
On Tue, 17 Jul 2012 00:28:23 -0700 (PDT), mortadelo
<morta...@googlemail.com> wrote, quoted or indirectly quoted
someone who said :
IIRC I saw some Sun code where a password word stored in a char[]
rather than a string to make it possible to erase it so that it could
not be found even a core dump. Of course that presumes the password
came from the keyboard, not from a static final String in the program.
--
Roedy Green Canadian Mind Products
http://mindprod.com
The greatest shortcoming of the human race is our inability to understand the exponential function.
~ Dr. Albert A. Bartlett (born: 1923-03-21 age: 89)
http://www.youtube.com/watch?v=F-QA2rkpBSY
<morta...@googlemail.com> wrote, quoted or indirectly quoted
someone who said :
rather than a string to make it possible to erase it so that it could
not be found even a core dump. Of course that presumes the password
came from the keyboard, not from a static final String in the program.
--
Roedy Green Canadian Mind Products
http://mindprod.com
The greatest shortcoming of the human race is our inability to understand the exponential function.
~ Dr. Albert A. Bartlett (born: 1923-03-21 age: 89)
http://www.youtube.com/watch?v=F-QA2rkpBSY
Daniele Futtorovic
Jul 17, 2012, 3:43:17 PM7/17/12
to
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.
> 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.
0 new messages