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.
You are, to the best my understanding, absolutely right.
But does that automatically mean that I, being responsible for the development of one of the most used electronic health care record application in Sweden (Profdoc Journal III), should strive for the adoption these super-smart smart cards? Or even, as some PKI fundementalists in this country would have it, prohibit the sending of unsigned prescriptions?
Of course not. Sending unsigned prescriptions electronically is a big safety improvement over paper based prescriptions. The way things look right now, we should gladly keep promoting our current, not really really safe, way of doing things.
The difficult question for me is therefore not technical (I’m not a deep technician) but timing. When is the right time for me to join the ranks of the PKI mafia and say “let’s stop this unsafe electronic handling of medical information and start doing it right”?
I feel that the time is probably quite distant. There are hardly any smart cards out there in the hands of my current users and the few pilot installations that use personal smart card often get into trouble.
Or is this attitude just me being lazy and backwords, unwilling to adapt to the future? I dont’t know.
> You are, to the best my understanding, absolutely right.
Thank you.
But before diving into the detailed replies, I want to emphasize that my article wasn’t about introducing smart cards and PKI, but how to avoid a couple of important problems once you do. And the problems I pointed to were trust of the workstation, which to a large part eliminates the security advantages of smart cards in the first place. But, no problem, your points are valid anyway.
> But does that automatically mean that I, being responsible for the
> development of one of the most used electronic health care record
> application in Sweden (Profdoc Journal III), should strive for the
> adoption these super-smart smart cards? Or even, as some PKI
> fundementalists in this country would have it, prohibit the sending
> of unsigned prescriptions?
Yes, it does, theoretically and morally speaking. Not that I think you will, since you’ve got a business perspective that is more important to your employer. But the expedient idea, popular in business and very understandable, to only implement things when the pain of not doing it becomes unbearable, is what has brought the Internet to the miserable state it is today. In other words, you and all the other producers of software really should be more proactive, but I have no illusion whatsoever that any one of you will be. History tells us that. Just look at the most used operating system that has gotten away with an abysmal design for a very long time. Good business, but poor technology. And you are, after all, a business. I would (maybe) do the same thing in your place.
So, as a business person, I’d say you’re doing fine. You’re not going to lose any business by not implementing good security, since nobody else does it either. Not right now, anyway.
> Of course not. Sending unsigned prescriptions electronically is a big
> safety improvement over paper based prescriptions. The way things
> look right now, we should gladly keep promoting our current, not
> really really safe, way of doing things.
No, sending unsigned prescriptions is a disaster waiting for a trigger; it’s much worse than paper.
But you don’t do that, you do send encrypted and signed prescriptions using state-of-the-art cryptographic technology. I know that, because I designed and developed that application for you. So your solution is much better than what you’ll find elsewhere. It would be even better if the entire process, from the source user to the destination user was covered, but that is the next stage. I’m sure you’ll get there, too. At the very minimum, I’m sure you’ll provide for the ability to do that, since it would make great business sense. Your communication system, by the way, is designed to easily adapt in this direction, since it’s such an obvious future road.
> The difficult question for me is therefore not technical (I’m not a
> deep technician) but timing. When is the right time for me to join
> the ranks of the PKI mafia and say “let’s stop this unsafe electronic
> handling of medical information and start doing it right”?
Well, if you call them/us a “mafia”, I figure it won’t be anytime soon, will it? But if I were you, I’d start figuring out how you will allow it into your records applications, once disaster strikes and it becomes a requirement. If you’re a little proactive, it would be a great sales argument, too. I’m sure you’d win clients by telling them that you’re working to achieve better security than your competitors. Trying to tell clients that PKI is only high-faluting theory will not enhance credibility. Especially since Profdoc is practically the only company today in its speciality that actually does use state-of-the-art PKI, albeit for only some applications.
Let me make another observation here: most people seem to think that using decent crypto, like PKC’s, is somehow very complicated, expensive or resource demanding. That is simply not true. It does require some knowledge on the part of the developers and project leads, but nothing you can’t learn. For the users, if correctly implemented, it’s practically invisible. In short, it is not rocket science. It also does not require everyone to agree on a system beforehand, as too many people seem to think. You can do it, in your end-user apps, on your own, in a decent timeframe and without loss of user-friendliness. But someone has to show you how.
> I feel that the time is probably quite distant. There are hardly any
> smart cards out there in the hands of my current users and the few
> pilot installations that use personal smart card often get into
> trouble.
It’s a chicken-and-egg problem. Also, we need a serious incident with really embarrassing data compromise to make this happen. We need a medical Enron or Card Systems event. Let’s just hope it doesn’t involve Profdoc.
The pilot installations I have seen that got into trouble did it wrong. You really have to have someone design it that understands it. You can’t run it politically, for instance.
> Or is this attitude just me being lazy and backwords, unwilling to
> adapt to the future? I dont’t know.
No, it’s missing a great business opportunity. Users really do want better security and they’ll flock to the first vendor that takes it seriously. To the first vendor that actually begins doing something, even if it’s incomplete.
Again, I don’t understand you entirely, since you are doing something, but don’t seem to exploit that fact very much in your marketing (but I may be wrong, though).
Thanks for your reply.
I just want to clarify that by “PKI mafia” I mean people-that-whatever-the-cost-claim-that-user-to-user-encryption-and-signing-is-the-only-thinkable-way-to-send-electronic-prescriptions. So that doesn’t include you.
And yes, I know that it doesn’t need to be a lot of work to use PKI encryption if standard libraries can be used.
And no, I don’t thing that user-to-user is worth a lot market-wise. But I could be wrong.