>> IOT SECURITY - FEASIBILITY IN MICRO CONTROLLERS?

As the Internet of Things has gained popularity and buzzword status, a number of large efforts to create standards consortiums and offer cloud services for storage and processing the data collected. Unfortunately, the weakest link, the device actually gathering data has not really been considered or has been marked in the "too difficult" bucket in regards to security and marked as a problem for someone to solve.

With the introduction of micro controllers like the Arduino, Raspberry Pi and BeagleBone - it has become very easy (for almost anyone) to connect sensors and the appropriate network connections to gather information as part of the IoT ecosystem either in a hobby project or even the future development of a commercial product. Can such solutions be secured?

Of course, security via public knowledge not security via obscurity.

It has been accepted that implementing a TLS (Transport Layer Security) or SSL (Secure Sockets Layer) has been sufficient for securing communication over a network stream. Is it possible to implement this directly on micro-controllers with limited CPU or memory - chances are not directly, but something based on the same principles should be secure.

wikipedia.org identifies the algorithm involved - there is first a key exchange or agreement (typically secured using RSA), then the identification of a cipher (typically AES) and some form of data integrity (typically hash functions SHA1, MD5) to validate the message is complete and has not been modified in transmission. Sounds basic enough - can it be done?

There is only one way to find out - challenge accepted!

It is clear from the start that the idea of an implementation that would be 100% TLS/SSL compatible and be able to talk to existing server solutions is out of the question - due to memory limitations and processing power, so a "custom" client and server variant will definitely be required and use at least a 1024 bit RSA key pair to classified as secure.

The basic network communication strategy would be as follows:

The only element missing from this workflow is a mechanism for the client (Arduino device) to perform a validation of the server's public key to prevent fake servers stepping in and stealing information - there are alternative ways to solve this problem, which can be built into the workflow later, first it must be known if RSA-1024 is even possible on them!

After purchasing a suite of Arduino testing devices (ranging from the 16Mhz Arduino UNO through to the beefy 400Mhz Intel Galileo including all devices in-between) and hand-crafting a BigInteger data type and required functions to implement the following algorithm:

cyphertext = message^exp % mod

It was time to run the code on the devices and report on their performance (time taken)!

• Arduino UNO       16Mhz AVR               ==> 8504 ms * (was 12596 ms)
  Arduino Leonardo  16Mhz AVR               ==> 8563 ms * (was 12682 ms)
  Arduino Mega      16Mhz AVR               ==> 8504 ms * (was 12596 ms)
  Arduino Due       84Mhz ARM               ==> 1032 ms
  Arduino Yún       16Mhz AVR + 400Mhz MIPS ==>  707 ms
  Intel Galileo     400Mhz x86              ==>  192 ms
  
  *updated after mission critical code implemented in AVR asm
  
  

One of the interesting devices was the Arduino Yún where it was possible to interface with the secondary 400Mhz MIPS processor that is running a Linux distribution to offload the encryption work while still operate as a standard Arduino device.

While the underpowered AVR based devices did take sufficient time to encrypt a message using a 1024 bit public key – it was still possible to do so within the limited resources available and with a very small code foot print. It would be feasible to simply wait the 12 seconds or, do it as two separate sessions – but once this is done, all future communication would use symmetric keys which is almost in real time.

It is clear from the initial findings that the resource limitations of micro-controllers are definitely no excuse for IoT hardware to not provide an acceptable level of security in them. With the most difficult (implementation) algorithm out of the way and proven to work - the next will be to focus on AES and SHA1/MD5 and build a test server to communicate with.