Make Hardware Strong With CWE

What is a weakness? And why should we care? These questions are relevant in probably any field or context you may think of, well beyond engineering or electronics. While in some cases the first-level answers might be obvious, in many others they are not. Generally, weaknesses are considered bad things that can lead to malfunctions, injuries, and other undesirable situations. In many cases, they can be mitigated or eliminated. As usual, there are challenges. Firstly, we need to identify the weaknesses. Thankfully, many weaknesses are often known and well documented. Most people regularly practicing sports know that weak core muscles increase the probability of injury, for example. Secondly, we need to decide whether it is worth dealing with them. Nobody likes injuries, no doubt. However, if you are an amateur like me, who likes randomly kicking the ball more than doing plank exercises, you may decide to take your chances. On the other hand, if you are a professional, I am sure your training and support team would not let you get away with that.

In the context of hardware security, a weakness is a type of mistake that, in proper conditions, could contribute to creating vulnerabilities. Weaknesses could be introduced during any stage of the ASIC and FPGA hardware development process, including pre-silicon phases such as RTL coding, integrations of third-party intellectual properties (3PIPs), synthesis, place-and-route, and bitstream generation. Akin to a functional bug, a weakness may remain latent. Typically, a hardware bug causes malfunctions only under specific workloads. Despite bugs, the system may always work as expected, with a bit of luck. If you are developing a demonstrator or a final year college project, it is probably OK to rely on luck. The key objective is to eliminate all showstopper bugs. If the hardware component goes into a car, smartphone, cloud storage or computing infrastructure, or smart fridge, things are very different. Car drivers or phone owners do not spend months of hard work or buy expensive equipment trying to find use cases where the expensive product they bought malfunctions. Nevertheless, bad luck is a more realistic assumption. Hardware developers know it and use advanced verification processes to detect and eliminate issues as soon as possible. Unfortunately, when it comes to security weaknesses, the issues and consequences get even worse. Professional hackers, security researchers, and other very smart and creative people continuously try to find ways to breach security protections. In some cases, they may even use expensive equipment to achieve their goals. They love weaknesses and are experts in leveraging them. Ultimately, one or more weaknesses may cause a vulnerability that is exploited by attackers to violate system security policies.

CWE

MITRE launched the Common Vulnerabilities and Exposures (CVE) list in 1999 to catalog publicly known cybersecurity vulnerabilities using a standardized description. Nowadays, CVE is the de-facto industry standard for vulnerabilities identifiers. To better support early detection of frequent root causes of known vulnerabilities, MITRE established Common Weakness Enumeration (CWE), a community-developed list of software and hardware weakness types. Unlike vulnerabilities, weaknesses are not associated with a specific system or product. Software weaknesses have been covered since the first release of the list in 2006. Due to the increasing role of hardware security issues in high-severity attacks, support for hardware weaknesses was added in 2020. At the time of writing, the list contains 87 hardware entries out of a total of 1248.

CWE entries are organized in a tree-like structure, and not all entries are actual weaknesses. Weaknesses that share common characteristics are grouped into category-type entries, for example. It is worth noting that a weakness may belong to multiple categories. Moreover, weaknesses may be described at different levels of abstractions. Class-type weaknesses are very abstract and typically independent of a specific coding language, whereas base-type weaknesses are more specific. CWE entries start with an icon. Put your mouse over it to show the associated tooltip, which explains the entry type. All hardware-related entries can be selected using the view-type entry 1194.

Solutions

Consumer electronics connects us to financial institutions and payment systems. Mil/Aero and automotive electronics control safety-critical functions like braking and steering. Communication, data center, and even cheap IoT devices may process highly-sensitive, private data. Security requirements and assurance processes must be an integral part of all these applications’ hardware development life cycle.

CWE provides a common language and list of targets for IP and integrated circuit (IC) developers, and electronic design automation (EDA) tool vendors. OneSpin provides certified IC integrity assurance solutions covering functional correctness, safety, and trust and security. Within this holistic view, OneSpin aligns security assurance objectives derived from CWE with powerful technology and verification methods. Many weaknesses can be detected with low effort through the automated analysis of RTL models. Leveraging high-capacity formal engines and other technology, OneSpin can also exhaustively prove the absence of certain weaknesses, which simulation- and emulation-based technology cannot achieve. Automated checks analyze finite state machines (FSMs) to detect issues that could enable a denial of service (DoS) attack through deadlock (CWE-1254). Many security flow issues (CWE-1196), including modification or leakage of security assets by unauthorized agents (data confidentiality and integrity violations), are also detected through the automated, exhaustive analysis of information flow paths. The absence of undocumented features (CWE-1242), including hidden processor instructions and leftover debug backdoors, can be proven using OneSpin’s GapFreeVerification solution. For a complete list, please contact OneSpin’s Product Manager Trust and Security John Hallman.

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!