Why right TLS configuration Matters in IoT?

Significant progress has been made in IoT devices, but few restrictions still apply today. Most IoT devices are constrained in terms of power consumption, compute power, and available memory. In the exploding world of IoT, where every gadget seems to be getting smarter and more connected, security isn't just important—it's absolutely critical. With the sheer volume of devices and the diverse range of capabilities they possess, the potential for breaches and vulnerabilities is immense.

Unfortunately, most of the IoT product developers don't go deep when it comes to TLS. Most developers go with the default options provided by various TLS libraries. While it is not wrong, it is not optimized for most of the applications. You should also look into the TLS configuration you use in your firmware a bit more carefully. Not only it can improve security, but it can also reduce firmware binary size and power consumption. Let's look into the aspects.

CPU and Memory Requirements

The majority of the CPU and Memory in TLS handshake goes to cryptographic operations. When it comes to memory requirements, it is well known that Elliptic Curve Cryptography(ECC) uses lower memory compared to RSA, but what about CPU? Turns out it is not that simple.

I can simply run openssl speed rsa and openssl speed ecdsa in a Linux pc to find out the difference.

                  sign    verify    sign/s verify/s
rsa  512 bits 0.000036s 0.000002s  27476.1 406708.8
rsa 1024 bits 0.000104s 0.000007s   9653.7 149798.0
rsa 2048 bits 0.000699s 0.000021s   1430.8  48194.0
rsa 3072 bits 0.002256s 0.000047s    443.2  21330.8
rsa 4096 bits 0.005249s 0.000078s    190.5  12753.4
rsa 7680 bits 0.044978s 0.000263s     22.2   3808.7
rsa 15360 bits 0.245610s 0.001044s      4.1    957.6

                              sign    verify    sign/s verify/s
 160 bits ecdsa (secp160r1)   0.0002s   0.0002s   5212.5   5239.5
 192 bits ecdsa (nistp192)   0.0002s   0.0002s   4357.1   4325.8
 224 bits ecdsa (nistp224)   0.0001s   0.0001s  19684.7   8623.2
 256 bits ecdsa (nistp256)   0.0000s   0.0001s  43047.5  14436.6
 384 bits ecdsa (nistp384)   0.0009s   0.0008s   1099.6   1330.3
 521 bits ecdsa (nistp521)   0.0003s   0.0006s   3397.1   1703.6
 163 bits ecdsa (nistk163)   0.0002s   0.0005s   4409.6   2213.1
 233 bits ecdsa (nistk233)   0.0003s   0.0006s   3230.7   1645.3
 283 bits ecdsa (nistk283)   0.0005s   0.0010s   1951.9    992.6
 409 bits ecdsa (nistk409)   0.0009s   0.0017s   1115.8    576.2
 571 bits ecdsa (nistk571)   0.0018s   0.0035s    559.6    283.7
 163 bits ecdsa (nistb163)   0.0002s   0.0005s   4396.3   2216.0
 233 bits ecdsa (nistb233)   0.0003s   0.0006s   3121.7   1620.5
 283 bits ecdsa (nistb283)   0.0005s   0.0010s   1874.0    963.0
 409 bits ecdsa (nistb409)   0.0009s   0.0019s   1093.0    539.6
 571 bits ecdsa (nistb571)   0.0020s   0.0039s    496.0    253.3
 256 bits ecdsa (brainpoolP256r1)   0.0004s   0.0004s   2447.4   2464.0
 256 bits ecdsa (brainpoolP256t1)   0.0004s   0.0004s   2468.5   2659.2
 384 bits ecdsa (brainpoolP384r1)   0.0009s   0.0008s   1075.5   1238.9
 384 bits ecdsa (brainpoolP384t1)   0.0009s   0.0007s   1098.3   1340.9
 512 bits ecdsa (brainpoolP512r1)   0.0014s   0.0012s    693.0    826.1
 512 bits ecdsa (brainpoolP512t1)   0.0014s   0.0011s    715.8    887.6

Now let's compare side by side. Let's compare RSA3072 and ECC P256 as they are roughly equivalent when it comes to bit strength.

                            sign      verify     sign/s   verify/s
rsa 3072 bits               0.002256s 0.000047s  443.2    21330.8
256 bits ecdsa (nistp256)   0.0000s   0.0001s    43047.5  14436.6

Although it's done on a PC, you'll see similar characteristics in an MCU as well. What we can observe?

RSA is significantly slow in signature but almost 47% faster in verification compared to ECDSA

Hold on to this fact! We will revisit it later.

There's also a matter of hardware acceleration in H/W. So what we can conclude?

Generally, for applications involving device certificates, consider using ECC.

• If your MCU has a dedicated crypto coprocessor block, use that algorithm as it'll be much faster and can offload CPU for other tasks. i.e if your MCU has an RSA accelerator, consider using RSA instead of ECC

Anyway full disclosure: In modern MCUs, this is not a noticeable overhead when you transmit several kBs of data. But things become quite interesting when your device transmits a few hundred bytes.

Power Consumption

When you design a product that relies on battery backup to run, power consumption is very crucial. Even if you have a direct power supply, it is always desired to consume as minimum power as possible to make the product more sustainable. In some cases, power consumption may have very stringent constraints. For such a scenario, TLS configuration can be very crucial.

The first thing here is the selection of the TLS version. The latest version of TLS is 1.3 and it adds significant improvements over TLS 1.2. TLS 1.3 reduces the total number of round trips required for the handshake to just one compared to TLS 1.2 which requires two roundtrips, and hence is significantly faster. Switching to TLS 1.3 can definitely reduce the amount of time the CPU needs to remain awake and hence the power consumption per wake-up and data submission.

According to this conference paper, the algorithm scheme can have a significant impact too. For the tests the author conducted using STM32F439ZI MCU, there are some interesting facts. Here's the power consumption measured by algorithm:

Algorithm      Mutual Authentication    Server Auth Only
RSA + ECDHE    78.062mJ                 12.991mJ
ECDSA + ECDHE  18.242mJ                 18.533mJ

Interesting? Why RSA is using high energy in mutual but less in server auth only? Remember the CPU Benchmark? We figured that RSA is quite fast when verifying the signature but not when generating one. In mutual authentication, client needs to both sign and verify while in server auth client only verifies the server certificate.

What does that mean? If your device uses device certificates to authenticate(which it should!) better to stick to ECC! If you are connecting to the server with TLS but just verifying server certificate RSA is better.

Now, you may think why should I care about few milli-joules worth of energy. But if your device operates on battery, every electron counts!

Conclusion

That was a lot! Don't worry, Anedya supports TLS 1.3 and both RSA as well as ECC certificates whichever you want to choose, and if you're just using default config, Anedya servers automatically prioritize ECC certificates over RSA reducing your device's memory requirement and power consumption! 🥳

To conclude:

• Use TLS 1.3 to improve latency, reduce active CPU time and hence power consumption.
• Use ECC certificates to save on memory and power when using device certificates to authenticate.
• Switch to the algorithm for which your MCU provides H/W acceleration. Look for cipher suites in your TLS Library configuration to achieve this.
• Disable unnecessary cipher suites in your TLS library, it can reduce your firmware binary size.
• Use external crypto-coprocessor chips to further reduce power/memory consumption as well hardening your device from attacks!