Why you should care about don't cares: Exploiting internal don't care conditions for hardware Trojans

Hu, Wei; Zhang, Lu; Ardeshiricham, Armaiti; Blackstone, Jeremy; Hou, Bochuan; Tai, Yu-Wing; Kastner, Ryan

doi:10.1109/iccad.2017.8203846

Cited by 16 publications

(35 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This Trojan can survive from design verification since the design with the Trojan is equivalent to the specification before deployment on hardware. Hu et al used internal don't-care conditions for malicious design modifications [15]. Their idea was to use internal design states that will never be satisfied (e.g., two signals cannot be logical 1 at the same time) in normal operation as Trojan trigger.…”

Section: B Don't-care Hardware Trojansmentioning

confidence: 99%

“…Hu et al introduced the idea of using an SDC signal pair to create two discrete trigger signals [15]. In Fig.…”

Section: A Satisfiability Don't-care Hardware Trojanmentioning

confidence: 99%

“…This helps prevent the Trojan being optimized away while not changing design functionality. However, the attack model used by Hu et al [15] requires physical access to the Trojan implementation in order to overclock the design to trigger the Trojan (by inducing timing failures in the two DFFs and forcing them both to logical 1) and probe faulty outputs to recover the key. In this work, we consider a more practical attack scenario, which does not assume direct manipulation of signals (e.g., design clock) in an isolated private FPGA region.…”

Section: A Satisfiability Don't-care Hardware Trojanmentioning

confidence: 99%

See 2 more Smart Citations

X-Attack: Remote Activation of Satisfiability Don't-Care Hardware Trojans on Shared FPGAs

Mahmoud

Stojilović

2020

2020 30th International Conference on Field-Programmable Logic and Applications (FPL)

Self Cite

View full text Add to dashboard Cite

Albeit very appealing, FPGA multitenancy in the cloud computing environment is currently on hold due to a number of recently discovered vulnerabilities to side-channel attacks and covert communication. In this work, we successfully demonstrate a new attack scenario on shared FPGAs: we show that an FPGA tenant can activate a dormant hardware Trojan without any physical or logical connection to the private Trojan-infected FPGA circuit. Our victim contains a so-called satisfiability don't-care Trojan, activated by a pair of don't-care signals, which never reach the combined trigger condition under normal operation. However, once a malicious FPGA user starts to induce considerable fluctuations in the on-chip signal delaysand, consequently, the timing faults-these harmless don't-care signals take unexpected values which trigger the Trojan. Our attack model eliminates the assumption on physical access to or manipulation of the victim design. Contrary to existing fault and side-channel attacks that target unprotected cryptographic circuits, our new attack is shown effective even against provably well-protected cryptographic circuits. Besides demonstrating the attack by successfully leaking the entire cryptographic key from one unprotected and one masked AES S-box implementation, we present an efficient and lightweight countermeasure.

show abstract

Section: B Don't-care Hardware Trojansmentioning

confidence: 99%

“…Hu et al introduced the idea of using an SDC signal pair to create two discrete trigger signals [15]. In Fig.…”

Section: A Satisfiability Don't-care Hardware Trojanmentioning

confidence: 99%

Section: A Satisfiability Don't-care Hardware Trojanmentioning

confidence: 99%

See 1 more Smart Citation

X-Attack: Remote Activation of Satisfiability Don't-Care Hardware Trojans on Shared FPGAs

Mahmoud

Stojilović

2020

2020 30th International Conference on Field-Programmable Logic and Applications (FPL)

Self Cite

View full text Add to dashboard Cite

show abstract

“…For Trojan research, many Trojan benchmarks have been proposed [6,7,8,9,10,11,12,13,14,15,16]. To keep dormant in functional verification, hardware Trojan is usually triggered by some rare conditions, which is the so-called trigger condition.…”

Section: Introductionmentioning

confidence: 99%

“…In the existing Trojan benchmarks, the trigger part and payload part are designed separately and the rare-triggered condition is implemented by a combination of several low-activity or low testability signals, which may be detected by logic analysis techniques [17,18,19,20]. The traditional digital Trojan design methodology can be divided into two categories, the first exploits the rare transition signals in the original design [6,7,9,15], and the second attempts to partition the Trojan circuit into smaller parts and stages [12,14]. A uniform distribution of states is acquired by linear feedback shift register in [8], but low transition wire is still created when generating rare condition by combinational circuits.…”

Section: Introductionmentioning

confidence: 99%

Holistic hardware Trojan design of trigger and payload at gate level with rare switching signals eliminated

Huang

Jiang

2019

IEICE Electron. Express

View full text Add to dashboard Cite

A unified trigger and payload design scheme was proposed and re-convergent logic was introduced to eliminate rare transition signals which may be taken as suspicious signals in existing Trojan detections. Two Trojan structure templates were proposed and they could be applied to both privilege promotion and deny-of-service attacks. By combining these two structures in different proportion and position, a Trojan benchmark generation algorithm was proposed in which Trojan variations were resistant to feature analysis based detections. The proposed Trojans can obtain a very low activation probability using only primary inputs, which can reduce the restriction on primary trigger signals. So the Trojans will have better operability and adaptability in Trojan insertion. Then we discussed the method to keep concealed in fault diagnostic. At last, we made a comparison between the proposed Trojans and the state-of-the-art Trojan benchmarks on structural and logical features.

show abstract

Integrating Information Flow Tracking into High-Level Synthesis Design Flow

Ardeshiricham

et al. 2021

Behavioral Synthesis for Hardware Security

View full text Add to dashboard Cite

High-level synthesis (HLS) enables hardware designers to write an untimed circuit description allowing them to focus on architectural design optimizations like pipelining, task level parallelism, and array partitioning [1]. By removing the burden of describing cycle accurate behaviors, HLS designers can perform a more comprehensive design space exploration to better find an architecture that meets the desired power, performance, and area (PPA) constraints.While HLS tools are effective at exploring tradeoffs and optimizations related to PPA, security has largely been an after-thought. The emergence of hardware security flaws and threats [2-5] has brought a demand for hardware security verification tools. Due to the high cost (or even technical impossibility) to patch hardware security vulnerabilities after chip fabrication, identifying and eliminating security flaws in the early design phase is crucial.Information flow tracking (IFT) is a fundamental technique for hardware security verification [6][7][8]. IFT allows the designer to verify security properties related to confidentiality, integrity, and availability. An important first step is to create security enhanced circuit models for accurate description of security-related design behaviors and formal verification of security properties [9][10][11][12]. Some recent

show abstract

Why you should care about don't cares: Exploiting internal don't care conditions for hardware Trojans

Cited by 16 publications

References 23 publications

X-Attack: Remote Activation of Satisfiability Don't-Care Hardware Trojans on Shared FPGAs

X-Attack: Remote Activation of Satisfiability Don't-Care Hardware Trojans on Shared FPGAs

Holistic hardware Trojan design of trigger and payload at gate level with rare switching signals eliminated

Integrating Information Flow Tracking into High-Level Synthesis Design Flow

Contact Info

Product

Resources

About