InfoCards Secure Zone

08 Mar 2006

Kim Cameron and Aldo Castañeda had a discussion about InfoCards and Higgins that touched the user interface issues (quoting Aldo):

For those who haven't seen an InfoCard demo, one impressive aspect of how it works is that when an "ID transaction" is initiated the system visually and technically goes in to a type of "security zone". To be dramatic envision the lights dimming and the sound of cold steel rolling followed by the clang and reverb of metal meeting metal as the doors close around you. I should stress that in this scenario, unlike the movies those doors are closing to provide a security cordon in service for end-users to keep the thieves at bay not to capture them in act. The point I'm getting at is, that because the end-user is entering a separate "zone" it really shouldn't matter if the end-user entered it through Windows, Linux, Sun or the Apple OS as long as their entry is valid.

I have to say that such a "zone" is not very secure and I doubt it can be made really secure in soon future. The people that ever worked with "Orange Book" systems knows why, for all of the others here comes the explanation:

As you start an "ID transaction" in InfoCards, the screen will dim and a big window appears that allows you to choose a "card". You choose a card, enter some password or PIN to unlock it and proceed with transaction. Looks fine, looks secure. But ...

The whole Windows screen can be easily used by any application, like screen saver or a computer game. Now imagine a trojan that takes whole Windows screen and simulate the "dimming" effect of InfoCards secure zone. I bet you will go on and enter the PIN or password to the trojan.

Offtopic: This trick is really old. I remeber how we used it back in the university on old back-green text terminals, simulating UNIX login prompt.

Well, it may not be that easy in the practice. The trojan will need to learn what cards you have in your InfoCards system (I suppose that the "common" application will not have access to full InfoCards API). The easiest way to do it is a wild guess. The user may not notice that some card is missing or that other is slightly different. When I consider how successful are today's primitive phishing attemps, I can believe that simple guess may be a worthy technique. Then there are plenty of processes in Windows that have high privileges. Subverting any of these may provide access to full InfoCards API for the trojan. And there may even be the easiest way of all. Many windows users are administrators of their own computers. What else the trojan needs?

How to solve the problem? That's not difficult. The designers of "trusted" systems solved that long time ago. The solution is called "trusted path". You need to have a portion of a screen that no OS application can write to. You need to have a button in this portion of a screen that no OS application can override. And the user will use that button to switch to the secure mode. No trojan can subvert that, unless it already has god-like privileges. I got it that the same reason was behind the infamous ctrl-alt-del combination in Windows, but it looks like the motives are already forgotten.

But for that to work the OS has to be at least a bit secure. At least some parts of it (like OS core and window manager) has to be trustworthy. And we still have a long way to get to that state - for all common desktop OSes (including Linux). Maybe NGSCB (read "Palladium") and similar projects can bring this as a side effect? I doubt it ... but hope dies last ...