Cryptography For ULP Devices

Soon virtually everything and everyone will be connected to the IoE in one fashion or another, and much of it will be wireless. To make it all work, these wireless, and low-power devices will need a new paradigm for handling cryptography.

Ultra-low power devices have an interesting, and challenging set of metrics. There are, in general, two approaches that can work, with a variety of sub-scenarios. But the bottom line is that when it comes power consumption, there is a finite number of joules available from a self-contained power source such as a battery—although eventually things like super capacitors, solar cells, and other energy harvesting technologies will be options, as well.

To optimize the power in a ULP device, cryptography and otherwise, there are two approaches that can be uses; steady-state low-power over time and pulsed operation over time. There are many sub-schemes that can vary these categorical absolutes, even combinations of each, so this isn’t an either-or proposition. But the bottom line is that available power from batteries is affected by a number of environmental and usage variable – temperature, battery type, load demand (over time and whether steady or pulsed) and device parameters.

ULP cryptography issues
The main issue surrounding cryptography in ULP devices is the relationship between functionality and power utilization. There are other issues, but they are generally a subset of this. The IoE will use highly computationally constrained devices. Traditional cryptographic algorithms are power- and clock-cycle hungry, because they are the exact opposite of the IoE devices – computationally intensive. That is their job – to check everything that can be compromised and that takes power. ULP devices, being computationally constrained, need to make every clock cycle and micro amp count. The two are not mutually compatible.

There are different approaches on how best to utilize the limited resources in ULP devices while still providing adequate cryptography functionality. The main one is to design smarter decision-making circuitry that can decide what needs to be run under a cryptographic envelop. There are various avenues being followed under that umbrella. Another is to develop lighter weight algorithms and ciphers.

On the hardware side, the most obvious is going down in process architecture, but that’s easier said than done. “One cannot just go to lower power and architecture,” said Gordon Cooper, product marketing manager at NXP. “You have to have to maintain performance. As we go down in process architecture you have that performance for less power, but now you have leakage issues.”

And where there are leakage issues, there are integration issues. At the most advanced nodes all IP, whether it’s security or a processor or I/O block with security built in, needs to fit into the surrounding components in a device. Understanding those integration challenges and building security to match those criteria is extremely difficult.

“If you make something that is trivial to integrate with, it will make a huge difference,” said Simon Blake-Wilson, vice president of products and marketing at Rambus‘ Cryptography Research Division. “It’s a good tradeoff of achievable targets, trying to address ease of use for the designers, for the managers of the devices.”

Fitting into a tight power budget is just another constraint—but this one is really tough to manage.

Lightweight cryptography
The term “lightweight cryptography” (LWC) points to the next generation of low-power security. And according to Philip Dunkelberger, CEO of Nok Nok labs, “here, the devil will be in the details.”

Richard Newell, senior principal product architect for the SoC products group at Microsemi, observes that, “lately there has been a lot of research going on in LWC. The biggest challenge we have seen is not only to make it lightweight, but keep it strong.”

Cryptography primitives is one of the more promising approaches in LWC. These are the most basic building blocks and the basis for virtually all crypto systems (TLS, SSL, SSH) that are well established and very reliable. Therefore, they turn out to be the ideal platform for the ground level of low-power crypto design.

Cryptography primitives present a number of basic premises to build upon. Some of the more common are:

• Integrity: Mechanisms that make sure the data at the destination is correct, for example.
• Availability: Validate the availability of communication nodes, such as determining if the node is compromised under a denial of service attack.
• Authentication: Provide collision awareness and prevention, compression, integration with other cryptographic mechanisms and overall integrity characteristics.
• Non-Repudiation: Verifying the sender is, indeed the message originator.
• Message Authentication Codes (MAC): One-way compression (HASH) functions that can compute an abbreviated hash value for a message (certain SHA algorithms for example).
• Private and public key cryptography: Cipher text that is encodable and decodable with the same key (AES), or encodable and decodable with a different key (RSA).
• Digital signatures: Verifying the message sender’s authenticity.
• Network integration: Making sources anonymous by pooling the communications from many users, which convolutes what came from where.
• Anonymous information retrieval: Acquiring information from databases anonymously, so the server is unaware from where it came.
• PRNG: Cryptographically secure pseudo random number generators.

“In the past couple of years, there have been some LWC’s proposed based upon basic primitives,” said Newell. “Present is one of them. And the NSA has published a couple of ciphers, as well—Simon, which was particularly good on hardware, and Speck, which is the software compliment to Simon.”

Currently these are undergoing analysis to see just how strong they really are.

Another approach is stream ciphers. Stream ciphers have been around for a while but haven’t drawn a lot of interest until ULP became hot. Stream ciphers consist of a continuous stream of bits or string numbers that are generated using an initialized vector and key. The methodology behind this is to use mathematical operations that will generate cipher text from plain text using the key and initialized vector. Combining such mechanisms with a PRNG and a hashing mechanism provides a set of cryptographic services. Following is a short overview of the set of major components common to lightweight stream ciphers (listed chronologically from oldest to newest).

• Grain: A cipher with various bit lengths capable of variable throughput from 1 to 16 bits per clock. This has a very wide range of applicability but suffers from weakness against a number of attack vectors including, time, algebraic, and memory.
• Salsa20: A family of stream components that emphasizes speed over confidence. They are relatively easy to compromise, so their implementations, as well as their weaknesses, must be well understood.
• Trivium: A cipher that is good for implementation on platforms with flexible hardware. Overall a strong design with decent attack resistance.
• Enocoro: This is a very robust element with a number of variations that use key-length streams from 80 to 128 bits. It offers excellent resistance to hacking, has a low implementation cost and is relatively flexible.
• MICKEY: This is a acronym for Mutual Irregular Clocking KEYstream generator. It is a fairly simple component with strong security.
• SOSEMANUK: A cipher with a variable key length; between 128 and 256 bits. Offers a very high throughput, and has a small internal state footprint. The strength is about average.
• A2U2: This component offers a high throughput rate (1 bit per clock cycle), and is very simple and compact. However is very weak in its ability keep the key secret.

There are others, of course, and interest in this segment is heightening. Expect to see a lot of activity in lightweight ciphers as development in next generation IoE devices ratchets up.

A third area of lightweight cryptography emerging is in lightweight Hash Functions. Briefly, a hash function takes the key, and creates a hash value by mapping it to a specific length value. The value is a representation of the original string of characters. However, its big advantage for, LWC, is that the hash value is generally smaller than the original.

Hash codes are very resistant to collisions, and virtually impossible to invert, such as decoding the original data from the hash value alone. Their condensed format makes them extremely attractive to LWC platforms in their simpler configurations. Below are some of the more popular hashing function (again in order of date, oldest to newest).

• Photon: A number of instances exist — 80/20/16, 128/16/16, 160/36/36, 224/32/32 and 256/32/32. This function offers strong resistance to differential and linear cryptanalysis and offers decent throughput.
• Keccak: NIST selected this hash-function because of it “sponge” construction, which can infinitely vary the input and output. This is a very good function with broad-based applicability because it offers superior protection against typical generic attacks.
• Spongent: This function also offers various instances of output – 88, 128, 160, 224 and 256 bits. It is also very secure against collision and preimage.
• Quark: Also based on “sponge” construction. Sponge technology has the advantage of a reduced area and lower power consumption. Various instances exist; D-Quark, U-Quark and S-Quark. It boasts good resistance to collisions and pre-imaging.
• ARMADILLO: ARMADILLO 1 and ARMADILL0 2 currently exist. They provide very good, secure authentication for a challenge-response protocol, but are susceptible to secret key attacks in polynomial time.

There are other hashing platforms, as well.

This section has discussed some of the platforms that are being looked at to address the emerging ULP IoE device market. None of these are earth-shattering technologies and some have been around for quite a while. Most of these are being “reborn” because the low-power segment has found new territory in the IoE and emerging platforms such as wearables.

Lightweight security
The term lightweight security does not mean weak or “light” security. It means good good security without being power hungry. The above discussions have shown that such security it possible and within the realm of effective algorithms on a variety of platforms.

There also is work being done in lightweight block ciphers. A table of block ciphers is given in Appendix 1, for reference and further reading. One direction is to try to optimize the substitution box (S-Box). S-boxes are a relatively abstract subject and analysis here is beyond the scope of this article, but a brief discussion is warranted because they are a fundamental cryptographically building block.

Some of the newer work in S-box optimization is interesting. For example, about a year ago, a new design concept was proposed, which is intended to unify the seven S-Boxes of KASUMI (S7 and S9), SNOW-3G (SR and SQ), MILENAGE (AES) and ZUC (S0 and S1) algorithms into one universal (common) substitution box. The objective is to see if such an approach can be used to reduce the resources required so this methodology can be scaled down to low-power applications. While still in the theoretical stage, the synthesis results did prove that this particular approach achieves higher levels of performance, with at least 30% fewer hardware resources. [See reference 1]

This is a relatively new theory and there are others doing similar work to optimize S-box functionality for applicability to lower power designs. The sweet spot seems to be finding the right matrix size while still maintaining adequate convolution. However, most of this is still in the development area and the primary metric is to reduce the S-box matrix without substantially weakening the cipher.

Missive
There really is a fairly deep well of ciphers and algorithms that can be investigated for ULP applicability.

The one thing that surfaces repeatedly is that lightweight security will, most certainly, have to run on hardware. Figure one is a generic representation of that relationship compares software and hardware power utilization. If one integrates the area under this curve example, it will be obvious that the consumption of software is orders of magnitude higher than the hardware. That is not to say that software implantation is out of the game, but for ULP devices, it will have limited applicability. The power demand of software security is much too high to be able to implement in the ULP devices coming down the road.

Figure 1. Relationship between software and hardware encryption vs. power. Source: Electronics News.

This article has discussed some of the technologies and platforms that have the potential to evolve into or be integrated into ULP devices. We may not have a clear view of what the IoE will eventually evolve into, but we do have a clear view of ULP platforms. And within the next few years, expect to see this area get some real traction—especially as we start to develop those nifty little gadgets such a motes, Internet dust, and smart socks.

Reference 1: Anastasios N. Bikos, Nicolas Sklavos, Apostolos Fournaris, from the KNOSSOSnet Research Group, Computer & Informatics Engineering Department, Technological Educational Institute of Western Greece, Greece, Fully Depleted Silicon-On-Insulator.

Appendix