Java and security bits

The Java PKCS#11 Provider and NSS

Mustang beta has just been released. Read all about it in Mark's blog and if you have not been running the snapshots, you should definitely download and try out the beta. But you knew all that already, so let's get to the point.

Last time I wrote about the dramatic crypto performance gains you can achieve just by running your existing Java applications on UltraSPARC-T1 based servers. You'll also see a very noticeable improvement on any other Solaris 10 systems thanks to the Solaris Cryptographic Framework.

But what about all those people not (yet?) on Solaris 10? The good news is that because Java utilizes the PKCS#11 standard, users that run Linux and Windows can see performance improvements, too. It is not out-of-the-box as on Solaris 10, but all you have to do is configure Java to utilize an optimized PKCS#11 crypto module, such as NSS.

NSS is an open source C based security library that is used in all products derived from the former Netscape product line. In other words, the Mozilla/Firefox browsers, the Sun Java Enterprise System server software, and more. To download the source or binaries, read this page first and then go to the FTP server. You will also need their platform layer, which is called NSPR and available here.

Still with me? Good. The crypto modules in NSS are based on PKCS#11, but with a few quirks. In Mustang, we have made it easier to access NSS. Now all you have to do is create a config file like this one:

name = NSS
nssLibraryDirectory = /opt/tests/nss/lib
nssDbMode = noDb
attributes = compatibility

Where /opt/tests/nss/lib is the directory in which you placed all the NSS and NSPR library files. Depending on your platform, you may also have to set your LD_LIBRARY_PATH or your Windows PATH to include this directory. Finally, configure your program to use NSS via the SunPKCS11 provider:

import java.security.*;

// your code here

// program startup code
Provider nss = new sun.security.pkcs11.SunPKCS11(configFileName);
Security.insertProviderAt(nss, 1);

// your other code here

Pretty neat. But there is more to PKCS#11 than just performance.

A second reason to use the SunPKCS11 provider is that it allows you to utilize crypto implementations that can be considered more secure, either because they employ tamper resistant hardware (e.g. Smart Cards) or because they have been through security certification program (such as FIPS 140). Some products are all this and very fast as well, see the Sun Crypto Accelerator 4000 or the just announced SCA 6000.

But what if you need security certification but don't want to spend money on a hardware security module? In that case, we are back at NSS. It is currently going through FIPS 140 validation, and of course you can also access NSS in FIPS mode from Java. It really gets interesting when you combine that with the experimental FIPS mode in the SunJSSE provider. This combination is intended to give you a FIPS 140 compliant TLS solution in Java. Which will be free, and available on Solaris, Linux, and Windows.

It works something like this. Create another configuration file for the PKCS#11 provider:

name = NSSfips
nssLibraryDirectory = /opt/tests/nss/lib
nssSecmodDirectory = /opt/tests/nss/fipsdb
nssModule = fips

Where the fipsdb contains the NSS secmod.db, which has been configured in FIPS mode, and the key and cert db files. See the NSS documentation for more information. Then have your Java program do this at startup:

Provider nss = new sun.security.pkcs11.SunPKCS11(fipsConfigFileName);
Security.addProvider(nss);

Security.removeProvider("SunJSSE");
Provider jsse = new com.sun.net.ssl.internal.ssl.Provider(nss);
Security.addProvider(jsse);

KeyStore ks = KeyStore.getInstance("PKCS11", nss);
ks.load(null, myNssPassphrase);
// next configure JSSE to use 'ks' as the KeyStore
// for its KeyManager

Not bad. But there is more to the SunPKCS11 provider ;-)

A third way in which PKCS#11 could come in handy is to allow Java applications to employ cryptographic algorithms for which we don't have a pure Java implementation yet. We don't do that currently, but this could change soon. If you have been following the news, it should not be hard to guess and - would you believe it - could even involve NSS yet again.

But that is another story. Watch this space.

Posted at 01:39 Feb 16, 2006 by Andreas Sterbenz in Java  |