Eric Sivertson, VP of Security Business, Lattice
Eric Sivertson recently discussed field-programmable gate arrays, or FPGAs, on The Robot Report Podcast, Episode 260.
The vice president of the security business at Lattice Semiconductor discussed how FPGAs are a critical component in security for robots. The conversation examined some of the security risk vectors and how FPGAs can help to lock down the system.
Where we are with physical AI and robotics today?
Sivertson: This is a good question, and I like to use humanoids as the standard-bearer of this intersection of AI and the physical world. You can look at robot [arms] too, but humanoids really highlight this situation. I like to say that you can’t trust a humanoid if it’s not both safe and secure.
This is really the big paradigm shift that’s about to hit this industry. If you look at robots today, a lot of robots are in a cage, or they’re locked to the floor. So they have limited mobility.
When you get to a humanoid, some robots fall in this category too. You can think of a Tesla as really a rolling robot. So when you think about these intersections of what I would call cyber with the physical world, another term that’s used is “cyber-physical systems.” The humanoid is an easy one for people to wrap their heads around because it really is this intersection of AI and the physical world.
And that’s why I say it needs to be both safe and secure. In other words, if it follows the typical safety paradigm that it does certain functions within its limits, that’s good. You have to have that.
We want the humanoid to be able to detect the force properly and have a way to stop when it might be going to bump into a human, and have some guardrails to keep it from doing bad behavior.
But because it’s typically run by multiple different components — some are software-based, some are FPGAs or hardware-based, or ASICs, particularly those that are programmable — now the security part kicks in because it’s very easy for bad guys now to come in and attack that software structure.
So you’ve built all the safety parameters, but if someone can go in now and adjust the data set that those safety parameters are using to make decisions, it’s not really safe anymore because this now could be used for bad purposes. So I think when you have a cyberattack on infrastructure today, everyone thinks about my system going down, I lose my ransomware, I lose my data, I get locked out. I mean, that’s not a good thing.
But imagine now there are a thousand humanoids working in a particular area, and they all get hacked, and now they start doing really bad behavior. And they’re moving 50- to 100-kg things around, and now they turn into weapons.
So I think the intersection of AI with the physical is gonna drive this safe and secure concept. Whereas traditionally, we’ve had secure systems and safe systems. But not everyone has really put those two together. And I think this new paradigm we’re going to go into is going to force that.
What are some of the issues that hardware developers might need to consider when it comes to securing communications in today’s world?
Sivertson: I think a couple of key security features need to happen. Attestation is a big one. Am I authorized?
Am I what I think the system looks out and says, “Hey, is this PLC, or is this sensor the one I think it is?” So you need to be able to attest that these are trusted entities, and it goes the other direction as well.
That sensor needs to know: “Am I talking to this manufacturer’s true cloud?” or, “Wait a minute, I don’t think this is who I think it is. I can’t talk to them.”
And then the next thing is, are both ends running the right stuff? So this is where you get into digital signatures, and this is where [the question] is: “Is this the right authenticated code?”
So do I know who I’m talking to? And think of it as a human process, right?
You go in, you’re gonna get on an airplane, and a guy walks in, and he doesn’t look like a pilot. He says, “I’m your pilot,” and you’re like, “Wait a minute, there’s no way that guy’s the pilot for this plane.” It’s the same concept. But let’s say, okay, now I know it’s the pilot; then the next issue you’ve got to know is whether all the systems are properly configured.
And so I need authentication. And if you notice a pilot, he’ll go through a checklist. You sit there at the gate for a long time while they’re going through a whole bunch of checklists. They’re really authenticating the aircraft to make sure everything on the aircraft is set to perform properly.
So you need to do that process, and then once you have all that, now you can start to run. And the next layer in protecting the run is that we could actually encrypt that data.
It’s hard to intercept that data or spoof that data and give bad input to the system. So we need to know the entities that are running the system or that the stuff it’s running is what should be there.
And then once it’s running, we have confidence that it’s running properly and is safe and secure. So those are the concepts that you want to look at. And the beauty of the FPGA is that it can fit all of these pieces into the system.
Where FPGAs can help
What’s the role, from an architecture perspective, of deploying FPGAs across the various subcomponents of a system like a humanoid robot?
Sivertson: So in particular to Lattice, we call them our root-of-trust — ROT — products. And so in each of our major FPGA families, we have ROT components. And one of the key differentiators from most of our competitors, we have the non-volatile memory contained within the chip, and we have it in such a way that we can boot from two different flash images, and we can lock those flash images.
So effectively, once you have that chip leave your factory, you can lock down its configuration. It’s reprogrammable, but you can lock it so it can’t be corrupted. And then, because we have two of these flashes, once you have a known-good, working, secure, safe image. It can supervise the update of the other image. And so it’s very difficult to attack that.
And now back to my cyber-resilience piece. Most of the main processors or the AI engines do not have internal flash. It’s very hard to do that in these very small nanometer; you don’t have a 3-nm flash today, right? But all the GPUs and all the CPUs that are the highest capacity are moving into those 2- and 3-nm geometries. So it’s impossible for them to get flash into that same system.
Look at the memory wars that are happening. Memory is considered a commodity, whereas the GPUs, the CPUs, and the MCUs are not. They’re distinguished by what their capabilities are. It’s why NVIDIA is what it is today. It’s not a commodity product.
They all have to go and get their instructions because it’s an instruction set architecture. They have to go get that software to run from an external non-volatile memory, typically flash, but it could come from the cloud as a system download. But that process is extremely vulnerable to attack. That is the place you can hit in a big, big way. So the GPU, MCU, CPU can securely boot itself, right? It can make sure I’m not gonna run code that hasn’t been signed for me to run.
But the bad guy is smart. He’s like, “I don’t care about that. Let’s just not let it run. Let’s make sure that thing doesn’t start.” That’s your classic ransomware. That’s your denial of service. And you don’t want denial of service when your car’s driving down the road and is gonna automatically turn, and it keeps going off a cliff, right? So, the whole idea with cyber resilience, and why, particularly, Lattice FPGAs can be very helpful to these systems. We can stop that from happening.
So we can be monitoring, like I was saying earlier, that the GPU is reading its instructions. And if we see any behavioral issue where a problem is occurring, we can even have a channel to that GPU because it can boot securely. It can tell us, “Hey, I’m in a booted state, but I can’t run because I’m not getting authenticated code anymore.” We can now take action thanks to our FPGAs.
And go recover the image for that GPU and get it back online. So even though that GPU is much more sophisticated than our FPGAs and even a lot more expensive, and some of our parts are sub-10, you can use our sub-10 parts to guarantee that a $100 or $1,000 part is always going to function and do what you want it to.
Editor’s note: This conversation was edited for clarity and readability.
Register now and save on your pass to RoboBusiness 2026
Tell Us What You Think!