LJ Archive

Smart Cards and Biometrics: Your Key to PKI

David Corcoran

David Sims

Bob Hillhouse

Issue #59, March 1999

The cool way to make secure transactions.

For centuries, security was synonymous with secrecy. The shared secret—conducting business between two parties who each knew the code—was a worldwide approach. Even in this age of electronics and supercomputers, passwords and PINs are shared between you and the computer or ATM machine to which you want access. But secret passwords require a great deal of trust between parties sharing the secret. Can you always trust the administrator or other users of the machine you are accessing? Most computer break-ins today are due to compromise by system users or by a hacker who uses a legitimate account (possibly yours) to gain access to general security—sometimes even gaining superuser access. This traditional paradigm of shared-secret computer security could soon be a thing of the past with smart-card-based cryptographic credentials and biometric authentication for access control.

Some individuals and companies are replacing shared secret security (also called symmetric security) with the Public Key Infrastructure (PKI) approach. PKI uses a standardized set of transactions using asymmetric public key cryptography, a more secure and potentially much more functional mechanism for access to digital resources. The same system could also be used for securing physical access to controlled environments, such as your home or office.

In a PKI world, everyone would be issued at least one cryptographic key pair. Each key pair would consist of a secret (private) cryptographic key and a public cryptographic key. These keys are typically a 1024-bit or 2048-bit string of binary digits with a unique property: when one is used with an encoding algorithm to encrypt data, the other can be used with the same algorithm to decrypt the data. The encoding key cannot be used for decoding. Public keys are certified by a responsible party such as a notary public, passport office, government agency or trusted third party. The public key is widely distributed, often through a directory or database that can be searched by the public. But the private key remains a tightly guarded secret by the owner. Between sender and receiver, secure messaging (or other secure transaction) would work as described below.

Figure 1. Sender

For the sender (Figure 1), the following steps occur:

  1. Message data is hashed; that is, a variable-length input string is converted to a fixed-length output string. Hash functions are mainly used with public key algorithms to create digital signatures.

  2. A symmetric key is created and used to encrypt the entire message. DES and IDEA are examples of symmetric key cryptography.

  3. The symmetric key is encrypted with the receiver's asymmetric public key.

  4. The message hash is encrypted with the sender's asymmetric private key, creating a digital signature independent of the encrypted message.

  5. The encrypted message, encrypted symmetric key and signed message hash are sent to the receiver.

Figure 2. Receiver

For the receiver (Figure 2), these steps occur:

  1. The encrypted symmetric key is decrypted using the receiver's asymmetric private key.

  2. The symmetric key is then used to decrypt the message body.

  3. The encrypted hash is decrypted with the sender's asymmetric public key.

  4. The decrypted message is then rehashed with the original hashing algorithm.

  5. The two hashes are compared to verify the sender's identity and serves as proof that the message was not altered in transit.

Several technical issues must be solved before this scenario can be realized:

  • Secure key storage

  • Secure authentication to the key store

  • Directory services (central public key database)

  • Key escrow or other emergency recovery method for encrypted data

  • Cross-platform standards (Microsoft PC/SC, Netscape SMIME, Intel CDSA, IBM OSF, etc.)

  • International export and usage regulations for strong cryptography

If these issues seem daunting, remember how impossible a common network strategy once seemed. Today, the Internet is everywhere and connected to almost every type of computer. Let's consider the PKI issues one by one.

Secure Key Storage

A few possibilities exist for key storage. Remember that these keys are long bit strings and memorizing them is out of the question. There are three storage possibilities: hard disk, floppy disk and smart card.

Hard disk storage provides a low-cost solution. The user's key pair is stored directly on the user's machine. The user authenticates with a shared-secret password to unlock their private key for signing. This solution does not allow for easy mobility in a desktop environment, and it put constraints on terminal applications. A user cannot easily use another machine without offloading the information to the machine they are trying to use. Problems also arise if a user tries to log in to another machine and the network is unavailable. Hard disk storage also lends itself to physical attacks, such as theft of the terminal or hard drive, both of which can be used for leisurely password cracking.

Floppy disk storage addresses the mobility problem. Now the user has a quite inexpensive and portable way of using mobile digital credentials. Someone could use another machine simply by inserting the floppy and using a traditional shared secret password for authentication. However, floppy disks are not well known for long term, robust data retention, particularly when carried around. Floppy disks are susceptible to magnetic fields (airport security stations, for example) and do not fit conveniently into your pocket or wallet.

Smart card storage presents the best scenario. Smart cards have been used for many years in Europe for a variety of applications. These credit-card-sized computers have a rugged and familiar form that fits nicely into a wallet or pocket and can take lots of physical stress. Some modern processor-based smart cards even have on-board cryptographic co-processors that allow signing and key generation to be done entirely on the card, so the private key might never need to be revealed or offloaded. The microprocessor gives the smart card a big advantage over magnetic or optical media storage. A smart-card-based PKI might be very secure indeed, eliminating any possibility of the key pair being snooped out during creation and transmittal. The initial expense is higher, since smart cards require a reader. But this additional cost is offset by much higher security for the private key and by convenient porting.

Secure Authentication with Biometrics

All three storage methods—hard disk, floppy or smart card—could use symmetric encryption (shared-secret password or PIN) to secure the private key. This accommodates single sign-on, since once a user authenticates to the key store, cryptographic protocols can be used for subsequent authentication to different applications. This would be good from an administrative point of view, but makes the security situation much worse. Now, if a cracker gains access to the shared secret password or PIN that secures the cryptographic keys, he also gains access to every cryptographically protected application or data element available to the authorized user. What we need is an authentication method to which only the authorized party has access. Enter biometrics.

The word biometrics comes from the Greek words bio and metric, meaning “life measurement”. By measuring something unique about an individual and using that to identify them, we can achieve a dramatic improvement in security of the key store. Newer biometric measurements include DNA from tissue samples, voice pattern, face pattern or even the arrangement of blood vessels in the retina or pattern of coloration in the cornea of the eye. The oldest and most widely accepted biometric is the fingerprint. The tip of every finger has a characteristic called “friction ridges”. While generally similar, no two friction ridges are exactly the same. By imaging the ridges of the fingertips, we get the fingerprint.

Most implementations of fingerprint biometrics create a template from the original image, which is a fraction of the size of the original fingerprint image. This template can be used only to compare the fingerprint against other templates, and it cannot be used to recreate the original image. Template implementations of biometrics fit well with smart cards for two reasons. First, they usually range from 100 to 600 bytes in size and can easily fit on a smart card. Second, you don't have to worry about an attacker reproducing your fingerprints from your templates and using them to impersonate you. Biometrics can aid authentication. Here is a rough outline of the procedure for authenticating yourself to a computer application:

  1. Insert your smart card into a reader. The smart card contains your cryptographic keys and biometric fingerprint data.

  2. Enter your shared-secret PIN (or password), in order to unlock the digital representation of your fingerprint. In the trade, this is known as the minutia data.

  3. Place your finger on the scanner. The scanned fingerprint is compared to the fingerprint data on the smart card.

  4. If the data matches, the smart-card fingerprint data is converted into a number and combined with the smart-card secret PIN (retrieved in Step 2) and used as a symmetric cryptographic key to decrypt the private key.

  5. A nonce (random number) is passed from the computer application to the smart card.

  6. The private key on the smart card is used to encrypt the nonce and pass it back to the application.

  7. The application verifies that a certified public key obtained from the network-based directory service or from the card does, in fact, decrypt the encrypted message from the card and reveal the same nonce that was originally passed to the card.

This process irrefutably authenticates the person presenting the card as the same person to whom the cryptographic keys belong and provides the necessary tight binding between the cryptographic key storage and the authorized user of the cryptographic keys.

By this time, you are probably asking, “Just how well do these biometrics work? What is the margin for error?” Two terms describe the functionality of biometrics. The false acceptance rate (FAR) is the probability that an intruder is accepted with a measurement that does not belong to the enrolled user. The false rejection rate (FRR) is the probability that an enrolled user is not recognized. Good biometrics have low FAR and low FRR, but unfortunately few standardized tests are available to determine these results, as each biometric read takes measurements in a slightly different way. Thus, third-party verification is very important when evaluating any biometric.

As a rule, there is usually a trade-off between security and convenience. Biometrics are no exception. In general, the better their security (the lower the FAR), the more inconvenience there is to the user, because more false rejections occur. Similarly, the more convenient the system is to use, the poorer the security is. Good biometric systems allow the user to choose from a wide range of possible FAR/FRR levels, so that convenience can be maximized for the desired level of security.

Exposure to a few detective movies can cause the average person to ask the macabre but pertinent question, “How can these devices ensure that the finger is alive?” Attempts have been made to solve this problem. Some vendors measure the heat of the finger to ensure that it is at body temperature, which makes the system difficult to use in cold climates or with people who are predisposed to cold hands. Other vendors measure the conductivity of the finger to prevent forged fingerprints (for example, silicone castings). This does not address the dead finger issue, but it is worth noting that conductivity measurements can be fooled with a bit of saline solution on the silicone casting. The best solutions spectroscopically measure the amount of oxygenated hemoglobin in the blood, as this measurement is the most difficult to fool and is radically different for live and dead fingers, but again there is a trade-off between price and necessity. Are you authenticating yourself to a space shuttle launch or the garage door?

Figure 3.

One of the best products to merge smart-card technology and biometrics is the BioMouse Plus from American Biometric Company (http://www.biomouse.com/). The BioMouse Plus is an integrated smart-card reader and fingerprint scanner. A Linux toolkit is provided for developers, with documentation on how to create biometric and smart-card aware applications. The toolkit is complete with examples, sample source code, drivers and libraries. In fact, over 13 platforms are supported, including most flavors of UNIX, Windows and MS-DOS.

The Central Public Key Database

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.

A Variety of Standards

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/.

Export Regulations

The laws regarding export of strong cryptography are a patchwork quilt at best; collectively they represent possibly the largest hurdle to be overcome. Solutions that employ message recovery features such as multiple key encryption or key recovery will help move legislation forward. Currently, the worldwide nature of the Linux development community and the modular approach of the MUSCLE project would seem to facilitate the spread of this technology.

Conclusion

Integrating smart cards, biometrics and public key cryptography provides a solid foundation for developing secure applications and communications. The highest level of security uses three-factor authentication:

  • Something you know (password or PIN)

  • Something you have (smart card, magnetic stripe card or a physical key)

  • Something you are (your fingerprint, retinal/iris scan or voice pattern)

An individual gains three-factor authentication by combining a smart card, biometric and PIN. If the user loses the smart card, the card is inoperable without the biometric. Forged fingerprints are weeded out with use of the PIN.

In a smart-card-secure world, you are not locked into one form of authentication, such as the ever-vulnerable password. You control your identity because it is contained on the card you carry with you. Even if attackers run Crack 5.0 on your Internet provider's password file, they cannot gain access without possession of the smart card tucked safely in your own front pocket.

The argument for improved security is a noble one. Some methods of achieving improved security may use expensive hardware and still be relatively easy to compromise. Most symmetric forms of security fall into this category. It is only a matter of time before a shared secret is no secret at all. Smart cards combined with biometrics provide today's best approach to secure electronic data. But as your mother may have told you, the only way to truly keep a secret is never to share it.

David Corcoran is a student studying Computer Science at Purdue University. He works with the COAST/CERIAS labs directed by Gene Spafford and also as a Knowledge Worker for Schlumberger Limited in Sugar Land, Texas. He can be reached at corcordt@cs.purdue.edu.

David Sims is the Technical Manager of Information Technology for Schlumberger Limited, based in Sugar Land, Texas. He holds a BS degree in Mechanical Engineering from Washington University in St. Louis, Missouri. He can be reached at sims@sugar-land.sl.slb.com.

Bob Hillhouse is a Senior Software Engineer for American Biometric Company. Based in Ottawa, Ontario, Canada, he holds a BMath degree in Computer Science with Electrical Engineering Electives from the University of Waterloo. He can be reached at bob@abio.com.

LJ Archive