Why it’s important for hardware engineers to be talking about security and trust in ASICs, FPGAs, and SoCs.
Yet another blog on security! Oh, wait, this is hardware security – and trust. While secure hardware should be free from vulnerabilities in general, I use the term trust to refer to the belief that a semiconductor intellectual property (IP) or integrated circuit (IC) is free from malicious, intentionally inserted vulnerabilities.
Hardware security is on the rise. The media is helping. Stories of hacks into webcams and cars, or even the discovery of a new class of processor vulnerabilities, reach mainstream news outlets regularly. Consumers are well aware that their safety and privacy depends on more than just installing the latest software or app updates. Besides hackers discovering and exploiting hardware and software vulberabilities to hijack electronic systems for nefarious purposes, there is also the possibility of attacks to the IC supply chain. The risk of using tampered equipment in communication networks like 5G or other systems is a topic of many conversations today. In this scenario, a rogue employee, organization, or even a nation-state deliberately places a vulnerability, using malicious circuitry, for example, in a chip. Once deployed in the field, the tampered chip can be used to violate privacy, steal information, or worse.
Up until recently, security has been mostly a system-level and software business. Even today, some companies building tools to perform security threat analysis and risk assessment for electronic systems have a lack of expertise in the risks associated with the hardware components in the system. Aside from the few lucky ones designing hardware to accelerate encryption or other obvious security-relevant functions, most hardware engineers would not have to consider security in their daily coding work. This is changing rapidly. The process is similar to what has happened with functional safety over the last ten years. Nowadays, many more engineers are exposed to FMEDA processes, fault injection and analysis, safety mechanisms, and functional safety standards such as ISO 26262. Similarly to safety, automotive electronics is a crucial driver in the process of spreading security awareness. The upcoming automotive cybersecurity standard ISO/SAE 21434 is, in a sense, the counterpart of ISO 26262. Trust is also becoming a real concern, beyond MIL/AERO applications. Integrating third-party IP requires confidence that the IP does what it says in the tin and nothing else, for example. Developers of semiconductor IP and systems on chips (SoCs) need processes and electronic design automation (EDA) technology to avoid security vulnerabilities and assess the trustworthiness of a design.
Hardware security is its infancy. Let me mention at least one fact that supports this statement. The MITRE Common Weakness Enumeration (CWE) database was first released in 2006, focusing on software. It is only in 2020 that CWE has started to support hardware weaknesses. Hopefully, the 6MS blog can be a fun, entertaining way to promote knowledge and start engaging technical discussions about hardware security and trust. The aim is to keep blog posts relatively short, certainly below 1K words, and with a reading time not exceeding 6 minutes. Ideas for topics and general comments are very welcome! A great way to start this excellent adventure is to agree on a set of terms and acronyms.
In a previous blog post, I announced that OneSpin was creating a glossary of security and trust terms and acronyms for hardware engineers. Since then, the glossary has gone live and grown to over 90 entries. If you are not sure about the meaning of an acronym or term used in a 6MS post, the glossary should help. In my personal experience as a hardware engineer with little exposure to security for the first 15 years of my career, I have found it challenging to familiarize myself with the topic. While there are many resources available, they are biased towards software. Some security acronyms have an alternative meaning in hardware. See ECC, for example. Some concepts and terms that can make perfect sense in hardware have lower-quality alternatives. In this blog post, I note the relation between information CIA and data sanctity. Hopefully, the glossary can make your journey a little smoother than mine. Please, check it out, propose new entries, and suggest improvements. Your feedback is highly appreciated.
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!
 |
 |
 |
 |
 |
 |
 |
Leave a Reply