Michael F. Jones
Bruce Schneier
Security concerns impose a severe constraint on a vast array of products and services that can be offered within the context of the World Wide Web. Electronic commerce on the Web will be enabled by emerging security protocols such as S-HTTP and SSL. Introducing additional choices such as Microsoft's recent release of STT and PCT may have the effect of causing confusion and, therefore, delaying implementations. However, it is clear that serious attention to security has now become mainstream. S- HTTP and SSL, which incorporate Public-Key cryptosystems, are just beginning to be implemented by WWW applications developers. Recent announcements by major software vendors indicate that widespread implementation of these standards is likely to occur [10].
Public-Key cryptosystems involve an authority issuing a pair of complimentary encryption keys to each user in the system. One of the keys is intended to be made public, analogous to an email address, and is called the Public-Key component. The other key in the pair must be available for use only by the "owner" of the key-pair and is called the Private-Key component. Application software making use of the key-pairs provides users with a rich set of security functions that essentially lifts the current constraints on electronic commerce in the WWW environment. For an introduction to Public-Key cryptography, please refer to [3].
Although Public-Key cryptosystems have many desirable characteristics in securing distributed systems, they typically rely upon the ability of the system to protect the beneficial use of the Private-Key component from all but the intended user. If the Private-Key component can be copied, or is made public, the authenticity of transactions using that Public-Key pair are called into question and therefore, cannot be trusted. In the commercial internetworked environment, software-only solutions for protecting the Private- Key component are inherently vulnerable to attack by viruses and other methods of compromise such as password guessing schemes.
Smart Tokens, the subject of this paper, are hardware devices with associated software that have the ability to perform Private-Key operations without the Private-Key ever being vulnerable to compromise. The WWW security community is in general agreement that Smart Tokens will play a major role in the future of electronic commerce on the Internet. This paper further describes a Smart Token implementation with characteristics that make it suitable for use with general purpose software applications such as word processors, email packages, and WWW browsers. Portability and isolation from the hardware layers are important architectural goals. Finally, a major electronic commerce application in which the Smart Token is used as the analog of traditional checkbook functionality is then discussed.
A "smart token" is an easily portable device that does special-purpose operations for its user, generally identifying the user to some larger computer system. A smart token can look like a PC Card, 3.5" diskette, credit card, pocket calculator, or many other things--the important feature is that it carries some secret information for you and that it does some internal calculations when you need them performed. A smart token is often designed to be tamper-resistant: It is difficult to take apart. It is protected with a user password, so that even if it is physically stolen, it will be difficult to impersonate its owner.
Just as most pocket calculators are used to do arithmetic, most smart tokens are used to identify their user to some remote computer. If the user's identification checks out, then she is allowed to do something: make a purchase on her credit card account, read her email from a public terminal, board a plane, or log in to a remote computer system, etc.
To see the value of this, consider making a purchase on the Internet. People used to type their credit card numbers directly into a computer, and then send those numbers to the merchant. This is insecure both because those credit card numbers can be easily collected by someone who monitors network traffic, and because the merchant has no way to confirm that the person who typed in the credit card number is the same person who owns the credit card.
Current solutions include encryption, which hides the buyer's personal information during transition, and digital signatures, which confirm the identity of the buyer. Financial models include digital checks, digital credit cards, and digital cash. These solutions protect against network monitoring, but do nothing to stop password guessing, password collection at the buyer terminal, or password compromise. The seller still has to trust that the person who signed the digital payment order has not accidentally disclosed his password or private signature key.
Tamper-resistant tokens are needed to compute the digital signatures for electronic commerce applications; they are the best way to prevent disclosure of the signer's private signature key. If the private signature key is disclosed, then anyone can use it to forge the signer's signature. If significant numbers of private keys are disclosed and are used to forge electronic checks, electronic credit cards, or electronic cash, then these forms of money will not be accepted. In a situation like purchases on the WWW, where other forms of identification can't be used, merchants must rely on the security of the signer's private signature key.
Enough tamper-resistance is needed to make it economically unattractive for attackers to steal signature cards, extract the private key, and pass bad "checks" with that key before the card is reported stolen and the account changed.
Smart tokens often require a password in order to function. This provides the token some certainty that the person using it is the person who is supposed to be using it. This isn't always necessary--for some applications, entering a password each time the token is used is more trouble than it's worth. In general, if a person can use the token to spend money or access sensitive data, it will have a password. The user enters the password on his keyboard, or directly into the token via a keypad. Even if the computer has been hacked to record passwords, that won't allow anyone to break the system; they still have to get possession of the smart token.
The most common application for a smart token is to convince some larger system of a user's identity, so that the larger system, perhaps with help from the token, will allow the user to do something. Protocols for proof of identity are a well-studied area of cryptography, and several techniques are discussed in [8]. For example, in order to allow a user to log in to a remote system, a computer might require the user to use a "one-time password" stored in the token. Since only the token and the remote computer know what the next password should be, only this token could have given the right password.
Once the user and token have identified themselves to the larger system, then the system and the token can work together to allow the user to do something. For example, a software metering token, after it has identified itself to the software being metered, can authorize another execution of the software and increment its internal counter by one.
Secure tokens can also be used to implement protocols for electronic auctions, secure voting, anonymous transactions, and others.
This section is meant as a brief introduction to the operations of smart tokens. To get a better understanding of the algorithms and protocols discussed here, see [2, 8].
In order to integrate cryptographic functionality with "off the shelf" commercial software, there have been many recent efforts to develop a modular Cryptographic Application Program Interface (CAPI). Of these, there are three proposals that are proving to be widely accepted. They are the GSS-API (Internet Engineering Task Force)[5], the GCS-API (X/Open)[9], and Cryptoki (RSA)[5].
Although it is beyond the scope of this section to describe these three CAPIs, it is important to note that they differ significantly in the degree of cryptographic knowledge required on the part of the application developer for implementation. The GSS-API requires the least knowledge of the underlying cryptography and Cryptoki requires the most understanding. In addition, Cryptoki is the only one of the three CAPIs that was written primarily for smart cards and tokens. It includes an abstract token interface that is intended to be the only layer in a software architecture that requires change in order to implement a wide variety of Smart Tokens. A useful analysis of CAPIs can be found in [7].
Since Cryptoki requires more knowledge of the underlying cryptography, it will be helpful to some application developers for an additional higher level API to be provided along with the Smart Token software development tools.
The currently implemented Smart Token combines high-density flash memory and data security functions in a ubiquitous PC Card Type I package. It is compatible with PC Card release 1.x and 2.x memory card specifications. The design provides the computer user with removable, secure nonvolatile memory plus data and communications security support in a single package.
This Smart Token implementation is available with storage capacities from 1 to 24 Megabytes. In normal operation, the Smart Token's memory is compatible with host computers having PC Card adapter slots for additional memory or removable media. The Smart Token uses flash memory with 64-Kbyte block erase capability and supports both word-wide and byte-wide transfer modes.
Security features provide memory access control as well as support for data security functions such as secure remote log in, Public-Key encryption, digital signatures, etc. The security feature is provided by the FIPS PUB 140-1 Level 3 compliant Cryptographic Support Processor (CSP) embedded in the card. The CSP is an integrated circuit based on ISO standard smart card technology which is recognized internationally as a secure vessel for key and password storage. The Smart Token's CSP provides secure computing functions such as random number generation, key encoding, and key comparisons, while the private key information never leaves the secure silicon. Multiple passwords can be stored on the chip.
Passwords stored in the CSP can be changed, but not read, by host resident software. The Smart Token is shipped with default memory passwords installed in the CSP. The operating environment and software resident in the CSP prevents access to the secure storage, but allows certain defined operations using the secure data. The CSP can detect physical security violation, attempts such as probing the chip, de-soldering the chip, and electronic probing involving single stepping the clock.
Access to the CSP is through host-resident software and Smart Token drivers described below. The electrical interface between the host and the Smart Token is compatible with PC Card memory-only release 1.x and 2.x. Data transfer between the host and the CSP interface is controlled by the card interface ASIC which supports the ISO 7816-3 standard. Host resident software supports the RSA Cryptoki standard.
The presence of the CSP allows host resident software to execute secure data interchange such as remote login, data communications, digital signatures, information "metering," and electronic funds transfer (EFT), using standards including DES, DSS, PKCS, and RSA. The Smart Token is all solid state, requires no batteries and is robust compared to storage media such as floppy disks.
This section provides an overview of the software architecture of the PC Card Smart Token. Applications are presented in a Microsoft Windows 3.1 environment, with PC Card software support provided by SystemSoft card and socket services. Some of the architectures presented are considered to be building blocks for higher level functionality and are designed in a way which will promote future advanced application development. There are six major software components which interface with various levels of DOS, Windows, and PC Card architectures:
Figure 1. Software components of PC Card Smart token
The Financial Services Technology Consortium (FSTC) is a collaboration of major banks, technology companies, and laboratories that was formed to address the critical need for viable means of conducting electronic commerce on public networks such as the Internet. Currently, over sixty organizations are members of the consortium. A secure payment system and deposit gathering mechanism for the banks is considered to be an essential enabling component in the commercialization of these networks.
The Electronic Check Project was developed by the FSTC to provide a secure, all electronic payment system modeled after the familiar paper check. It is an integration of a traditional form of payment within the existing financial services infrastructure and the rapidly growing electronic networks. A detailed description of the project, the functional flows and its objectives can be found in [4]. On September 21, 1995, a live demo of the Electronic Check Project took place at the Bank of America in San Francisco. Participants in the demo included Bank of America, Bank of Boston, Bank of Montreal, Bank One, Chemical Bank, BBN, IBM, Sun Microsystems, Telequip, and Bellcore.
The demo was conducted over the Internet using the World Wide Web. It included the purchase and payment by electronic check of a "Teddy Bear" for the Vice President of the United States, Al Gore, from PC Gifts and Flowers. One of the more remarkable aspects of the demo was that the check actually cleared electronically through the Automated Clearing House of the US banking system. Telequip's PC Card Smart Token implemented as described in the preceding section, performed the role of the Electronic Checkbook, generating and signing the first electronic check through the U.S. banking system.
In the demo and subsequent pilot program, Electronic Check makes use of a PC Card Smart Token in the form of an Electronic Checkbook which can be used within the context of the World Wide Web. A Web browser in conjunction with an Electronic Check application has been integrated with the implementation described in Section 4. Two additional software layers are provided between the Electronic Check client application and the Cryptoki API in order to provide a higher level interface as discussed in Section 3 and to fulfill specific functional requirements of the Electronic Check initiative. The overall goal of this architecture is to make maximum use of existing standards and lower the risks associated with lower level interfaces to cryptographic devices.
Unlike some of the newer stored value proposals for electronic commerce such as Mondex, Electronic Check is based on the familiar paper check model. Email is substituted for paper delivery by the postal service and digital signatures on the Electronic Check message replace the hand written signatures on paper checks. Since the functional flows are essentially the same as in the paper check model, the system is easy to understand. It is anticipated that rapid adoption of the Electronic Check will take place due to ease of integration and significant cost savings. Support for payment instruments like certified checks, cashiers checks, credit card charge slips, and additional features such as future dating, limit checks, and multicurrency payments can be accommodated.
Several scenarios for functional flows are described below. Figure 2 depicts the typical Electronic Check flow. The payer receives an invoice from payee, generates an Electronic Check, and sends it to the payee via email. The payee then emails the received payment to his bank and settles the transaction with payer's bank.
Figure 2. Electronic check flow
In Figure 3, the payer receives a bill/invoice from payee, issues an Electronic Check, and sends it to the payee. The payee presents it directly to the payer's bank to be paid to the payee's account at his bank.
Figure 3. The cash and transfer scenario
In Figure 4, the Payer receives a bill/invoice from payee, issues an Electronic Check, and sends it to the payee's bank, either directly or via a lockbox. The Payee's Bank then sends accounts receivable information to the payee and clears the payment with the payer's bank. In this scenario, there may be no payee endorsement.
Figure 4. The lockbox scenario
In Figure 5, the payer receives a bill/invoice from his bank, (assuming electronic bill presentment allows for capture of the payee's bills by the payer's bank), issues an Electronic Check, and sends it to his bank. The payer's bank, in turn, transfers funds to the payee's account at the payee's bank.
Figure 5. The funds transfer scenario
The demonstration phase of the project was completed in September of 1995. A limited commercial pilot
is expected to commence in 1996 and be in place for approximately six months. After evaluation and
subsequent modifications have been implemented, a more extensive pilot will be followed by a full
production version of the system.
Smart Tokens have the potential to enable a revolutionary expansion in products and services that can be offered on internetworked systems. The essential elements needed to bring this expansion to fruition are just beginning to appear in the marketplace. APIs have now evolved to the point at which mainstream commercial software applications can be architected to include Smart Token capability as a standard feature. Implementations in conjunction with projects initiated by major financial institutions, such as the one described in this paper, offer a starting point and a glimpse of a whole new industry that will underpin the future of electronic commerce on the Web.
The authors would like to thank John Kelsey, who assisted with the theoretical sections on smart tokens, and Chris Carlisle, who assisted with the section on the current implementation GLOSSARY OF CRYPTOGRAPHY TERMS
1. R.J. Anderson, "Why Cryptosystems Fail," Communications of the ACM, v. 37, n. 11, Nov 1994, pp. 32-40.
2. D.W. Davies and W.L. Price, Security for Computer Networks, John Wiley & Sons, 1989.
3. P. Fahn, "Answers to Frequently Asked Questions About Today's Cryptography," Version 2.0, RSA Laboratories, 1993
4. FSTC, "Electronic Check Proposal: Public Document," Financial Services Technology Consortium, 1995
5. B. Kaliski, PKCS #11, Cryptoki, RSA Laboratories, 1995
6. J. Linn, "Generic Security Service Application Programming Interface," RFC 1508, Nov 1993.
7. National Security Agency, "Security Service API: Cryptographic API Recommendation," NSA Cross Organization CAPI Team, 12 Jun 1995.
8. B. Schneier, Applied Cryptography, Second Edition, John Wiley & Sons, 1996.
9. X/Open, "X/Open Preliminary Specification: Generic Cryptographic Service API," draft 3, Mar 1995.
10. M. Zurko, "WWW Security Standards Forecast: Partly Cloudy," IEEE Cipher #7, 1995