Paranoia and Java Cryptography

I started looking at rewriting a web app I wrote a while ago that does encryption in Java. This time trying to pay more attention to crossing the T's and dotting the I's, and I'm realizing encryption in Java is tricky.

The JCE itself makes things pretty easy, however where it gets a little tricky is how to deal with discarded information - passphrases, private keys, unencrypted data - when you are done with it. Unlike C code, for example, where you can simply zero out portions of memory when you are done with it, Java has very little available to do the same thing.

And it can get worse, when you are dealing with Strings, for example, they can get stuffed into a master String table - via String.intern(), squirreled away in the far reaches of the JDK, with no ability to destroy them. Thus, at the very least, never convert any sensitive information to a String, if you want any hope of ever clearing it out of memory.

The JCE designers seem to have been pretty keen to this, and provide interfaces that never use Strings as any parameters that could be sensitive. A good foundation, however dealing sensitive data elsewhere can be tricky.

A simple example, back to the web app, is dealing with parameters in a servlet. Say you have a servlet which takes a passphrase and a chunk of text and encodes it. Normally you retrieve parameters in a servlet with HttpServletRequest.getParameter(String name). The problem: getParameter() returns a String, and thus could get stuffed into the JVMs String table for ever more.

Although it would be unlikely for someone to gain access to the String table, and then figure out which String actually represented a passphrase, the paranoid side in me makes me a little nervous to allow that sensitive information to exist out of my control.

Even worse, the unencrypted data that you want to encrypt. Again, if you retrieve it with getParameter(), you won't be able to fully discard the unencrypted data until you restart the JVM.

I haven't quite figured out a plan for how paranoid I want to be. One thought would be to instantiate a new ClassLoader to manipulate sensitive data. Presumably when you get rid of the ClassLoader all the classes (including the String table) would at least be eligible for garbage collection.

Comments:

Err, you're worried about what? It's more easy to project attacks against your site without any compromise of your host machine.

Think about it...worst case you serve up your login via https (known plain text attacks) or you serve up only the login page--which has known plain text portions on submission. Either way worrying about things stored in your VM (as you rightly point out) rate low/are not worth addressing.

You'll fare better introducing either IP restrictions or something along the lines of PKI e.g. only remote clients signed by trusted authorities are allowed to connect. The latter approach ensures that only known, trusted clients pass through the standard SSL handshaking mechanism. E voila you have Single-Sign-On capabilities...at least from some people's perspective.

Posted by Ed on May 18, 2009 at 05:05 PM PDT #

Also note that cryptographic keys are often held in BigInteger objects, which are immutable. Thus you have no way of clearing the key bytes.
I filed a request for enhancements with Sun a few years back to allow this feature on BigInteger, but so far it has been ignored.

Posted by Soren Hilmer on May 19, 2009 at 06:48 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

mock

Search

Top Tags
Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks
Blogroll

No bookmarks in folder