KeystrokeEndToEndCrypto

Why end-to-end keytsroke encryption, from simple HW to application?

"End to end cryptography" is well known.

The same protocols and software (eg. multiplexers and demultiplexers) would be useful not just for keystroke data, but virtually any realtime automotive, industrial, environmental, communication, soho or security data (saving millions of kg of copper and providing better redundancy and tapper-free datapath, eg. from microphones or motion detectors).

Honest businesses prefer an honest money supply (which historically didn't exist for thousands of years, or existed in isolation and was effectively suppressed), and fast, secure transactions (that need secure method to enter secret passphrase for signature or communications).


Proposed architecture


Searching for a better place to host this:


VEMS has


To be defined (to be useful)

Apparently evdev [struct input_event] (simple 16 byte stuct with 4 fields) is the most common standard interface (the tty or faketty could also work, but is different).

[uinput evdev notes from Peter Hutterer]

Proof of concept with Xephyr (check logs carefully, easy to get tricked):

cat </dev/input/event9 >/tmp/inev9
/usr/bin/Xephyr :2 -keybd ephyr,,device=/tmp/inev9,xkbrules=evdev,xkbmodel=evdev,xkblayout=us -mouse ephyr,5,device=/dev/input/event11 -verbosity 100 -evdev &

Needs Xephyr patch (which is not merged in Debian and Ubuntu for some weird reason).

X can be configured to read from /dev/input/eventN evdev, but does NOT work with named pipe (X attempts ioctl which fails on pipe created with mknod /path/pip p )

Conclusion: on the PC-side it should be straightforward to bypass the USB host HW (of many or all PC-s) is (almost certainly) trained to sniff;

However, if using uinput and evdev and libinput (unmodified geth), the kernel sees the plaintext (marked as EV_KEY data) but the USB HW can be bypassed (or see encrypted serial data). Modified libinput would be better, and:

To decrypt inside geth (not another process), modified geth (or suitable libinput or faketty) library needed.


Usefulness

Anyone with some knowledge about computer security or USB knows that currently keystrokes are crying out "catch me please" when traveling from keyboard to application (via a deep HW and SW stack), and the user has no option to "tunnel" keystroke data securely to the application

Some will argue that sufficient security can be reached by:

Marcell thinks this is not the case, but this beyond the scope of this page. Those who think so should simply silently go away. For extremely high value [offline wallets] to store and use keys are very reasonable (who would argues that ?). However, for smaller value (or to secure everyday communications) some practical method still needed to handle secret keys.

When the next multi-billion dollar theft will be publicly known (probably already happened, but traditional "create money and not inform" banks don't publish) we'll know more about which practice is more secure.

If different methods provide different security:

Should be a reasonable first step, even if more secure (and more costly) method will be possible later for Completely secure key => known application running on custom hardware (perhaps verified etched Si). Hopefully we don't need to solder 6000 gates to sign in a secure way :-)


DIY or closed source ?

Some will implement in


Same HW, different applications

Input-outputs and LED-indication (pushbuttons not strictly needed but do not hurt either)

LCD version (displays text, fingerprint, status; perhaps photo)


ECDH instead of RSA