Speck finding its place in the internet of things

In some IoT applications, devices such as RFID tags, sensors, contactless smart cards and medical devices, have only limited computational capability because of cost or power reasons. Yet, security is still a critically important requirement, and cryptography is a basic building block that needs to be supported now and in the future as companies’ critical infrastructure of IoT ecosystems expand. Traditional cryptographic algorithms, such as Advanced Encryption Standard (AES), may require more computational power than these kinds of devices can support. Thus, there has been substantial interest in recent years in lightweight cryptography.

Enter Speck, a family of lightweight block ciphers publicly released by the National Security Agency in 2013. It has been optimized for performance in software implementations while its sister algorithm, Simon, has been optimized for hardware implementations. Speck is a simple add-rotate-xor (ARX) cipher that can have anywhere from 22 to 34 iterations of functions that repeatedly scramble data to secure and support a variety of block and key sizes.

Speck is not without controversy. The NSA attempted to standardize these ciphers in 2014, but withdrew its submission last year after delegates from Germany, Japan and Israel went to the International Organization of Standards to express concern over the NSA’s motives and were suspicious that the NSA had engineered backdoors into the cipher. For certain applications, where such concerns don’t apply, Speck is still an excellent choice for a lightweight cryptography cipher. The algorithm has been extensively studied in the academic community, and to date no viable attack has been found.

Those familiar with white-box cryptography understand that white-box implementations of cryptography impose both computational and memory overheads to a cryptographic implementation, potentially undermining the goal of being lightweight. White-box algorithms rely on large numbers of table lookups and code transformations to ensure that encryption keys are never revealed in the clear, even while they are being used to encrypt or decrypt data.

However, there are two reasons why you might be interested in a white-box implementation of the Speck lightweight cipher.

The first reason is that it is a lightweight white-box algorithm compared to, for instance, AES. So, if white-box protection is a core requirement and you are trying to minimize the computational and memory footprint, white-box Speck might be a good choice. Compared to a white-box AES implementation, a white-box Speck implementation is about eight times faster and somewhat smaller. However, in many applications the footprint is an issue, and Speck could be a feasible option that would meet the specifications of the device.

Second, IoT devices often are part of a broader ecosystem. Although the IoT device itself might even lack resources to implement lightweight white-box cryptography, it may need to share information encrypted with a lightweight cipher or communicate securely with other devices that don’t have such constrained performance requirements. Those devices may be under different threats that white-box cryptography can mitigate.

Consider a medical device that may have severe computational restrictions, such as a glucose monitor. The device itself might run Speck directly to encrypt blood sugar information and communicate that to a smartphone so that users can track their health statistics conveniently. The smartphone can use a white-box implementation of Speck to handle that sensitive data on the phone. The same holds true for handling sensitive data within one’s burgeoning home IoT ecosystem.

These are just some of the many examples where lightweight cryptography will play an increasingly important role in securing the internet of things across industries and inside our personal dwellings. We’re just scratching the surface.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.