Hacker News Reader

Comment by jcfrei | Hacker News Reader

Seeing that this is a keylogger, how complex would it be to enable a sort of SSL protocol between the keyboard and a specific application? The computational overhead should be manageable, the connector (USB) wouldn't need to change and there should be a fallback for any applications which doesn't support it. But if crucial applications like mail and the browser programs could use it, it might deliver another blow to security companies.

The way I would implement it is that the keyboard has a switch to enable this SSL type communication. Then the keyboard can perform a Diffie–Hellman key exchange with the current process. As a result any other interaction with the OS would become impossible until that process is terminated - basically disabling all OS related shortcuts etc. This would allow true end to end encryption - even on compromised systems (as long as the kernel code isn't modified to allow accessing the memory of other processes).

View on HN

If the OS is compromised, then you can't work around that to secure a program inside the OS. You can run the program somewhere else, like on the keyboard itself. Some secure crypto devices have displays, so you can see what you're signing.

The only similar thing I've heard of is the "Secure Attention Sequence" in Windows. That is, pressing CtrlAltDel before entering credentials lets you be sure an application is not mimicking the logon prompt. But of course if the OS is compromised (like by loading a driver that intercepts such keystrokes, like VMware Enhanced Keyboard) all bets are off.

Think about it, the OS is executing all the code for the app, and storing all the memory.

This is also why there is a push for trusted computing. Being able to have your processor, OS, etc be able to verify they are running a trusted configuration is a powerful thing. It makes the owner of the computer in control. (The downside is when the user is not the owner, but would like to be, then they get upset at restrictions.)

"Trusted computing" puts the controller of the trusted infrastructure in control - the owner of the computer should expect that any NSA-approved malware will be considered properly trusted, and being in control of a secure OS doesn't help against attacks coming from the hardware (malware or backdoors on firmware) with direct memory access.

I LOVE how you come with trusted computing on a topic about a malware allegedly created/modified by the NSA.

You MUST be a security professional! Only those have such a distorted view of reality!!!!

If the operating system is compromised, your application stands no chance hiding its data (including keystrokes) from it. The keystrokes could simply be intercepted after decryption, or even before - if you keyboard controller is that capable, it probably has more than enough space for malware of its own.

as long as the kernel code isn't modified to allow accessing the memory of other processes

This is kind of what the kernel is for, though: if you can't modify the memory of other processes you can't handle IO for them. Hiding data in plaintext from the OS is basically impossible. Nearest you can get is heavy obfuscation (Skype) or communication to a secure hardware bastion (TPMs for DRM or otherwise, ARM TrustZone).

What might be more interesting and useful is secure communication between a remote website and a non-PC device. Kind of like PIN pads, but more user friendly.

Actually I may have been too quick to reply. This might be accomplishable with remote attestation (Intel TXT). I think Intel chips can setup trusted execution areas and provide a hash of the code running. Now, input and output are gonna be tough. You could do encryption to and from the device but then you're essentially running another computer.

It might be easier on a simple DOS like OS, where IO is m can be straightforward and handled by the hardware pretty much.

Reply on news.ycombinator.com