>> 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 = messageexp % mod
It was time to run the code on the devices and report on their performance
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.