Light-weight Crypto for IoT

While AES and SHA work well together within computer systems, they struggle in an IoT/embedded world as they take up: too much processing…

Light-weight Crypto for IoT

While AES and SHA work well together within computer systems, they struggle in an IoT/embedded world as they take up: too much processing power; too much physical space; and consume too much battery power. So NIST outlines a number of methods which can be used for light-weight cryptography, and which could be useful in IoT and RFID devices [1]. They define the device spectrum as:

  • Conventional cryptography. Servers and Desktops. Tablets and smart phones.
  • Light-weight cryptography. Embedded Systems. RFID and Sensor Networks.

Embedded systems

With embedded systems, we commonly see 8-bit, 16-bit and 32-bit microcontrollers, and which would struggle to cope with real-time demands for conventional cryptography methods. And in the 40+ years since the first 4-bit processor, there is even a strong market for 4-bit processors. RFID and sensor network devices, especially, have limited numbers of gates available for security, and are often highly constrained with the power drain on the device.

So AES is typically a non-starter for many embedded devices. In light-weight cryptography, we often see smaller block size (typically 64 bits or 80 bits), smaller keys (often less than 90 bits) and less complex rounds (and where the S-boxes often just have 4-bits).

The constraints of IoT

For light-weight cryptography the main constraints that we have are typically related to power requirements, gate equivalents (GEs), and timing. With passive RFID devices, we do not have an associated battery for the power supply, and where the chip must power itself from energy coupled from the radio wave. An RFID device is thus likely to be severely constrained in the power drain associated with any cryptography functions, along with being constrained for the timing requirements and for the number of gates used. Even if an RFID device has an associated battery (active RFID), it may be difficult to recharge the battery, so the drain on power must often be minimised.

There is thus often a compromise between the cryptography method used and the overall security of the method. Thus often light-weight cryptography methods balance performance (throughput) against power drain and GE, and do not perform as well as main-stream cryptography standards (such as AES and SHA-256). Along with this the method must also have a low requirement for RAM (where the method requires the usage of running memory to perform its operation) and ROM (where the method is stored on the device). In order to assess the strengths of various methods we often define the area that the cryptography function will use on the device — and which is defined in µm².

Within cryptography, we use symmetric key encryption, and which is either a block cipher or a stream cipher. Generally stream ciphers are faster and have a smaller overhead on providing memory buffers.

For light-weight cryptography PHOTON [2], SPONGENT [3] and Lesamanta-LW [4] are defined as standards for hashing methods within ISO/IEC 29192–5:2016, PRESENT and CLEFIA for block methods within ISO/IEC 29192–2:2012, and Enocoro and Trivium for stream methods within ISO/IEC 29192–3:2012.

Block ciphers

With a block cipher we typically have 64-bit or 128-bit blocks. In this we replace methods such as AES, RC5 and 3DES:

  • XTEA. XTEA. XTEA is a light-weight block cipher.
  • PRESENT. PRESENT. Present is a light-weight block cipher.
  • SIMON. SIMON. SIMON is a light-weight block cipher.
  • SPECK. SPECK. SPECK is a light-weight block cipher.
  • CLEFIA. CLEFIA. CLEFIA is a light-weight block cipher.
  • LED. LED. LED is a light-weight block cipher.

Stream ciphers

With a stream cipher we typically generate a key stream from a key and IV, and then X-OR the plaintext stream with the stream key. In this we replace methods such as RC4 and ChaCha:

  • Enocoro. Enocoro. Enocoro is a light-weight stream cipher.
  • Grain. Grain. Grain is a light-weight stream cipher.
  • Trivium. Trivium. Trivium is a light-weight stream cipher.
  • Mickey. Mickey. Mickey is a light-weight stream cipher.
  • Rabbit. Rabbit. Rabbit is a light-weight stream cipher.

Hashing methods

In this we replace methods such as MD5, SHA-1, and so on:

  • SPONGENT. SPONGENT. SPONGENT is a light-weight hashing function.
  • Lesamnta-LW. Lesamnta-LW. Lesamnta-LW is a light-weight hashing function.
  • QUARK. QUARK. QUARK is a light-weight hashing function.
  • PHOTON. PHOTON. PHOTON is a light-weight hashing function.

MAC

  • Chaskey (MAC). Chaskey. Chaskey is a light-weight MAC function.

Asymmetric encryption

  • ELLI. ELLI. ELLI is a light-weight asymmetric encryption method.

Conclusions

Our crypto methods have been designed for high-powered computers, with lots of processing power and memory. But our IoT devices can be limited in their processing power, memory and battery capacity. We thus need to investigate new methods, and the methods I’ve outlined as just a few examples.

References

[1]	K. A. McKay, L. Bassham, M. S. Turan, and N. Mouha, “Report on lightweight cryptography,” 2017.
[2]	J. Guo, T. Peyrin, and A. Poschmann, “The PHOTON Lightweight Hash Functions Family,” Crypto, pp. 222–239, 2000.
[3]	A. Bogdanov, M. Knežević, G. Leander, D. Toz, K. Varici, and I. Verbauwhede, “{SPONGENT}: The Design Space of Lightweight Cryptographic Hashing,” 2011.
[4]	S. Hirose, K. Ideguchi, H. Kuwakado, T. Owada, B. Preneel, and H. Yoshida, “A Lightweight 256-Bit Hash Function for Hardware and Low-End Devices: Lesamnta-LW,” Springer, Berlin, Heidelberg, 2011, pp. 151–168.