Java Reference
In-Depth Information
security token smart cards. Suitable for low-level communications, the APDU interface
deals at the level of individual bytes exchanged with cryptographic hardware; for many
applications, the SATSA-JCRMI API may be more appropriate. The other two APIs—
SATSA-PKI API and SATSA-CRYPTO—provide high-level cryptographic services to your
application.
■
Caution
As I write this, there is no unified SDK that implements all of these optional packages for either
NetBeans or the older Sun Java Wireless Toolkit. Worse, not only are the packages described in JSR 177
optional, but a vendor may choose to only implement
some
of the packages described in JSR 177. This has
the potential for serious fragmentation of the availability of these APIs.
Communicating with Cryptographic Hardware
Using the APDU API
Today's smart cards secure many popular consumer electronics devices, including some
phones, computers, and consumer electronics set-top boxes. They're also a key security
feature of some industrial communications control systems. At its heart, a smart card is
simply a small plastic card with one or more hardened embedded circuits inside, provid-
ing memory and possibly processing power. Smart cards typically include tamper-
resistant properties such as a secure file system, a secure microprocessor, and human-
visible tamper-indicating devices such as holograms or other information. Some smart
cards include support for cryptographic functions such as key generation and cipher
algorithms; the purpose of the SATSA API is to support accessing these cards using Java
ME-enabled hardware.
At the lowest software level, hardware such as a Java smart card or USIM communi-
cates with its host hardware using a channel of bits and bytes, similar to a network socket
or serial port. The International Organization for Standardization (ISO) provides ISO 7816
to describe the mechanical, electronic, and software communication scheme between
smart cards and their host hardware. The software scheme relies on the notion of
application identifiers (AIDs) that permit the selection of a specific smart card function;
communication to the smart card is accomplished using an ISO-defined protocol of
application protocol data units (hence the name
APDU
for the protocol used by the
SATSA package to communicate with the card).
Because this low-level access to card functions consists of the exchange of bytes
across a communications channel, you might think the Java GCF would provide an excel-
lent means to support this communication, and you'd be correct. Figure 15-1 shows the
relationship between the GCF classes and the APDU hierarchy.
