Check out the new USENIX Web site. next up previous
Next: Smart Cards in Hostile Up: Session I: Hardware Tokens Previous: Tamper Resistance - A

Token-Mediated Certification and Electronic Commerce

Daniel E. Geer and Donald T. Davis, Open Market, Inc.

Dan began by noting that public key cryptography usually expects the use of certification authorities (CAs) to remove the need for real-time authority participation; he then suggested that we consider what could be done if certificates were made really cheap and disposable. For example, a smart card in the wallet could be trusted to act as a CA and generate certificates on a per-transaction basis, not to supplant existing CAs and certificates, but as a supplement. This could allow us to get highly scalable access control and simpler payment protocols.

As one possibility, we could have a delayed purchase scenario, in which the goods are not currently available at the time of purchase. We generate a certificate for the merchant which is a public key, an authorization to deliver (download) goods, and an expiration. The raw material required for this would be a smart card with reader, a cryptographic coprocessor, a secure key store, browser support for smart cards such as a Netscape plug-in or Microsoft cryptographic API, and certificates such as X.509v3. No certificate directory or revocation lists would be required. The card owner would begin by generating two key pairs, one for the owner and one for the card, and would certify the card's key with the owner's key. The private keys could then be deposited with a key recovery center, cross-encrypted with the public keys.

Dan argued that there would be many advantages to such a system. For authorization, he stated that such certificates correspond naturally to roles, and that roles scale better than access control lists and are easier to think out properly than capabilities. He pointed out that revocation would be unnecessary because these certificates are both short-lived and not generally published. He listed advantages of this scheme for electronic commerce including: ease of set up, design and management; the ability to do delayed fulfillment such as prime-time purchases with off-time deliveries; fewer on-line parties needed for each transaction; no access control list management; new services that rely on asynchronous delivery, such as magazine subscriptions; and consumer ease and safety because delivery can take place securely without the participation of either the customer or the smart card.

Marvin Sirbu pointed out that a Kerberos ticket and session key could be used instead of a public key; Dan agreed that public key cryptography was unnecessary here and that Kerberos would work fine. Greg Rose asked why it's necessary to create a new key pair; Dan's answer was that it's a containment issue. Terry Ingoldsby asked why the bank can trust the merchant to take payment from the customer's account; Dan explained that the certificate given to the merchant is signed with the customer's private key.

next up previous
Next: Smart Cards in Hostile Up: Session I: Hardware Tokens Previous: Tamper Resistance - A
Alma Whitten