Trust Is Not A Good Feeling

As a society, we trust in a lot of things in order for our daily lives to proceed. Trust is embedded in our lives. We trust in everything from the products we use to our relationships we have to our government. But when our trust is broken or shaken in something or someone, it is hard very hard for to for us to have confidence in that something or someone again.

If we apply the concept to of trust and trustworthiness to hardware design, we might discover that these terms  are not yet part of the daily vocabulary of hardware design engineers. However, they are on the rise, along with other security terms, and worthy of attention. We have included both words in our glossary of trust and security terms and acronyms for hardware engineers:

Trust: The belief that an IP or IC is free from malicious exploits.

Trustworthiness: Worthy of being trusted to be free from hardware Trojans. Worthy of being trusted to fulfil whatever critical requirements may be needed for a particular component, subsystem, or system.

In defense and mil/aero applications, trust and security assurance have been a top priority for many years. Most people have heard of counterfeit integrated circuits (ICs) and silicon manufacturing risks in overseas, untrusted foundries. However, all IC supply chain stages, including RTL design and integration of third-party intellectual properties (3PIPs) in systems-on-chips (SoCs), could be targeted by attackers. If you think that this type of supply chain attack, where malicious functions are inserted into a soft IP before production or delivery, are rare, refer to the recent SolarWinds scandal, the biggest hack of the US government in years, and consider how this same attack could be perpetrated in software or hardware. In a world full of autonomous vehicles and other AI-powered cyber-physical systems, IoT devices, smartphones, data centers processing and storing private information and IPs, it is hard to think of applications that have no appeal to potential attackers.

Trust assessment
In light of the recent attack, intentional insertions may be at the forefront of everyone’s mind, however both intentional and unintentional weaknesses may offer opportunity to an attacker for exploitation. Semiconductor IPs should go through a systematic, repeatable process to detect weaknesses and vulnerabilities before fabrication. Ideally, the process should require low engineering effort and deliver evidence or measure of trustworthiness. While the IP provider might support such a process, ultimately, it must be independent.

Automation in action
OneSpin’s Trust Assessment Platform (TAP) App detects and ensures the absence of entire classes of trust and security issues, and supports a growing range of hardware weaknesses listed in the MITRE CWE database. It identifies multiple classes of triggers (set of events and states activating potentially harmful functions), reliability issues, and deadlock conditions that could lead to denial-of-service (DoS) attacks. Users can configure and customize the set of checks that are executed.

As part of the Aerospace Corporation’s hardware assurance efforts, Aerospace performed an evaluation of OneSpin’s tool to determine its effectiveness in hardware Trojan detection. Three host designs, SpaceWire, RISC-V Taiga, and LEON3, were chosen to represent real-world MIL/Aero intellectual property (IP) of varying size and complexity. Six hardware Trojan triggers and four payloads were developed (coded) based on Aerospace’s hardware Trojan catalog and taxonomy, as well as academic literature, and then inserted into the host designs.

Nine Trojans were created from the combinations of triggers and payloads and inserted into the host designs. Three “golden” host designs (without Trojans) served as the baseline. Versions of the host designs with Trojans inserted were used to evaluate the tool against the baseline. OneSpin provided a TCL setup script template which required minimal modification to run the tool; it utilized OneSpin’s conventional flow, in which the user specifies the HDL design files and reset sequence, and then executes the elaborate and compile command. From this point, the flow allows the user to run either the OneSpin TAP App or OneSpin DV-Inspect formal “apps”. The tool was executed on each of the designs and reported back the total number of issues (potential Trojans). For each issue, the tool also reported the location in the design and a short description, used for further investigation to determine if the issue is a legitimate hardware Trojan.

Results demonstrate that the design analysis step requires a one-time process of minutes to hours of computational runtime for industrial-scale IP designs. The process efficiently identifies different classes of trigger, reliability, and in the future, other issues (or vulnerabilities/weaknesses), which could be leveraged to introduce Trojans in subsequent design implementation steps. The reported issues will focus on those functions in the RTL source code that require attention, while minimizing excess noise.

Aerospace’s use of the OneSpin TAP App was documented in a presentation delivered at last year’s Design Automation Conference titled “Automated Trustworthiness Assessment of Third-party Semiconductor IPs.” You can download the complete paper at https://onespin.com/resources/conference-materials.

Learn more
I invite you to take a look at the trust and security glossary, download the white paper Trust Assurance and Security Verification of Semiconductor IPs and ICs, and join the LinkedIn group ISO/SAE 21434 Automotive Cybersecurity. And of course, don’t miss the next 6 Minutes of Security blog post!