October 31, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Java Applet for Signing with a Smart Card

  • February 24, 2006
  • By Svetlin Nakov
  • Send Email »
  • More Articles »

You can a sign documents using a smart card through a user's web browser using a Java applet. Throughout this article, you will discover how to build an applet that is based on the  Sun PKCS#11 Provider, a cryptographic provider that is part of J2SE 5.0.

Signing documents requires the user to have a digital certificate along with a corresponding private key. Certificates are issued by certification authorities and can be stored in a file or on a smart card.

Smart cards are used to securely protect sensitive information such as private keys and certificates and provide better security because of the inability to copy the information stored in them. Private keys in the smart cards can be used to encrypt and sign data but cannot be extracted out of the card.

Background

In an earlier article (NakovDocumentSigner: A System for Digitally Signing Documents in Web Applications) a system was  presented to digitally sign documents in a Web-based environment. The system was based on a Java applet that used a Web browser to send files. On the server side, there was a J2EE Web application that received the signed files and verified their digital signature and the certificate. The signing was performed with a local file that contains the client's certificate and its private key, stored in the PKCS#12 file format (file with a PFX extension).

This article expands upon the Nakov Document Signer, found at NakovDocumentSigner, but this article will add some new functionality—signing documents in a Web environment with a smart card.

The Problem of Digital Signing in a Web-Based Environment with a Smart Card

Document signing with a smart card in a user's Web browser (form fields, forms, files, and other) is an ongoing problem for which there is no standard solution, regardless of the platform and the Web browser type or version.

Today's Web browsers do not have implemented functionality for the signing of attached files when they are sent from the client to the Web server. This leads to problems with the implementation of some custom applications in which the client needs to certify, in a trustworthy way, that he or she is the sender of a given document. Examples for such applications are found in e-government and e-banking systems, some financial systems, and others. Systems such as these obviously are going to contain sensitive data, and proper certification is a must.

There are two approaches to solve the problem.

  • Use a proprietary extension for the Web browser (for example, CAPICOM in Internet Explorer and crypto.SignText() in Netscape and Mozilla).
  • Use a Java applet, which would work nearly anywhere.

If you use extensions for the Web browser, signing parts of HTML forms through JavaScript can be easy, but the signing of a local file is still hard to do because JavaScript cannot read the local file system due to security restrictions. However, my Java applet can do this because it is signed.

By design, Java applets run with full permissions, without any security restrictions, and thus can read local files.

Building a Smart Card Applet

The goal here is to develop a technology that would digitally sign documents in a Web-based environment with a smart card. The developed technology should be independent from the operating system and from the user's Web browser. A Java applet will be used to execute the signing in the user's Web browser.

First, the ways and means for smart card access delivered by Java 5.0 will be presented. Afterwards, step-by-step development of the signing Java applet will be presented. It will sign files in the user's Web browser using a smart card before sending them to the Web server by a standard HTML form.

Defining What Is Meant By "Smart Cards"

Before moving forward, we need to have a common understanding of smart cards technology. Smart cards are magnetic or chip-cards that preserve and protect sensitive information (private keys, certificates, and other) more safely than a file record.

Most of the modern smart cards have a cryptoprocessor and a protected data area that cannot be copied. In fact, only the cryptoprocessor, which encrypts and signs data, has access to the protected area of the smart card. Developers cannot extract private keys from the card, only use the services of its cryptoprocessor instead.

It is impossible to extract the protected information from the smart card, thus making it exceptionally reliable because access to the card's private keys can happen only if the card is physically present. If the card is stolen, its owner can inform the issuing party to revoke the card.

When using the PKCS#12 certificate keystore, preserved in a file (with a PFX file extension), there is a risk of somebody copying the file and obtaining access to its password. The password can get stolen with a keylogger, trojan horse, spyware, or other hacking tool. Also, after that, one also can extract the private keys without the knowledge of the keystore owner. When using a smart card with a cryptoprocessor, it is not possible for the private keys to be extracted and copied due to hardware restrictions. The only possibility is if the card is physically stolen. However, the risk of this happening is far smaller in comparison to the risk of the certificate file being copied.

Smart Card Access Standards

As mentioned above, smart cards have their own cryptoprocessor, their own operating system, protected memory, and their own file system. The access to them is performed on different levels with different protocols. The standard, ISO 7816, specifies the main smart card components and describes the low-level access to them.

For higher-level access to smart cards, the PKCS#11 standard is used. This standard defines the application interface for interaction with the cryptographic devices (cryptographic tokens)—for instance, smart cards, hardware cryptographic accelerators, and others.

The software that is delivered along with the smart card usually contains an implementation of the PKCS#11 standard for the specific smart card and card reader. The implementation usually is a library (.dll file in Windows or .so file in Linux and UNIX) that can be loaded dynamically and can be used from all applications installed locally.

For example, if an ISO 7816-compatible Utimaco Safeware smart card is used, then the PKCS#11 implementation for this card is contained in the software package "Utimaco SafeGuard Smartcard Provider," which is delivered along with the card. For this article, you can assume you complete an installation of this software under Microsoft Windows XP. In Windows XP, the library that implements PKCS #11 will be seen as the file C:WINDOWSsystem32pkcs201n.dll.

The PKCS#11 standard doesn't allow physical extraction of the private keys from the smart card, but it is possible to use these keys to encrypt, decrypt, or sign data. Of course, for such an operation to be performed, the user must enter the PIN code beforehand; this protects the access to the smart card.

The PKCS#11 standard gives an interface for accessing the protected keys and certificate keystores, located on the smart card. For this reason, the smart cards can be operated in a way very similar to the operation with PKCS#12 keystores. A PKCS#11-compatible smart card, however, has much more capability than PKCS#12 keystores. Accessing protected keys and certificate keystores from a smart card using PKCS#11 is very similar to accessing information from PKCS#12 keystore files. Smart cards, however, have much more capability than PKCS#12 keystores; for example, encryption and signature built-in functionality.

Accessing Smart Cards from Java

From version 5.0 onwards of the Java 2 platform, each of these versions have built-in smart card access support. This smart access is performed via the PKCS#11 interface (Cryptographic Token Interface Standard); the interaction with it is established through the cryptographic services provider, "Sun PKCS#11 Provider".

Using the Sun PKCS#11 Provider

In Java 5.0, to access the smart card "Sun PKCS#11 Provider," a cryptographic services provider is used.

Unlike most Java Cryptography Architecture (JCA) providers, the Sun PKCS#11 Provider does not implement the cryptographic functionality directly; it relies on a native PKCS#11 implementation to which it forwards all operations. This implementation must be available as a .dll file in Windows or a .so file in UNIX and Linux. For example, if you use the Utimaco SafeGuard Smartcard Provider for Windows, the PKCS#11 implementation is the library pkcs201n.dll.

Configuring the Sun PKCS#11 Provider

It is important to remember that, to be used, the Sun PKCS#11 Provider must first be registered as a cryptographic services provider in JCA. The registration can be performed statically or dynamically. The following two sections will demonstrate how to both dynamically and statically register this provider.

Static Registration of the Sun PKCS#11 Provider

Static registration of the Sun PKCS#11 provider requires a change in the file:

%JAVA_HOME%/lib/security/java.security

To add a new security provider configuration, you need to insert the following lines:

# Configuration for security providers 1..6 omitted
security.provider.7=sun.security.pkcs11.SunPKCS11
   C:\smartcards\config\pkcs11.cfg

The pkcs11.cfg file, indicated in the preceding configuration, must contain the Sun PKCS#11 Provider settings. This file is in text format and describes some properties of the provider, such as the path to the PKCS#11 native library implementation.

Dynamic Registration of the Sun PKCS#11 Provider

For the dynamic registration of the "Sun PKCS#11 Provider," you must instantiate the sun.security.pkcs11.SunPKCS11 class registered in JCA. The name of the configuration file containing its settings should be given as a parameter. The following is an example:

String pkcs11ConfigFile = "c:\\smartcards\\config\\pkcs11.cfg";
Provider pkcs11Provider =
   new sun.security.pkcs11.SunPKCS11(pkcs11ConfigFile);
Security.addProvider(pkcs11Provider);

Configuration File of the Sun PKCS#11 Provider

In both cases, for the static and for the dynamic registration, a configuration file is required. This is necessary so that the SunPKCS11 class can read the path to the native library that implements the PKCS#11 standard. Here is an example of such a configuration file:

pkcs11.cfg

name = SmartCard
library = c:\windows\system32\pkcs201n.dll

The file contains two settings, as shown: name and library. The value of the name property is used as a part of the name for the instance of the PKCS#11 provider in JCA. The library property sets the path to the library that implements the PKCS#11 standard. If it is required to work with several smart cards simultaneously, the Sun PKCS#11 Provider must be registered several times with a different name each time.

In the configuration file, some additional properties can be set (described in the reference documentation), but the only mandatory properties are name and library.





Page 1 of 8



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel