Analyzing Security Vulnerabilities Induced by High-level Synthesis

Abstract

High-level synthesis (HLS) is essential to map the high-level language (HLL) description (e.g., in C/C++) of hardware design to the corresponding Register Transfer Level (RTL) to produce hardware-independent design specifications with reduced design complexity for ASICs and FPGAs. Adopting HLS is crucial for industrial and government applications to lower development costs, verification efforts, and time-to-market. Current research practices focus on optimizing HLS for performance, power, and area constraints. However, the literature does not include an analysis of the security implications carried through HLS-generated RTL translations (e.g., from an untimed high-level sequential specification to a fully scheduled implementation). This article demonstrates the evidence of security vulnerabilities that emerge during the HLS translation of a high-level description of system-on-chip (SoC) intellectual properties to their corresponding RTL. The evidence provided in this manuscript highlights the need for (a) guidelines for high-level programmers to prevent these security issues at the design time and (b) automated HLS verification solutions that cover security in their optimization flow.

Using Static Analysis for Enhancing HLS Security

“…Another concern is the unintentional introduction of security weaknesses in HLS-generated designs [5]. Design weaknesses are flaws in a design that, if exploited, can lead to vulnerabilities.…”

“…MITRE maintains a list of known weaknesses called the Common Weakness Enumeration (CWE) [11]. Some vulnerabilities identified by Pundir et al [5] map to the following CWEs: CWE 1245 (insecure finite state machine); CWE 1300 (improper protection of side channel); CWE 1271 (uninitialized value on reset for registers holding security settings); CWE 1189 (improper isolation of shared resources on system-on-a-chip); CWE 203 (Observable discrepancy). Of these weaknesses, we focus on CWE 203, as it may enable other weaknesses, like uninitialized values on reset or unbalanced pipelines, to leak sensitive data during operation.…”

“…The cipher implementations came with HLS directives for each design as they were HLS-ready. We derived 5 sets of directives: (1) All directives (ALL) from the original set; (2) Register I/O (REG): directives in original set plus the config_interface -register_io scalar_out directive; (3) Only pipelining (PIPE): Original set of directives removing all unrolling directives; (4) Only unrolling (UNROLL): Original set of directives removing pipeline directives; (5) No directives (EMPTY): no directives specified; tool's defaults as in [5]. This allows us to study choices that a designer could make.…”

“…Starting from an algorithm and using different HLS directives, one can obtain different results in terms of latency, resources, and weaknesses. Designers focusing only on traditional metrics can introduce unintentional security weaknesses [5].…”