##    
 ######  
   ##    
   ##    
   ##    
    ###  
         

         
         
  ####   
 ##      
 ##      
 ##      
  ####   
         

         
 ##      
 ##      
 ## ##   
 ####    
 ## ##   
 ##  ##  
         

         
 ##      
 ##      
 #####   
 ##  ##  
 ##  ##  
 ##  ##  
         

         
         
  ####   
 ##  ##  
 ##  ##  
 ##  ##  
  ####   
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''Why end-to-end keytsroke encryption, from simple HW to application?''' "End to end cryptography" is well known. * Components (like the USB-host and stack including usbhid, the primary "billion dollar target") should be able to route data without understanding it (or, in some cases, without knowing the exact destination, like an RS485 or CAN-bus, or Tor). Messages can be forwarded to listeners without drawing attention "catch me, here goes the keystroke data in plaintext" ** consider that today an ordinary PC has more bandwidth and greater transistor count than a whole campus had in the old days when the PC/AT keyboard was defined (and 14..90 nm Si verification is beyond reach for most of us) ** Often the existing components could do this right with sane software / firmware. A proper keyboard (with a few kbytes more memory, and a HW multiplier) would cost max +1 USD more (implementing it outside the keyboard costs 6..10 USD, similar to an USB hub; it can cost 0 when a "multikbd crypto mux" device is used, eg. in a [https://en.wikibooks.org/wiki/Multiseat_Configuration/evdev multiseat setup] and saves an USB hub) 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). * The lack of democratically issued currency is a very significant risk to our society. ** [http://www.ethereum.org/ Ethereum] is apparently the first network in history that allows businesses to issue their currency (in a non-centralized way: so it cannot be shutdown by adversary/gov without shutting down the whole internet) ** bitcoin or ether are NOT issued democratically, but ethereum allows any number of issued currencies via "contracts" (custom-defined programs/conditions) * the '''lack of keyboard to application secure path is an obvious security risk''', endusers and operators simply have no secure method to enter secret keys into financial applications (geth, or wallet, or market-GUI). "geth" below is shorthand for any smart application to handle encrypted keystroke events ** [http://www.coinmarketcap.com/ coinmarketcap] is growing, currently (2016-07) between 10 and 100 Billion USD 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''' * PS2 keyboard (or USB) * '''small (low power consumption, low cost) ARM or AVR hardware (with status LEDs and/or directly connected LCD)''' ** recognizes some special hotkeys to switch between N keys; or to send unencrypted keystrokes transparently if chosen by user * connected via serial or USB-serial port ** even the USB HID could be used ("keystroke steganography") ** however simple PS2 and uart-serial are highly preferred because of their simplicity: easily captured via 4+ channel logic-analyzer ("bitscope") like saleae. If protocol is well defined, stream can be analyzed for compliance * '''xorg / xinput / x11proto-input-dev''' ** demultiplexer / dispatcher could run outside or inside xorg process (in some library) ** [https://en.wikipedia.org/wiki/Evdev evdev] is the generic way (useful even if one opts to bypass evdev and use pipes instead of /dev/input/* ) ** [https://www.freedesktop.org/wiki/Software/libevdev/ libevdev] [https://joeshaw.org/linux-input-ecosystem/ evdev article] * window manager (like xfce) * old applications (eg. gtk, expecting keystrokes from xserver) * advanced secure applications understanding end-to-end encrypted keystroke data (geth with some added code) ---- '''Searching for a better place''' to host this: * '''Tor''' wiki (or git?) ** in some way this is very similar (in concept, and implementation) to Tor. ** The packets are smaller (eg. 32 bytes instead of 300..1460 bytes) and the packet overhead should ideally be smaller than 40 bytes and the routers should be lightweight (not "gated"). ** In PC, some data would be read from serial port, and demultiplexed into pipes (still encrypted) from which "geth" (the target applications) could fetch for decrypt inside (possibly with necessary code linked in: if someone security-minded considers crypto related shared libraries an unnecessary risk and rather sacrifices some RAM for security). * '''xorg''' wiki ? [https://www.x.org/archive/current/doc/man/man4/kbd.4.xhtml xorg] developers are system integration professionals, and know a lot about keystrokes and listeners (and much experience with queues, network and pipes); at least some xorg.conf snippet will be needed to "bridge" to existing X applications * '''gnupg''' ? ** gnupg has a lot of nice code. ** However, some official gnupg (bad) advice (that gnupg should be exec-d rather than the necessary code linked where needed) suggests that not every gnupg developer is concerned with application security (but probably many are) * '''socat / stunnel / libssl ''' ? * '''busybox / dropbear''' ? ** a really nice small footprint system useful for maintenance, audit, bootstrap and other purposes with an ssh implementation. Good job ! * some '''"secure linux"''' or '''BSD''' coders ? ** concerned with application security and doing a good job. (perhaps already solved some special case at least?) * '''webrtc''' ? ** experience: realtime connection through firewalls (and multiplexing voice, video and other data) * other ... ? ---- VEMS has * proven (and easy to tunnel; somewhat like PPP) communication protocol to send runtime data from firmware to app ** although not encrypted; and obviously other method like COBS or COBS-R or some improved version can be used (easy to solve) * and firmware code to interface with PS2 keyboard. ** (not before used for keyboard crypto) ; currently rarely used at all ---- '''To be defined''' (to be useful) * signalling '''handshake command-set''' eg. to agree on new keys ** handshake: application can inject public key to ARM, and ARM can send back random symmetric key to the application for further data encryption. ** The costly pubkey operation (~1..4 sec for small microcontroller) normally happens only once during application startup; after that, sending keystroke data to that application is lightning fast. * '''how/when xorg is notified''': switching between crypto keys => typically switching window focus also ** even if xorg can not decrypt the datasream sent to geth, it can switch to the xterm geth is running in ** xorg could prevent other apps seeing alien streams (which they cannot decrypt anyway, but might hold some statistic value, and processing noise => undesired cache contention) * hotkey to enter ("shared secret") passphrase to keyboard (usecase: sspp generated by app => shown on screen; entered via keyboard => not sent to PC, just stored in device memory: sspp used for secure comm) ** although a bit geeky, one-way channel (perhaps with redundancy and FEC) is suitable this way (no datapath from app to keyboard, other than the human) Apparently evdev [https://www.kernel.org/doc/Documentation/input/input.txt 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). Proof of concept with Xephyr: <code> 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 & </code> Also works with named pipe (and definitely no need to be in /dev/input/ dir, a trivial target for malicious kernel modules). Conclusion: on the PC-side it should be straightforward to bypass any keyboard datapath the USB host HW (of many or all PC-s) is (almost certainly) trained to sniff; Possible to use alternative paths the application could understand (but even for a kernel module, not trivial what is going on). '''To decrypt inside geth (not another process), modified geth or suitable libinput 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: * buy any PC HW * use windows-... (many backdoors, without sourcecode no way to make it secure) * install some antivirus software (add another backdoor) 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 [https://en.bitcoin.it/wiki/How_to_set_up_a_secure_offline_savings_wallet 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. * the USB host IP-designer (or fab) can easily allow keystrokes to be logged (eg. to hidden flash), and later sent (eg. via wifi or Ethernet from HW or via TCP/IP network from some collaborating app; but even via sonic noise or IR if such HW is installed) * NSA is known to pressurize network operators and HW-manufacturers; it would be very surprising if keystrokes would not be their first victim (because of the relatively small volume, and high value) If different methods provide different security: * keystrokes are begging to be caught => very easy to log (most likely they are acquirable by manufacturer and/or NSA) * keystrokes travel encrypted to sensitive applications when user likes so ** this makes it '''immensely more difficult to dig out''' (from application memory) ** today's HW are (Marcell's opinion) likely not designed for that (and application can be changed easily, even after HW was purchased); ** => definitely a better way, and only costs a few dollars nowadays, so those who prefer security should have the option 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''' ? * home-built firmware should be uploadable to the '''PS2-uart multikey keystroke-encryption HW''' ** otherwise if HW is backdoored by manufacturer to send same keystrokes to more than 1 subscriber (or nonvolatile log and later retrieve) => if manufacturer can also start an application to hook in; sensitive data can be leaked (and everything would appear to work properly exactly as currently with windows or X one does not notice leaks when happening): ** even the protocol analyzer might not notice it; ** especially if no extra data is sent, but leaked via the secret "not-completely-random" keys (that are small, but generated on every application startup). ** Some will prefer only 1 crypto-key at a time (only to application under her control), and all other data (not as sensitive as crypto keys) to be sent plain. This makes it fully verifiable (and using more than 1 keyboards or kb-switch and more than 1 encrpytion HW is possible of course) Some will implement in * '''FPGA with some RAM and mblite-plus core''' (~15 USD) ** "Apollo computer" style discrete (gates or transistors) would be more costly (footprint also) and only for "fun" or university project * '''ARM microcontroller''' (~6 USD; reasonably low price and MIPS or ARM => most likely good choice) * AVR microcontroller: OK for prototypes, but for convenience (pubkey crypto to exchange keys without effort from the user) ARM is faster * old PC: could work, but avoid it (except for "proof of concept" maybe). ** new PC: or notebook, or orange-pi or raspberry-pi : not safe to assume that USB keyboard data never leak; but running apps on them might be safe, especially if Faraday-caged (in OLD PC-supply metal box ?) and not connected to "default gw" (perhaps not connected to internet at all; or only some controlled app connected via some dedicated gateway)
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.