Date: Tue, 24 Jun 1997 18:45:21 -0700
Message-Id: <199706250145.SAA01346@games.eng.sun.com>
From: Li Gong <gong@games.eng.sun.com>
To: Steve Burnett <burnettS@RSA.COM>
Subject: Re: secure memory
In-Reply-To: Steve Burnett's mail of Tue, 24 June, 1997
Steve,
I do not believe that you are guaranteed the desired behavior on any
of the existing language/OS systems today. Even when you are using C,
how do you know that your memory is not swapped out? You might be
running on top of virtual machine that does the footwork
transparently.
So in this regard, Java is not that weak as you made out.
You can try to garbage collect the object in question proactively by
calling gc yourself, but that does not guanrantee when the thing will
be collected.
Li
--Steve Burnett writes: > > In cryptography, we are always concerned about leaving "memory > footprints". Suppose I use my private key. I have it stored securely, > but I need to, at some point, load that key in the clear in memory to > perform my operations. When I'm done using that key, if my operating > system does not overwrite memory (simply marks the area as available), > then my private key may still be sitting there in memory after I release > it. > > Hence, an attacker may be able to "take a snapshot of the memory" and > see any data left over (this used to be a common technique among college > crackers to steal passwords). > > So we in the crypto business want to overwrite memory when we are > done with it. > > But if I overwrite something in Java, I may have only overwritten one > copy of the data. Java may have, without my knowledge, copied my key > from one location in memory to another. It may also have done some > memory/disk swapping, so that my key is now sitting on a hard drive > somewhere. > > How do I prevent an attacker from looking at my memory when I'm done > with it? And remember, the attacker will use something other than Java > to look at my memory. In other words, don't say that when the attacker > grabs hold of the memory, Java will zero it out first, because the > attacker is not using Java to grab hold. > > One suggestion is to provide a key word (such as "secure") that > indicates the data is secure, and cannot be copied or swapped (or if it > is, the previous location must be overwritten). > > secure byte[ ] keyData = new byte[16]; > > So my overall question is, what is JavaSoft doing about this issue? > What are you doing in your version of DSA? What do you suggest we do > with our Java code? > > --Steve Burnett > burnetts@rsa.com >