More on on-card displays
These are some followup thoughts to my previous post about the availability of smart cards with builtin displays and keypads.
Yesterday, I finally read Schneier's 1999 Breaking Up Is Hard to Do: Modeling Security Threats for Smart Cards which actually describes the same threats that I was talking about as particular cases of the more general problem of "splits" where things that are all under the [nominal] control of one party in classical computer security (CPU, storage, I/O, power supply, software, data) are under the control two or more parties in smart card systems. This broadended my understanding of the problem, supported my idea that keeping the terminal under the cardholder's control is an important threat-reduction measure and reminded me that Ed had made some interesting comments that I'd meant to respond to. So:
Schneier suggests that the two largest areas of improvement are:
(i) per my own intuition, to place the terminal under the cardholder's control, whether with a seperate device (e.g. a Vasco-Digipass-800-series type device) or with the terminal on the card itself (he actually talks about the now-departed REX personal organiser; of course the newly-available on-card devices have a better shot of mass-market success), and
(ii) to make the cardholder also be the data-owner. This is trickier because it's very tempting for the card-issuer to see the card as a trusted computing device doing its bidding while in the hands of its customer. Mobile phone companies explicitly talk about the SIM as the one thing that they can reliably control (because customers do change phones, sometimes to phones not supplied by the telco), subscription TV services embed crypto keys in the card, etc. There are even offline digital cash systems that depend upon the smart card containing an "observer" module that represents the bank; the rest of the software on the card can do whatever it wishes, but the bank's observer will only generate "this looks reasonable" signatures for transactions that look reasonable. For this to work, the observer needs to possess a key, stored in the card somewhere, that must not be available to the user. The mere presence of this element provides an incentive for cardholders to invest effort in gaining unauthorised access to the key and using this to cheat the system.
He also points out some potentally surprising consequences of collaboration between apparently seperate and potentially hostile parties (e.g. card manufacturers and software developers could collaborate in ways invisible, but harmful, to card issuers and/or cardholders.)
On my earlier post, Ed suggested that the mobile phones that most of us now carry could be used in the role of trusted terminal. My concern with this is the same as my concern with trusting one's own PC in this role; PCs are so complex, and run software from so many sources (if you are reading this with a web-browser then it is likely that you are also running some Javascript that it's downloaded from somewhere...) that it is difficult to be confident that a PC's owner is truly in control of it. This is in fact a large part of the importance of external security tokens (think SecureID) in the first place. An important characteristic of the Vasco (and other) devices is that they are not field-upgradeable. From the day that they're shipped until the day that they're discarded, they'll run exactly the same software. This is problematic if they contain a vulnerability which becomes known (mass recall time!), but does mean that no adversary can ever replace the software in the terminal, an event that would reintroduce the very split that having a cardholder-owned terminal was intended to remove. This weakness in PCs has not been lost on malware authors; there have been reports of malware found in the wild which waits until a compromised browser is used to log in to a particular bank's web-banking interface and then proceeds immediately to milk the user's account while the user is logged in (more broadly, all phishing and pharming are examples of this). The same weakness exists in mobile phones, albeit to a lesser degree at present. The non-field-upgradeability of the software in the Vasco-type device or the newer on-card devices is a potent protection against this form of attack.
Ed made another great suggestion about placing the real keypad under the counter with a set of solenoids to operate its buttons and to present the customer with a fake keypad (which controlled the solenoids). This would actually have worked against the EFTPOS machines that I worked on at Burroughs, as the card was swiped through a slot at the bottom of the checkout operator's interface, however it would not work against the newer terminals which have the card slot in the keypad. This is in part about the requirements of chip+PIN smart cards (instead of being swiped, the card is inserted for the duration of the transaction and, I suspect, receives the cleartext PIN) but would also thwart the attack that Ed suggests. On the flipside of course, some merchants (notably Waitrose) no longer put the keypad on a cable; instead it's on an arm attached to the wrong side of the checkout counter, so it's not possible to block sight of the keypad with your body, and the side-guards only block visibility from a viewing angle so steep that a snoop viewing at that angle would probably not have been able to work out which keys you were pressing anyway; while the angle that the next person in line at the checkout views it from is unobstructed. Perhaps this is intended to make life slightly trickier for corrupt checkout operators, who are probably a more serious threat than opportunistic customers anyway.
Yesterday, I finally read Schneier's 1999 Breaking Up Is Hard to Do: Modeling Security Threats for Smart Cards which actually describes the same threats that I was talking about as particular cases of the more general problem of "splits" where things that are all under the [nominal] control of one party in classical computer security (CPU, storage, I/O, power supply, software, data) are under the control two or more parties in smart card systems. This broadended my understanding of the problem, supported my idea that keeping the terminal under the cardholder's control is an important threat-reduction measure and reminded me that Ed had made some interesting comments that I'd meant to respond to. So:
Schneier suggests that the two largest areas of improvement are:
(i) per my own intuition, to place the terminal under the cardholder's control, whether with a seperate device (e.g. a Vasco-Digipass-800-series type device) or with the terminal on the card itself (he actually talks about the now-departed REX personal organiser; of course the newly-available on-card devices have a better shot of mass-market success), and
(ii) to make the cardholder also be the data-owner. This is trickier because it's very tempting for the card-issuer to see the card as a trusted computing device doing its bidding while in the hands of its customer. Mobile phone companies explicitly talk about the SIM as the one thing that they can reliably control (because customers do change phones, sometimes to phones not supplied by the telco), subscription TV services embed crypto keys in the card, etc. There are even offline digital cash systems that depend upon the smart card containing an "observer" module that represents the bank; the rest of the software on the card can do whatever it wishes, but the bank's observer will only generate "this looks reasonable" signatures for transactions that look reasonable. For this to work, the observer needs to possess a key, stored in the card somewhere, that must not be available to the user. The mere presence of this element provides an incentive for cardholders to invest effort in gaining unauthorised access to the key and using this to cheat the system.
He also points out some potentally surprising consequences of collaboration between apparently seperate and potentially hostile parties (e.g. card manufacturers and software developers could collaborate in ways invisible, but harmful, to card issuers and/or cardholders.)
On my earlier post, Ed suggested that the mobile phones that most of us now carry could be used in the role of trusted terminal. My concern with this is the same as my concern with trusting one's own PC in this role; PCs are so complex, and run software from so many sources (if you are reading this with a web-browser then it is likely that you are also running some Javascript that it's downloaded from somewhere...) that it is difficult to be confident that a PC's owner is truly in control of it. This is in fact a large part of the importance of external security tokens (think SecureID) in the first place. An important characteristic of the Vasco (and other) devices is that they are not field-upgradeable. From the day that they're shipped until the day that they're discarded, they'll run exactly the same software. This is problematic if they contain a vulnerability which becomes known (mass recall time!), but does mean that no adversary can ever replace the software in the terminal, an event that would reintroduce the very split that having a cardholder-owned terminal was intended to remove. This weakness in PCs has not been lost on malware authors; there have been reports of malware found in the wild which waits until a compromised browser is used to log in to a particular bank's web-banking interface and then proceeds immediately to milk the user's account while the user is logged in (more broadly, all phishing and pharming are examples of this). The same weakness exists in mobile phones, albeit to a lesser degree at present. The non-field-upgradeability of the software in the Vasco-type device or the newer on-card devices is a potent protection against this form of attack.
Ed made another great suggestion about placing the real keypad under the counter with a set of solenoids to operate its buttons and to present the customer with a fake keypad (which controlled the solenoids). This would actually have worked against the EFTPOS machines that I worked on at Burroughs, as the card was swiped through a slot at the bottom of the checkout operator's interface, however it would not work against the newer terminals which have the card slot in the keypad. This is in part about the requirements of chip+PIN smart cards (instead of being swiped, the card is inserted for the duration of the transaction and, I suspect, receives the cleartext PIN) but would also thwart the attack that Ed suggests. On the flipside of course, some merchants (notably Waitrose) no longer put the keypad on a cable; instead it's on an arm attached to the wrong side of the checkout counter, so it's not possible to block sight of the keypad with your body, and the side-guards only block visibility from a viewing angle so steep that a snoop viewing at that angle would probably not have been able to work out which keys you were pressing anyway; while the angle that the next person in line at the checkout views it from is unobstructed. Perhaps this is intended to make life slightly trickier for corrupt checkout operators, who are probably a more serious threat than opportunistic customers anyway.
<< Home