How Secure Are RISC-V Chips?

Open source by itself doesn’t guarantee security. It still comes down to the fundamentals of design.


When the Meltdown and Spectre vulnerabilities were first uncovered in 2018, they heralded an industry-wide shift in perspective regarding processor security. As the IBM X-Force Threat Intelligence Index put it the following year, “2018 ushered in a new era of hardware security challenges that forced enterprises and the security community to rethink the way they approach hardware security.”

RISC-V is coming of age in that new era, benefiting both from lessons learned in the past and from the broad range of contributions by its open-source community.

For most attacks, threat actors don’t care which processor they might be targeting. “If someone’s doing spear phishing, it relies on you clicking on a URL,” said Rupert Baines, Codasip’s chief marketing officer. “It doesn’t matter whether you’re running an Intel processor or an Arm M2. If you click on that link, you’re vulnerable. And a lot of attacks are like that.”

But for more sophisticated attacks designed to exploit more subtle vulnerabilities, the specifics of processor architecture can make a significant difference. “As you get into things like side channel attacks, and Spectre and Meltdown, then the architecture and the implementation really, really start mattering,” Baines said.

This is where RISC-V can bring some unique strengths to the table.

Security through openness
RISC-V’s open architecture allows it to be examined closely on an ongoing basis. Baines pointed to a 2017 Princeton University study that uncovered several bugs in the RISC-V spec, as an example. While some people suggested the findings were a sign of weakness in RISC-V, most others disagreed. “We’ve never been able to do this study for Intel or Arm,” he said. “They might have the same vulnerability, but because it’s proprietary, we can’t look at it. And if that’s true, RISC-V is now more secure, because someone did look at it, and it’s been fixed.”

OpenHW Group president and CEO Rick O’Connor said RISC-V was similarly useful in response to the initial onset of side-channel attacks. “The original research papers around that work were published using RISC-V architecture, just because it was the only architecture that was open,” he said. “So you could get your hands on it, put it up on a hoist, dismantle it, figure out where the vulnerabilities were, develop algorithms to prove your thesis, and then attack the thing.”

That kind of openness, O’Connor said, ultimately makes RISC-V more secure. “It seems maybe counterintuitive, but the best way to build a secure platform is to make the entire design open and available to scrutiny in the public domain,” he said. “There are no back doors or hidden channels, and the entire community can work on securing it.”

What’s more, RISC-V offers a unique chance to do that from the beginning, by design. “We have this clean canvas,” said Crypto Quantique CEO Shahram Mossayebi. “We can do things right, build things right, in a way that is more suitable to how the ecosystem is evolving.”

The end of security by obscurity
Peter Laackmann, distinguished engineer for the Connected Secure Systems (CSS) Division at Infineon, said it all comes down to Kerckhoffs’s principle — the idea that a system should remain secure even if attackers know everything about how it works.

“The age of security by obscurity is over,” Laackmann said. “We are working toward transparent security, where we explain how things are working rather than hiding them.”

Cycuity security application engineer Anders Nordstrom pointed to AES as a good example of that. “Even if you know exactly how AES works, you can’t reverse engineer it and get the key out of the encrypted data. And that’s the correct way of addressing security,” he said. “Trying to hide something works until somebody finds it out. If the architecture and the security features are known, and can be designed to be secure even when they are known, then you’ve got a much stronger defense.”

Still, Laackmann said it’s important to keep in mind that just because something is open source, it hasn’t necessarily been examined. Due diligence is still crucial. “There are many software packages that are open source, and everybody thinks somebody has looked inside it. But then, it turns out, that for 20 years nobody did — and then the security fails. So even if you use open source, you have to check it.”

To that end, Nordstrom said, verification is key, particularly in an open-source ecosystem. “Just because it’s open source and RISC-V, that doesn’t mean that it’s ready to use,” he said. “You have to be aware of what you’re getting. If you’re buying from Arm, you are getting a black box, but you have some confidence that it has gone through a lot of verification.”

The risks of open source
Commercial ISAs have a significantly longer track record, and that track record comes with innate benefits. “Intel and Arm have had a lot more experience, and there’s a lot more buildup of techniques and solutions and architectures they’ve got in there that the RISC-V community hasn’t yet built or standardized or rolled out,” Baines said.

Newer open-source solutions can introduce other challenges, as well. Nicole Fern, senior security analyst at Riscure, noted that including third-party IP in a design always requires effort and budget for integration and testing. But she said that effort is far greater when using open-source hardware, “especially open-source IP that lacks maturity compared to its closed-source version. For example, Arm cores have been successfully integrated into SoCs and taped out for many years now. It will take some time before RISC-V implementations reach the same level.”

There’s also a risk of threats being intentionally introduced. “Because anyone can publish an open-source RISC-V implementation, there are more opportunities for bad actors to publish designs with known vulnerabilities or hardware Trojans,” Fern said. “For open-source projects with multiple contributors, there is opportunity for untrusted entities to try and push vulnerable patches or updates into otherwise trustworthy open-source projects.”

Improving security and reliability
Still, as competition grows, security will steadily improve across the RISC-V ecosystem. Baines said he expects the level of security required for automotive applications to become table stakes within the next 12 to 18 months. “Not everyone wants to pay for the certification, not everyone wants the legal guarantees, but every company should be capable of delivering ISO 26262 safety and ISO 21434 security,” he noted.

In fact, if you’re doing a vendor selection, it’s worth ensuring that a company can deliver at that level, regardless of whether that’s something you actually need. “I want to know that you as an organization have those capabilities, have that understanding, because that gives me confidence in the way you do all of your engineering,” Baines said.

It’s also crucial to catalog assets and do threat modeling to assess what needs to be protected. “Once you understand what’s important in your system, you need to start writing security requirements,” Nordstrom said. “These security requirements express, ‘This is my asset, and this is how the information is kept secure.'”

What’s needed for hardware security, Nordstrom said, is very similar to what’s needed for any other aspect of verification. “You need a plan, and you need to make sure that you follow the plan. And then afterwards, you know what you can claim, and you know that you’re as secure as you feel you need to be.”

That’s true for any system, open-source or not. “If you buy the processor or a system from somebody else, ask them, ‘Okay, show me what you did to verify that there are no hardware security vulnerabilities,'” Nordstrom said.

Building the ecosystem
More broadly, it’s in each company’s own interest to support open standards and to work toward improved quality across the board. “Bad quality poisons the well for everyone, so if we can help purify the well for everybody, that’s good and that helps the RISC-V ecosystem,” Baines said. “It means there’s more software developers, it means there are more libraries, it means there are more people using it, and it’s a virtuous circle.”

To that end, Baines said it’s important for more companies to support organizations like the OpenHW Group and RISC-V International. “One of the things that does worry me about RISC-V is the potential for fragmentation,” he said. “People are taking a RISC-V architecture and developing RISC-V cores, and then adding their own proprietary stuff, as well, which de facto means it’s not an interoperable standard anymore.”

Think of mobile solutions, which can only succeed through a shared focus on standards and interoperability. “You can use an Apple phone with a Nokia base station or an Ericsson base station or a Samsung base station — and Nokia, Ericsson and Samsung all compete fiercely, but they will all work with that same Apple phone,” Baines said. “And I hope that RISC-V goes in that same direction.”

The future of RISC-V security
Just patching up the security isn’t sufficient for RISC-V to succeed. But security will be a requirement if RISC-V is to be used in more mainstream applications.

“We’re not going to be able to deploy all of these smart and intelligent IoT edge connected devices, which have all the benefits we’re talking about with AI and ML, if you can trust my stuff but you can’t trust your stuff,” OpenHW’s O’Connor said. “As soon as there’s this hierarchy of better security, then as a collective, we’re doing the communities that we’re trying to serve a disservice.”

The good news, according to Riscure’s Fern is that RISC-V’s openness has the potential to lead to vastly improved security. “There is a lot of opportunity to create implementations from the ground up with security properties such as increased tolerance against fault injection attacks, and to integrate new ideas and techniques from the research community in a more agile manner compared to other closed-source commercial options,” she said.

Part of the challenge, lies in simply getting companies of all sizes to buy into the idea. “Inside each company, there are the groups who think open-source hardware as a concept is ready, and it’s time to start figuring out how the workflows are going to function and what it means to collaborate in the public domain on open-source projects,” O’Connor said “But at the same time, there’s an equally strong — and maybe even stronger — contingent or camp that thinks this is total hogwash.”

The best way to respond to that contingent, O’Connor said, is to let the work speak for itself. “Implementations and existence proof go a long way for skeptical hardware engineering types,” he said. “Fundamentally, the industry is based on proving that your design works and then releasing it to production. As hardware engineers, we’re trained to have existence proof before we say okay.”

And that’s inevitably going to take time. “Acorn, and then Arm, and even x86 for that matter, none of these things happened overnight,” O’Connor said. “Relatively speaking, the rollout of the RISC-V architecture, and the volume associated with these devices, is actually moving pretty fast. It’s not a one- or two-quarter problem. It’s years.”

Still, Baines said, for any company considering RISC-V but unsure if the ecosystem is ready, there’s always going to be a reason to delay. “If you’ve got an engineering project that’s going to benefit from RISC-V, you should be looking at it now,” he said. “Or you can wait two or three years and find out that your competitors have launched two generations of projects in that time. And what will that do to you?”

RISC-V Pushes Into The Mainstream
Open-source processor cores are beginning to show up in heterogeneous SoCs and packages.
Semiconductor Engineering’s RISC-V Knowledge Center


Hertz says:

“We’ve never been able to do this study for Intel or Arm,”. The Arm architecture spec is available to all:

Anyone can study it or (with a license) go and build their own Arm cores.

TL says:

The security superiority of open source has been proven useful for years in the software domain.

On the hardware side, we will learn soon that the situation is slightly different. When you face hackers, pragmatism prevails. You need to do something to mitigate the attack, you need to REACT.

In software, reacting means fixing the code and deploying a patch. Afterwards, you may publish an article. This is the principle of “responsible disclosure”.

How do you react when the bug is in the hardware ? In a CPU which is deployed in zillions of copies ?

Think about this. On a pragmatic standpoint, software or hardware, your capability of REACTION is more important than your capability of discovery.

Rale says:

You can study spec, but there is vast difference between specs and implementations.

Open Intel manuals and find Spectre and Meltdown in specs. Wait, FDIV bug wasn’t in spec either.

Leave a Reply

(Note: This name will be displayed publicly)