The National Institute of Standards and Technology (NIST) has recently finalised a lightweight cryptography standard designed to provide a defence from cyber attacks for even the smallest of electronic devices.
‘Ascon-Based Lightweight Cryptography Standards for Constrained Devices’ contains tools designed to protect information created and transmitted by billions of devices that form IoT and other small electronics, such as RFID tags and medical implants.
Constrained devices like these often have far fewer computational resources than computers or smartphones, but still require protection from cyber attacks. The anseer to this is lightweight cryptography.
“We encourage the use of this new lightweight cryptography standard wherever resource constraints have hindered the adoption of cryptography,” said Kerry McKay, NIST computer scientist, who co-led the project with her NIST colleague Meltem Sönmez Turan. “It will benefit industries that build devices ranging from smart home appliances to car-mounted toll registers to medical implants. One thing these electronics have in common is the need to fine-tune the amount of energy, time and space it takes to do cryptography. This standard fits their needs.”
The standard is built around a group of cryptographical algorithms in the Ascon family, which NIST chose in 2023 as the basis for its lightweight cryptography standard after a multi-round public review process.
Ascon was developed in 2014 by a team of cryptographers from Graz University of Technology, Infineon TEchnologies, and Radboud University. In 2019 it emerged as the primary choice for lightweight encryption in the CAESAR competition.
In the standard are four variants from the Ascon family that give designers different options for different use cases. The variants focus on two of the main tasks of lightweight cryptography: authenticated encryption with associated data (AEAD) and hashing.
ASCON-128 AEAD is useful when a device needs to encrypt its data, verify the authenticity of the data, or — importantly — both. A common weakness of small devices is their vulnerability to side-channel attacks, in which an attacker can extract sensitive information by observing physical characteristics like power consumption or timing. While no cryptographic algorithm is inherently immune to such attacks, ASCON is designed to support side-channel-resistant implementations more easily than many traditional algorithms. Devices that can benefit from its approach include RFID tags, implanted medical devices, and toll-registration transponders attached to car windshields.
ASCON-Hash 256 takes all the data it encrypts and uses it to create a short ‘hash’ a few characters long, which functions like a fingerprint of the data. Even a small change to the original data results in an instantly recognizable change in the hash, making the algorithm useful for maintaining the data’s integrity — such as during a software update, to ensure that no malware has crept in. Other uses are for protecting passwords and the digital signatures we use in online bank transfers. It is a lightweight alternative to NIST’s SHA-3 family of hash algorithms which are widely used for many of the same purposes.
ASCON-XOF 128 and ASCON-CXOF 128 are hash functions with a twist: both algorithms allow the user to change the size of the hash. This option can benefit small devices because using shorter hashes allows the device to spend less time and energy on the encryption process.
The CXOF variant also adds the ability to attach a customised ‘label’ a few characters long to the hash. If many small devices perform the same encryption operation, there is a small but significant chance that two of them could output the same hash, which would offer attackers a clue about how to defeat the encryption. Adding customised labels would allow users to sidestep this potential problem.
McKay explained that the team plan for the standard not only to be of immediate use, but also to be expendable to meet future needs.
“We’ve taken the community’s feedback and tried to provide a standard that can be easily followed and implemented, but we are also trying to be forward-looking in terms of being able to build on it,” said McKay. “There are additional functionalities people have requested that we might add down the road, such as a dedicated message authentication code. We plan to start considering these possibilities very soon.”
There’s plenty of other editorial on our sister site, Electronic Specifier! Or you can always join in the conversation by visiting our LinkedIn page.
