Your Chip Works. Prove It Is Secure. - ARTERIS INC

Good morning, good afternoon, or good evening, depending upon where you are in the world, and welcome to today's 30-minute BitCast. Your chip works. Prove it is secure. Hardware security assurance, systematic and scalable security across chip design. Brought to you by EE Times, Arteris, and broadcast by AspenCore. I'm Colleen Heckman, and I'll be your moderator today. I have just a few brief announcements before we begin first the slides will advance automatically throughout the event you may also download a copy of the slides by clicking on today's slide deck in your resource folder located to the right of the presentation window today's presentation will be followed by a Q&A session you can participate in that Q& A session simply type your question into the Q& a text area and hit the submit button if you experience any technical difficulties during the broadcast just type your issue into the same q a text area hit the submit button and i'll be glad to offer you one-on-one assistance and now on to the presentation your chip works prove it is secure discussing today's topic are leon brown director of marketing cyber security at arteris leon has spent more than a decade in cyber security spanning identity public key infrastructure quantum security and post quantum Cryptography. He is a Director of Marketing Cybersecurity at Arteris and focuses on hardware security assurance. And joining Leon today is Pete Marr, Staff Field Security Applications Engineer at Arteriis. Pete is a Staff Field security application engineer at Arteryis with deep expertise in hardware security verification proficiency in FPGA and ASIC synthesis and pre silicon verification with industry standard emulation and multi FPGA prototyping platforms. It's a great pleasure. I'm going to now turn things over to Leon to begin. Leon, take it away. Hey, thanks, Colleen. Hey, everybody. It's great to be here. I am Leon Brown. I m here with Pete Maher, one of our security application engineers. We are both part of the Arteris Harbor Security Security Product Team. Let's get started. We're going to look at a little bit of why hardware security is really getting attention right now, or functional verification, maybe some blind spots, how PsyQt follows assets through your design, gives you a view that you might not be getting with functional today, and how to turn all this coverage into a sign-off evidence that you can use in any reports you have to be creating. So we often like to talk about why is security for hardware getting a lot of attention these days. And this is just one example. You've heard about the frontier models like Mythos and some of the new chat GPT models exploiting a lot software vulnerabilities and hardware attacks are happening too. This is an example just from a research group where they demonstrated a rebuild of Spectre and Spectre, if you're unfamiliar with it, caused billions of dollars of damage a number years ago and it took years and years to develop many researchers tons of research and they were able to reproduce a spectra-like attack in 2026 using a dollar and a half or a little under a dollar and took under four minutes and what we like to make sure lands with people is like attack discovery used to be expert work but that's really changed fast and the attacks are really now automated at scale and we're not going to we're assuming that the next harbor flow is going to to get discovered fast enough. And hardware vulnerabilities are a real thing. We often look, you'll hear from us as we go through the discussion here about common weakness, enumeration, CWEs, but you can also just look at the growth of the vulnerabilities and we're already seeing that the vulnerabilities that have been discovered in hardware to date in 2026 have eclipsed. All of those are in 2025, real growth in kind of the things that are being reported. And they aren't exotic. The way chips are built now really kind of explain how this is happening. You know, security features, you know, better processors, secure booths, software that changes state, data left in memory, all these things contribute to, you the complexity of designs and that in turn is leading to some of the reason why we're seeing a lot of growth in the phone or abilities and that's why verification has to look more about how the design actually runs and simulation emulation that's what we're going to talk about going forward and why is this really important well we all have these obligations uh you know the automotive industry really moved there first uh with iso se 21434 it specifies for people supplying to the automotive the type of security uh information needs provide the european union with the cyber resilience act uh they started reporting obligations for everybody in september just last month but december next year they're going to have specifications around what hardware people providing products into the european union need to do for hardware right and that's going to trickle down uh from you know somebody who's selling a device who's going gonna be asking their chip suppliers can be asking their ip supplier for evidence in terms of you know how you've done diligence on your hardware and on your semiconductors and your designs to make sure they're secure as possible the united states is doing the same thing too we had a recent press release related to third-party IP, often called 3PIP or third-part IP, which has discussed our work with our partners at BAE and Psi 5. This was funded in part by the U.S. government to create kind of consistent evidence for security verification, which is really relevant in programs that feed into the U S national defense industry. And, you know, the thing to remember is products even in market today or those that are being created are all going to enter into an environment where people are being more and more concerned about security. So there's two different questions about, you know, you can think about a block with hardware security. Functional testing kind of asks where did the crypto block do its job? Those right algorithms, right strength, did the key go from one place to the, you, know, the place it's supposed ago. And security assurance actually, you know, asked a little bit more. It asked, you know, did it go anywhere outside the protection boundary or could something like a debug read it or, you know, it's looking more about the flow of data. Isn't that right, Pete? Yes, that's right, Leon. With security verification, functionally speaking, we are determining whether or not the security function works as intended. So here we have a key that we want to program into the secure EFUSE OTP memory and configure the AES hardware to use that key and encrypt a known plain text, compare that against the test vector. And so, you know, we're functionally verifying does the AEs block, is that functionally correct? Does it meet the cryptographic requirements? Whereas security protection verification, We're looking to see if the key can escape the protection boundary, even though the encryption actually works. Can the debug fabric read the AES key register, or maybe some DMA transaction has some access to the internal bus? So that's the difference between functional security verification and security protection verification. Thanks. Yeah, it's really different to be trying to, you know, something work as you designed it, you know just at the end point, or do you really know where things went along the way? So, I'm going to go through a couple of things pretty quickly in this section, but every design has a version of this kind of floor plan. This one isn't real, of course, but everyone's got something like this and everyone has an asset like this key and i'll use a key for this example because it's really easy to understand also it's a small visual on the screen so it's easy to follow along and so the seven questions that follow they're all kind of the same very there are variations on the same question is where can the key go and on each of these slides you're going to see something from the mitre catalog of hardware weaknesses and mitre is organizations doing great work helping categorize uh you know with industry input uh you know weaknesses and they've been doing it for hardware for a number of years too and this is the common weakness enumeration database it's the industry's list of known hardware design known things where hardware designs go wrong and so the numbers are on this you can look them up uh if you want to just give us a you know send us a note later we'll be happy to go over all these things with you but um So, after a secure boot, you know, things we often think about, what gets left behind? So, we had a real customer where their key content was still sitting in a third-party encryption IP block after the boot completed, right? And SciQ2 is actually able to track the key's value, and we found places that had been left that weren't expected. A lock can be sent and registers are privileged, but can anything still clear the lock in a way that nobody planned? This one was a public case, not ours, but, you know, a ship's security engine whose lock permissions were quietly cleared by a chip reset, so the lock really didn't stay locked. And debug and test logic, that reaches into the chip design, you know, that's kind of its job, right, but what can you read that it shouldn't? And does your security even model, does it even cover that path? And we've had customers of ours who didn't recognize where they had missed that in some of their testing or were able to see it when they looked at it through simulation. What about firewalls, MPUs, MMUs, they enforce policy, right? Question is often ordering, right. Does the check happen before the asset moves, or is the data already gone when the check lands? And so, tests that confirm just a specific policy or outcome can't see the race. This one's big for us. It's on actually MITRE's 2025 list of most important hardware weaknesses, too. Most of all, tenants, they share the same interconnect, the same buffers, caches. Are they isolated or assumed isolated? Pete, we've had some cases around this, right? That's correct. We have many situations where there's secret data that must be remaining in one context or one job ID and not visible to another. That's very common in a lot of designs today as we move forward with AI, virtual machines, and very similar type of environments. This too, speculation often leaves states behind. That's what caused meltdown in Spectre that enabled those exploits. So one of our customers we worked with, they were able to find a previously unknown weakness in their own branch predictor. So an attacker branch history was able to steer, you know, our customers' predictions, right? So this was in Spectre itself, but if they had not caught it pre-tape out before they went to silicon, it was a weakness that could have become a Spectre-class motor ability, and they didn't want to have that liability and responsibility and cost post-silicon. So they were happy they found it. And so their assertions in testing had missed it once they were looking at it through simulation and tracking the assets, they were able to visualize it. And so functional testing, you know, from verification to pass, and what happens is crypto data can still end up in registers that nobody expects. Many of our customers, you Know, come to this understanding that if you're not tracking where data went, you can miss this risk. And passing tests often has two explanations, right? The design is safe or the test couldn't see where the data really went. And the rest of our presentation we kind of walked through is telling those two apart. You know, and I just showed seven of these. MITRE, up until yesterday, cataloged 110 hardware weaknesses. They just came out with version 5.0, and so there's 112 now. And the weakness class is a design condition that could have a vulnerability under it. SciQt can help you evaluate roughly, you know rsm is about 80 of those before tape out the other the other 20 percent are physical they're side channel tax or fault injection things you test on silicon after you've actually uh created the silicon and so um a lot of a lot of good things and so it's not to say every design will test everything every cwe uh but we do have a lot to cover what's going on there and i do want to take a moment just go a little detail on one example um you know this is a root of trust for the mailbox and uh you know a region of its local sram that you know the untrusted cores can see and so the two sides can talk right in privilege mode the mailbox is shut nothing goes in nothing comes out and so the standard test the functional test is you know from an untested core in privilege mode, read the mailbox. You know, if you get a refused, great, passed. But what the test checked is the answer to just one request. And, you know, when you get refused on the, you know, refused, it says nothing about the data. Did it go through the NOC? Did it sit on a bus? Did the land in another register while the request is being refused? And if you don't know where it went or you don t have a way to visualize that flow, you don know whether it's fully protected and so but it did not check is whether anything from that region across the interface anyway in any direction at any point of the mode is privileged and so down below if you look at that strip there's like one read uh you know one read one moment inside that window the mode of set but outside of that we're able to see it over the you know the full time range and so what you end up doing is the type of rules that you can develop with psychuity and you you know, using the kind of just text form here, but you want to be able to say nothing enters or leaves the mailbox through its interface to the untrusted site within privilege mode. And so this is the type of test that functionally, when you're running functional tests, you can specify, but again, this timing of being able to see what happens, you know before the privilege mode cleared is really something that's hard to visualize without doing information flow tag like PsyQD does. So how does it work? I'll give you a very simple analogy, but it was once the first time it was explained to me, they explained it as if you have a river, like Mississippi River, and you want to get a drop of ink from the top of the United States down to the Gulf of Mexico. And you put that drop of ink in and it flows down. If you think of it visually that way, the ink is never going to get straight there. It's going to go out of tributary. It's maybe a little bit going to be caught on the shore. Maybe it's going hit an eddy and spiral around and get held up. And the same thing is in a design. Pete, that's a really simple explanation, but there's probably a little more detail there, right? Of course, yeah. but this is a very very good illustration of how an asset you know could be requested in an aes block here but as you emphasized with the the analogy of the river and water flow uh the key could wind up in a reused buffer or a debug port as we saw in a previous slide or an idle bus and you know these are things that you would need to have a large number of tests on the functional side to really explore and cover to ensure that those scenarios did not happen. You know, same thing with other methods. You would need to have all the mathematical calculations to make sure that the asset does not leak out or is not visible, accessible in undesired locations. So information flow tracking allows you to visualize where the asset flows both intentionally and unintentionally in your design. Is that kind of an aspect of pushing, you know, kind of stimulus through different blocks through the design? How does that, like, work technically to get coverage? Yeah. I mean, when you basically are running your tests, you can try to, you know, use UVM and other methods to get, you know, full coverage. But there's always going to be scenarios and tests and situations that may not been thought of. So, you know, having information flow that can use symbolic analysis that is independent of values is of great benefit. Thanks. And at the end of this, the way that this operates is you look for a secure asset, and everyone's different, right? the asset and you end up tracking it through its life cycle and at the end of it you end up with a sign-up report that you can create and this is just representatives of you know i'm using a excel sheet basically to make a table if you're able to sort of give a report on how much of the coverage you were able to do uh when you push uh you know push the the information through the design or the asset to the design might not just be a key it might be other aspects that need to be secure or isolated. And so you're able to sort of show, well, maybe part of it was bounded, easily bounded. I was able to do a formal proof, or maybe I was able to push through 80, you know, get coverage of about 90% of my design and were able to find and close things out by improving my test passes. And what happens at the end of all this is after you do your design of your, you know, your rules, what do you need to protect, and you run this through simulation over a number of period of times, you'll get gaining confidence on how much of your coverage you've done, and that's something that you can define. And that's, again, gives you a way to feed into the reports, whether it's, you now, into the automotive industry or as you prepare to understand what you need report for the EU Cyber Resilience Act or anything for the U.S. Department of Defense. It gives you really a lot of good visibility into how your design operates, where the data is going, and how much coverage you've actually tested within your design. And so, we're going to wrap up here. You know, the key thing we want to say is that instead of just testing an end state of a functional test, it's really about following the assets and building evidence. And so hardware threats and the assurance requirements and obligations you have are really accelerating. Like we looked at passing a functional test does not prove that assets stayed protected through the entire time that they were moving through the design. SciCUNY does this through following it on simulation ambulation flows. And you're able to develop some, you know, the evidence you need to create a security sign-off or a security verification sign-up before you tape out. So, that's what I have right now. I'll turn it back over to Colleen for questions. Well, thank you, gentlemen, for an excellent presentation to our audience. We are now moving on to the question and answer portion of the event. If you haven't done so already, please feel free to enter a question in now. Please note that we'll get to as many questions as we can in the time that we do have left. If we don't get to your individual questions, someone will get back to you. So gentlemen, I've got a few questions that have actually already popped in, so I'll go ahead and get started. Our first question is interesting. We're asking what's changing in hardware security landscape that makes pre-Silicon security assurance more important today? I'll go ahead and grab that one. I talked a little bit in the beginning of the presentation, but it really comes down to the ease of which attacks are being able to be conceptualized. So we're seeing AI tools be able to take in research that's been done over decades and apply it to attacks that we hadn't even imagined in the past. And so we're not, you know, we're seeing that the expectations, you know for being able to defend designs has also been going up. So, you if you look at the EU CRA and the federal government and where the automotive industry was, again, all these sort of point to just a plethora of ease of attacks and the responsibility for hardware manufacturers to really understand the design in great detail. Excellent, thank you. Moving on to our next question, how can a chip pass its functional tests and still be exposed to sensitive information? Pete, you want to grab that one? Sure, yeah. With functional verification, you know, you're basically just checking for the expected result, making sure that the various blocks are operating and producing and generating the results that you expect. So these are kind of like checking for the knowns, right, the known behavior. Security verification, however, is actually looking for how protected information is being tested and where it travels, where it becomes observable or what is left behind. security verification is a little more nuanced because you actually have an idea of how can an attacker potentially access a protected asset, some secure information, some secret data, or checking for particular leaks, where does the dam break, so to speak. So functionally checking for, you know, behavior is different than looking for how an asset protected information may be accessible. Excellent. Thanks, Pete. We've got quickly moving on to our next question. How can design teams follow a sensitive asset like a cryptographic key through a complex chip to see where it goes? Yeah, so that's very similar to what I was just explaining in regards to understanding, you know, what is, first of all, a secure asset, you know, secret data that you want to protect in your design, and then defining where it may or may not travel, where is an expected location, where unexpected locations information flows kind of a core technology being able to track such assets across your design showing where information goes and also being agnostic to the native values is is the key aspect of it all because of course there may be other methods to which you may be able to say okay i see the the secret asset in these various uh places of my design but that you know there's so many mathematical equations in which you are able to calculate or have a tool calculate and i think information flow tracking is a key technology that enables a much wider scope of understanding of where secret assets may be discovered Okay. Excellent. Thank you, Pete. So, our next question asks, does our Terrace hardware accelerate post-quantum cryptographic algorithms? I'll take that one. In brief, no, we're not a hardware – we don't focus on hardware acceleration. We focus on verifying hardware security pre-Silicon – I mean, yeah, pre-Silicon before tape out. So it's a little bit different area than post-Quantum Cryptographic Algorithm acceleration okay excellent um this next question this is interesting who is actually using this today i'll take a little bit of this uh peeking cover off he's got other examples but i think one of the most recent one was arm uh in their press release a couple months ago talks about expanding their usage of the security solution to more of their their new designs uh and that that was really exciting for us that they've you know they've been a long-time partner for us additionally uh we had a release recently with the third party ip the 3pip program with the federal government along with our partners at bae and sci-fi where we've done some work on risk 5 designs and it was exciting to get the news out recently where we talked about how the evidence developed by the program is something that is you know something that can be used consistently in other government programs. We're seeing a lot of uptake in both the federal space and the commercial space, and I don't know. Pete may have some other examples. Honestly, you kind of highlighted the key customers, I think, and users of which have been very successful and implemented such solutions extensively. Yeah, I guess the thing I was looking at, I think there's a, you know, we've had a lot of success in the federal government, but often the automotive industry routine in the physical AI space and other customers coming in that are looking for security of their designs too. Excellent. Well, thank you, gentlemen. Thank you for an excellent presentation and Q&A, excuse me, to our audience. For more information related to today's webinar, you can visit any of the resource links in your resource folder. Within the next 24 hours, you will receive a personalized follow-up email with details and a link to today's presentation on demand. So thank you for attending today's webinar, Your Chip Works, Prove It is Secure, brought to you by EE Times and Art Terrace. This webinar is copyright 2026 by Aspen Core. The presentation materials are owned by or copyright by Art Terrice, and the individual speakers are solely responsible for their content and opinion. So on behalf of our guests, Art Terrance, I'm Colleen Heckman. Thank you for your time, and we hope you have a great day.