When designing Internet of Things devices, there may come a time when the encryption frameworks builtin to your communications interface don’t meet your needs. Maybe the 1.6kB handshake overhead for a DTLS connection is excessive for a device that only transmits once a week. Or maybe you want to protect Bluetooth advertising data in a way that still allows other devices in your deployment to receive and act on that data. Regardless, you need application level encryption, so how should you proceed?

As with any engineering task, the first action is to gather requirements.

Our Requirements

Certified Standard

Your choice of encryption algorithm is not the place to be a cowboy/girl. By a certified standard, we are happy with any algorithm certified by NIST. This means the algorithm has been thoroughly scrutinized by a wide range of sources.

Protect unencrypted metadata

Many packet formats have a range of metadata that we would like to ensure has not been tampered with, but which cannot be encrypted (e.g. for routing purposes). One potential location for this information is in the nonce (initialization vector), but most algorithms have a fixed size nonce with tight requirements to maintain security guarantees. The other solution is to use an AEAD algorithm (Authenticated encryption with associated data). AEAD algorithms also verify the contents of the plaintext associated data, not just the nonce, tag and ciphertext.

Computationally Efficient

IoT devices are often resource constrained in energy usage and computational throughput. The more efficient the algorithm is, the faster we can finish encrypting/decrypting and start the next packet or go back to our sleep mode.

Algorithm Options

Recognizing the need for lightweight encryption algorithms that meet these requirements, NIST started investigating new AEAD algorithms in 2013. A call for algorithms was made in 2018, with entrants compared against the current standard (ChaCha20-Poly1305) and security claims evaluated. In February 2023 the ASCON algorithm family was announced as the candidate for standardization.

Algorithm Performance

As we all know, engineering without data is just guesswork, so we decided to evaluate the performance of ASCON against the incumbent, ChaCha20-Poly1305. Using the reference implementations we evaluated the ascon-128, ascon-128a and ascon-80pq members of the ASCON family, with ascon-128a being the most performant (as we would expect from the literature). The reference repository provides multiple back-ends optimized for different hardware architectures and use-cases. We will only present armv7m_small here as we found it to hit the sweet spot of size to performance on our nRF5340 SoC.

Encryption and decryption times are averaged across multiple runs for each algorithm and payload size. ChaCha20-Poly1305 is from MbedTLS v3.5.2, as distributed by Zephyr v3.6.0. Both CPU cycle counts and nanoseconds are provided.

ascon-128a - armv7m_small
  Length    1 Encrypt   3083 (  48171 ns) Decrypt   3067 (  47921 ns)
  Length   16 Encrypt   3725 (  58203 ns) Decrypt   3684 (  57562 ns)
  Length   64 Encrypt   5842 (  91281 ns) Decrypt   5786 (  90406 ns)
  Length  128 Encrypt   8666 ( 135406 ns) Decrypt   8590 ( 134218 ns)
  Length  256 Encrypt  14314 ( 223656 ns) Decrypt  14198 ( 221843 ns)
  Length  512 Encrypt  25610 ( 400156 ns) Decrypt  25414 ( 397093 ns)
  Length 1024 Encrypt  48202 ( 753156 ns) Decrypt  47846 ( 747593 ns)
chacha20-poly1305 - MbedTLS v3.5.2
  Length    1 Encrypt  20211 ( 315796 ns) Decrypt  20182 ( 315343 ns)
  Length   16 Encrypt  19797 ( 309328 ns) Decrypt  19922 ( 311281 ns)
  Length   64 Encrypt  20322 ( 317531 ns) Decrypt  20449 ( 319515 ns)
  Length  128 Encrypt  26185 ( 409140 ns) Decrypt  26312 ( 411125 ns)
  Length  256 Encrypt  37911 ( 592359 ns) Decrypt  38038 ( 594343 ns)
  Length  512 Encrypt  61363 ( 958796 ns) Decrypt  61490 ( 960781 ns)
  Length 1024 Encrypt 108267 (1691671 ns) Decrypt 108394 (1693656 ns)

We can see that ascon-128a compares quite favorably to the default chacha20-poly1305 implementation, being around 6 times as fast for tiny packets and over twice as fast for larger packets.

The default MbedTLS implementation is not the only choice however. Mbed has the option to provide optimized implementations of various algorithms, and Nordic Semiconductor has licensed a collection of these implementations from Oberon Microsystems for use with their SoCs. ChaCha20-Poly1305 is one of the supported algorithms, so we can run the test again with this back-end.

chacha20-poly1305
  Length    1 Encrypt   9781 ( 152828 ns) Decrypt   9762 ( 152531 ns)
  Length   16 Encrypt   9545 ( 149140 ns) Decrypt   9613 ( 150203 ns)
  Length   64 Encrypt  10326 ( 161343 ns) Decrypt  10393 ( 162390 ns)
  Length  128 Encrypt  12922 ( 201906 ns) Decrypt  12989 ( 202953 ns)
  Length  256 Encrypt  18114 ( 283031 ns) Decrypt  18181 ( 284078 ns)
  Length  512 Encrypt  28498 ( 445281 ns) Decrypt  28565 ( 446328 ns)
  Length 1024 Encrypt  49266 ( 769781 ns) Decrypt  49333 ( 770828 ns)

While not quite reaching the performance level of ascon-128a, the optimized implementation is much closer, especially once payload sizes reach 256 bytes.

Other considerations

The PSA Certified IoT Security Framework , is an industry initiative to provide standardized resources for all aspects of IoT Security. One component of this is the PSA Crypto API, which simplifies the process of performing cryptography operations in a secure manner.

The big advantage of this API is that it allows cryptography operations to be run without the caller ever needing to handle the encryption key, which is a big security win, especially when combined with other PSA components such as TrustedFirmware-M. As an existing standard, ChaCha20-Poly1305 is well integrated into the PSA crypto ecosystem, while the ASCON family is not yet (but on their radar).

Summary

Based on its well developed integration into the PSA framework, we have made the decision to based our AEAD encryption on the ChaCha20-Poly1305 algorithm. While not quite as performant as ASCON, the additional security provided by its ecosystem integration is more than enough to make up for the slight performance hit in the use-cases we see, where encryption is typically at least 64 bytes.

As the standardization process of ASCON progresses and software integration increases, we have no doubt that eventually it will overtake ChaCha20-Poly1305 as our preferred algorithm.

If you would like to discuss wireless communications, PSA or cryptography for your IoT product feel free to contact us on LinkedIn or via connect@embeint.com