How to Secure Cryptography on Constrained Devices

TL;DR

Constrained devices need cryptography that balances strong security with limited memory, gate count, and power budgets. Lightweight designs such as SIMON and SPECK target those restrictions, but testing on Google Glass found their performance advantage over AES 128 was negligible, showing that established encryption may remain practical when the device has a capable processor.

Transcript

Excellent. Well, thank you everyone for coming. Um, so I'm Ray Potter, CEO of SafeLogic, and with me is, uh, Whit Diffie, uh, technical advisor, uh, to SafeLogic, and I guess he really needs no introduction. So, um, no, I'm glad you all are here and, and pardon the, uh, informality of the talk today. But we just wanted to have a kind of a conversat... Read More

Key Insights

• Constrained-device cryptography is shaped by several resource limits, including available memory, implementation footprint, hardware gate count, and power consumption. These constraints vary significantly among wearables, RFID tags, wireless sensors, medical implants, smart meters, and other connected devices, so one design cannot be assumed to fit every environment.
• SIMON is a lightweight algorithm that uses cellular automata as combining functions. Its rounds use several tapped inputs that are fed back, and the combining operation appears cheaper than a table lookup, supporting implementations where hardware gate count is a central limitation.
• SPECK is a flexible lightweight design that uses a modulo-N adder as its nonlinear function. The adder can be implemented economically as a ripple carry adder or with more gates as a carry lookahead adder, allowing adaptation to different hardware and software requirements.
• SIMON and SPECK use many relatively inexpensive rounds and support flexible parameters. Their published block-size options extend from small constrained configurations up to the AES range, allowing implementers to consider different balances among footprint, processing cost, and security requirements.
• Actual hardware testing is necessary before assuming that a lightweight cipher will deliver a meaningful performance advantage. SafeLogic's proof-of-concept tests on Google Glass found negligible performance differences among SIMON, SPECK, and AES 128 when encrypting substantial amounts of data.
• Wearable devices can hold regulated or sensitive information that requires strong protection. A surgeon recording a procedure with Google Glass could place patient data on the device, creating a need for encryption that satisfies the applicable healthcare rules described in the discussion.
• Connected household devices can reveal private information or enable physical disruption when inadequately protected. A compromised Nest could expose whether away mode is active, while interference with heating access during severe winter conditions could create consequences beyond ordinary data loss.
• Low power consumption is especially important for devices that are difficult to reach or service. Wireless sensors placed inside the body or distributed in denied areas should minimize battery replacement needs, making cryptographic energy costs a practical design concern alongside memory and gate count.

Questions & Answers

Q: How should cryptography be chosen for constrained devices?

Cryptography for a constrained device should be selected by identifying the device's actual limiting resources, including memory, implementation footprint, hardware gate count, and power consumption. The algorithm should then be tested on the intended hardware rather than judged only by its lightweight label. SafeLogic's Google Glass tests showed why this matters, since AES 128 performed similarly to SIMON and SPECK in that environment.

Q: What are SIMON and SPECK designed to accomplish?

SIMON and SPECK are cryptographic algorithms designed for constrained environments. They use many rounds whose individual operations are relatively inexpensive, and their parameters can accommodate different block sizes. The discussion presents SIMON as focused on economical combining functions and SPECK as an adaptable design that can suit hardware or software, particularly where gate count, footprint, or processing resources are restricted.

Q: How does SIMON support implementations with low gate counts?

SIMON uses cellular automata as combining functions, with several tapped inputs being fed back during each round. Diffie describes this operation as appearing much cheaper than a table lookup. Combined with a structure that uses many inexpensive rounds, this approach targets devices where the number of hardware gates is a critical constraint on whether cryptography can be deployed.

Q: How does SPECK adapt to hardware and software constraints?

SPECK uses a modulo-N adder as its nonlinear function. An implementer can build that adder inexpensively as a ripple carry adder or spend more gates on a carry lookahead adder. This range of implementation choices makes the design adaptable to different resource profiles, although the discussion notes that SPECK was presented as the more software-friendly of the pair.

Q: Why should lightweight ciphers be tested against AES on real devices?

A lightweight design does not automatically produce a meaningful performance improvement on every constrained device. SafeLogic created proofs of concept using SIMON, SPECK, and AES 128, then performed bulk-encryption tests on Google Glass. The performance differences were negligible because the processor was more powerful than expected, demonstrating that measurements on target hardware should guide the final algorithm choice.

Q: Why do wearable devices require strong encryption?

Wearables may collect or store information whose sensitivity is determined by the application rather than the device's small size. The discussion gives the example of a surgeon recording a procedure with Google Glass, which would leave patient data on the device. That information would need encryption under the healthcare rules cited in the talk, making strong cryptography necessary despite resource constraints.

Q: What security risks can arise from connected home devices?

Connected home devices can expose private behavioral information and create opportunities for physical disruption. The discussion notes that an attacker who compromises a Nest could inspect away mode to infer whether someone is home or on vacation. It also describes the risk of someone cutting off heating access during severe winter conditions, showing that device security can affect both privacy and safety.

Q: Why is power consumption important for wireless sensors and medical devices?

Power consumption matters when a device is installed somewhere that is difficult, risky, or impossible to service frequently. A medical sensor placed inside the body should not require an operation merely to replace its battery more often than necessary. Sensors distributed in denied areas create a similar servicing problem, so cryptography must protect communications without exhausting the available power budget.

Summary & Key Takeaways

• Cryptography for constrained devices must accommodate limited storage, small implementation footprints, restricted gate counts, and low power budgets. These limitations affect wearables, RFID tags, wireless sensor networks, medical devices, smart meters, and other connected equipment. The appropriate design depends on the particular constraint imposed by each environment and its hardware.

• SIMON and SPECK were designed for constrained environments using inexpensive rounds and flexible parameters. SIMON uses cellular automata as combining functions, while SPECK uses a modulo-N adder for nonlinearity. SPECK can be adapted to hardware or software by choosing between a simpler ripple carry adder and a more gate-intensive carry lookahead adder.

• SafeLogic tested proofs of concept using SIMON, SPECK, and AES 128 on Google Glass by bulk-encrypting substantial amounts of data. The observed performance differences were negligible because the device's processor was more capable than expected. This result suggests that lightweight algorithms should be evaluated against established options on the actual target hardware.