25. Smart Cards and Cryptography

THE Security and Trust Services APIs (SATSA) are defined by JSR 177. SATSA actually contains four separate APIs. Two of these are for communicating with smart cards, while the other two relate to cryptography.

• SATSA-APDU is an API for communicating with a smart card using basic data packets called Application Protocol Data Units (APDUs).

• SATSA-JCRMI is also about smart card communication but is based on Java Card Remote Method Invocation, a distributed computing protocol based on Java SE’s Remote Method Invocation (RMI).

• SATSA-PKI provides methods for using a smart card to generate digital signatures and manage certificates.

• SATSA-CRYPTO is a compact API for general-purpose cryptography, including message digests, digital signatures, and ciphers.

This chapter provides a brief introduction to SATSA. For more depth, read the SATSA Developer’s Guide, available here:

http://java.sun.com/j2me/docs/satsa-dg/index.html

Some of the discussion about tools is out of date, but the basic concepts and descriptions are valid.

The MSA specification requires SATSA-CRYPTO. Furthermore, if the device has a smart card or a similar component, then SATSA-APDU and SATSA-PKI are also required.

25.1. Smart Cards? Really?

A smart card is a tiny computer. Many smart cards look just like credit cards with some extra electrical contacts.

A boiled-down view of a smart card is that it is a physical manifestation of a private cryptographic key. One of the big problems of Public Key Infrastructure (PKI) is key management. A smart card is a compact place to store a private key that can be kept physically secure by placing it in a purse or wallet, just like a regular credit card. The smart card, however, can do wonderful things such as digitally sign information on the card, which makes it appropriate for all sorts of transactions involving money and important information. A full discussion of PKI is beyond the scope of this book. If you need some background, try the SATSA Developer’s Guide (mentioned earlier) or this article:

http://developers.sun.com/techtopics/mobility/midp/articles/security1/

How do smart cards relate to MIDP devices? All Global System for Mobile Communication (GSM) devices already have a special kind of smart card inside them called a subscriber identity module (SIM) card. Beyond this, some phones may have one or more slots where smart cards could be inserted.

On devices that support SATSA, the microedition.smartcardslots system property contains a list of all available slots. The slot is identified by a number followed by a letter that indicates whether cards can be inserted and removed while the device is powered on. This is called hot swappable, indicated by H. Slot numbers are separated by commas. The Sun Java Wireless Toolkit returns this list for microedition.smartcardslots:

This list indicates two hot-swappable slots numbered 0 and 1.

25.2. Testing SATSA Applications with the Emulator

The Sun Java Wireless Toolkit supports SATSA, but testing applications that interact with a smart card is a little more complicated than just running the emulator. The key is another program that simulates a running smart card, cref. cref is really part of the Java Card Development Kit, which is a set of tools for creating smart card applications. At this writing, the current version is 2.2.2. If you want to explore smart card application development, download the kit here:

http://java.sun.com/products/javacard/dev_kit.html

As a convenience, however, the Sun Java Wireless Toolkit now includes cref in its bin directory. To test SATSA applications in the toolkit’s emulator, use one running instance of cref to represent each connected smart card.

The toolkit includes an example application, SATSADemos, that has working versions of the concepts outlined in this chapter. Consult the Sun Java Wireless Toolkit User’s Guide, Appendix A, for instructions on running SATSADemos.

25.3. Basic Smart Card Communication

The SATSA-APDU API provides basic communication to smart card applications. It consists of a single interface, javax.microedition.apdu.APDUConnection, which is an extension of the Generic Connection Framework (GCF).

To communicate with a smart card application, you need to know its identifier, a magic number expressed as a series of hexadecimal numbers. Then open a connection to the smart card application like this:

The connection URL includes the slot number, 0, and the application identifier. Once the connection is established, you can send and receive data using APDUConnection’s exchangeAPDU() method.

When you’re finished talking to the smart card, close the connection. Use a finally block to ensure the connection is shut down.

25.4. Smart Card Communication with Java Card RMI

Using SATSA-JCRMI is similar to using SATSA-APDU, but you use a remote object to do work on the smart card, which follows RMI’s distributed object model. Your application needs a local stub class that contains the same methods exposed by the smart card application.

The SATSA-JCRMI API consists mainly of javax.microedition.jcrmi.JavaCardRMIConnection but also includes some RMI-related classes.

Making the connection is similar to using SATSA-APDU. You need to specify the card slot and application identifier:

Next, get a reference to the remote object (a stub, really) by calling getInitialReference() on the JavaCardRMIConnection. You must cast the returned Object to the appropriate stub type. Here is an example:

Now you can call methods on the stub, which invokes methods on the remote object on the smart card. When you’re finished working, remember to close the connection.

25.5. Generating Signatures

SATSA-PKI gives your application the ability to sign data using a smart card or to manage certificates. SATSA-PKI has two main classes:

CMS refers to the Cryptographic Message Syntax defined by RFC 2630 and RFC 2634.

http://www.ietf.org/rfc/rfc2630.txt

http://www.ietf.org/rfc/rfc2634.txt

Your application uses CMSMessageSignatureService by calling its static methods sign() or authenticate(). The implementation will locate an appropriate key and use a smart card or other appropriate mechanism to sign some data.

The only real difference between sign() and authenticate() is the type of key that the implementation will find. Bear in mind that the implementation is likely to display one or more prompts to the user, to verify the use of a key, ask for a PIN, and so on.

You can limit the key search by supplying a list of allowed issuing Certificate Authorities (CAs). You can also use options to affect the exact format of the generated signature.

A typical use would be for a client application to sign a small message and send it to a server. The server can verify the signature on the data to be sure the message has not come from an imposter.

25.6. Managing Certificates

The other part of SATSA-PKI is UserCredentialManager, which allows applications to manage the keys that are available to CMSMessageSignatureService.

Use UserCredentialManager’s addCredential() method to add a key, represented by a certificate path, to the certificate store. The specification is deliberately vague about the location of the certificate store; it might be on the device, or it might be in a smart card. The certificate path is a byte array, which is normally a CA’s response to a Certificate Signing Request (CSR). You have to supply a human-readable name for the key.

The generateCSR() method creates a request to a CA for a signed certificate. Most of the time, an attached smart card is used to generate a new key pair, which is then wrapped up in a CSR. Your application can submit the CSR to a CA server for signing. The response can then be passed to addCredential() to add it to the certificate store.

Finally, use removeCredential() to remove a certificate from the certificate store.

25.7. Cryptography

SATSA-CRYPTO provides three cryptographic tools in an API that resembles Java SE.

25.7.1. Using Message Digests

A message digest can be used to generate a “fingerprint” for a set of data. In SATSA-CRYPTO, java.security.MessageDigest is the corresponding class.

Get a MessageDigest instance by passing an algorithm name to the static getInstance() factory method:

Next, feed the MessageDigest data with the update() method.

Generate the digest value by passing an appropriate byte array to digest().

25.7.2. Using Signatures

A signature is a lot like a signed message digest. It acts as a fingerprint of data, but it is generated using a private key and can only be verified using the matching public key.

Back in the world of SATSA-PKI, CMSMessageSignatureService is capable of generating signatures. In SATSA-CRYPTO, java.security.Signature can verify signatures.

You’ll need the correct public key to verify a signature. Loading and manipulating keys is outside the scope of this chapter, but you can find information on this topic in the SATSA Developer’s Guide.

Obtain a Signature object using the getInstance() factory method. The following example requests a Signature that uses SHA-1 to generate a message digest, then encrypts or decrypts the digest value using an RSA cipher.

Now initialize the Signature for verification with the public key.

Just as you did with MessageDigest, pass the data whose signature will be verified using update():

Now pass the expected signature value to verify(). If everything checks out, this method returns true.

25.7.3. Using Ciphers

The javax.crypto.Cipher class allows for general-purpose encryption and decryption using symmetric or asymmetric ciphers.

The basic steps for using Cipher are as follows:

1. Create a Cipher by passing an algorithm to the factory method getInstance(). Along with the algorithm name, you can also specify a mode and a padding scheme. For example, AES/CBC/PKCS5Padding means to use the AES cipher in the CBC mode with PKCS #5 padding.
2. Initialize the Cipher with a key and a flag that indicates whether you want to encrypt or decrypt data.
3. Feed the Cipher data with the update() method.
4. Send the last data to the Cipher with doFinal().

Both update() and doFinal() perform encryption or decryption directly, taking input data and placing output data in arrays you supply.

25.8. Summary

SATSA defines four APIs for smart card communication and cryptographic functionality. SATSA-APDU provides basic smart card communication, while SATSA-JCRMI is a smart card communication API based on remote objects. Both SATSA-APDU and SATSA-JCRMI are extensions of the Generic Connection Framework.

SATSA-PKI allows applications to request digital signatures from a smart card or other security device. In addition, it provides methods for applications to add or remove keys and their associated certificates.

SATSA-CRYPTO provides message digests, digital signature verification, and general-purpose ciphers for applications with sophisticated cryptographic requirements.