>> µTLS - DEFINING LIGHTWEIGHT SECURITY FOR IoT (PART 10)
This was a project from day one we weren't even sure would be possible
to do - persistence prevails!
With the last few blog entries I have covered the design and evolution of
the µTLS (micro TLS) project with the aim to bring a feasible security
protocol to low powered micro-controllers with limited resources. From
design, through implementation, tweaks, refactoring and integration into
an existing deployment - we now have a solid foundation to build on that
accomplishes the initial goals defined.
The
Arduino UNO
was the primary target for µTLS (micro TLS) due to its limited resources
an widespread adoption within the hobby IoT environment - it has become
a platform known as the birthplace for numerous IoT projects with breadboards
and jumper wires going crazy that eventually gets replaced by a custom
PCB as ideas become reality and hit production phase.
Does it really make sense to throw in a higher powered ARM
or X86 micro-controller when it isn't required? It comes
down to being lazy - it is easier to throw together a Linux based
micro-controller instead of writing barebones firmware for a low-powered
micro-controller - which compound additional security issues to the
product and have higher power demands; as well as increasing operational costs.
In reality; most IoT products are pretty dumb. They have simple tasks;
such as reading a few sensors; trip a few GPIO's to control relay or
switches and periodically check in with a server to upload data or
receive instructions to perform specific operations. Product design
for the embedded space can be costly - for most, it is who gets to the
market first, security and data integrity comes second.
µTLS (micro TLS) was created to prove to the community that
security and data integrity is feasible; without having to sacrifice
power and costly components - and more importantly open a pandoras
box of issues these systems inherit as a result. There is no reason
to do so - and here we have proof.
It is time for IoT product manufacturers to stop being lazy and bring
the right people into the job when designing products. "Real programmers"
are a dying breed these days - IoT has forced developers to think about
memory and performance, not encourage bloatware and just throwing together
a heap of third party libraries. As unfortunate as it sounds; this is the
reality these days.
To finish off the µTLS (micro TLS) series - it is only fitting
to define some metrics for what has been achieved so far. With these
facts presented; we do hope that the excuse of not having security
being low-power and limited resources be thrown out the window - and
lay off any engineer who claims that.
When targetting the
Arduino UNO
(16Mhz avr) we see the following memory and resource utilization:
protocols program size mem:entry mem:peak mem:diff (entry/peak)
-----------------------------------------------------------------------------
none-none 16,718 bytes 966 bytes 1,164 bytes
none-rot13 16,888 bytes 966 bytes 1,164 bytes 0 bytes 0 bytes
none-xor128 16,960 bytes 1,094 bytes 1,292 bytes 128 bytes 128 bytes
none-aes128 20,584 bytes 994 bytes 1,234 bytes 28 bytes 70 bytes
none-aes192 20,600 bytes 1,002 bytes 1,282 bytes 36 bytes 118 bytes
none-aes256 20,658 bytes 1,010 bytes 1,330 bytes 44 bytes 166 bytes
none-rc4 18,158 bytes 1,234 bytes 1,786 bytes 268 bytes 622 bytes
aes128-aes128* 21,030 bytes 994 bytes 1,256 bytes 28 bytes 92 bytes
ecc163-aes128* 26,262 bytes 994 bytes 1,622 bytes 28 bytes 458 bytes
When targetting the
Arduino Due
(84Mhz ARM) we see similar memory and resource utilization:
protocol program size mem:entry mem:peak mem:diff (entry/peak)
-----------------------------------------------------------------------------
none-none 21,828 bytes 5,688 bytes 5,912 bytes
none-rot13 21,948 bytes 5,688 bytes 5,912 bytes 0 bytes 0 bytes
none-xor128 21,988 bytes 5,816 bytes 6,040 bytes 128 bytes 128 bytes
none-aes128 24,492 bytes 5,724 bytes 6,028 bytes 36 bytes 116 bytes
none-aes192 24,500 bytes 5,732 bytes 6,076 bytes 44 bytes 164 bytes
none-aes256 24,540 bytes 5,740 bytes 6,124 bytes 52 bytes 212 bytes
none-rc4 22,692 bytes 5,964 bytes 6,532 bytes 276 bytes 620 bytes
aes128-aes128* 24,716 bytes 5,724 bytes 6,076 bytes 36 bytes 164 bytes
ecc163-aes128* 27,508 bytes 5,724 bytes 6,452 bytes 36 bytes 540 bytes
The figures presented include a full application sketch for the initialization
and operation of a µTLS (micro TLS) client. All core logic dealing with
connection establishment to a µTLS (micro TLS) server, authentication,
identification, key exchange and on-going communication over the HTTP
protocol.
Also included is the system memory required for the Serial and networking
(WiFi or Ethernet) libraries - in addition to a 512 byte shared memory
region known as 'scratch'; which can be resized as needed depending on the
target architecture and purpose for the micro-controller. The cases marked with
an asterisk ('*') would be considered secure; in alignment to the
Transport Layer Security guidelines.
We have demonstrated that even an Arduino UNO can be a secure
weather station;
and we can target any micro-controller as necessary quite easily - with
little or zero modification to our source code. Personally; it is nice
to see µTLS (microTLS) working without problems on the
particle.io device series.
The full source to the driver routines for each of these modes are provided
for reference:
µTLS (micro TLS) will undergo further development - mainly to add
additional protocol modules and refine the library to match additional use-cases
as we integrate it into some existing IoT projects that we currently have
deployed. Parties interested in knowing more about µTLS (micro TLS)
and information on licensing should contact us at the link provided below.
It is my hope that 2017 will bring true awareness to IoT security and
make sure something is done.
![[Valid RSS]](valid-rss-rogers.png "Validate my RSS feed")
