Check out the new USENIX Web site. next up previous
Next: Session II: Protocol Analysis Up: Session I: Hardware Tokens Previous: Token-Mediated Certification and Electronic

Smart Cards in Hostile Environments

Howard Gobioff, Carnegie Mellon University; Sean Smith, IBM Research; J. D. Tygar, Carnegie Mellon University; Bennet Yee, University of California, San Diego

Howard Gobioff described a security problem with smart cards due to the lack of direct I/O to the customer; that is, in an untrusted environment all communication between the customer and the smart card must go through an untrusted card reader. As an example of the problems this can create, Howard described a point-of-sale scenario in which the merchant's terminal reports the transaction to the smart card as $100 while displaying it to the customer as $10.

We would like to have communication between the customer and the smart card be secure (private and trusted) in both directions. Howard outlined possible additional capabilities that we could assume for the smart card, and the benefits that would result from each.

If we assume that we have a one-bit private input channel from the customer to the smart card, then we can also have private output from the smart card to the customer, by having the customer input a key through the private channel which the smart card can then use to encrypt its output. This might be used to allow the customer to check the balance in the smart card without revealing it to the merchant. Similarly, if we assume we have a one-bit private output channel from the smart card to the customer, then the card can provide the customer with a key and the customer can input encrypted values for privacy. This is similar to work by Abadi, Burrows, Kaufman and Lampson in which the card presents a random value which the customer then adjusts using arrow keys.

If we assume we have trusted input plus one bit of trusted output, then we can have general trusted output: the customer feeds the displayed value back to the card via trusted input and the card uses the one bit of trusted output to signal any discrepancy. Likewise, if we assume we have trusted output plus one bit of trusted input, the card can display and the customer can signal discrepancies, so again we have general trusted output.

Bob Gezelter pointed out the importance of having a timeout equal not-okay, since otherwise the merchant can attack by distracting the user at the right time. Simon Kenyon argued that in a closed-loop system fraud will be caught when the books are balanced; Howard responded that this is true in present systems but fraud is still a problem.


next up previous
Next: Session II: Protocol Analysis Up: Session I: Hardware Tokens Previous: Token-Mediated Certification and Electronic
Alma Whitten
1998-07-21