RE: Vulnerabilities due to BigInteger being immutabl e?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

RE: Vulnerabilities due to BigInteger being immutabl e?

Marcin Cinik
I think You should think of migration to hardware security tokens like
microprocessor cards for example. Using hardware tokens You can be sure that
private key is never outside hardware token and hardware token is the only
place in the system where there is a risk of losing private key. You cannot
retrieve private key from most of smartcards (microprocessor cards). JRE 1.5
has native bridge between PKCS#11 and Java. Currently there are no software
solutions of Your problem. Cleaning up memory after key had been used does
not solve your problem because another part of your hardware, software,
operating system can contain bytes of private keys and You do not even
realize that. Remember that operating system can potentially make copies of
memory page when it tries to optimize and defragment memory (at any moment
between processor's monitor state). Then You won't have access to that
memory anymore and content of copied memory will not be cleaned up. Some
operating systems like those from Microsoft have nice feature which makes it
impossible for the operating system to swap or copy protected memory. It can
also encrpyt some blocks of memory in real time on demand, but where from
will You take encryption key ? And remember that in a world of Java you
don't have access to most of operating system's functions, because Java
software is to be portable. Hardware tokens solve all of those problems, but
those can be expensive and hard to deploy.

Marcin Cinik

-----Original Message-----
From: Kevin Smith [mailto:[hidden email]]
Sent: Monday, August 29, 2005 10:21 PM
To: [hidden email]
Subject: [dev-crypto] Vulnerabilities due to BigInteger being immutable?


Greetings,

As part of an internal security audit process, we uncovered some
potential vulnerabilities, and I have been asked to share them with you
and solicit feedback. We realize that these are probably relatively low
risk concerns, but would like some reassurance that they really are.

RSA private keys are stored internally as BigIntegers. Because
BigIntegers are immutable (Sun's decision), it is impossible to clear
them. Once some memory location contains a private key, there is no
reliable way to wipe it.

This opens up three possible attacks that we can think of:

1) Memory can be scanned while the app is running, or after it exits,
and the key could be extracted. The app has no way to clear the key when
it is finished using it.

An attacker would not have to know exactly where in memory the key is
stored--they could brute-force try all the possible locations in RAM.
This would only require perhaps billions or trillions of attempts, far
less than the normal strength of a 2048 bit RSA key. The same is true
for #2 and #3, below.

As has been pointed out on this list, an attacker capable of scanning
memory on a secure system such as a server is probably able to perform
other more effective attacks. On a relatively insecure workstation,
there are likely to be other more serious vulnerabilities that could be
exploited. So the simple case of memory scanning does not seem to be a
serious risk in most cases.

2) Memory may be swapped to disk, so the swap file could be scanned.
Swap files may potentially exist after a computer has been shut down.
Even after a disk sector has been overwritten it may be possible to
retrieve earlier data stored in that location. This exposure is most
significant in cases where the computer may get stolen (which happens to
be a real consideration in our domain).

3) After losing power, DRAM retains a faint image of the data it used to
contain, potentially allowing the old data to be recovered for hours, or
perhaps days after the power has been shut off[1].

The longer a particular bit pattern is stored, the stronger the
persistent image. So the easiest way to mitigate this would be to move
the key around in memory frequently. Unfortunately, because BigIntegers
are immutable, this isn't really possible (they could only be copied,
making the problem worse). Again, this risk becomes most interesting if
the computer is stolen.


We would appreciate any feedback as to whether we have overstated or
understated any of the risks above. Also, we would be interested to hear
if there are any steps we might take to mitigate any of them. Of course,
we would also be interested in hearing about any similar or related
attacks that we have not thought of. Are any of these risks high enough
to warrant exploring replacing BigInteger with a mutable (wipeable)
alternative?

Thanks!

Kevin

[1] http://www.totse.com/en/technology/computer_technology/161780.html