Smart Cards and Biometrics: Your Key to PKI
Directory services play an essential role in any PKI system. Applications must be able to verify the certificate authority of the public key contained on the smart card. The certificate authority is the organization that initially issued the encryption keys and smart card. The certificate authority verifies that the person is who they claim to be. If privacy concerns can be overcome, public keys (for the certificate authority and for the individual) should be available to all applications that need cross verification.
PKI at the office: a person has a smart card containing cryptographic keys secured with biometrics and signed (validated) by a government agency. Now the person applies for a job in the private sector. If the company verifies that the government signature is valid, the person's public key can be used for employment verification. The smart card is essentially reusable as identification.
Personal Banking: this application makes a binding between the application, the public cryptographic key and personal data stored in an employee directory. Again, the original single identity token is reused. Directory services and biometrically secured cryptographic key storage would truly enable electronic commerce. Such a scheme, if widely adopted, would allow an individual to carry a single convenient token to authenticate themselves to applications anywhere.
Assuming that a smart-card-enabled PKI works for all other reasons, a few issues must still be overcome with regard to standards and cross-platform performance. The smart-card environment needs standard resource managers and APIs for communicating to the card via the card reader. These APIs are generally card-specific. Some APIs are reader-specific. Since most smart cards adhere poorly to common standards such as ISO-7816-4, it is necessary to have a high-level API for communicating to all cards. The same is true for readers. Generally, a reader's resource manager tracks the different readers installed on the system and monitors events such as card insertion and removal. This resource manager is also responsible for transferring control of the smart card to other applications, so that multiple applications can communicate with the card.
Card management tracks communication speeds and the currently selected file. Consider the following example: application B wants to offload data from elementary file 0200. Application A is in wait state but currently has selected file 0001. The card manager must keep track of this file so that when application B takes control, selects 0200 and performs data transfer, application A can regain control upon completion and reselect elementary file 0001. Without such resource management, a user must assume another transaction has occurred and do a cold reset before any file or verification-related transaction.
Cards contain specific functions that make them unique. The most common is the cryptographic-capable smart card. In this card, it is necessary to have yet another common API which communicates with the card manager. This API is known as the cryptographic service provider. The cryptographic API performs functions such as key generation, secure signing, hashing, encryption and key verification.
Just as several standards exist for card and reader resource managers, quite a few proposed standards have been made for cryptographic service providers. One of these is the PKCS-11 standard, driven mainly by Netscape. Microsoft, of course, proposed a different standard, called the Crypto API (CAPI). Intel is also making a run at the cryptographic middleware market with the release of CDSA. CDSA is more of a framework than an API and takes advantage of CAPI and PKCS-11. CDSA and PKCS-11 both lack one major component for a system: card and reader management. Neither CDSA nor PKCS-11 was designed specifically for cryptographic tokens, but both would fit nicely with other card and reader managers. Microsoft's model encompasses a specification known as PC/SC. PC/SC handles all card and reader resource managing and fits with the CAPI for cryptographic support. All of these specifications can be found at http://www.smartcardsys.com/.
On the open standards end, IBM has created support for reader and card resource managing in a cross-platform style using Open Card Framework (OCF). This is a purely Java-based card and reader resource manager that runs on most operating systems with a working JVM (Java Virtual Machine), including Linux. Nice idea, but what is missing? OCF fails to include cryptographic support, although an open version of PKCS-11 would probably fit nicely on top of the infrastructure. If this PKCS-11 is written in ANSI C, then users of superior workstations such as Linux, Macintosh and Sun could have all the support included on Microsoft systems. A port of CDSA for non-Microsoft operating systems would also be nice, since one could imagine better portability to a Microsoft OS. In fact, a PC/SC-compliant resource manager for non-Microsoft systems would limit cross-platform compatibility only by the low-level reader driver code.
The MUSCLE project is currently working on a C-based resource manager for smart-card readers. The resource manager uses remote procedure calling to make remote authentication possible. For more information, visit http://www.linuxnet.com/smartcard/.