Hardware Honeypot: Setting Sequential Reverse Engineering on a Wrong Track

TL;DR

The paper tackles FSM reverse engineering threats by proposing a two-part obfuscation: hardware FSM honeypots (FSM-HP) that appear more attractive to RE tools than the real FSM, and unattractive FSM design that degrades correct SFF identification. The approach is implemented at RTL or gate level and evaluated on nine open-source designs against RELIC-Tarjan and topological-analysis techniques, showing that RE tools favor the FSM-HP or fail to recover the original FSM. Key contributions include a concrete methodology for constructing FSM-HP and unattractive FSM, strategies for increasing or masking SFF features (e.g., high FP and dissimilarity), and empirical evidence of robust obfuscation with manageable overhead. The work demonstrates a practical, keyless, camouflaging-free route to protect FSM functionality from sequential RE and offers avenues for extending the technique to new RE tools and multiple honeypots.

Abstract

Reverse engineering (RE) of finite state machines (FSMs) is a serious threat when protecting designs against RE attacks. While most recent protection techniques rely on the security of a secret key, this work presents a new approach: hardware FSM honeypots. These honeypots lead the RE tools to a wrong but, for the tools, very attractive FSM, while making the original FSM less attractive. The results show that state-of-the-art RE methods favor the highly attractive honeypot as FSM candidate or do no longer detect the correct, original FSM.

Figures (3)

• Figure 1: Novel two-part FSM obfuscation: hiding the original FSM by making it less attractive (unattractive FSM) and providing an attractive alternative (hardware FSM honeypot)
• Figure 2: State bit replication of the design fpSqrt opencoresGeneral
• Figure 3: Maximum Z-Score value of the FF in any data SCC and of the FF in the FSM SCC before ($\mathcal{A}$) and after ($\mathcal{Z}$) obfuscation, and maximum Z-Score value of the FF in the FSM-HP SCC