#### ## ## ## ####
|\ /| | ) ( | | | | | ( ( ) ) \ \_/ / \ / \_/
##### ## ## ## ## ##### ## #####
___ ( _`\ | (_(_) `\__ \ ( )_) | `\____)
_ _ | \ | | | \| | | |\ | |_| \_|
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?''' * 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''', 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 ---- '''Proposed architecture''' * PS2 keyboard (or USB) * '''small (low power consumption, low cost) ARM or AVR hardware (with status LEDs)''' ** 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") * xorg * 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: * xorg wiki ? xorg developers are system integration professionals, and know a lot about keystrokes and listeners * ... ? ---- 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) ---- '''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'''. 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 :-) 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.