The Hack@DAC Story: Learnings from Organizing the World's Largest Hardware Hacking Competition

The Hack@DAC Story: Learnings from Organizing the World's Largest Hardware Hacking Competition

Speakers: Arun, Harish, Jason (Intel, Offensive Security Research Experts); Professor JV Rajendran (Texas A&M University); Professor Ahmed Sadegi (TU Darmstadt)

Conference: Black Hat USA

YouTube: https://www.youtube.com/watch?v=IC-BB7HEor8

Overview

This talk, "The Hack@DAC Story," delves into the genesis, evolution, and impact of Hack@DAC, the world's largest hardware hacking competition. Presented by Arun from Intel, representing a diverse team of offensive security research experts from Intel and academic partners from Texas A&M University and TU Darmstadt, the presentation illuminates critical challenges in hardware security and how Hack@DAC addresses them. The core objective of the competition is to elevate awareness of hardware security vulnerabilities, foster the development of specialized security tooling, and promote a "shift-left" mindset within the hardware design community.

The speakers highlight a significant gap in the industry: a limited understanding of the anatomy of hardware security weaknesses and a severe dearth of dedicated security tools for hardware, especially when compared to the mature ecosystem available for software and firmware. Hack@DAC distinguishes itself by adopting an open-box approach, providing participants with the actual source code of buggy chip designs at the Register Transfer Level (RTL). This unique methodology aims to empower designers to think like attackers, identifying and mitigating vulnerabilities much earlier in the design cycle, thereby influencing industry best practices and academic research.

The talk underscores the competition's role in driving significant contributions to the hardware security landscape, including substantial input to MITRE's Common Weakness Enumeration (CWE) Hardware Design View and NIST's Hardware Security Failure Scenarios. By creating a realistic, buggy System on Chip (SoC) framework, Hack@DAC provides an invaluable benchmark for developing and testing hardware security tools, a resource previously unavailable to the industry and academia. This initiative is crucial for bridging the knowledge gap and enhancing the overall security posture of modern hardware.

Background

▶ Watch: Introduction to talk and speaker team (0:00)

The increasing complexity of modern computing systems has led to a "race to the bottom of the stack" in security research. While application-level and firmware vulnerabilities have long been a focus, attention has progressively shifted towards lower layers, with microarchitectural attacks and vulnerabilities becoming more prevalent. This trend highlights a critical need to secure the foundational hardware components that underpin all software execution.

In 2019, the speakers' team published a seminal paper titled "Hard fails" at Usenix Security, which aimed to elucidate how hardware security bugs could be exploited by software. A key learning from this publication was the widespread lack of understanding regarding the precise nature and anatomy of hardware weaknesses. Unlike software vulnerabilities, which are often well-documented and understood, the specifics of hardware security flaws, particularly at the RTL or hardware source code level, remained largely opaque to many in the security community. This limited awareness constituted the first major challenge identified by the team.

The second significant challenge revolved around the scarcity of dedicated security tooling for hardware. While an abundance of tools—such as code scanners, protocol checkers, configuration checkers, and reverse engineering tools—exists for software and firmware, the landscape for hardware security tools is strikingly sparse. The speakers lament that one can "count on your fingers" the number of effective hardware security tools available today. This deficit is directly linked to the limited awareness of hardware weakness types; without a clear understanding of what constitutes a hardware vulnerability, developing effective detection and mitigation tools becomes exceedingly difficult.

The third challenge, and a core driver for Hack@DAC, is the imperative to cultivate a "shift-left" mindset in hardware development. This concept, borrowed from software development, advocates for detecting and fixing bugs as early as possible in the design lifecycle. For hardware, this means identifying and addressing vulnerabilities at the RTL phase itself, rather than later stages when remediation becomes significantly more costly and complex. The Hack@DAC competition was conceived as a direct response to these three interconnected challenges, aiming to educate, equip, and inspire the next generation of hardware security practitioners and designers.

Key Findings

▶ Watch: Identifying three main challenges in hardware security (2:20)

The Hack@DAC competition has yielded several significant contributions and findings over its seven-year history, directly addressing the identified challenges in hardware security. Foremost among these is its profound impact on raising awareness about hardware security weakness types. The organizing team's collaboration with MITRE led to the development of the CWE Hardware Design View, first released in version 4 of the Common Weakness Enumeration. This crucial initiative documented approximately 110 distinct ways in which hardware security can be compromised, with the Hack@DAC organizing team, primarily from Intel, contributing about 75 of these entries. This comprehensive resource provides detailed vulnerability and mitigation examples, serving as a foundational text for understanding hardware security flaws.

Further extending its influence, the work driven by Hack@DAC and its contributors has significantly informed the NIST Hardware Security Failure Scenarios document. This reinforces the competition's role in shaping industry standards and government guidelines for hardware security, providing a common language and framework for identifying and addressing vulnerabilities.

Another critical finding is the creation of a much-needed "buggy System on Chip (SoC) framework" for fostering innovation. Prior to Hack@DAC, existing benchmarks like Trust Hub, while valuable, were often small-scale, lacked realistic security features or threat models, and did not support commercial Electronic Design Automation (EDA) tools. The Hack@DAC framework fills this void by offering a robust, realistic benchmark for evaluating the efficacy of new hardware security tools. This enables tool developers to rigorously test their solutions against a diverse set of real-world-inspired vulnerabilities, a crucial step towards developing more effective security design automation tools.

Finally, the competition has demonstrated its effectiveness in facilitating a "shift-left" mindset. Feedback from participants indicates that teams involved in traditional functional verification found it significantly easier to transition into security verification after participating in Hack@DAC. By immersing designers in an open-box approach where they actively seek to exploit vulnerabilities in their own designs, the competition instills a proactive security mindset, empowering them to detect and fix bugs much earlier in the RTL phase. This direct experience helps bridge the gap between design and security, fostering a more secure hardware development lifecycle.

Technical Deep Dive

▶ Watch: Understanding the computing stack and hardware vulnerabilities (2:50)

The technical foundation of Hack@DAC rests on understanding the intricate layers of the computing stack and focusing on the Register Transfer Level (RTL), which is essentially the "source code" of hardware. The computing stack is broadly categorized into software (applications, operating systems), firmware (interfacing software and hardware), and hardware. Hardware itself is further decomposed into microarchitecture, RTL, gates (interconnected logic), and transistors. The competition's emphasis on RTL allows participants to interact with hardware at a high level of abstraction, akin to software developers working with programming languages, making it accessible for security analysis without requiring deep physical hardware expertise.

To illustrate a typical hardware vulnerability and the competition's focus, the speakers provided an example concerning key clearing in an Advanced Encryption Standard (AES) block within a hypothetical System on Chip (SoC).

• Asset: The secret key stored within the AES block.
• Security Objective: Confidentiality of the secret key.
• Threat: A hardware debug adversary gaining access to the chip and extracting the secret key.
• Intended Mitigation: Implement a mechanism where all reads to the key return zero when the chip is in debug mode, preventing unauthorized key exposure.

The vulnerability was demonstrated through a snippet of Verilog code, a widely used Hardware Description Language (HDL) for RTL design. The correct implementation would check for a debug_mode signal for all key segments. However, in the provided example, the check was incompletely implemented:

In this scenario, key_big_zero and key_big_one are correctly zeroed out when debug_mode is active. However, key_big_two lacks this conditional check, making it readable by an attacker operating in debug mode. This seemingly "painfully obvious" omission highlights a common class of hardware vulnerabilities: incomplete or incorrect implementation of security features at the RTL level. Such bugs can arise from complex design flows, human error, or inadequate security verification.

Hack@DAC's methodology is distinct from traditional hacker-centric (closed-box scenario) CTFs, which often involve physical probing, desoldering, reverse engineering, or side-channel attacks on compiled hardware. While these physical attacks are crucial, they do not address the "shift-left" imperative. Instead, Hack@DAC employs a designer-centric (open-box approach). Participants are given the complete RTL source code of a buggy chip design. Their task is to identify and exploit these vulnerabilities using standard chip verification techniques commonly employed by hardware designers:

• Simulation: Executing the RTL code in a software environment to observe its behavior and identify discrepancies.
• Emulation: Running the RTL on an FPGA or specialized hardware platform to achieve higher speeds and closer-to-real-world behavior than simulation.
• Formal Verification: Using mathematical proofs to verify that the design adheres to its specified security properties, ensuring exhaustive coverage for certain types of bugs.
• Static Analysis: Analyzing the RTL code without executing it, using tools to identify patterns indicative of vulnerabilities or design flaws.
• Manual Reviews: Expert inspection of the RTL code for logical errors, security policy violations, or implementation bugs.

This open-box approach allows participants to gain a finer-grained understanding of how security features are implemented, how vulnerabilities manifest in the hardware source code, and how they can be programmatically exploited, often leading to software-exploitable hardware bugs. It effectively transforms designers into security auditors of their own work, fostering a deeper integration of security into the design process.

Demo / Proof of Concept

▶ Watch: Challenge 2: Lack of hardware security tooling (4:40)

The talk itself did not feature a live demonstration of the Hack@DAC competition in action or a real-time exploit of a hardware vulnerability. Instead, the speakers presented a conceptual Proof of Concept through the detailed Verilog code example of an AES key clearing vulnerability. This example served to illustrate the nature of hardware vulnerabilities at the Register Transfer Level (RTL) and how a seemingly minor oversight in design can lead to a significant security bypass.

The Verilog snippet, demonstrating the incomplete debug mode check for key_big_two in an AES block, effectively acted as a static proof of concept. It visually conveyed how a hardware debug adversary could exploit this flaw to extract a secret key, despite the presence of intended mitigations for other key segments. While not a dynamic demo, this conceptual example was crucial for articulating the technical depth and specificity of the vulnerabilities that Hack@DAC participants are challenged to find and exploit within the competition's open-box environment. The competition itself, by providing participants with buggy System on Chip (SoC) designs and a suite of verification tools, effectively serves as a continuous, hands-on demonstration platform for hardware security research and education.

Defensive Implications

▶ Watch: Detailed example: Anatomy of a hardware key-clearing vulnerability (6:40)

The insights gleaned from organizing Hack@DAC and the broader discussion on hardware security weaknesses carry significant defensive implications for the semiconductor industry, hardware designers, and security practitioners. The overarching message is a call to action for a fundamental shift in how hardware security is approached, moving from reactive patching to proactive, "shift-left" integration.

Firstly, defenders must embrace the shift-left mindset for hardware security. This means integrating security considerations and verification techniques from the earliest stages of the design process, specifically at the Register Transfer Level (RTL). Detecting and fixing bugs during RTL design is orders of magnitude more cost-effective and less disruptive than discovering them in post-silicon validation or, worse, after products have shipped. This proactive approach necessitates a cultural change within design teams, empowering them to think like attackers and scrutinize their own designs for vulnerabilities.

Secondly, the creation and adoption of the CWE Hardware Design View (version 4) and the NIST Hardware Security Failure Scenarios provide invaluable resources for defenders. These documents offer a standardized taxonomy of hardware weakness types, enabling designers and security analysts to better understand, categorize, and communicate about vulnerabilities. Defenders should leverage these resources to train design teams, develop comprehensive threat models, and create security checklists tailored to the unique challenges of hardware. By understanding the specific ways hardware can go wrong, organizations can develop more targeted and effective mitigation strategies.

Thirdly, the development of specialized hardware security tools is paramount. The current paucity of such tools leaves a significant gap in the defensive arsenal. The Hack@DAC framework, with its "buggy System on Chip (SoC)" benchmarks, offers a crucial platform for researchers and commercial vendors to develop, test, and validate new security design automation tools. Defenders should advocate for and invest in the creation of tools that can perform static analysis, formal verification, simulation, and emulation specifically tailored for hardware security properties. These tools are essential for automating the detection of vulnerabilities that are difficult or impossible to find through manual review alone.

Finally, the designer-centric, open-box approach championed by Hack@DAC should be integrated into internal security verification processes. By encouraging designers to "put on a hacker hat" and actively attempt to break their own designs using existing chip verification techniques, organizations can foster a deeper understanding of security vulnerabilities. This internal "red teaming" at the design stage can uncover flaws before they become exploitable in real-world products. Furthermore, adopting frameworks similar to Hack@DAC for internal training and continuous education can help bridge the gap between functional verification and security verification, ensuring that all aspects of chip design are robustly secured.

Key Takeaways

• Elevate Hardware Security Awareness: There is a critical and widespread lack of understanding regarding the specific types and anatomy of hardware security weaknesses, necessitating concerted efforts to educate designers and security professionals.
• Invest in Hardware Security Tooling: The current ecosystem of security tools for hardware is severely underdeveloped compared to software, highlighting an urgent need for research, development, and adoption of specialized security design automation tools.
• Embrace the "Shift-Left" Mindset: Hardware vulnerabilities must be identified and fixed as early as possible in the design cycle, ideally at the Register Transfer Level (RTL), to minimize cost and risk, promoting a proactive security posture.
• Leverage Standardized Weakness Enumerations: Resources like the MITRE CWE Hardware Design View (version 4, with 75 entries contributed by the Hack@DAC team) and NIST Hardware Security Failure Scenarios are vital for categorizing, understanding, and addressing hardware vulnerabilities effectively.
• Utilize Open-Box Benchmarks for Tool Development: Platforms like the Hack@DAC framework provide essential "buggy System on Chip (SoC)" benchmarks, enabling rigorous testing and validation of new hardware security tools, which is crucial for advancing the field.
• Foster Designer-Centric Security Verification: Encouraging hardware designers to adopt an open-box approach and use traditional chip verification techniques (simulation, formal verification, static analysis) to actively seek flaws in their own designs is key to building a robust security culture.

About the Speaker(s)

The talk was primarily presented by Arun from Intel, who represented the broader organizing team behind Hack@DAC. Arun, along with his Intel colleagues Harish and Jason, are described as offensive security research experts with extensive experience in vulnerability root-causing and categorization across various Intel products, including CPUs, clients, servers, and Intel security technologies. All three are active members of MITRE's hardware CWE special interest group (SIG), significantly contributing to the Hardware Design View.

The Hack@DAC competition is a collaborative effort, also involving eminent academic partners: Professor JV Rajendran from Texas A&M University and Professor Ahmed Sadegi from TU Darmstadt in Germany. Both professors are highly respected in their fields, boasting over 44,000 citations for their impressive body of work in areas such as circuit research and network security. The team also acknowledges the crucial contributions of PhD students from both Texas A&M University and TU Darmstadt, who help organize the competition, and collaborators from Synopsis, a major Electronic Design Automation (EDA) tool vendor.