UPDATE: after some optimizations of C -> AVR assembly, some new timings available.
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 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:
It was time to run the code on the devices and report on their performance (time taken)!
Arduino UNO 16Mhz AVR ==> 12596 ms* 8504 ms# Arduino Leonardo 16Mhz AVR ==> 12682 ms* 8563 ms# Arduino Mega 16Mhz AVR ==> 12596 ms* 8504 ms# Arduino Due 84Mhz ARM ==> 1032 ms* Arduino Yún 16Mhz AVR + 400Mhz MIPS ==> 707 ms* Intel Galileo 400Mhz x86 ==> 192 ms*
# these numbers are based on mixed C/AVR assembly implementation
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 an 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.
We are actively looking into the realisation of this technology and building a framework for anyone to work with – if this would be of interest to you or you would like to know more about what we are doing, please reach out and contact us via email at info@evothings.com.