The world is increasingly filled with connected computing devices. These are the computers running our automobiles, lighting, and alarm systems; inventory tags on products in distribution channels; and environmental sensors in industrial facilities, to name a few.
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 possible since they are likely to be deployed in large volume.
Security issues are a concern since these devices do not have the spare CPU capacity and random-access memory handy to run modern cryptography routines. Even adequate power may be an issue.
Several years ago, the National Institute of Standards and Technology (NIST) created an initiative 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 US 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 more of a case to be made.
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 radio-frequency identification tags, sensor nodes, and smart cards.
The term lightweight shouldn’t be mistaken as weakness. The goal of the Lightweight Cryptography project is to create and standardize methods and practices that are strong for the environments they run on.
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 small, 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 or 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.
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.