Security Sign-Off Is Coming For Chips — But Standards May Not Be Enough

Key Takeaways:

• AI is emerging as a force multiplier for cryptanalysis, increasing pressure on post-quantum implementations even if lattice-based algorithms remain broadly trusted.
• Security sign-off is becoming inevitable, but experts say it must be pragmatic, layered, and integrated into existing design and verification workflows.
• The industry’s move toward heterogeneous systems, custom AI hardware, and fragmented standards makes end-to-end chip and system security harder to define, verify, and enforce.

Experts At The Table: As AI-driven cryptanalysis, post-quantum migration, chiplets, and custom silicon reshape the threat landscape, the semiconductor industry is confronting how to define, verify, and sign off security across increasingly complex chips and systems. Semiconductor Engineering sat down to discuss this topic 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. Part two is here.

L-R: Synaptics’ Arora, Synopsys’ Hinkel, Arteris’ Siwinski, Cadence’s Vunnam, Keysight’s Petr, Rambus’ Best, Siemens’ Giles.

SE: Does the industry have a good understanding of the impact of AI on PQC?

Best: There was a recent publication that described an Anthropic Claude Mythos power tool running CryptanalysisBench, and it turned CryptanalysisBench loose on Hawk, which was a round three candidate, and also on a reduced round AES. It improved the attacks that it knew about, that people have explored and published, and said, ‘Well, we think it has this resulting key strength,’ and the tool proved it was several hundred times smaller. As a force multiplier, these kinds of frontier models are going to be unfortunately great at exploring the weakness of these cryptographic protocols. Now, there’s nothing out there right now that suggests that we have feasible, useful attacks against lattice cryptography, which is currently the basis of the major standards that are going into place — like 70%. You can check Cloudflare’s website, where 70% of HTTPS traffic right now is using the new protocols. Every time you establish an HTTP connection, Cloudflare monitors it, and at the start of the year it was around 30%. It’s now at 70%. That’s all based on lattice crypto. Nothing suggests lattice crypto is going to fall because of the introduction of frontier models. Now, with CryptanalysisBench looking at it, that’s good, but it is a risk, and it’s a force multiplier. But then, it’s a force multiplier for both sides.

Arora: Since it’s all so new, and not vetted over years and years, the price will have to be paid to make sure the approach is stable. That’s going on, but that also takes a toll on the associative profile that you have — runtime key generation, making sure you only do it every time, don’t reuse. It changes the ground rules quite a bit. It’s not just about the algorithm itself, but everything around it, because security is only as good as your weakest link.

Hinkel: From some of the papers I’ve read and studies I’ve seen, it’s not so much that the algorithm itself is weak, but that the implementations are weak. And if you have a weak implementation, that can actually leak information. It could be the camel’s nose under the tent.  Once you start giving signatures to things, then you can actually figure out the next attack vector. That’s all good for those of us in the tools part of the industry who do verification, security analysis, and all of that. We need to make sure our customers know this when they sign off. The final step will be to have sign-offs for everything else, but not for security. You’ll need a security sign-off at some point, too.

Siwinski: Security sign-off is absolutely coming.

SE: How soon? Shouldn’t it have already happened?

Siwinski: There are examples, but it’s very fractured. It’s a layered problem. It’s a layer cake. Is there something uniform across the board? No, and I don’t think the standards and regulations are going to force it, either. But because the workflows are different, who is involved in it is different, and so there’s enough difference in the different layers of the cake that you might need to do different things. At least on the hardware side, the concept kind of exists. It’s raw, but it exists because it builds on the nature that whatever we apply and deploy here must be pragmatic. Telling everybody, ‘Hey, to comply with the project, you must now do A, B, C, and D. And no, you don’t get more budget. And please be on schedule.’ That’s great. You’re going to get an amazing solution, and whatever it is, it needs to build on top of some of the stuff we already have, versus completely turning the design process on its head. What we’re seeing is that pragmatic solutions build on what you already have. It’s maybe one more step that isn’t too painful, and it’s going to give you the best results. And at least for semiconductors and the sign-off concept, it’s the closest thing to verification sign-off, where you’re basically doing coverage sign-off and things of that nature. You just consider security as another coverage kind of an asset of sorts, so at least you get that layer. That’s something you can maybe do. Does it scale to all other layers of the stack? I’ll defer to the experts.

Petr: Assuming there are people in that stack who can do that.

Siwinski: This is where I come back to the first thing I said. The first thing you have to do is get started. If you don’t start, you’ll never know what you don’t know, and it will be evolutionary. The good news is that for every layer of the stack, there are now examples. I would say hardware used to be the furthest along, but people are not doing hardware. Software security is not new. It just keeps evolving. So, it’s fixable.

Giles: I completely agree. It needs to be part of the process. Where it gets a little murky for me is, ‘Where does the chip end and the system begin? You can have great chip security and terrible system security, or vice versa. So if you’ve got bad chip security, good luck with building a secure system.

Petr: As soon as you go into embedded systems with FPGAs, it’s super murky.

Siwinski: To be clear, when I say hardware, I mean hardware at least the lower level of the firmware. Otherwise, it’s just silicon. It’s worthless, right? Now, do you really need to worry about middleware and running the application layer? Good question. At least the firmware and better metal software have to be in sync. Otherwise, it’s just a useless piece of silicon.

Giles: My point is that we can’t silo the process. Starting somewhere and having everybody do their best is certainly great. The best solution would be a consolidated effort to actually get to something meaningful.

Petr: IoT is mostly mobile devices, and now wireless communication protocols are evolving, so we’re adding neural networks into the transmitter-receiver. We’re going to dynamically adapt the communication layer, so we just keep adding more and more complex systems at every single level. We expect that people know how to secure those, while we’re just trying to figure out how to establish the communication. The same is true for wired communication. We’re switching to fiber optics for most wired communications. I’m not sure if everyone thought it through. Sure, you’re taking one thing away — copper emits fields, so it can potentially inject something there. Wired fiber doesn’t have that problem. So, are there different layers you can attack now? All of those things keep evolving, and we are constantly adding more and more software to those stacks, which are vulnerable to begin with because of open-source code and all those layers. It goes back to, ‘Do you have visibility? Can you track it? And are you monitoring?’

SE: When we talk about encompassing everything, how does that look? Are you seeing that manifest today?

Giles: I don’t think we are seeing that. And honestly, I’m probably stating the ideal. I’m not sure how we get there.

Hinkel: This exposes a critical missing link. In my many years of being involved in standards and things like that, all the standards we set are way up in the system, and they’re basically subject to interpretation in how you implement them all the way down here. The problem is that we don’t have a known good formula from the bottom layer up to meet the standard end-to-end. That’s really where the gap is. ‘Does your IP support this?’ Well, we support part of it, but the rest of it is firmware, or it’s something else in your system that’s responsible for it. So, I’ve done my job, but that doesn’t help solve the problem. We need a way to standardize the system layer. But then we probably need to define the software and a baseline of hardware, so these elements are in place. In other words, you won’t be able to meet the top-line device spec adequately.

Giles: Yes, it’s a much easier problem to solve if you have a closed system. That system is being defined. Going back to the Apple example, that system is extremely closed. Once you get to open systems, well, we’re going the other way.

Siwinski: With chiplets and heterogeneous disaggregation because of reticle limits, guess what? We’re going the other way. We’re not converging. We’re diverging.

Best: Caliptra is an interesting approach for that ,as well. Microsoft has declared that if you’re going to put equipment into our data center, it will be Caliptra-certified. And to be Caliptra-certified, you must implement a very large root of trust capable of not just firmware authentication, but attestation. You must also be able to sign attestation reports for all firmware in that system. And without that root of trust, you are not allowed to install that equipment in our data center. It gets very strange. Microsoft also has people who own the Caliptra specification, and it makes one wonder, given they say there can be zero deviation allowed from the hardware and software impacts, and it’s entirely open source, and now there are universal bugs?

Hinkel: It’s not just Microsoft. If you look at Calyptra, basically it’s all those guys who sat in TCG for all those years designing TPM, figuring out how they’re going to put TPM on a chip, and that’s what they did.

Best: It’s an interesting way of tying down what a foundation had, rather than just trusting. That’s an interesting approach to do an implementation as a standard, basically, and we may see a lot more of that.

SE: Does that mean more standards and more guidance are needed?

Petr: Well, there’s a little bit of an issue with that stuff. Right now, we’re also seeing that we have to increase performance. We’ve seen some of the digital standards. If you look at data centers, HBMs, or PCI Express, you see analog designers coming in with ideas on how to break up old-fashioned digital behavior. And what happens now is there are 10 ideas for how to improve latency and speed because now we’re bringing analog concepts into something that was exclusively digital, and that leads to the problem of doing it one way or another. Now you have two standards, and a third guy comes along and has an idea: ‘Oh, let’s do it that way.’ If you go into the network layer, I have colleagues who sit in those committees, and the guy constantly comes to me and says those analog guys are awful. It’s because they understand the signal in a way digital design does not.

What you’re seeing right now is also how many companies are building CPUs and GPUs. It’s not just the old-fashioned ones. It’s that every single one who operates a big data center wants to do AI and LLMs. They’re coming up with their own infrastructure, and they are not following standards because, again, they have smart ideas, and they just go through the stacks, and nobody knows what they’re doing. So, when we’re talking about standards, that is a romantic idea. But right now, what he’s seeing is that every single company comes up with their own TPUs, MPUs, GPUs, CPUs, and integration layers. It’s NVLink here, other things there. It’s like they’re building up their own cities, literally, to feed the world’s need for data centers.

Giles: This is ultimately why I said I don’t know how to answer your question, because obviously the answer is the perfect standard and the perfect set of standards. Except I don’t know how you implement them and enforce them amid market pressures.

Hinkel: This also goes back to if you have all these different things that are not vetted by other people, that becomes a problem. What happened with Spectre and Meltdown was the eagerness to get cache operating in a way that allowed them to meet performance levels that they could never have before. They were implementing caches directly from .edu papers. The problem was that those never had a security study of the architecture before they did it, and that’s why Specter and Meltdown happened. Back to what you said about Arm. When I was there, we started this whole process, but it took a while to get everything under the umbrella. So you start with the security spec up front.

Best: They added protected memory long after they implemented speculative stuff.

Arora: It’s a double-edged sword. When the specification goes down through the weeds on the implementation side, that becomes the actor itself.

Read parts one and two of the discussion:

The Next Big Chip Failure May Be A Security One
Semiconductor leaders say hardware trust, verification, and lifecycle resilience must become core design requirements rather than late-stage additions.

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.

The post Security Sign-Off Is Coming For Chips — But Standards May Not Be Enough appeared first on Semiconductor Engineering.