Security Focus Widens To HW, SW, Ecosystems

Hardware security strategies are pushing much further left in the chip design flow as the number of vulnerabilities in complex designs and connected devices continues to grow, taking into account potential vulnerabilities in both hardware and software, as well as the integrity of an extended global supply chain.

These approaches leverage the speed of fixing problems in software, and the effectiveness of hardware root of trust and crypto modules. But they also represent a significant shift in mindset, moving from hardware- or software-specific approach to one that is more holistic and system-wide, from point of origin in heterogeneous designs to final manufacturing and in-field monitoring and remediation.

“We used to have hardware for security,” said Vivek Tiwari, vice president of the product assurance and security group at Intel, during a recent panel discussion at the Design Automation Conference. “Then, it was about how to provide hardware hooks to software in order to make software more secure. If there was a problem in software, the damage could be contained. Or, you’ve got a buffer overflow, what can you do to contain the damage? That was the role of hardware, and that was the traditional role. Lately what has happened, because of a sequence of incidents — including Spectre and Meltdown in 2018 — the role of security for hardware came to the forefront. Very smart researchers started focusing on hardware, and that opened a rich vein of work for them. As researchers got interested, the full ecosystem got interested in the foundational security for hardware. Today, it’s going back to the basics of the hardware-software contract — what do you expect — and then hardening those foundations.”

And, as software quality has improved and newer memory-safe languages and tools are being more widely used, more network-based software attacks that target underlying hardware vulnerabilities are being observed. Dana Neustadter, senior director of product management for security IP at Synopsys explained, “There has also been a steady rise in recognition of the important foundational role of hardware in system security. These factors raise the importance of hardware security in establishing and maintaining overall system security. There is also an increasing number of laws and regulations, including the latest E.U. Cyber Resilience Act, U.S. Cyber Trust Marke initiative, the automotive U.N. regulation R155 U.N., that are driving for security by design done right, from chips to systems. Companies have increased pressure to assess the security of their products and demonstrate assurance, trust, and conformance, otherwise they may not be able to sell their products, or they may be subject to hefty fines if data breaches occur. One relevant and very recent example is Porsche not being able to sell their Macan, Boxter, and Cayman models in the E.U. because of noncompliance with the cybersecurity protections mandated by the U.N. regulation R155 that takes effect on July 1 this year.”

In the past, many people took it for granted that chips were secure. In general, it was assumed that the software was the problem. Today, it can be both, and securing either one by itself is insufficient.

“You’ve got to have a two-random differential if you’re going to have somewhere to store the secrets before you can authenticate them, and if you want to accelerate hardware for some of the critical operations,” said Neeraj Paliwal, senior vice president and general manager of Rambus’ silicon IP business unit. “Ten years ago, the guys who were doing semiconductor microcontrollers were very proudly saying, ‘By the way, we’re putting security in the software stacks on your microcontroller to secure them.’ Then they started saying, ‘We’re putting smart-card-level security in the microcontroller.’ Nowadays, the game is not just the hardware security, but tamper-resistant hardware security, because hardware security alone isn’t sufficient until you make it tamper-resistant.”

That tampering can be through software as well as hardware. “Marc Andreessen was always saying, ‘The software’s eating the world.’ Everybody became a software developer, nobody cared about EDA or chip design anymore,” said Andreas Kuehlmann, CEO at Cycuity. “Everybody assumed it was working, and the big wake-up call was Spectre and Meltdown. People realized that in order to hack a chip, you don’t need physical assets. That was the change. Before, yes, you could attack a chip. You could open it up, you could slice it down. Then, when people realized you can remotely attack a chip, you got attackers from an advanced state-sponsored lab that has all kinds of equipment. Now, you’re getting to the high school kid, downloading a script, and doing something remotely. The attack surface is massively bigger.”

What’s different
Security experts have been sounding the alarm for decades, but until recently only those with extremely high-value data were willing to pay for it – financial institutions, governments, and multi-national companies with trade secrets. In other cases, it was like selling insurance into an industry based on sparse data, because many victims of cyberattacks were reluctant to talk about them publicly, and because there were no good comparisons between different solutions

“Trusted platform modules have been built into commercial PCs/laptops for more than a decade,” said Josef Haid, vice president of technical marketing for digital security and identity in the Connected Secure Systems Division at Infineon Technologies. “Previously, hardware security devices were mainly used by very security-conscious companies as a differentiator for their products. That has changed. Due to both internal demands and emerging worldwide regulations, hardware security modules are now being used more widely.”

What’s also changed is that the target of the attacks has shifted as more data is digitized. “In the past, hardware security was focused on protecting high-value data stored within a device, typically crypto keys used for financial transactions — essentially a uni-directional flow of data,” said Lee Harrison, director of Tessent automotive IC solutions at Siemens EDA. “Today, hardware security has evolved to address the new multi-dimensional challenge, with devices and systems being more connected and with a wide range of high-speed interfaces. The amount of data being shared is a lot larger and often contains sensitive content. Also, this data is no longer just static data hidden within a device, it is dynamic data being shared on the fly.”

In addition, this data flow is now bi-directional, so hardware security needs to include the device connectivity, which is typically where the biggest vulnerabilities exist. “This is not just to make sure that the data extracted from the device is done so by trusted sources, but also to make sure that any access into the device is also trusted to not tamper with the internal operation,” Harrison said. “On top of this, the security is often multi-layered. In the past, it was single-layered. This multi-layered approach provides internal monitoring to make sure that even if the interfaces of the device are penetrated, any unusual activity is detected and mitigated against.”

Toward a holistic approach
As hardware security evolves, it’s critical to understand the different threat models and best practices for hardware and software, individually and together. In general, hardware security focuses on protecting physical components from tampering and physical attacks, while software security looks at vulnerabilities in applications and operating systems through code inspection.

“Developing security standards requires a holistic approach that integrates both hardware and software protections,” said Jim Montgomery, semiconductor market development director at TXOne Networks. “The permanence of hardware creates unique security challenges that play a significant role in designing standards, as updating these devices is difficult and costly in most cases. Updating software security can be somewhat more flexible and adaptable in its approach. The ability to update software is generally present, and we can address new vulnerabilities and exploits as they emerge.”

Further, hardware is immutable after it’s been committed to silicon, whereas software and firmware can be updated relatively easily. “Also, the state of hardware security practice in the industry is on average less mature than that for software,” Neustadter said. “So, we have the opportunity to adapt techniques developed for software to hardware. The immutability of hardware means that standards need to focus on early stages of the development process (architecture and design), and pre- and post-silicon verification best practices.”

Still, hardware security brings its own unique challenges. For one thing, the latency in hardware is lower than in software, which is why it’s often claimed that hardware security has zero latency.

Often, hardware security has its own independent architecture, so it cannot be tampered with through access to the functional system, and this is one big advantage because any software-based system will typically run on the functional hardware which is the target of the attack,” said Siemens’ Harrison. “Software does have the advantage of being patchable, so updates can easily be made throughout the lifetime of the hardware. For this reason, it is common for hardware-based security to also have some small software element, which allows for an element of tuning as needed when new attack vectors and threats emerge. But for any system to have a comprehensive security solution, it will be multi-layered and contain both software and hardware elements. In the context of house security, for example, it can be compared to having both deadlocks and security cameras, as each brings different security elements to protect the same asset.”

Solutions vary greatly by application. “The big advantage of a dedicated hardware device is that it is designed for a specific task — protecting security-relevant credentials,” Infineon’s Haid said. “For this, a specific security chip is designed to protect against sophisticated attacks, and a certificate is provided, e.g., Common Criteria. In a system, these security chips are then typically placed beside MCUs, which enables the designer to make an easy-to-use modular design. Application-focused security standards for vertical industry can then simply reference the desired security certification.”

Fig. 1: A more nuanced and complex security architecture. Source: Infineon

On the other hand, hardware can be significantly more expensive to implement,” observed Victoria Coleman, chief scientist at the U.S. Air Force. She said that when security is implemented in hardware, the ecosystem needs to enable it, including developing security standards.

“In practice, even understanding what security standards are for is a really important consideration, because we have common criteria for software that are well understood in practice, and when we are asked if this is needed for hardware also, there’s a lot of confusion in industry and in government about the types, the classes of standards that one needs to advance security,” Coleman said. “Some of them I call ‘make’ standards, while others are ‘use’ standards, and these are very different things. They need to come together, but they’re different things, and there is very different content in each one.”

Make standards push security further left in the design flow. “Standards for security, in general, used to be something that we worried about at the beginning of the lifecycle,” Coleman said. “But when it comes to the government, it’s all about manufacturing. It has almost nothing to do with design, which is problematic. We all are focusing on distributed secure enclave and how we are going to build these things in such a way that bad actors can’t get into it, forgetting that actually, in many ways, it is the most secure part of the lifecycle because so few people have access to it. Also, companies like Intel are really good at safeguarding the manufacturing processes. But then you have this open-ended thing at the beginning and the end, when you do both design, testing, and configuration, which are the really big holes. So when you think about security standards, you need to be thinking about standards in each one of these lifecycles, and how we come together to give better overall security for the system that you deploy the device into.”

This includes both hardware and software. “Security is, in any decision criteria, always the weakest point,” said Cycuity’s Kuehlmann. “It’s always about time-to-market, cost of development, features, power and performance — they’re all conflicts. If everybody’s honest, that’s absolutely the case. Security is all about business risk management, because there’s no perfect security. So it’s really about how much risk you are willing to take, per incident, for something that gets a lot of publicity like Spectre and Meltdown.”

Security lifecycle management
One of the big challenges for security is that systems built today may be in the market for decades, depending upon the application. So what’s secure today is unlikely to be secure at some point in the future.

“The products are out in the field, and that’s what the world is running on, so how do we secure those,” asks Intel’s Tiwari. “Can regulations related to those make them secure? There, the hardware versus software difference is somewhat important. You can’t fix a transistor of a product that’s in the field, so you’re relying on firmware updates, you’re relying on the survivability features built into the product. That is different from software where it’s relatively easier to do a software patch, instantly deploy it, and it goes straight to the end user or straight to an IT shop. If you’re doing a firmware update, there’s an ecosystem. The delivery of the firmware update to an end customer’s laptop goes through an ecosystem. That’s something that is different in hardware versus software, and is important to keep in mind as folks are talking about regulations and formalizing this model.”

There is a whole series of best practices that have emerged around security over the past decade or so, starting with acceptable levels of trust and what should be included in security standards.

“We start with the concept of zero trust, said Rambus’ Paliwal. “In today’s environment, which is starting to wake up to bringing more onshore development, we will never be in a position where we will have everything under one roof — even in the foundries. So we need a way to insert a unique and immutable identity that can be re-used, and then follow it through. The commercial world is doing it already. The big application processor companies ship anywhere from 200 million to 2 billion or 3 billion chips a year, and they can drill down to feature management, not just over the air with these keys and the software. The solution is out there, built around zero trust. It’s a unique way of looking at the supply chain and building in integrity and assurance.”

Infineon’s Haid agreed. “Developing trust depends strongly on the industry and application on which level of trust is to be taken into account,” he said. “The first step is to be crystal-clear about the multiple consequences a successful attack can have on the user, the company, and maybe even the public, such as a successful attack on the electricity network. Based on this assessment and the device to be implemented, an internationally accepted security scheme should be selected, such as Common Criteria.”

The concept of zero trust has been used for some time and to enable any level of communication between system components, a form of authentication is required. This can also be done either in hardware or software. “It ensures that the system is protected against many different types of attack, from man in the middle type attacks to hardware counterfeiting,” Siemens’ Harrison added.

This comes down to identifying the levels of security to be implemented, as acceptable levels of security are very application dependent and need to be established as part of setting the security objectives for a product. “These will depend, among other things, on the threat environment in which the product will operate, regulatory and certification requirements, and the value of what’s being protected,” Synopsys’ Neustadter said. “Security standards can generally be divided into two categories: application-specific standards (e.g. automotive applications); and those oriented towards product suitability or fitness for purpose. Standards in the first category may impose specific requirements on compliant products. Standards in the second category should not, but rather state the principles by which application-specific standards should establish their requirements, and perhaps provide guidance or requirements to claim a particular level of security compliance.”

Governments are starting to put in place regulations to ensure that security measures are taken where safety critical systems are involved, such as in automotive. Europe has UNECE WP155 and 156 regulations governing the delivery of over-the-air updates, for example. More regulations are expected, even in the home where critical home systems are controlled.

Customers are also requesting security certification support, such as FIPS 140-3, Common Criteria, and for automotive specifically ISO 26262 functional safety and ISO 21434 cybersecurity. This is happening even in the area of design for test, as these tools provide significant attack surfaces due to the nature of the technology needing access to all of the flip-flops and state elements within the designs, Harrison said.

Haid sees similar customer requests. “For decades, traditional security chips have been certified according to international standards, e.g. Common Criteria. Additionally, industry-specific certification schemes are of interest for customers, such as “PSA Certified” – a framework established by Arm in 2018 to unite the IoT and embedded ecosystem under a common security baseline. PSA is especially used in the MCU market to make the security measures visible to customers.”

A number of alliances are emerging between semiconductor governments, industries, and suppliers, as well, to create best practices for how the different stakeholders interact. Actual regulations may be harder to establish, and need to be more narrowly focused.

“Regulations set uniform standards and requirements across the industry that manufacturers and suppliers must adhere to,” said TXOne’s Montgomery. “Protecting the infrastructure is one of the primary concerns being addressed today. Chip fabrication has been around for decades, and the equipment lifecycles are extremely long. This leads to additional risk and exposure to cyber incidents and targeted attacks in this critical space due to outdated software and operating systems. An event in semiconductor can have global implications, and we need to act immediately to ensure the protection and resiliency of the semiconductor ecosystem. The SEMI organization is very active in driving this initiative forward with the Semiconductor Manufacturing Cybersecurity Consortium (SMCC). Within SMCC, there are several workgroups addressing this exact issue and developing implementation guidance. Standards like E187, E188, EU Cybersecurity Act, NIST Cybersecurity Frameworks, Cyber Resilience Act (CRA) are all standards for the industry which are considerations for the group’s application and implementation guidance.”

On the other hand, no regulation or standard will guarantee that a system is completely safe. So where regulations and standards help is in providing a common approach for how to analyze security, Harrison said.

Others agree. “Part of the role for the semiconductor industry is to verify and validate that chips are resistant to tampering and unauthorized access,” Montgomery said. “Advances in fabrication techniques and secure supply chain practices, such as employing secure boot processes and hardware-based cryptographic methods, are critical in maintaining the integrity of semiconductor products. Designers and fabricators also need to leverage technologies like Hardware Security Modules (HSMs) and Trusted Platform Modules (TPMs), which can embed intrinsic security features directly into the chips, providing protection against both physical and cyber threats. Just as critical is the ongoing research and development efforts that focus on advancing security technologies and methodologies, enabling the ecosystem to stay ahead of potential vulnerabilities.”

Indeed, the semiconductor industry has proven capable of providing a supply of secured chips over the last decades, Haid said. Examples include security ICs used in payment and ID cards/passports or TPMs. These are produced in a security-certified environment and equipped with dedicated security credentials when delivered to the customer.

“In the last years, security regulations, standards, and best practices have been issued on a high pace,” Haid said. “As a result, for most industries there are much more concrete requirements on the table than 10 years ago. This is a chance for organizations to take design decisions on a better foundation, and security experts need to make those decisions. Using hardware security in this context is an approach taken by some industries for a long time. Also, using a dedicated security IC to store the most security relevant credentials enables designers to partition the system in a comparably easy way.”

Conclusion
Security is a moving target with a lot of access points. It’s not possible to build a completely secure chip that will withstand the rigorous attacks of a nation state forever, but it is possible to make it so hard to retrieve valuable data that it’s simply not worth the effort. But all of that comes at a price for performance, power, and area/cost, and in most cases security is not a primary business objective.

“The business objective is always primary,” said Cycuity’s Kuehlmann. “In the automotive industry, the primary business objective is safety. If you can hack a car, you can potentially look into it and drive it. For social networking companies, it’s privacy. The primary business objective is always different in different industries, and depending on that, the notion of security, the notion of trust, and the notion of risk taking is different.”

Nevertheless, more chipmakers are paying attention to security these days. But to come up with a consistent formula or approach that applies to every design or application is impossible. And that creates a challenge for securing chips that is likely to persist for years to come.