Lightweight Cryptography For The IoE

This is the age where technology is expected to do more, faster, anonymously, and often invisibly. And it’s supposed to use less power, with smaller footprints, unobtrusively and intuitively. And all that needs to be protected with cryptography.

That’s the goal, at least. But as Simon Blake-Wilson, vice president of products and marketing for Rambus‘ Cryptography Research Division notes, “the lower the security level, the more has to be compromised.”

To mitigate the effects of that compromise, the industry has embarked on a mission to develop and implement lightweight ciphers, cryptography primitives, and lightweight processor cores. And they are beginning to show up on the cryptography scene.

Let’s talk processors
There are a lot of MPU architectures that exist in the archives that have the potential to serve as lightweight crypto processors. However, it seems to be difficult to bring together the right compact core and a workable instruction set architecture (ISA) that is both compact, and code-efficient enough to run on the core.

Another boundary is that the solution must also be low-cost, and low-power.

“One of the restrictions of the IoT is that it needs to be very low power and secure,” said Emerson Hsiao, senior vice president of sales and technical service for North America operations at Andes Technology. “To do that you need a custom engine that is low power, secure and efficient.”

The theme of non-standard approaches to solving this problem is a recurring one these days throughout the semiconductor industry. “Standard cryptography approaches on light devices are not feasible, mainly because the pin count is so restricted, the amount of power they draw, and the amount of energy available to them,” said Pankaj Rohatgi, director of engineering at Cryptography Research.

“Furthermore, one has to look at three things; the algorithms used, how to securely implement them, and, finally, how one manages those algorithms, and the keys,” adds Blake-Wilson. “When you look at lightweight cryptography for the IoE, you have to look at those three areas.”

Adds Chowdary Yanamadala, vice president of business development at ChaoLogix: “No matter how light the chips are, there are two security features that they must contain—encryption and authentication.”

Light cryptography processors present some unique challenges. There is progress being made on all fronts, however. For example, one solution points to designing a custom hardware platform. That might be the best overall solution but not very feasible for anything other than high-value targets. It tends to be expensive, and inflexible when it comes to wide-scale applicability. Yet it is one avenue of the light platform.

The software approach gives the hardware the flexibility to implement a wide range of cryptographic options, but is computationally burdened and often translates into sub-par performance. So the development has been around finding the magic bullet that brings hardware and software together to create a practical platform.

As this approach gains steam, there is a likelihood that other peripheral problems will arise that aren’t part of today’s standard cryptography. “With these new lightweight approaches, if you compromise one chip, it can lead to what is called a ‘class break,’ which means that all of the devices with that particular solution are compromised, as well,” said Yanamadala. With all that on the plate, it will take a bit of jockeying to come up with workable solutions.

There are a number solutions in various stages of development. One particularly novel approach to a lightweight processor solution was presented by Begul Bilgin, Elif Bilge Kavun and Tolga Yalcin from the Department of Cryptography at the Middle East Technical University in Turkey. Their research lays out the two elements, hardware and software, for a lightweight crypto processor.

On the software side, the ISA used is the GNU Compiler Collection (GCC), which is a very mature and widely used compiler that supports a number of languages. It happens to be a good choice for C-based programming languages, which are very commonly used in cryptogram coding. It is also freeware.

The hardware end is comprised of a core processor linked to an ASIC cryptographic co-processor and attached to the main core via I/O. The instruction set used is based on the Zylin Processing Unit, a zero-operand stack-based minimalistic design. Natively, it has a 32-bit data path, but for this design, it was modified to 8-bits. Narrower data paths are one of the crucial parameters that keeps the processing fast and lean. But it requires running light algorithms to obtain the efficiency.

For the cipher, a lightweight KLEIN block cipher was chosen. This cipher was actually designed to work with 64-bit data blocks of varying key sizes. However, it has an 8-bit serial data path which mates up nicely with the modified ZPU design.

The theory looks promising, but it is unknown if the design was ever put into production.

Another interesting approach uses a compact FPGA architecture working with the standard elliptical curve cryptography (ECC), based on standardized National Institute of Standards and Technology (NIST) primes [See reference 1]. In this approach, the MicroECC processors are working with 16-bit registers and a single 16-bit hardware multiplier. It also implements block memories rather than registers. These options significantly reduce the operational overhead of the chip and provide a lightweight solution that can run various lightweight cryptographic algorithms relatively efficiently.

Another approach presents lightweight cryptoprocessors using network on chip (NoC) technology. NoCs are considered an excellent platform for such applications because they address the bus constraint issues of SoCs. That approach, and scaling native 64-bit operations to 16 bits, will significantly reduce the device footprint and computational complexity. It also will reduce power consumption.

NoCs also offer a lot of design options. There are a wide variety of design parameters that can be modified to optimize the computational efficiency of the NoC processor. The NoC contains a number of interfaced components, such as a network adaptor, interconnect links, and routing nodes. Each can be optimized for efficiency and functionality. Because NoCs have their storage and I/O interconnected by network switches rather than hardwired paths, the overall computational time is reduced vs. the SoC, and component counts are reduced, as well. Couple that with new ultra-lightweight cryptographic algorithms like PRESENT, Simon, Speck, and KATA, and NoCs become a viable contender for ultra-lightweight cryptography.

Let’s talk ciphers
Before we get too deep into the inner workings of ciphers, note that this topic is wide and deep. There is, virtually, an unlimited field of ciphers and their applications. It’s not quite so deep for lightweight ciphers, but still the platform is broad. For that reason, this discussion will stay with a narrower view of ciphers with a focus on the majority of IoE devices, which will be, predominantly, low-cost and low-tech. That being said, a quick overview of ciphers might be in order.

Fig. 1. German Lorenz cipher. Source: Wikipedia

Both block and stream ciphers are encryption/decryption algorithms belonging to the symmetric key cipher family. All ciphers take plain-text inputs and convert them to ciphertext outputs. Block ciphers are used to encrypt fixed-length bits blocks using what is called an unvarying transformation. Stream ciphers, on the other hand, take variable length bit streams and apply a varying transformation on each bit.

Stream ciphers are generally faster than block ciphers in execution. They are also less complex, from a hardware perspective. Stream ciphers are better at encrypting plain text in differing quantities (a secure WI-FI connection, for example). Stream ciphers involve more work to implement correctly and they have an intrinsic weaknesses based on usage, similar to that of the one-time pad, and the keystream has strict requirements. Stream ciphers also have less memory requirements because they only work on a few bits at a time. This makes them cheaper to implement overall, in more complex devices.

Typically, block ciphers mandate more memory than stream ciphers. The reason for that is due to the fact that they work on larger chunks of data, and often have what is termed “carry over” from earlier blocks. Block ciphers are also more powerful and can be applied in more ways. One advantage to block ciphers is that they can be used to encrypt and authenticate at the same time, whereas stream ciphers require a separate message authentication code.

Lightweight ciphers for the IoE
At first glance it might seem that stream ciphers would be the choice for IoE devices because of their size, speed and simplicity. This would be especially true considering the IoE’s three primary drivers: execution time, memory metrics and binary code size.

However, initial observations can be deceiving. As it turns out, these metrics are best addressed by block ciphers when it comes to IoE devices.

The main reason is that the majority of such devices, as mentioned earlier, are block data type devices, where the amount of data is either known or fixed. Such data may be a file, data fields, or protocols such as request/response, as in HTTP where the length of the complete message is known before encryption. That makes the block cipher the better choice, and with these low-complexity devices, it is relatively easy, and inexpensive to implement, as well.

There are many block ciphers available, but not all lend themselves to lightweight cryptography. Today, two of the most prolific are Simon and Speck, which were developed by the NSA and just blessed by NIST. However, there are others. The table below lists the most active and is a handy comparison of a number of specs of the various ciphers.

The golden children
Simon and Speck, however, are the golden children for low-power, low-resource IoE devices. They were specifically designed for optimal performance on processor- and memory-constrained devices. They also offer a variety of block and key sizes, and function well in software.

“The size of the key does affect the energy used by the device,” notes Richard Newell, senior principal product architect in the SoC products group at Microsemi. “And that is directly related to the security level.”

So even though Simon and Speck are light products, the designer can’t necessarily assume that they can do whatever they want because the parameters are related. And to keep within constraints means compromising on such things as the security level.

However, Simon and Speck do promise to be two general algorithms that easily can be designed into a wide variety of IoE devices, with varying levels of security, as opposed to the many other ciphers that target specific applications. That is their forte. And they are free and relatively inexpensive to implement. That is what the NSA and other entities envision for these ciphers so that, going forward, IoE devices will have cryptography, no matter how low-end.

Primitives
The basis for these lightweight algorithms comes from a new class of lightweight primitives. Briefly, cryptography primitives are the lowest level cryptography algorithms that serve as a base for cryptographic protocols and functions. Lightweight primitives are designed to work with less complexity, and minimal functionality.

What one finds in primitives are such things as hash functions, public and private key cryptography, authentication protocols, digital signatures, and a cryptographically secure pseudorandom number generator, among other things.

By themselves, primitives are rather like cards in a deck. Each has a function, but to get a winning hand one must combine the right cards for the resultant hand. In the same way, combining security primitives creates the security protocol one desires.

Fig. 2: Primitives

Consider SPONGENT, for example, which is a lightweight hash function. The basic security design consideration for a lightweight hash function with an n-bit output size calls for a collision resistance of 2^n/2. Additionally, the pre-image and second prei-mage resistance is specified as 2^n.

To meet this requires a number of assessments. For the IoE, low-power and small footprint limit the design. In such a case, the design could be a permutation-based sponge construction where r = rate, (bits per in or out, per one permutation call); c = capacity, then the permutation-based sponge construction can reduce the state size to almost half, for n ≥ c with a reasonably small r. The key is the r. In this case, the sponge construction is hermetic with the preimage resistance reduced to 2^n-r, and the second pre-image resistance reduced to 2^c/2. The collision resistance remains at the 2^c/2 level.

If one plugs in some values, it can be seen how compact this hash function is. If further compacting is desired, the second preimage can be eliminated.

Essentially what this says is that the smaller the rate, the smaller the function. It is this type of design methodology, with any security protocol design or primitives, that should be kept in mind when designing cryptography for low-cost/power IoE devices.

This is just one simple, generic approach to demonstrate how one of the lightweight primitives looks and works. There are many others out there and the space keeps getting larger, especially those looking at the IoE objects and security.

Conclusion
Without a doubt, the lightweight cryptography landscape is up and coming. There really isn’t much choice. Either deal with low-cost, low-power platforms and secure them, or leave the IoE as vulnerable as a newborn kitten.

Rohatgi notes that the future of lightweight cryptography certainly rests with the IoE. “The need for IoE devices, especially in sensors and tags, is mushrooming and the awareness of cryptography for these devices is growing, as well.”

These devices are low-power, low-cost, and there is no bandwidth for high-end cryptography. To secure them, the lightweight segment—both software and hardware—has a tremendous opportunity to develop and capitalize on the development of a lightweight cryptography that can work in the IoE and keep it locked down. Let’s hope it works.

Reference 1: NIST primes are significantly smaller, in bit sizes, than public-key cryptosystem. In general, their computational complexity is lower that RSA or discrete algorithmic schemes.