Chip Security Moves From Checkbox Compliance To Continuous Defense

As AI, chiplets, software-defined systems, and new regulations expand the attack surface, visibility, accountability, and real deployment discipline matter more than certification alone. Key Takeaways: Experts At The Table: As threats move across hardware, firmware, software, networks, and emerging chiplet architectures, semiconductor companies are being forced to rethink security as a continuous design, deployment, and monitoring discipline rather than a certification exercise. Semiconductor Engineering sat down to discuss these considerations with Michal Siwinski, executive vice president, chief product and marketing officer, and general manager for security solutions at Arteris; Yathiendra Vunnam, senior application engineer at Cadence; Alexander Petr, senior director and portfolio manager at Keysight EDA; Scott Best, senior director for silicon security products at Rambus; Chris Giles, director of product management for static and formal verification at Siemens EDA; Mohit Arora, senior director of architecture at Synaptics; and Reed Hinkel, director of strategic programs for security, processor, wireless, and NVM at Synopsys. This roundtable was held behind closed doors at the recent Design Automation Conference. What follows are excerpts of that discussion. To view part one of this discussion, click here. Fig. 1: L-R: Synaptics’ Arora; Synopsys’ Hinkel; Arteris’ Siwinski; Cadence’s Vunnam; Keysight’s Petr; Rambus’ Best; and Siemens’ Giles. SE: Are you finding that customers have an organized plan to implement security tracking? Vunnam: We’ve been seeing a lot of defense-in-depth approaches from many different customers. For every layer of the OSI networking model, they have a different type of security processing — IPsec, MACsec, etc. — and customers are using them for high performance because of high compute needs. We do see that a lot of customers are focused on certification because they want to sell the product. Commercially, it makes sense. But we’ve also seen an approach where they come up with everything they want, from A to Z, then start filtering it out. They may say, ‘We don’t want the highest performance of everything because it’s bigger.’ They want to shrink it down and get a final IP that’s plug-and-play. We’ve also seen a lot of open compute, like OCP Caliptra. That’s a big discussion we’ve been having in the market, and there’s a lot of potential with chiplets. You could have a subsystem on a specific chiplet, and you just plug-and-play. Your device cost goes down because you don’t need to use the most advanced nodes for each block. That’s probably the biggest hurdle right now. How do you verify which chiplet is secure and which isn’t? Petr: The distinction we need to make here is, ‘Is it a physical attack, or is it a software attack?’ The complexity we see is that software is getting deeper into the stack, so we’re talking about embedded software. Also, if you look at how data centers are built, you start with an IC. You do chip-level, then you do package-level, then you do board-level, and then you have the system, and the systems get connected, and you’re basically building town-sized systems that are fully connected everywhere. So the network is becoming one of the bottlenecks where you see a massive number of attacks, and that’s the software. Also, if you look at how the systems are built, you find a ton of FPGAs now, and FPGAs are programmable, so you now have programmable logic. It’s not just that the hardware can be faulty. You can have a physical attack. But more likely, you’re trying to get through the network, through the software stack, and trigger something in the system, like a denial. We’ve seen that across the board. Ultimately, there are multiple layers of defense where you can try to inject protection if you can detect what’s going on. One of the things we’ve also been looking into is, since everything is shifting left — meaning software as far down as the FPGA — is how can you actually make visible what’s going into the product? This means the software bill of materials for hardware is becoming significantly more important because that’s where the attacks are coming from. Especially with AI attacks, they come from the network. They go in and try to trigger something. And a lot of the software we use, including FPGA and other programmable units, is embedded software — the frameworks, and everything that drives hardware now have a software layer, as well. If you have any open-source software or anything like that, it’s a potential threat, and we’ve seen malicious actors trying to get into open-source communities to inject back doors. So it’s not just about knowing what you use. The bigger challenge is that you may use something you think is safe, and then someone exploits a zero-day vulnerability and triggers something. So every layer now needs a defense system, and it starts with visibility. If you don’t know what’s available there, you can’t track it. Let’s say we find a new zero-day vulnerability. Do you know if your system is impacted? How do you know? That alone is already a big challenge. And if it is, can you fix it or defend against it? Best: There’s an important part about personal accountability, or corporate personal accountability. But are your customers aware of the problem? Yes, almost by definition, all of our security customers are aware that security is important in the system. But there’s always that matter of degree. In the movie, The Big Short, there’s a fantastic scene where one of the traders is talking to someone from the rating agencies and saying, ‘How could you possibly put a AAA rating on this stuff that you knew was garbage?’ And they were like, ‘Our customers wouldn’t buy it unless it was rated AAA.’ And they were now captured inside of the same system. So when people come to us and say, ‘I require side-channel protection, I require fault injection attack, I need PUF technology,’ We say, ‘We can give you all of that, and we’re glad that you’re asking the right questions. But how well are you deploying it? How are you actually going to use it in your system?’ And at some point, they say, ‘That’s our system. You’re just the IP provider.’ For them, it might be just a check-box purchase. ‘I have side-channel protection. I have PUF technology. I’m going to adhere to the CRA. I’m going to adhere to ISO 26262. I’m going to go to Keysight or one of Keysight’s competitors, and I’m going to get CSIP (Cybersecurity Strategy And Implementation Plan) Level 3-certified.’ But is it secure? Hinkel: That’s just enough to make the claim to get that AAA rating so that you can sell it into the market. Best: Not that I’m cynical, but there’s a lot of money at stake. Giles: From what I see, I completely agree. There’s a full spectrum of adoption and awareness, and I’d also say there needs to be an incentive. Everyone is trying to get products out the door cost-effectively while meeting requirements, and a lot of that comes down to priorities. Unless security is one of those priorities, it often doesn’t get attention. Even though people say, ‘Yes, I believe that it’s necessary,’ the effort they put into it reflects the priority. How do you change the priority? You have to do it through incentives. I do believe there is a role for things like the CRA, but having the law is one thing. Following through on the enforcement piece, in my opinion, is going to be necessary to bring the level of investment in security to where it needs to be. Petr: Do you feel like the SSDF (Secure Software Development Framework) or the European CRA has actually changed something regarding sectors? Giles: I think it’s changed awareness. CRA comes up in a lot of conversations. Has it changed behavior yet? I’m not sure. Petr: No one has gotten fined yet. SE: What’s the CRA deadline? Siwinski: For semiconductors, the one that has teeth is September 11 of this year. Petr: The big question is: if you disclose it, does that mean malicious actors [will test it]? Siwinski: Like the comments made here, we’ll disclose what? That somebody has the sticker that some lawyer was happy that somebody securely thought, ‘I did my job’? Petr: The known vulnerability of your software stack has to be disclosed. Siwinski: It’s not just the software stack of your electronic device, which means software, hardware, whatever else you plug into it. That’s the trick. It’s not software. Petr: So now we are in the good luck scenario. Giles: The interesting part will be the follow-through. We see this in so many different areas of regulation where you get close to the date, and then the implementation cost becomes apparent, and everybody says, ‘Okay, we’re going to pause this for a year, we’re going to pause this for two years, we’re going to change it.’ Petr: We’ve seen that with the SSDF. The SSDF timeline was the year before last. Then the government changed, and things have changed. Hinkel: CRA has been a very positive change. When we deal with customers that have to sell worldwide, they know they have to support their customers now. In the past, they would have said, ‘Oh, the customer’s not going to pay for it.’ They can’t say that anymore. But there are still markets in the world where customers won’t pay. We all know where those markets exist. But that’s one key. The other thing I’ve seen is companies I thought would never change are putting a gigantic root of trust on a chip — way bigger than any of us have ever built with our own solutions. Some companies are bending to OCP to drive their root of trust into chips. Companies I thought would never say yes are saying yes. Arora: Just to add, the penalties are pretty hefty — like 4% of your annual revenue. So the bigger the company, the greater the liability. Siwinski: But it’s the usual stuff. It’s sticks and carrots. You have a stick, and once the stick is applied a few times, everybody else is compelled to avoid the stick. Hinkel: I’ve had a lot of discussions about the positive motivating factor, and it goes back to what Scott said a little bit earlier, which is that the value of what you’re protecting is a key driver. And if you’re making money making with services, then you have to really care about that because the high value services involve personal information. They involve PINs, codes, passwords, and all those things. It’s a virtuous cycle. I use the iPhone as an example. The iPhone sells for the same price or higher than it did when it was first introduced. The reason is that people trust it implicitly with their lives. If you look at the iPhone over time, the investment they put into security, and extra layers of security, has gone from a few dollars to hundreds of dollars to maintain that. But at the end of the rainbow, they can sell a phone for two or three times what their competitors can because people trust them, and that comes back to the service. So when they’re having a discussion with engineering — and we do best if the product manager is in the room and you can actually have the discussion with them — they say, ‘I want to differentiate, and I want to be able to rent services and all those things.’ I say, ‘Do you know what that actually means? If this is going to be a high-value service you want to offer, you’re going to need a service level agreement, and you’re going to have to live up to it.’ Otherwise, the customers or even governments will basically say, ‘Sorry, you’re going to have to give us some of your money, or you’re going to get sued, or whatever it happens to be. In Europe, it’s going to be government fines. In the U.S., it’s going to be lawsuits. That’s just the way it works here. And the courts are already opening the door to a lot of that. The C-suite is getting a little bit more interested, so they’re pushing down. But the product managers need to consider what they’re saying. ‘I want a high-value service running on it.’ Well, you’re going to have to spend a little bit more on that device to run a high-level service than you spent on that device that just did the basics. Petr: The U.S. military also drives a lot of the investment. The DoD and all the suppliers to the DoD, the Boeings, the Airbuses. Those are the ones who keep constantly pestering you on that stuff. SE: Switching gears a bit, but it’s related. We have not brought up PQC. The government recently pulled the deadline in to be quantum-ready. Best: They did that after suspending it. Then they pulled it in. Hinkel: The way I viewed the executive order when we analyzed it was that it really didn’t pull in the dates. The dates have always been the same. Now, it could be that the compliance to the dates was muddled with what different people said. SE: It’s still five years out. Hinkel: That’s always been the date for deprecation. It takes a while for them to actually deprecate everything. That’s the five years out. But you need to have the algorithms available on products. That’s a three-year date. So that’s the key there. The other piece I noticed from the executive order is that the long pole in the tent wasn’t the hardware. It was not the firmware for the devices. It’s taken the PKA (Public Key Accelerator) industry a long time to get to the point where they can actually support the algorithms and some of the new structures that are required, and that’s one thing I saw show up. Now, any PKA has to meet certain requirements. The problem that came up at a PQC conference about 18 months ago was that PKA is ancient technology. It’s a patch upon patches. It’s a spaghetti work of stuff. It was never organized to be deployable and changeable at scale. They’re faced with trying to do something new on top of a patchwork, and it’s forcing a lot of restructuring in architecture so that we can even support some of the hybrids, some of the stuff they want to do. Leave a Reply