Lightweight Cryptography Security Modules for IoT Devices

Fault Analysis of Lightweight Cryptography

Background

Fault analysis intentionally introduces computational errors into a cryptographic device and uses both correct and faulty ciphertexts to estimate the secret key. In this study, we propose a fault-analysis method for the lightweight block cipher LTLBC.

The assumed fault-injection method is clock glitching. A shortened or disturbed clock pulse can cause setup-time violations in flip-flops forming the data register and can introduce multiple bit faults. Because the clock signal is distributed to many flip-flops, it is difficult to precisely control the fault location and number of corrupted bits.

If setup-time violations occurred in every flip-flop, each bit could exhibit one of four transitions: 0→0, 0→1, 1→0, or 1→1. Two of these four transitions invert the bit, suggesting a theoretical fault probability of 1/2. In practical hardware, however, signal propagation delays differ across internal paths. Setup-time violations therefore occur only in part of the register, and the actual fault probability is generally lower than 1/2.

Fault Model

Figure 1 shows the fault model. A clock glitch is injected during the 13th round. Multiple faults are introduced into the data register at the end of that round. The faults are then diffused by the 14th-round processing, producing a faulty ciphertext.

Proposed Key-Recovery Method

The proposed method prepares multiple pairs consisting of a correct ciphertext C and a faulty ciphertext C^*. For each ciphertext pair, the intermediate value at the end of Round 13 is calculated. The value derived from the correct ciphertext is denoted by x¹³, while the value derived from the faulty ciphertext is denoted by x^13*.

For each candidate round-key value pk, the method computes the Hamming distance between the two derived intermediate values. If the key candidate is correct, the Hamming distance reflects the actual number of injected faults. If the key candidate is incorrect, the Hamming distance is expected to approach 2, which is the expected value for a random 4-bit difference.

The average Hamming distance is calculated over N ciphertext pairs, and the candidate with the smallest average is selected as the estimated key.

Experimental Results

The analysis was evaluated with fault-injection probabilities of 10%, 20%, and 30%. As shown in Figure 3, all target keys were successfully recovered when at least 45 ciphertext pairs were used, regardless of the evaluated fault probability.

Power-Analysis-Resistant Implementation of Midori128

Background

This research develops a tamper-resistant implementation of the lightweight cipher Midori128. The proposed method is based on Rotating S-boxes Masking (RSM), originally proposed by M. Nassar and colleagues for AES.

RSM hides the correlation between cryptographic intermediate values and side-channel information by introducing randomized transformed S-boxes. Conventional masking often requires multiple transformed S-boxes corresponding to different random values. RSM reduces the circuit overhead by rotating and reusing transformed S-boxes.

Challenge in Applying RSM to Midori128

Directly applying the original AES-oriented RSM method to Midori128 is difficult because the S-box structures differ significantly. In AES, transformed S-boxes can be generated mainly by considering the mask value used in the data register.

In Midori128, the SubCell operation is formed by the 4-bit Sb1 structure together with surrounding permutations. Constructing transformed versions of the larger 8-bit structures SSb0, SSb1, SSb2, and SSb3 would require mask processing that also accounts for these permutations, leading to a complex circuit.

To solve this problem, the proposed method applies RSM to Sb1, the smallest 4-bit unit used to construct the Midori128 S-box.

Proposed Masking Architecture

Figure 4 shows the proposed architecture. Random masking is applied not only to the data-register values but also to all intermediate values during encryption. The mask hides the correlation between secret-dependent intermediate values and measured power consumption.

Because Sb1 processes 4-bit data, the proposed implementation uses 4-bit mask values. This design helps preserve the lightweight nature of Midori128 while improving resistance to power analysis.

Transformed Sb1 Structure

Figure 5 shows the detailed transformed Sb1 structure. It consists of two shifter circuits and 32 Sb1′ components. This structure enables masked processing and reuse while controlling hardware overhead.

Experimental Setup

Figure 6 shows the measurement environment. A total of 50,000 power traces were collected with an oscilloscope and used to evaluate the tamper resistance of the implemented Midori128 circuit.

Evaluation Results

Figure 7 compares the unprotected and protected implementations. All key bits of the unprotected circuit could be recovered using 10,000 traces. In contrast, the proposed protected implementation revealed zero correct key bits even when 50,000 traces were used.

Secure Smart-Factory Application Using Ascon

Background

Smart factories require real-time control because production speed and system responsiveness directly affect operational efficiency. Lightweight cryptography is therefore attractive as a means of providing security with low latency.

Ascon was selected as a standard lightweight cryptographic algorithm and is expected to be deployed widely in industrial systems. Evaluating Ascon in realistic IoT environments is therefore important for understanding both its security benefits and implementation overhead.

In this study, we constructed an IoT system using myCobot, which was described in 2023 as one of the world's smallest and lightest robot arms. We investigated its standard control and communication methods and implemented secure communication using Ascon.

System Configuration

Figure 8 shows the system overview. The robot arm is a myCobot 280-Pi containing a Raspberry Pi 4 Model B as its control computer. A server computer and the robot-arm client are connected to the same local-area network and communicate through Wi-Fi.

Packet-Level Security Evaluation

Figure 9 shows packets observed on the wireless network. In the left example, a server sends 47 bytes of robot-pose information to the client. The client then returns operation-completion information to the server.

Because these packets were transmitted without encryption, their payloads could be read by a third party. The right example shows a packet protected by Ascon. The payload is encrypted, preventing an observer from learning the robot's pose information.

The packet length increased from 47 bytes to 63 bytes. The additional 16 bytes correspond to the Ascon authentication tag. Verification of this tag also protects the system against message modification and impersonation.

Latency Evaluation

Figure 10 shows the measured communication latency. The middle result corresponds to communication with padding added so that the payload length is the same as that of the encrypted communication.

Secure communication introduced an implementation overhead of approximately 0.9 ms compared with unencrypted communication. Even so, the additional delay remained small compared with industrial demonstrations that target communication latencies below 4 ms using local 5G systems.

Protecting production know-how and preventing system stoppage caused by cyberattacks are essential in smart factories. The evaluation indicates that Ascon can provide confidentiality, integrity, and authenticity while preserving practical responsiveness.