Java and Cryptographic Smartcards
This document is to highlight the important details of Cryptographic smart cards and their accessing mechanisms from Java applications. This also provides information on how to establish SSL connection with mutual authentication using Smartcards and PKCS#11.

Cryptographic smartcard
Introduction
The emerging world of e-commerce depends on security services:
user authentication
key distribution
data integrity and confidentiality
digital signatures / non-repudiation

Smart cards and cryptography are helpful tools for implementing these services

What is a Smartcard?
A smart card is a device that feels and looks like a credit card, but contains a small computer that combines dedicated hardware and software with more standard components such as various types of memory and small operating systems.
They also consolidate multiple applications — like PKI credential storage, user authentication, building access and corporate ID badging — onto one device, easing deployment and administrative burdens for enterprises worldwide.

What are the different Smartcard types?
Stored Value Cards
Microprocessor Memory Cards
Cryptographic Cards
Stored value cards are the most basic form of smart card. They are best thought of as an electronic version of a magnetic stripe card and the security in this card is provided through encrypting the data that is stored on the card, not by any particular function or process on the card.

Microprocessor memory smart cards are more complex than the traditional stored value cards. All access to the card’s memory goes through the microprocessor. In addition, the microprocessor can enforce PIN protection or other security features.
The internals of a microprocessor memory card are much like a mini computer and include: RAM — temporary storage where the processor performs computations; ROM — permanent memory which houses the operating system for the smart card; and EEPROM (Electrically Erasable Programmable Read Only Memory) — re-writable memory for the application data (and perhaps code).

What is a Cryptographic Card?
Cryptographic card is a high-end microprocessor memory card with additional support for cryptographic operations (digital signatures and encryption). Crypto cards are designed to allow secure storage of private keys (or other secret keys). These cards will also perform the actual cryptographic functions on the smart card itself. In this way, the private key need never leave the smart card. As a result, crypto cards play an essential part of any public/private key system.

What is PKCS#11: Cryptographic Token Interface Standard?
The Cryptographic Token Interface Standard, PKCS#11, is produced by RSA Security and defines native programming interfaces to cryptographic tokens, such as hardware cryptographic accelerators and Smartcards.

It’s called Cryptoki and provides an interface to one or more cryptographic devices that are active in the system through a number of "slots". Each slot, which corresponds to a physical reader or other device interface, may contain a token. A token is typically "present in the slot" when a cryptographic device is present in the reader.

Cryptoki is likely to be implemented as a library supporting the functions in the interface, and applications will be linked to the library. An application may be linked to Cryptoki directly; alternatively, Cryptoki can be a so-called "shared" library (or dynamic link library), in which case the application would link the library dynamically.

What is PKCS #11 module?
A program on your computer that manages cryptographic services such as encryption and decryption using the PKCS #11 standard. Also called cryptographic modules, cryptographic service providers, or security modules, PKCS #11 modules control either hardware or software devices.

What is Security device/ Token?
This is the hardware or software that provides cryptographic services such as encryption and decryption and can store certificates and keys. A smart card is one example of a security device implemented in hardware.

Java PKCS#11
Introduction
The Java platform defines a set of programming interfaces for performing cryptographic operations. These interfaces are collectively known as the Java Cryptography Architecture (JCA) and the Java Cryptography Extension (JCE).

The cryptographic interfaces are provider-based. Specifically, applications talk to Application Programming Interfaces (APIs), and the actual cryptographic operations are performed in configured providers which adhere to a set of Service Provider Interfaces (SPIs).

To facilitate the integration of native PKCS#11 tokens into the Java platform, a new cryptographic provider, the Sun PKCS#11 provider, has been introduced into the J2SE 5.0 release.

Sun PKCS#11 Provider
The Sun PKCS#11 provider does not implement cryptographic algorithms itself. Instead, it acts as a bridge between the Java JCA and JCE APIs and the native PKCS#11 cryptographic API, translating the calls and conventions between the two. This means that Java applications calling standard JCA and JCE APIs can, without modification, take advantage of algorithms offered by the underlying PKCS#11 implementations, such as, for example, Cryptographic Smartcards.

Configuration
We have to create a configuration file for PKCS#11 provider. The configuration file is a text file that contains entries in the following format.
attribute = value

The two mandatory attributes are name and library.
name = mysmartcard
library = /opt/foo/lib/libpkcs11.so

The library file is installed with smartcard installation in our system. The format of the library pathname is platform dependent. For example, /opt/foo/lib/libpkcs11.so might be the pathname of a PKCS#11 implementation on Solaris and Linux while C:\foo\mypkcs11.dll might be one on Windows.

To install the provider statically, add the provider to the Java Security properties file ($JAVA_HOME/lib/security/java.security).
# configuration for security providers 1-6 ommitted
security.provider.7=sun.security.pkcs11.SunPKCS11 /opt/bar/cfg/pkcs11.cfg

To install the provider dynamically, create an instance of the provider with the appropriate configuration filename and then install it.

String configName = "/opt/bar/cfg/pkcs11.cfg";
Provider p = new sun.security.pkcs11.SunPKCS11(configName);
Security.addProvider(p);

Example program for SSL with mutual authentication:

public class Client{
public static void main() {
System.setProperty("javax.net.ssl.trustStoreType", "pkcs11");
System.setProperty("javax.net.ssl.trustStore", "NONE"); //PIN to access the smartcard
System.setProperty("javax.net.ssl.trustStorePassword", pin);
System.setProperty("javax.net.ssl.trustStoreProvider", "SunPKCS11-mycard"); System.setProperty("javax.net.ssl.keyStoreType", "pkcs11");
System.setProperty("javax.net.ssl.keyStore", "NONE"); //PIN to access the smartcard System.setProperty("javax.net.ssl.keyStorePassword", pin);
System.setProperty("javax.net.ssl.keyStoreProvider", "SunPKCS11-mycard"); System.setProperty("javax.net.debug","ssl"); //dynamically configuration of PKCS#11

String configName = "/opt/bar/cfg/pkcs11.cfg";
Provider p = new sun.security.pkcs11.SunPKCS11(configName);
Security.addProvider(p);
SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory.getDefault();
//host to establish the SSL connection
SSLSocket socket = (SSLSocket)factory.createSocket(host, 443);
socket.startHandshake();
}
}

This is sufficient for many applications but it might be difficult for an application to deal with certain PKCS#11 features, such as unextractable keys and dynamically changing Smartcards. In this scenario we can consider the other PKCS#11 providers like IAIK PKCS#11 Provider, IBM PKCS#11 Provider.

I used “IAIK PKCS#11 provider” to establish SSL connection with host where the private key is unextractable and it’s not maintained on the token. All the cryptographic operations should be performed on smartcard instead of extracting the Private Key out of it.

IAIK PKCS#11 Provider
Introduction
This product allows easy integration of smart cards, USB tokens and HSMs into Java™ applications. It provides a simple java.security.KeyStore view of these tokens and makes cryptographic operations of these devices accessible via the JCA/JCE framework.

Unlike Sun PKCS#11 provider, this provides the following APIs:
Object-Oriented API for PKCS#11
Java API for PKCS#11
Java Native Module Interface of the Wrapper

The Layer model of the System:


OO Java API for PKCS11 is solely builds upon the API for the Java™ platform for PKCS#11 as implemented by the Wrapper for PKCS#11 for the Java™ platform.

Java API for PKCS11 is the non-Object Oriented Wrapper API for PKCS#11 for the Java™ platform is a set of Java™ classes and interfaces that reflects the PKCS#11 API.

This native module of the wrapper is responsible for translation of the Java™ data structures, which the API for PKCS#11 for the Java™ platform part defines, to native PKCS#11 data structures and vice versa. This module of the system does not include any additional logic, it only provides a straightforward mapping from the API for PKCS#11 for the Java™ platform to the PKCS#11 Module of the Smart Card.

The lowest layer, the PKCS#11 Module of the Smart Card, is the PKCS#11 module that the smart card manufacturer supplies. This is normally a DLL or shared library.

You can download evaluation version at http://jce.iaik.tugraz.at/sic/download

The installation and API documentation on PKCS#11 Provider is available at http://jce.iaik.tugraz.at/sic/products/core_crypto_toolkits/pkcs_11_provider

For implementing SSL, we have to use IAIK’s iSaSiLk module. The documentation on this avaiable at:
http://jce.iaik.tugraz.at/sic/products/communication_messaging_security/isasilk/documentation/smartcards