Criminals, Conjecture and Connected Things

My connected devices were initially secured using a hash-based message authentication code (HMAC).  An HMAC is constructed for each HTTP request directed at a device. The HMAC is created by combining some of the HTTP header elements, the time and date, the body of the request and a secret key / passwd.  The output block is then attached to the header of the request and transmitted to the selected device.  Upon reception of the request, the device collects the same header information, the time and date, and the body of the message and computes the HMAC using the same secret key / passwd.  If the computed HMAC and the one  sent with the request match, then the request is fulfilled.

While this protects the device from being compromised and the data being changed, it does nothing to protect the data from being read by prying eyes.  At first glance this seems unimportant since the data, inadvertently or intentionally, viewed by others carries little information.  For example, why would we care if others know the temperature of some sensor in our home? Why would it matter if someone knows the ringtone loaded in to our doorbell? Why would it matter if others know the setting on our thermostat?  Well each on their own might not matter, but with perhaps hundreds of devices in our home we offer up a lot of unprotected data for criminals to conjecture with.

Imagine a criminal mastermind sniffs your unprotected data and learns that your thermostat was just set to 55 degrees and the dog bark ringtone was loaded into your doorbell. In addition, late in the evening the temperature in the home is 55 degrees.  It wouldn’t be difficult to conjecture that no one is home.  In addition, the dog bark ringtone may lead them to believe that your gone for a while.

This simple example is intended to show that while we might erroneously think that this data does not need to be protected, it does!  In addition to protecting the device from intruders using HMAC, the data needs to be encrypted using SSL or other techniques.  By securing both, your connected devices and your data you will reduce the chance of having your virtual and physical spaces compromised by criminals.

Arduino As An AVR Debugger

When you leave the safety of the Arduino development environment and move to development with Atmel AVR processors, without an IDE, you lose some debugging / printing capabilities.  However, there is a simple technique to recover some functionality. This is not a replacement for real debugging tools, but rather a quick fix for simple print capability. I develop in an OS X environment with Emacs as my editor, avr-gcc as my compiler, and avrdude to download the compiled code to the AVR processor via an AVRISP mark II device.

Now the simple hack. You take an Arduino and make it a slave SPI device that simply reads data off of the SPI bus, when it is selected, and uses the Arduino’s Serial.print() capability to print the data over the USB port to the Arduino console. The following code performs this function.

You now setup the AVR microcontroller to be an SPI master and create print functions that meet your needs.  A simple function that prints a single byte or character is included below.  It simply selects the debug device, sends a byte of data over the SPI bus, and deselects the debug device.  When the Arduino receives the byte of data it is displayed on the Arduino console, our new debug window.

This function can now be used to create additional functions such as printStr(), etc.  As I said, a simple hack to solve a simple problem.