The world around us is increasingly filled with connected computing devices, even if we don’t recognize them as such. These are the computers running our automobile, lighting, and alarm systems; RFID inventory tags on products in distribution channels; and environmental sensors in industrial facilities, among other things.

We call these devices the Internet of Things. IoT devices come in all sizes and levels of complexity. Some may have a full Linux server in them and others a simple, proprietary OS with no file system, display interface, or other components standard in conventional computers. For efficiency’s sake, they have just what they need.

While security is absolutely an issue for these devices, major security efforts in the industry are leaning toward algorithms that require computing power beyond what these devices possess. To power these devices, a vibrant market of 16-bit, 8-bit, and even 4-bit microcontrollers is available, but they are designed as simply and inexpensively as practical because they are likely to be deployed in large volume.

The problem, when it comes to security, is that these devices do not have the spare CPU capacity and RAM handy to run modern cryptography routines. Even the necessary power may be an issue.

Several years ago, the National Institute of Standards and Technology (NIST) created a project and a group to address the problem, which it called Lightweight Cryptography. The project’s goal is “to solicit, evaluate, and standardize lightweight cryptographic algorithms that are suitable for use in constrained environments where the performance of current NIST cryptographic standards is not acceptable.”

NIST, part of the U.S. Department of Commerce, conducts research and advances standards in a variety of areas, from weights and measures to applications of neutrons to computer security. It has a mandate specifically mentioned in the U.S. Constitution: “Congress shall have the power to … fix the standard of weights and measures.” Many months ago, I wrote about NIST’s efforts to develop cryptography standards resistant to the quantum computing, a new computing paradigm that weakens many of our key cryptography algorithms.

What is a constrained device?

Put simply, a constrained device is one that lacks the CPU and memory capacity to run conventional cryptographic routines. To be clear, NIST says devices that are capable of running conventional, standard cryptographic algorithms should do so. There are two NIST-approved block cipher algorithms: Advanced Encryption Standard (AES) and Triple Data Encryption Algorithm (TDEA, or colloquially known as Triple DES or 3DES). AES supports keys as small as 128 bits, and this may be in reach of some microcontroller-based applications.

Not all “lightweight” devices need cryptographic protection, just the ones that communicate. Consider a typical electronic body temperature thermometer. It takes temperature and displays it. It doesn’t need a lot of processing power, but the function is completely contained in the device. There’s no real need for encryption.

But imagine a more sophisticated thermometer that reports temperature wirelessly to a device that collects patient data. Or a blood glucose monitor. Or one of those pill cameras that transmits images of your digestive system to an outside receiver through sensors you wear. The need for encryption in the communications for these devices is debatable, but there is at least a theoretical case to make for it.

How light is ‘lightweight?’

The term lightweight cryptography does not imply a weak implementation but rather cryptographic algorithms with low overhead requirements. These algorithms are appropriate for relatively simple, low-power and resource-constrained devices, such as RFID tags, sensor nodes, and smart cards.

The notion that the methods are weak is a tempting and common but ultimately incorrect one. The goal of the Lightweight Cryptography project is to create and standardize methods and practices that are strong for the environments on which they run.

And there’s more to the definition of lightweight than constraints. This project is targeting devices that are not connected to the Internet, at least not directly.

It is possible to make little, low-power devices that run powerful cryptography routines. Consider the Yubikey Nano. It’s the size of the business end of a male USB-A plug, but there’s a chip in there that performs strong asymmetric encryption functions. But this is an authentication device, an application with very different requirements than the typical lightweight device, and it’s a $50 product.

No ‘cross-weight’ functions

The lightweight algorithms are different from and incompatible with conventional heavyweight functions. Therefore, if a lightweight device running lightweight crypto software needs to communicate with a heavyweight device, either the lightweight algorithms must be implemented on the heavyweight device or a proxy/intermediate device must be used to decrypt input from one side and output encrypted data to the other.

The proxy device would seem to be an unnecessary expense and add complexity and vulnerability. In such cases, it is more likely that the lightweight algorithms would also run on the heavyweight device, but—like so much else in this area—it depends on the application.

First call for submissions

After much consultation with industry, academia, and other NIST groupies, the Lightweight Cryptography project issued its first call for submissions for standard algorithms. It was not a call for a comprehensive cryptography suite but for basic algorithms for use in building applications.  

One of the main categorical divides of encryption is between symmetric and asymmetric encryption. Each is better suited than the other for specific applications. Symmetric takes plaintext (unencrypted data) and a key and generates ciphertext (encrypted data). Asymmetric encryption uses public and private keys and digital certificates to authenticate parties to one another. In the normal course of encrypted communications on the Internet, such as when your browser connects to an HTTPS site, asymmetric encryption is used to authenticate one site to the other or both to each other, and to exchange encryption keys. The real work of encryption of the data is done using symmetric algorithms.

The NIST requirements included an authenticated encryption with associated data (AEAD) algorithm, which is a symmetric function, and a hash function. NIST is not, at least at this point, addressing asymmetric encryption, because it poses severe challenges for constrained devices. In many cases, an AEAD function performs the missing functions of asymmetric authentication and key exchange by using a unique combination of an encryption key and a cryptographic nonce (a randomly generated value) to ensure the authenticity and confidentiality of the data. The combination of key and nonce must be unique to prevent “replay attacks,” in which a valid data transmission is repeated by an attacker. The nonce will force a change in the ciphertext even for the same plaintext.

The AEAD requirements say that the encryption function takes four inputs: the plaintext, associated data (a header that is not encrypted), a fixed-length nonce, and a fixed-length key; it outputs ciphertext. The decryption function, also known as decryption verification, takes the ciphertext, associated data, nonce, and key and—if and only if the input ciphertext was valid—outputs the plaintext.

This does leave the problem of key distribution, but this is less of a problem in the envisioned lightweight applications. In an automobile, for example, it is not unreasonable to preload the key in the devices. These systems are not connected to the Internet, and there is no obvious way for the key to become available to outsiders. There is, however, an unobvious way.

Because of the nature of the applications and standards, a class of exotic attacks—side-channel attacks—becomes more significant in lightweight cryptography. Side-channel attacks use side effects of a cryptographic implementation, such as timing, power consumption, and electromagnetic emissions, to discover sensitive information about the implementation itself.

The key sizes and other parameters of lightweight implementations are smaller than in conventional, heavyweight implementations, so an attacker who can collect large amounts of data from an encrypted device and analyze it with brute-force methods offline on more capable hardware will have a better chance of success with lightweight than with heavyweight applications.

There is research that explains how resistance to side-channel attacks works. The NIST requirements call for how to protect against these forms of attacks.

There is a similar problem with what are called fault attacks, which induce crashes and other errors into computation to learn about program behavior and are especially at issue when the attacker has physical access to the device. The requirements also call for resistance to fault attacks.

Hash functions are all over cryptography and used for a variety of purposes. A hash function takes a variable-length string of data as input and outputs a fixed-size value, known as a digest or hash. The same input string will always generate the same output hash, and even a small change in the input will cause a significant change in the output. It should be computationally infeasible to construct a second input that will hash out to the same value. So hashes are often used as proxies for the input text, especially in asymmetric cryptography.

The dominant mainstream hash function now is SHA-2 (for Secure Hash Algorithm), and a SHA-3 function was standardized several years ago. But both have internal state requirements that are likely to exceed those in constrained devices. Thus, NIST is calling for new proposals for those devices.

Round 1 candidates

There was a lot of interest from the community regarding the new standards. After filtering out the ones that, for one reason or another, did not meet the requirements, there were 56 candidates left.

The candidates show a wide variety of approaches and claims as well as some amusing names, like Elephant, Liliput, and Thank Goodness It’s Friday (TGIF).

So where are we?

Don’t be surprised if many of the candidates see approval in one form or another. The applications envisioned for these standards are highly varied, and the requirements are context-sensitive. It’s still early, but NIST may want to give developers many tools and allow them to make their own design trade-offs.

If you’re a conventional IT technologist, it’s unlikely that you’ll deal directly with lightweight cryptography for implementation any time soon. But the security of everything is at issue these days, and you should expect to see more and more complicated devices and wonder if they are being properly secured. If they are, lightweight cryptography may be playing a role.

I would like to thank Kerry McKay of NIST for helping me understand the issues and processes in lightweight cryptography and the working group.