A Glossary For Chip And Semiconductor IP Security And Trust

A significant portion of electronic system vulnerabilities involves hardware. In 2015 the Common Vulnerabilities and Exposures (CVE-MITRE) database recorded 6,488 vulnerabilities. A considerable proportion (43%) can be classified as software-assisted hardware vulnerabilities (see Fig. 1). The discovery of Meltdown and Spectre in January 2018 has sparked a series of investigations into hardware security, particularly processors. Researchers have already exposed numerous other vulnerabilities, including Foreshadow, ZombieLoad, and RIDL and Fallout. Computer scientists at Stanford and Kaiserslautern (Germany) have also unveiled a new type of attack, dubbed the Orc attack, which threatens simple processors commonly used in embedded applications. These hardware flaws affect the security of personal computers, smartphones, and even the cloud.

Figure 1: The CVE-MITRE database recorded 6,488 vulnerabilities in 2015. 43% can be classified as software-assisted hardware vulnerabilities. In the last two years, researchers have discovered and reported numerous vulnerabilities in processors, including Spectre, Meltdown, Foreshadow, ZombieLoad, and RIDL and Fallout. Source: DARPA and OneSpin.

In a previous blog post, I argued that security needs to become an integral part of the hardware development lifecycle. Engineers developing semiconductor intellectual properties (IPs) and integrated circuits (ICs) shall have the appropriate knowledge, processes, and tools to detect and address security vulnerabilities as early as possible in the flow. Hardware security specialists are essential, but there is also a need for widespread awareness and expertise.

Glossary
I have two decades of hardware design and pre-silicon verification experience, but it is only in the last three years that I have taken a keen interest in security. During this time, particularly in the early days, I have often found myself confused about the meaning of specific terms or acronyms. The first time I saw the abbreviation ECC for example, I did not question what it stood for. It surely meant error-correcting code. I was familiar with ECC modules from my work in automotive hardware, where ECC safety mechanisms protect memories from errors caused by random faults. However, that did not make much sense. With more investigation, I learned the correct meaning in that context, namely elliptic curve cryptography, a public-key cryptographic method using operations in an elliptic curve group. While I am not an expert in cryptography and know nothing at all about elliptic curves, the word cryptography was by itself revealing.

Another term that caused confusion was data sanctity. Some electronic design automation (EDA) vendors have been using this term to refer to the requirement of protected hardware memory locations or registers to be writeable only from authorized agents or transactions. As I learned about security more comprehensively and systematically, I realized that information confidentiality, integrity, and availability (CIA) is a more appropriate and comprehensive term, long-established in software and other fields. Information integrity is the security objective that generates the requirement for protection from intentional or accidental attempts to perform unauthorized data modifications. This definition is applicable to hardware.

When starting a presentation about hardware security and trust, the audience often asks what I mean with trust that is not covered by security. Trust is the belief that an IP or IC is free from malicious, intentionally inserted vulnerabilities. The risk of hardware Trojans being present in third-party IPs or added by rogue employees is a significant concern for many government agencies and institutional organizations. Corporations are also starting to consider what measures they can implement to measure and increase trust in their internal development processes and supply chain.

Conclusion
As hardware engineers get more involved with security, they need to familiarize themselves with new concepts, terminology, and acronyms. Introducing new terms when appropriate ones already exist and are widely adopted in the software community, for example, is not advisable. A clear distinction between malicious and unintended vulnerabilities is also useful for all practical purposes. While there are excellent resources available on the web, they often favor a software or system perspective. A concise glossary focusing on the needs of hardware engineers would not be redundant. I have made a first attempt to create such a glossary and will make it available in a few weeks [now available here] . If you would like to stay informed or contribute, please do get in touch. In the meantime, for more information about IC security and trust assurance, please read the OneSpin Trust and Security Solution flyer.