What is the difference between a PKCS12 keystore and a PKCS11 keystore?

Question

I'm interested in Java-NSS libraries, and I'm reading the Sun's P11 Guide. I am confused on the following:

What is the difference between using a PKCS12 keystore and a PKCS11 keystore?

A keystore is just a keystore, right? Are there some differences? Can they be used interchangeably in any aspect?

Cainozoic

Bruno has already explained quite well, so I'll just make some comments. With PKCS#12 you would extract the keys and then simply handle them using the Sun provider (or one of the other Java only providers). With PKCS#11 (which is an entirely different standard, PKCS just means Public-Key Cryptography Standards) the key will stay inside the PKCS#11 token, so it will be handled by the native PKCS#11 library (or underlying token). So a KeyStore is not just a keystore. However, the keys/certs within the keystore can be used interchangably (if the Java code is compliant enough). – Kidskin

@owlstead:I am not clear on the following:Can a PKCS11 keystore be used as a keystore of a keymanager (in ssl context in jsse) for self-authentication to the other party, the same way as a PKCS12 keystore can be configured in a keyManager?Or it is not possible? – Cainozoic

yes, you can use PKCS11 KeyStores like any other, including through a KeyManager and SSLContext. – Bathsheba

Answer 1

PKCS#12 is a file format (often called .p12 or .pfx) where you can store a private key and certificates. It's used for converting/transporting keys and certificates, mainly. If you export a private key + certificate from your browser, it's likely going to be in that format.

PKCS#11 is an interface, usually used to talk to hardware cryptographic tokens (often smart-cards or USB-tokens, which effectively are smart-cards embedded in a reader). This interface has a number of operations to make use of the keys and certificates. Some tokens are able to sign using the private key they contain, without the key being able to leave the device. The point of this interface is to treat what handles the keys and certificates as a separate entity, without having to do the cryptographic operations that PKCS#11 offer (more specifically, the ones related to the private key).

When you use PKCS#11 with NSS, you're effectively using NSS as a black-box wrapped behind the PKCS#11 layer (it's effectively a software provider for what a PKCS#11 hardware token would be). There is a slight difference in the way Java uses NSS via PKCS#11 in that it doesn't require a PKCS#11 shared library (compared to other PKCS#11 libraries), so as such, it's not PKCS#11 strictly speaking, although it's very similar.

In Java, you may be able to get an RSAPrivateKey instance from a PKCS#11 store, use it to sign and decipher, without ever being able to get anything from its modulus. The security provider handling it will do the signing/deciphering via the library (and thus via the token, if that library is supported by a hardware token).

Coming back to the KeyStore in Java, it's an API that can allow you to load and use keys and certificates from files (you get various files formats such as JKS, PKCS#12, PEM, depending on your security provider) or from other underlying APIs (such as PKCS#11, more or less merged with NSS in the Sun provider, or the KeychainStore if you're on OSX and want to use the KeyChain as a KeyStore).

Bathsheba

@Bruno:1)You mention smart cards.What about the cert8.db?Is this the PKCS11 container for NSS?2)I am not clear on the part concerning the usage of the RSAPrivateKey.Could a keystore be configured in a ssl context (to be used as the private keystore and signing) and the keystore be the cert8.db (i.e. pkcs11 type)?Or it is not possible? – Cainozoic

If you want to use cert8.db, you can use a PKCS11 KeyStore configure to use NSS and to point to that file (that's not PKCS#11 strictly speaking, but it's so close it's merged with it in Java). You could also configure the PKCS11 KeyStore differently, to use a PKCS#11 shared library. The KeyStore in general is a higher level of abstraction to encompass anything that can store keys/certs or via which you can make use of them. You can indeed use such a KeyStore for SSL, provided the keys are of the right type (depending on the cipher suites): RSA is quite common. – Bathsheba

KeyStore, as a class, isn't necessarily a tangible thing, rather it's an entity that can be used to interface with files (JKS, P12), tokens (PKCS#11) or other libraries (KeychainStore, NSS). It just turns out that the requirements for NSS is so similar to what a PKCS#11 consumer would be that they've put them together. Each of these underlying entities can then be configured if required, for example to point to a cert8.db file or to use a certain smarcard slot. The simpler ones like PKCS#12 files don't need any configuration like this. – Bathsheba

@Bruno:The java examples for NSS refer to cert8.db.So it is a simple file that is accessed as if it were a hardware token?Did I get it right? – Cainozoic

@user384706, yes, more or less. When you access a hardware token via PKCS11, you get the KeyStore to access the PKCS#11 library (e.g. libpkcs11.so), which then talks to the token (e.g. slot=1); however that PKCS#11 lib drives the actual hardware isn't Java's concern. When you use NSS, the PKCS11 KeyStore talks to libnss, which is configured to use cert8.db (or whatever you choose). You need to configure these KeyStores with more information than just a path to a file (via pkcs11.cfg for example) because you're effectively configuring an underlying library, which needs more parameters. – Bathsheba

You may also be interested in this article: java.sun.com/developer/technicalArticles/J2SE/security – Bathsheba

@Bruno:I read the article.I want to be clear I got the concept.Java provides the ability to utilize tokens as well as certified sw implementations.NSS is a certified implementation that is build to be used via PKCS11.Is this correct? – Cainozoic

(Being certified isn't important here.) It's more about the fact that NSS is "external" to Java (it's a library that comes from Mozilla), and has similarities to the actual PKCS#11 libraries. Hence, Sun have implemented the interfaces for both pure PKCS#11 and NSS into the PKCS11 store type. The difference is between the configuration: with a "pure" PKCS#11, you're using library = .../libpkcs11.so; with NSS you're specifying nssLibraryDirectory = .... NSS wasn't built to be used via PKCS11, but Java's PKCS11 store type was extended to support NSS as well as real PKCS#11 libraries. – Bathsheba

Answer 2

From Different types of keystore in Java -- Overview, the differences between PKCS12 and PKCS11 can be described as following

PKCS12, this is a standard keystore type which can be used in Java and other languages. You can find this keystore implementation at sun.security.pkcs12.PKCS12KeyStore. It usually has an extension of p12 or pfx. You can store private keys, secret keys and certificates on this type. Unlike JKS, the private keys on PKCS12 keystore can be extracted in Java. This type is portable and can be operated with other libraries written in other languages such as C, C++ or C#.

Currently the default keystore type in Java is JKS, i.e the keystore format will be JKS if you don't specify the -storetype while creating keystore with keytool. However, the default keystore type will be changed to PKCS12 in Java 9 because its enhanced compatibility compared to JKS. You can check the default keystore type at $JRE/lib/security/java.security file:

PKCS11, this is a hardware keystore type. It provides an interface for the Java library to connect with hardware keystore devices such as SafeNet's Luna, nCipher or Smart cards. You can find this implementation at sun.security.pkcs11.P11KeyStore. When you load the keystore, you no need to create a specific provider with specific configuration. This keystore can store private keys, secret keys and certificates. When loading the keystore, the entries will be retrieved from the keystore and then converted into software entries.

Karol