Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Assembly C D Python Other
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
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.