REPQC: Reverse Engineering and Backdooring Hardware Accelerators for Post-quantum Cryptography

TL;DR

The paper addresses the risk of automated backdooring of PQC hardware accelerators via supply-chain compromise. It introduces REPQC, an automated reverse-engineering tool that locates the Keccak hashing block to anchor a backdoor, enabling an HTH via a ring-oscillator payload. Using Dilithium on 28nm ASICs, it demonstrates automated node localization and HTH insertion with minimal performance impact and modest power penalties, under both A-IP and A-FO threat models. The work highlights defense strategies and releases an open-source REPQC, underscoring the urgency of protecting PQC hardware from automated RE-driven backdoors.

Abstract

Significant research efforts have been dedicated to designing cryptographic algorithms that are quantum-resistant. The motivation is clear: robust quantum computers, once available, will render current cryptographic standards vulnerable. Thus, we need new Post-Quantum Cryptography (PQC) algorithms, and, due to the inherent complexity of such algorithms, there is also a demand to accelerate them in hardware. In this paper, we show that PQC hardware accelerators can be backdoored by two different adversaries located in the chip supply chain. We propose REPQC, a sophisticated reverse engineering algorithm that can be employed to confidently identify hashing operations (i.e., Keccak) within the PQC accelerator - the location of which serves as an anchor for finding secret information to be leaked. Armed with REPQC, an adversary proceeds to insert malicious logic in the form of a stealthy Hardware Trojan Horse (HTH). Using Dilithium as a study case, our results demonstrate that HTHs that increase the accelerator's layout density by as little as 0.1\% can be inserted without any impact on the performance of the circuit and with a marginal increase in power consumption. An essential aspect is that the entire reverse engineering in REPQC is automated, and so is the HTH insertion that follows it, empowering adversaries to explore multiple HTH designs and identify the most suitable one.

Figures (15)

• Figure 1: Keccak state as a $5\times5\times64$ 3D matrix, for keccak-f[1600]. Each box in the Keccak state represents one bit.
• Figure 2: Locations of the adversaries A-IP and A-FO in the supply chain and design flow.
• Figure 3: Flowchart of the entire attack.
• Figure 4: The element $a[0][0][0]$ is being updated and every other element for which there is a dependency is marked with the permutation function that creates the dependency. There are 33 dependencies in total.
• Figure 5: The Keccak state is composed of 1600 flip-flops that have predictable fanin/fanout properties. The goal is to find a register with 64 flip-flops that is the input to Keccak and therefore holds the message $M$ and the component $K$.