scln
----

Embedded devices are all around us and mesh networking is a hot research topic
right now.  When devices want to communicate with one another, their
communication is often unencrypted readable.  Or, end-to-end security is used,
so that if one of the two devices is compromised, communication between the two
can be decrypted.  This is especially a problem for embedded devices because it
is easy for an attacker to purchase a device and take it apart to extract
secret keys in the device (and which are all too often the same among all of
those devices that the manufacturer produces).  scln is the beginning of what
could be a solution to this problem.  It is essentially a miniature onion
router protocol; it can't do everything that a true onion routing protocol can,
but it can mitigate a lot of the security concerns that arise in a network of
embedded devices.

The test hardware that it is designed for is only for the purposes of
demonstration.  Essentially, a bunch of AVR microcontrollers are connected to
one another over I2C (Atmel refers to the protocol as TWI due to trademarking
issues from Philips) to form a basic network.  Certain micros are set up to act
as relays while others are set up to act as communication devices.  When one
device wants to talk to another, it generates an onion and a reply onion and
passes the message through the network.  At each relay reception, the onion is
unpeeled a bit and passed to the next relay.  The system is designed to be as
stateless as possible.

The obvious security flaw in this demonstration is that the devices can all
"hear" communication from all of the other devices, so if any relay is
compromised, it can listen to all of the other network chatter.  But, in a real
environment, devices cannot "hear" every other device.  This demonstration
setup is intended to show the operability of scln.  scln can then be installed
onto a mesh network, whereby the aforementioned security flaw no longer exists.


Deliverables
------------

    fw/ contains firmware for the AVR microcontrollers
        - a custom-made bootloader allowed me to progrm all of the devices with
          scln easily
        - scln/ contains the main code
        - there are some other basic tests in there
          
    sw/ contains software used to interact with the network
        - the bootloader software allows for programming and modification of
          the devices
        - the xfer script allows for sending packets, e.g. via
            echo "[hex] [hex] [hex]..." | xfer.py


Explanation of Operation
------------------------

    A relatively simple circuit containing a network of ATMEGA168's is set up.
    The SDA and SCL lines are connected between the devices.  Port B can be
    connected to LEDs for debugging.  For the purposes of the demo, one of the
    devices is designated as the "transmitter" and the other is designated as
    the "receiver."  The first transmits whatever the computer says to over the
    UART through the network via onion routing and the second ultimately
    receives this data and sends it back to the computer for verification.
    
    In between the transmitter and the receiver are a series of nodes.  These
    nodes unpeel the onion given to them and send the result to the next node
    in the circuit.
    
    The basic framework defined by scln can be easily extended to support
    complicated implementations of onion routing.  Unfortunately, I didn't have
    as much time as I thought I would to fill out the features I wanted to.
    
    Unfortunately, because I wasn't good about committing successful attempts,
    the communications network began to fail after a series of changes and
    hasn't run since then.  I'm thoroughly confused as to why it is no longer
    working.


Limitations
-----------

    Due to some frustrating bugs, I wasn't able to get RSA up and running.  I
    was looking to use AVRCryptoLib (http://www.emsign.nl/, source located in
    ext/), but didn't have enough time to look into the considerations
    involving dealing with how the packet length would change.  So, I used a
    simple XOR key and kept all keys in flash (normally, we would want to store
    private keys in the internal EEPROM or somewhere unique).  A cool way to
    randomize the circuit forming would be to read the lowest bit from the ADC
    on an open input line a few times.  I didn't get around to handling reply
    onions.