>> µTLS - DEFINING LIGHTWEIGHT SECURITY FOR IoT (PART 6)
Choosing a candidate for key exchange is so difficult - so it was time to
go head to head!
With the implementation of the Advanced Encryption Standard in place
within µTLS (micro TLS) - it is time to move onto determining the
best manner to perform key exchange. Traditonally; TLS employs a
key exchange algorithm that tends to utilize
algorithms to exchange senstive information to establish on-going communication
with less resource constrained algorithms such as AES.
There are two well known public-key cryptography algorithms available on
the market, commonly used for security internet communications - they are
ECC (Eliptic Curve Cryptography).
RSA was first introduced in 1977 and MIT filed a patent in 1983 describing
its use for securing communication systems. It wasn't until the late 1990's
before we saw the algorithm being used for sending information around the
internet; then later integrated into the TLS protocol. While it has
survived for decades; it has
due to its large key size and dependence on math factoring. There are even
with to find such factors - RSA 768 has been factored to date.
ECC on the other hand is relatively new on the scene and while it has
started to be slowly adopted within the security industry - it simply
doesn't have the longevity of RSA and hasn't had sufficient time to
be proven as a successful replacement. On the positive side; the key sizes
are smaller (for the same level of security) and while slightly more
complicated to process, tends to be faster. Not to mention ECC still has
that are still active which can cause licensing concerns.
Putting aside the politics of whether to use RSA or ECC - how do they perform?
RSA on the Arduino platform in the past - so, all that was required was
to review the documentation on ECC and re-work various public domain and
license friendly open source code available and target it for the Arduino.
At first; it wasn't pretty, but I got there in the end - obviously not
everyone writes code with resource constraints in mind!
Using an Arduino UNO (avr) and an Arduino Due (ARM); some
benchmarks are below:
Without fully understanding the complexities of the algorithms in
question (yet another fun read); let's take a look at the numbers. The
code column is the approximate compiled binary size when targetting
the avr platform. ECC requires around 2.5x more code than RSA
overall; the RSA implementation however isn't complete as it cannot
handle larger than key size packets.
Naturally; as the key size increases; so does the RAM requirement
to have local variables to perform the complex mathematical operations on
them; as RSA key sizes grow - we quickly run out of memory on the devices.
RSA 2048 isn't possible on the Arduino UNO due to this reason.
When comparing algorithms; it has been argued that the security level on
ECC with 163 bits is equivalent to the security level of RSA at 1024 bits
(see below). In these examples; two input buffers were provided; 128 bytes
in length and then memory profiling was performed. ECC uses almost 400
bytes less memory than RSA under these conditions.
It is also important to note the differences between encryption (public key)
and decryption (private keys) across the two algorithms. RSA is quite CPU
intensive when using the private key, as compared to the public key
(the exponent plays a major factor here) - where ECC tends to be relatively
similar in both operations with decryption being almost twice as fast.
It is also worth while pointing out that using RSA will always produce the
same result, where ECC integrates an element of randomness such that the
same input can produce different outputs; as the public keys and random
factors are integrated into the resulting bit stream.
I would also like to point out that the RSA code on Arduino has
had substantial optimations performed on it - the majority of the low
level routines written in avr assembly (40% speedup). The ECC
algorithm has yet to benefit from any optimizations at this point in time.
So; what does this mean for µTLS (micro TLS)?
In our last entry; we had a working none/aes-128 sketch on an
Sketch uses 17,880 bytes (55%) of program storage space.
Global variables use 475 bytes (23%) of dynamic memory,
leaving 1,573 bytes for local variables. Maximum is 2,048 bytes.
The question now comes down to how difficult it will be to integrate the
ECC algorithm into the sketch and share the dynamic memory that is being
used during the communication with the server. It may be a very tight
fit; but on paper it seems quite feasible.
Once we put all of these security algorithms and µTLS (micro TLS)
in place; we may only have a few Kb of space to actually do something.
Thankfully; reading and writing GPIO pins isn't rocket science and typically
doesn't require much program space. We must also keep in mind that there
are micro-controllers with more program space and RAM available if required.