Tapeout of a RISC-V crypto chip with hardware trojans

Hepp, Alexander; Sigl, Georg

doi:10.1145/3457388.3458869

Cited by 14 publications

(12 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Functional HTs aim to include circuitry into the layout with minimal power overhead and a low area footprint compared to the original device. Examples have been demonstrated in [1], [11], [9], or [7]. These flows typically rely on an engineering change order (ECO) flow.…”

Section: A Related Workmentioning

confidence: 99%

“…The uniqueness and reliability of silicon measurements in [20] have been assessed. The schematic and the layout implementation of an SRAM cell via the Skywater130 HD 1,2 open-source process design kit (PDK) is shown in Fig. 3.…”

Section: B Modified Sram Power-up Simulationmentioning

confidence: 99%

“…An HT can be implemented in any stage of the design flow, ranging from register transfer level (RTL) [1], to the transistor level. For the detection of HTs implemented in the design process before the layout level, testing procedures in the form of delay and timing characteristics [2], power dissipation Pre-print of paper #59338 for International Symposium for Testing and Failure Analysis (ISTFA) 2023, AMS International [3], electro-magnetic emission profiles [4], examination of the logic outputs [5], or verification through reverse engineering (RE) [6] are available.…”

Section: Introductionmentioning

confidence: 99%

“…HTs designed after layouting are beginning to receive more attention (e.g. [7], [1], [8], [9]). In these works, the rely on an untrusted foundry as attacker, which can be viewed as likely scenario [10], [9].…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Layout-Only Hardware Trojans: Attack Vectors and a Non-Golden Model Reverse Engineering-Based Counterstrategy

Ludwig,

Bette,

Lippmann

2023

International Symposium for Testing and Failure Analysis

View full text Add to dashboard Cite

Globally distributed microelectronic supply chains have disrupted trust in silicon hardware and have drawn academia’s attention toward different scenarios of malicious circuit modifications, i.e., hardware Trojans. This dynamic hardware environment, including open-source approaches and evermore outsourcing, requires constant reassessment of offensive and defensive aspects. Based on an untrusted foundry model, this work assesses the concrete technical realizations of layout-only modifications via design file editing, mask editing, or in-line alterations. Furthermore, the attack possibility on different modules within a system on a chip is qualitatively evaluated. Consequently, a modification is demonstrated on an SRAM- ’PUF’ module. To link the attack point-of-view with a defensive measure, we propose a hardware reverse engineering-based countermeasure, which is non-reliant on a golden layout. Through a novel approach relying on inherent polygon properties, potentially occurring modifications are detected via clustering and a statistical evaluation of the intra-cluster distributions. Finally, the approach is demonstrated on samples from 7 nm to 150 nm, for which a modification detection rate between 95% and 100% is reached for all evaluated samples.

show abstract

Section: A Related Workmentioning

confidence: 99%

Section: B Modified Sram Power-up Simulationmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Layout-Only Hardware Trojans: Attack Vectors and a Non-Golden Model Reverse Engineering-Based Counterstrategy

Ludwig,

Bette,

Lippmann

2023

International Symposium for Testing and Failure Analysis

View full text Add to dashboard Cite

show abstract

“…The fact that it could only be triggered under specific trigger conditions makes these modifications hard to detect. These modifications can be inserted into the SoC by changing the source code during the design phase [1], by using CAD tools during the silicon-synthesis phase [2], or by changing the masks during the tape-out process [3].…”

Section: Introductionmentioning

confidence: 99%

DEV-PIM: Dynamic Execution Validation with Processing-in-Memory

Bolat

Can

Hikmet

et al. 2023

2023 IEEE European Test Symposium (ETS)

View full text Add to dashboard Cite

Instruction injections or soft errors during execution on the CPU can cause serious system vulnerabilities. During the standard program flow of the processor, the injection of unauthorized instruction or the occurrence of an error in the expected instruction are the main conditions for potentially serious such vulnerabilities. With the execution of these unauthorized instructions, adversaries could exploit SoC and execute their own malicious program or get higher-level privileges on the system. On the other hand, non-intentional errors can potentially corrupt programs causing unintended executions or the cause of program crashes. Modern trusted architectures propose solutions for unauthorized execution on SoC with additional software mechanisms or extra hardware logic on the same untrusted SoC. Nevertheless, these SoCs can still be vulnerable, as long as deployed security detection mechanisms are embedded within the same SoC's fabric. Furthermore, validation mechanisms on the SoC increase the complexity and power consumption of the SoC. This paper presents DEV-PIM, a new, high-performance, and low-cost execution validation mechanism in SoCs with external DRAM memory. The proposed approach uses processingin-memory (PIM) method to detect instruction injections or corrupted instructions by utilising basic computing resources on a standard DRAM device. DEV-PIM transfers instructions scheduled for execution on the CPU to the DRAM and validates them by comparing content with the trusted program record on the DRAM using PIM operations. By optimising the DRAM scheduling process validation tasks are only executed when memory access is idle. The CPU retains uninterrupted memory access and can continue its normal program flow without penalty. We evaluate DEV-PIM in an end-to-end DRAM-compatible environment and run a set of software benchmarks. On average, the proposed architecture is able to detect 98.46% of instruction injections for different validation. We also measured on average only 0.346% CPU execution overhead with DEV-PIM enabled.

show abstract