>> µ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 the Diffie–Hellman key exchange algorithm that tends to utilize public-key cryptography 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 RSA and 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 problems due to its large key size and dependence on math factoring. There are even challenges 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 patents that are still active which can cause licensing concerns.

Putting aside the politics of whether to use RSA or ECC - how do they perform?

I had previously implemented 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:

				avr		ARM
	size	code	RAM	encrypt	decrypt	encrypt	decrypt
RSA	128	~2kb	284	178 ms	1,951 ms	28 ms	261 ms
RSA	256	~2kb	444	609 ms	12,716 ms	77 ms	1,586 ms
RSA	512	~2kb	764	2,225 ms	95,079 ms	264 ms	11,206 ms
RSA	1024	~2kb	1,340	8,504 ms	727,955 ms	1,032 ms	88,216 ms
ECC	163	~7kb	934	42,011 ms	20,686 ms	2,404 ms	1,179 ms

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 Arduino UNO:

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.