_       
( (    /|
|  \  ( |
|   \ | |
| (\ \) |
| | \   |
| )  \  |
|/    )_)
         

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

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

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

 _______ 
(  ____ \
| (    \/
| (__    
|  __)   
| (      
| )      
|/       
         

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") ** 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 * 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 :-) ---- '''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 keystroke data never leak from their Si
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.