To Counter Keystroke Logging in Keykos

Recent news tells of a new keystroke logger designed to capture and exfiltrate master passwords for password managers. I think that this is because any program is allowed to read the most recently typed keyboard character, together with other vulnerabilities. Keykos was not developed enough on a computer with a keyboard and bit-mapped display to encounter this problem but I consider here how it might be addressed.

Mark Stiegler originated most of these ideas and recent e-mail with him has improved this note.

The kernel supports a classic sharable cap (capability) to the keyboard as an IO device, D. But D is not shared. The keyboard cap is closely held by one domain, K, running a program that all programs that rely on the keyboard must go thru. Programs that need a secure path to the keyboard register with K for a tartan, T, which is an object that knows a secret pattern with which to frame a window into which a user can enter highly privileged information such as a password. Such a window might also include a pet-name chosen along with the pattern when T is created. The user is interactively involved with the creation of T. The user thus knows this pattern and pet-name and knows that that particular sensitive information should not be typed except in this particular context—the context of the tartan. Any authority to read rendered pixels from the screen is in cahoots with K to preclude reading tartan pixels or pet name.

The immediate threat this guards against is a malicious application with legitimate access to a large window, drawing within that window a simulacrum of a window of a more privileged actor which solicits information from the user that the application is not privy to. The user has a relationship with this more privileged actor and must be aware just when he is addressing it.

An order on T produces a displayed window bounded by the tartan pattern and returns:

Another order on T causes the window and R and W to disappear.

I have glossed over the operation of registering wherein T is produced. In case of high paranoia we might boot the machine in dumb screen mode which emulates a “glass teletype” augmented by the program’s ability to propose the pixels of proposed patters awaiting the user’s suggestions and modifications.
In many threat situations tartan production is performed before the machine has become a target and a more complex normal GUI program will suffice.

The ‘moral’ of this note it to show that with a capability foundation built on simple hardware, one can gain tartan style security by adding a small amount of software that impacts only those that need the new function. This note makes a few implicit assumptions about how screen space is allocated and controlled in a capability environment. It would be good to make those explicit.

Key Sensitivity

Our module that fits between the keyboard and almost all other software is in a position to suppress certain signals from the keyboard to the software and use those signals to modulate the tartan. Perhaps some few pixels change from red to white while the shift key is down. A bogus tartan would be unable to behave this way because it lacks the shift key information.

An Attack

The following must be considered. If I leave my Mac about and unlocked then an attacker can probably do what ever brings up a tartan and make an ordinary photograph of it sufficient to make a suitable fake. The answer is probably to lock your computer when you are away from it. Key sensitivity also ameliorates this.