Design For Security Now Essential For Chips, Systems

It’s nearly impossible to create a completely secure chip or system, but much can be done to raise the level of confidence about that security.

In the past, security was something of an afterthought, disconnected from the architecture and added late in the design cycle. But as chips are used increasingly in safety- and mission-critical systems, and as the value of data continues to rise, there is much more effort going into security methodologies and secure development lifecycles.

“From a very tactical perspective, we engage with customers on different spectrums,” Jason Oberg, founder and CTO of Cycuity (formerly Tortuga Logic). “Some have pretty good processes, some don’t. Some just say, ‘Here’s what I’m doing for security,’ and have a plan. Very tactically, write your security requirements down. In talking with customers, we often ask what their security requirements are, spend a lot of time with them, only to have them say, ‘My chip should be secure,’ or, ‘I don’t want my root of trust to be vulnerable.’ That’s very vague.”

A better approach includes identifying design assets, Oberg said. “Are the design assets written down? What are the security objectives with respect to that? Some organizations have this, some don’t. Just writing those down, and having a simple way of checking that off as part of the design verification process, will put you leagues ahead. Better still is to establish that process, since you can then add more complexity to it, including automation. You can start feeding in standards and so forth. At the same time, many times organizations are getting pressure from customers and the market to build a secure product, and they don’t really know what to do. They’re looking for solutions. But until they’ve established some structure, it’s pretty hard for them to adopt solutions.”

Defining a security development lifecycle is a good starting point. But that also has to be extended to the end consumer.

“There’s a real danger in security, because of its complications and being really hard to understand, to run into the equivalent of what in sustainability is called green-washing,” said Frank Schirrmeister, senior group director, solutions and ecosystem at Cadence. “This is ‘secure-washing,’ and while there may be government regulations, it’s all about customers in the commercial world. Semiconductor companies and system vendors have to serve their end customers, and for them it’s like selling insurance. You really didn’t know that you needed security until you ran into a real issue. That’s when they say, ‘If I just would have had insurance.’ But how to implement it is really an intricate issue, and it’s hard to understand from technology perspective. I fear it may be similar to a clean energy ‘Energy Star’ sticker on a washing machine, which may just mean, ‘Yes, I have documented processes.’ That’s why I think there’s a danger of secure-washing, where the end consumer is lulled into a sense that ‘this thing is secure,’ without really understanding what’s underneath, who confirmed it, and what the process was. That’s why standardization is crucial. But it also needs to be transparent.”

Still, insurance is just a way to change who is going to pay, when, and how, noted Mike Borza, fellow and scientist on the security IP team at Synopsys. “People who can’t get insurance are the ones with a bad claims history. So if you’re selling something that is insured, and you have to pay every time there’s an attack on it that succeeds, it either puts you out of business or forces you to up your game. At the end of the day, that’s what insurance does. It just delays when you’re actually going to start taking responsibility for products that you’re selling. Regulation sort of works the same way, because for effective regulation there needs to be penalties built into the regulation for people who don’t conform to it. If the penalties are not built in — and we’ve seen tons of these kinds of legislative initiatives where there’s no penalty built into it — then it’s completely toothless. If you pay fines because your stuff is not sufficiently secure, now you’ve got a way to get somebody’s attention and force action.”

This also requires an understanding of asset values, Borza said. “Put your assets in order in terms of which ones are most important to you. Once you start doing that, then you are on the road to having a decent notion of what your security is, where you’re vulnerable, and where you’re not.”

Verification takes a similar approach. “It starts with the requirements, then there is the process,” noted Jamil Mazzawi, CEO of Optima Design. Subsequently, for every requirement is a corresponding verification task, which can vary depending on the target application.

The application domain determines what is written down. “In aerospace/defense there is one set. In automotive, there’s another one. In medical, yet another one,” said Cadence’s Schirrmeister.

Another consideration is that if the chip or the system that contains the chip can’t be physically accessed, there are a lot of side channels that don’t matter. “In this case, it’s timing that’s important, but you don’t care about a cell phone that’s sitting right in front of you,” Borza said.

IP integration challenges
In systems with multiple blocks of IP, it is not uncommon to for users to struggle when trying to integrate third party IP, both software and hardware, and to understand where that IP is with respect to security.

“Transparency in this goes back to writing down your requirements, not having them scattered throughout your 500-page documentation, grouping them all together so that to the customer or the people trying to decide whether or not to purchase your solution it’s very clear what the security functionality you’re providing is,” said Nicole Fern, senior security analyst at Riscure. “Good vendors will have that. Great vendors also will tell you where the limitations are, because every solution that claims to offer some sort of security guarantee has weaknesses. There’s a certain point at which it can’t protect you because every solution can be broken eventually.”

That said, when looking at the vast landscape of all the different IP that can potentially be integrated into the product, how does the engineering team make a decision as to which one to integrate? “Definitely look for vendors that are transparent about the strengths, but also what conditions the IP no longer can provide those guarantees in is important,” Fern said.

Accellera created an IP Security Assurance Working Group specifically to address this issue. “It says, ‘This is the IP that you’re buying from us. It has some security properties. These are the things we’ve done to mitigate those concerns. And here are the things that are unmitigated in our solution, either because it wasn’t appropriate to the use case, or because it’s better to mitigate that at the system level,'” Borza noted. “The integrator — the customer for that IP — has some responsibilities to finish the integration and manage those security concerns for the risks that they care about. That goes back to the notion that different verticals have different concerns.”

Also, Schirrmeister suggested there’s a certain level of readiness for vendors to serve in this market. “We have to begin by having the right processes in place which incidentally is the same for safety. What we do legally between companies where we have to refrigerate people: you’ve worked on this, so you’re not allowed to work on that anymore for a while. That applies at a very important grand level for readiness for implementation.”

Countermeasure design methodology
As threat vectors increase, so must the security methodology to catch would-be attacks.

“While users may understand side channel attacks and where they come from, once the weakness is identified they can provide security ECOs,” said Norman Chang, fellow and CTO of the electronics, semiconductor and optics business unit at Ansys. “However, for fault injection, it is much trickier compared to side channel attacks. Based on electromagnetic fault injection, laser-based fault injection, or optical fault injection — in their mind they don’t know how to prevent fault injection, because if you do not make the fault injection large enough, the chip will fail for sure. They use just the right amount of fault injection, and that can cause the security output to be different.”

But in a safety context, there is no fail-safe, so fail-secure is the proper approach. “Interestingly, when you start combining safety and security, the fail-safe response is not necessarily the fail-secure response, because you have critical systems,” said Synopsys’ Borza. “If you think of automotive as a simple kind of use case, you don’t want the automatic brake system to shut down just because there was a security fault in it. You actually need it to continue to be a brake system.”

Optima Design’s Mazzawi suggests much can be borrowed from safety and applied to security. “In safety, we want the system always operating. It knows when there is a problem and tries to fix it. And here we want to simply stop operation and do something about it. What we can do in safety, which is add capabilities for detecting a failure happening and correct it, we also can do in security to detect that something bad is not going to disrupt this platform. There are lots of methodologies for how to detect attacks or failures in safety that can be applied to security. There are safety mechanisms that can be applied for security, and then verified to be good enough.”

Borza noted the biggest difference between safety and security in the formal sense is that safety is concerned with accidental failures of something, whereas faults are single-fault detection and correction, and sometimes double-fault corrective action. “But in the security scenario, you typically have faults that are injected on large swaths of the same chip that are simultaneously or closely correlated with timing. That’s a big difference in how the system needs to be able to deal with that, and what the thinking process that goes into understanding what the faults is.”

“The answer to the question is defining that up front,” Cycuity’s Oberg said. “’Here’s the asset I’m trying to protect. Here are the conditions in which someone can get access to that.’ This is what they seek to gain through the threat model process. You can define that requirement and you can then build your whole fault simulation and verification plan to accommodate it. There isn’t a one-size-fits-all approach — for example, ‘This is the percent of faults you need to cover.’ It might be possible to define that, but it really depends on what the attacker is going to try to do, where they’re going to focus their attention. You can build your whole fault verification plan from that. The same goes for side channels and so on, because for whatever market you serve, that measurement is going to vary based on the market and how much access people have.”

This is complicated by the fact that security is a very fast moving space. “The hacker actually knows the defined space and where they should focus, because we tell them what has already been covered,” Schirrmeister said. “So this whole notion of what is the area that we don’t cover — which in the case of safety and functional verification is something you didn’t think about — is much worse with security because you’re telling the hackers while we secure this bit, this other space over here is an opportunity for you.”

What’s good enough?
Even though perfection is not a realistic goal in security, there are some very solid guidelines to reach a high level of confidence. But it still comes down to what is good enough security for a particular design or application.

“If you’ve systematically gone through the process of writing down the requirements, and you have evidence to support verifying all requirements, and if you can use a coverage like the CWE (Common Weakness Enumeration) to transparently communicate what you’ve done, then you’ve done enough,” said Oberg. “There are going to be requirements that you’ve labeled as ‘out of scope,’ which may all of a sudden become in scope because someone exploited them. You’re never going to be fully secure, but if you’re systematic, you can sign off. You can say, ‘Here’s what I specified at the onset. Here’s the justification for why.’ You maybe even share that with customers and then verify. Then you say, ‘I’ve done it all. Here’s my evidence.’ You’ll probably still get hacked, but at least that’s enough to say that.”

Along with this is the ability to recover from attacks. “This includes a way to report the problem, then to address the problem, and finally be able to distribute the solution to that problem, is needed,” Borza added.

At the same time, much depends on the threat model, Riscure’s Fern said. “Good enough depends on how much energy the attacker has to expend, and how much attack potential. If you are able to protect your device up to a point where it’s not even worth the attackers going after it, then that is good enough. If they have to go somewhere else, attack an easier to target, that would be enough.”

In automotive, in particular, this is a huge challenge because of the safety-critical aspects and the long life expectancy of the chips. Some users are now asking suppliers to look 6 to 10 years into the future and design in enough flexibility to update it, said Lee Harrison, automotive IC test solutions manager at Siemens Digital Industries Software. “There’s a tradeoff between how flexible you might be, and the effectiveness of the solution,” he said.