Transient Key-based Obfuscation for HLS in an Untrusted Cloud Environment

Globalization of the integrated circuit (IC) supply chain exposes designs to security threats such as reverse engineering and intellectual property (IP) theft. Designers may want to protect specific high-level synthesis (HLS) optimizations or microarchitectural solutions of their designs. Hence, protecting the IP of ICs is essential. Behavioral locking is an approach to thwart these threats by operating at high levels of abstraction instead of reasoning on the circuit structure. Like any security protection, behavioral locking requires additional area. Existing locking techniques have a different impact on security and overhead, but they do not explore the effects of alternatives when making locking decisions. We develop a design-space exploration (DSE) framework to optimize behavioral locking for a given security metric. For instance, we optimize differential entropy under area or key-bit constraints. We define a set of heuristics to score each locking point by analyzing the system dependence graph of the design. The solution yields better results for 92% of the cases when compared to baseline, state-of-the-art (SOTA) techniques. The approach has results comparable to evolutionary DSE while requiring 100× to 400× less computational time.

show abstract

“…Behavioral locking locks a function with a locking key K. We consider three SOTA locking techniques [3,18,20]:…”

Section: B Behavioral Lockingmentioning

confidence: 99%

“…Since over 80% of counterfeited parts reported in 2019 by ERAI were not reported before [7], the real numbers are likely higher. Security protections must be introduced since the early stages of the design (e.g., during high-level synthesis -HLS) for IP protection [3,17,20].…”

Section: Introductionmentioning

confidence: 99%

A Composable Design Space Exploration Framework to Optimize Behavioral Locking

Collini

Karri

Pilato

2022

2022 Design, Automation &Amp; Test in Europe Conference &Amp; Exhibition (DATE)

View full text Add to dashboard Cite

show abstract

“…Let C be the input C code to synthesize. To create unique features unknown to the attacker, we borrow the idea of C-based obfuscation [9], [16]. We identify a set T of C-level transformations with parameters known only to the design house.…”

Section: Proposed Approachmentioning

confidence: 99%

“…For example, the other input of the multiplexer previously removed becomes unconnected and we can remove the logic generating this value if it is unused in other parts of the circuit. Differently from [9], we apply RTL simplifications instead of leveraging logic synthesis to remove the extra logic. So, we can analyze the birthmark directly on the RTL design (RT L T −1 ).…”

Section: Ip Birthmarking Creationmentioning

confidence: 99%

“…We propose to integrate IP birthmarking during HLS. After analyzing the effects of compiler and HLS transformations [8], we observe that reverting transient HLS transformations is never perfect in practice [9]. A transient transformation is a modification of the C code (i.e., before HLS) that is reverted on the resulting RTL design (i.e., after HLS).…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Opportunistic IP Birthmarking using Side Effects of Code Transformations on High-Level Synthesis

Badier

Pilato

Lann

et al. 2021

2021 Design, Automation &Amp; Test in Europe Conference &Amp; Exhibition (DATE)

Self Cite

View full text Add to dashboard Cite

The increasing design and manufacturing costs are leading to globalize the semiconductor supply chain. However, a malicious attacker can resell a stolen Intellectual Property (IP) core, demanding methods to identify a relationship between a given IP and a potentially fraudulent copy.We propose a method to protect IP cores created with highlevel synthesis (HLS): our method inserts a discrete birthmark in the HLS-generated designs that uses only intrinsic characteristics of the final RTL. The core of our process leverages the side effects of HLS due to specific source-code manipulations, although the method is HLS-tool agnostic. We propose two independent validation metrics, showing that our solution introduces minimal resource and delay overheads (< 6% and < 2%, respectively) and the accuracy in detecting illegal copies is above 96%.

show abstract