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.
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
.
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
.
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.
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.
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.
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.
SATSA-CRYPTO provides three cryptographic tools in an API that resembles Java SE.
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()
.
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
.
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:
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.Cipher
with a key and a flag that indicates whether you want to encrypt or decrypt data.Cipher
data with the update()
method.Cipher
with doFinal()
.Both update()
and doFinal()
perform encryption or decryption directly, taking input data and placing output data in arrays you supply.
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.
3.149.241.250