Send As SMS

Wednesday, September 20, 2006

On-Card displays

A problem that has bothered me for a long time with smart cards is what I refer to as the "trusted terminal problem"; that you (the card-holder) must trust that a terminal owned and largely controlled by a merchant is doing what it claims to be doing; that the merchant has not subverted the device. One solution is to have a UI (display and buttons) on the card/token in your possession. Several vendors now appear to be offering exactly this on credit cards.

I first encountered a variant of this problem a little over twenty years ago when I was doing work experience at a Burroughs (now Unisys) warehouse in Sydney. Most of my time that week was spent preparing French-made EFTPOS machines for delivery to Australian customers (supermarkets, I think). The task was to unpack each machine, fit an Australian power plug, perform basic functional tests and, assuming that all of that passed, set the machine up in the soak-test shelves for a day or two. Some fraction of the machines had problems that needed corrective actions (screens damaged in transit and screens mis-fitted were the most common, although occasionally EPROMs were fried and we had to replace them). This was generally pretty routine electronics, but there was a special consideration in the design of the keypad on which a customer would enter their PIN. The DES key used by the settlement provider was stored in SRAM in the keypad itself (so the PIN crossed the wire to the body of the terminal already encrypted); the SRAM was powered by a supercap so it could hold the key for months on end without external power and there was a normally-closed pushbutton connected inside the casing such that as soon as the casing started to open, the power pins on the SRAM would be shorted out and the key thereby destroyed. For any machines on which we had to replace the screen on the keypad, we had to re-enter the DES key into the keypad at first power up. The theory was that while the manufacturer did have access to the key, the merchants did not, so even if someone in a supermarket spent some time fitting an electronic surveillance device to the terminal, it wouldn't get them the PINs because (a) the PIN was only ever available unencrypted in the keypad and (b) the keypad couldn't be opened without destroying the key, thereby at least exposing any tampering merchant to investigation by the banks. (Clearly there remains an issue with a merchant's use of surveillance cameras in its own premises to gather the same information, but at least an alert customer has a reasonable chance of dealing with that possibility himself.)

I assume (well, I hope) that other manufacturers have incorporated such measures into their terminals but, of course, like any customer I have no way of knowing whether or not this is the case for any particular merchant, and even whether or not there has been collusion between a technician working for the manufacturer and a merchant.

While there's a "hey what's this on my statement?" recovery path for EFTPOS cheating, there's no such recourse for stored value cards. This has bothered me ever since stored value cards became available. Clearly, the system's greatest risk is to the card provider from card-holders tampering with the cards, but in situations where third-party merchants can accept payment and then bill the system-provider, there is a strong incentive for the merchant to tamper with the machine as it would be very difficult to prove after the fact that a merchant was cheating. Indeed, it would often be difficult even to notice; bear in mind that existing stored-value card systems work much like a blind person paying for groceries at the checkout by handing their wallet to the checkout operator and hoping that they remove the right money.

The solution has always seemed to me to be that the card-holder should not have to trust the merchant's terminal, but this would essentially require that the card-holder lug about his own secure terminal and that the merchant be able to cope with that. Interestingly, I've seen a Vasco device about the size of a small calculator which purports to do exactly this. Suppose that you're buying on the web something which won't be delivered to you physically (e.g. you're buying an e-book), so the merchant doesn't need to know your address.
  • you enter your order
  • the merchant website generates a "challenge" number
  • you slip your card into the device and enter the number
  • the device tells you how much money the transaction is for
  • perhaps you select which of your several accounts to pay from
  • you press "yes"
  • the device gives you a "response" code for this one transaction
  • you enter it into the merchant website
  • the merchant's website forwards the transaction details plus the challenge and your response to the payment processor
  • the payment processor gives the OK
  • the merchant website makes the download available
The nett result is that
  • the merchant and payment processor know for certain (and the latter can prove) that whoever entered the transaction was in possession of the actual card at the time, even though you weren't in the same room as the merchant['s employee]
  • you've not disclosed your credit card number to the merchant, so there is no risk of a leak of the merchant's database, or compromise of their webserver, leading to subsequent fraudulent use of your credit card number
  • you know, for certain, how much money has been debited to your account (note that with web merchants this is not a huge risk; any merchant who was regularly telling customers one price and the bank a higher price would quickly generate enough complaints to get shut down)
  • you've not disclosed your address, nor even neccessarily your name, to the merchant, thus enhancing your own privacy. (Note the qualifier at the beginning "so the merchant doesn't need to know your address". If you're buying a washing machine they have to know, at least, where to deliver it. This degree of privacy protection is, in principle, only available for transactions that don't require a courier or service provier to visit your home.)
So, Bruce Schneier has spotted an article announcing that displays and keypads are now available for credit cards! The article deals primarily with the bank's half of the problem (proof that you have the card at the time that a transaction occurs) so they're talking about implementing two-factor authentication ala SecureID in which a "random" number which has to be provided as a part of the transaction is displayed on the card, but Bruce points out, and the manfuacturer's samples suggest, that more involved "terminal on the card" applications (e.g. electronic wallet) are already being developed.

(Note that the "Subscribe to access articles more than sixty days old" at the bottom of the article suggests that the article will quickly expire, so for reference, the named manufacturers are InCard with their OTP DisplayCard, SmartDisplayer with their Display IC Card, and Aveso with their Display-enabled Smart Cards.)