Increasingly, computers are used to write pharmaceutical prescriptions and other medical documents. In most cases, the “signing” of these documents is a sad affair involving some simple checking of checkboxes and clicking of buttons. The application usually takes it from there, attesting to anyone willing to believe it that the logged on user (whoever that may be in reality) clicked the click and thereby took responsibility for the whole thing.
In more sophisticated systems, an actual digital signature is applied to the prescription. If we’re lucky, it’s also done in the right way (except I’ve never heard of a system doing it right), with digital signatures. If we’re even more lucky, that digital signature is not kept on the computer, a floppy, a USB flash memory or a dumb card (a magnetic stripe card or memory card), but on a smart card with microprocessor. But even then, we’re far from safe.
In what follows, the “smart card” I refer to is a microprocessor equipped smart card doing all cryptographic operations on the card. It needs a PIN to enable such processing. The term “smart card” may in general include cards without on-board processing, but I’m not considering those here.
Assume for a moment that you are a doctor and that you have been given a smart card with your digital signature on it. You sit down in front of a workstation, log on to the system (possibly, but not necessarily, using the smart card). You look up your current patient, create and fill in a prescription for Aspirin or whatever, insert your smart card in a reader, enter your PIN on the computer keyboard and click “Ok to sign”. Your prescription is signed and off it goes to the pharmacy.
Sounds good, but what if another application of some unknown kind is sitting inside that workstation just waiting for you to insert your card and enter your PIN? This malevolent application then goes on to sign fourteen prescriptions for speed, and a mortgage application for $100,000. And while it’s at it, it also logs on to your bank and transfers out everything in there to an account in Nigeria.
Note that all these transactions are individually and correctly signed by you, so you’ll have a terrible time convincing anyone that it wasn’t you doing it on purpose. It was done using a state-of-the-art digital signature system, a very smart card, and, to make it worse, at the workstation you yourself was sitting at the time. Believe me, you’ll be up the proverbial creek.
What happened here? Well, you trusted an untrustworthy workstation, that’s what. Your PIN should never have gone through that workstation’s electronics or software in any manner. You should never have entered that PIN on anything you don’t trust, that is on anything outside the smart card itself.
This leads to my first conclusion: any keyboard entry has to be done on the smart card itself. That is, it must have a keypad. Since we’ve seen cheap calculators with the same form factor as credit cards, it can’t be a problem to incorporate a keyboard into a smart card. There are smart card readers with integrated keyboards and sealed electronics on the market. That’s much better than having to enter pin codes into workstations, but it’s not as secure as having the keyboard on the smart card itself.
But what happens when you enter a pin code? Does it unlock the smart card for one signature or for any number of signatures for a certain time? Having to enter the PIN anew for every signature could very soon turn into torture, so a certain time period is more reasonable. But to stop a hidden process from accessing the unlocked card invisibly, we have to make it signal to the user that it is signing something. This could be done with a beep, for instance. Admittedly, once you notice a beep too many, it’s already too late, but at least you can stop the thing from carrying on indefinitely. The card should also provide a count of issued signatures on a built-in display.
An alternative to the beep would be to have a button on the card that you need to press to allow issuing each signature. That is, after entering the intial PIN, you can leave the card in the reader and allow it to issue each signature for each time you press that button. That ought to be acceptable as long as you can be sure the user won’t leave the card in the reader as he goes to lunch. You will have to invent ways of making users hang on to their cards for dear life, like allowing them to get free coffee with the cards, or having to use the card to open doors. You could also disable the card if the user moves too far away, but that may require you to implant RFID‘s into your users; a proposition that may be hard to sell (with some exceptions).
There is still one more vulnerability: the card may sign something different from what you think it is signing. The software may create a prescription for another person entirely, which will be discovered as the regular patient never gets his or her prescription. But if the software merely increases the amount of prescribed medication to the same patient, and the patient is in on it, it will not be discovered. Actually, if the patient is in on the scheme, anything can be signed and you’ll never know.
So we’re back to what I’ve discussed before: the semantics of signatures. The doctor can only be expected to sign a prescription he can understand as directly as technically possible. Which probably implies that he can only sign a bitmap representing the prescription he intends to create. The application then additionally creates an application dependent data structure representing the same prescription and signs that with an application signature key. It is then up to an auditor to compare the bitmap to what the application has created and to check that no deception occurs.