Determining What Really Needs To Be Secured In A Chip

Semiconductor Engineering sat down to discuss what’s needed to secure hardware and why many previous approaches have been unsuccessful, with Warren Savage, research scientist in the Applied Research Laboratory for Intelligence and Security at the University of Maryland; Neeraj Paliwal, vice president and general manager of Rambus Security; Luis Ancajas, marketing director for IoT security software solutions at Micron; and Doug Suerich, product evangelist at the Peer Group. What follows are excerpts of that conversation. To view part one of this discussion, click here and part 3 here.

SE: The best Trojans are the ones that will never actually be detected. How do we ferret them out?

Ancajas: Foundationally, the OEMs have code they want to make sure is secure so they cryptographically sign it. And you always can verify the firmware is real. But there’s also the ability to add code after the product has been deployed. That’s a problem that needs to be addressed because an employee can put a bug in there. But let’s say after the deployment that you need more hardware protection to prevent an authorized person from writing to a memory location that would be critical to the operation of the device. We rely on the semiconductor industry to add those hardware roots that protect code or data and prevent it from being changed without the correct authorization.

Paliwal: If you look to the seven properties of securing the device, the first one is who you trust to have access to the hardware, and the last property is failure reporting. But application processors are getting more much more complex. There are all sorts of variables, including speculative execution. If you can limit where the variables of security need to be and what assets need to be secured — basically limiting them to a small siloed co-processor — then you can limit how much damage a sleeper Trojan can do to your system. The second thing you need is to develop secure models with a root of trust. Security is only as good as the implementation in your SoC or ASIC. So we actually help our customers to deploy secure boot sequences. You can secure your usual security-conscious workflows and you can test for Trojans. The industry is working on that. You want to minimize where you store data, like in a siloed co-processor, and then check at the system level to minimize the damage that sleeper Trojans can cause to you system.

 
SE: Chips are getting much more complex, in part because we’ve run out of steam with Moore’s Law and in part because we are seeing so many new architectures with AI. Is it possible to secure all of those pieces? And is it even necessary?

Ancajas: The more complexity in systems, the more assets that need to be protected. It’s not necessarily about the number of chips, though. By virtue of having more clusters or functionality, you have more access to control. The focus needs to be around what are the assets in the system, zeroing in on that to reduce the complexity of how to protect an array of chips on a board. That’s really hard because it requires chip-to-chip communication, which involves different companies that make these chips using a protocol that needs to be seamless. It’s a tough challenge that nobody really wants to talk about.

Suerich: So what are you really trying to protect? If you’re trying to protect a chip, that’s impossible. It’s the same for a system. If you’re trying to protect a car from everybody turning left at the same time, we’re going to have that one chip that is going to send the left turn signal to some Trojan. Maybe you build those systems and those layers around it to have a fail-safe that fuses together everything else to stop that kind of bad behavior and monitor it. But it’s a large, complex system with many parts and many layers. Maybe one particular layer can be breached, but hopefully the combination of all of them will provide a chance to stop that bad behavior.

SE: Data in motion is much harder to protect than data at rest, and in an AI chip the whole idea is that you want data moving through at very high speeds. How do you protect that data?

Paliwal: One of the reasons we cannot ensure security for all operations that are happening, whether that’s compute or a simple map operation inside of AI, is the speed. Security still relies on a few techniques, such as obfuscation and encryption/decryption. One of our customers is developing a very large AI inferencing chip, where they have the host CPU and the co-processor inside, and they have a whole bunch of keys and high-throughput to the co-processor. We have a solution where we have a high-throughput, high-speed core, and we’re going to put 128 of them in parallel. So it is possible for one-time offloading/loading those kinds of feeds. However, when you talk about going to smaller and smaller MAC blocks in a heterogeneous architecture for AI, we don’t have margin in the design for extra memory, for example. So we really need to focus at a higher level to determine what you are trying to secure, because it would never be practical to secure every single compute operation or all matrix multiplication. It comes back to a siloed co-processor, but it has to be defined as a very small subset of the data moving through.

Savage: You have to look at the hierarchy of security. Some things need to be protected at a certain level, while other things need less protection. That’s part of system design. It could be done done at the chip level. So multiple chips, running certain functions, can be very secure. It can be a chip in a co-processor with a protected island. Anything can be protected at enough cost and power. But one of my concerns is that the expertise in security is not where it needs to be in semiconductors today. Big companies have strong security and expertise, but some of the smaller, more innovative companies don’t have the necessary expertise to be able to implement these things.

Ancajas: It’s not just that one particular group of people have knowledge in this space. It’s such a wide area, from the system level to the cloud to embedded, that it’s hard to find someone who has that overall knowledge and who could help optimize problems to predict problems. That’s what’s difficult about security. We have crypto experts, we have cybersecurity experts, but having a person who knows how to pull it all together is rare. We need to grow that expertise among security architects.

Savage: We asked a large military contractor about their security. They told us that they hand it off to one person and they get back a design in six months. But it all depends on one person, which is completely unscalable. That’s a problem for our industry.

Suerich: The military is one of the buyers sophisticated enough to even ask questions, and maybe they have the deep pockets to pay for it. But if you add $5,000 to the cost of a Tesla, there’s not much economic incentive to go ahead and implement that level of security. If you ask people if they want better security, they’ll say yes. But if you ask them to pay for it, their interest dries up pretty quickly.

SE: And that security extends all the way through the supply chain. So who’s responsible for that and who’s going to pay for it? Cost has been one of the big problems.

Ancajas: That’s going to continue to be the case. The way companies operate is they have their Tier 1s, which provide immediate revenue. Then they have their future expansions, and they have risk mitigation. Security always falls into risk mitigation. So until it becomes mandated and you can’t enter into the business without it, then you don’t really ask about security. But when you are mandated to have security, you try to do it as efficiently as you can to minimize costs and schedule.

Savage: I disagree slightly. The analogy I use is that in the 1950s, the medical community determined that fluoride helps to protect the enamel on your teeth. So they said, ‘Here are some pills that you can take to protect your teeth.’ Nobody took the pills. What the government did then was put it into the water. That’s the way security is going to evolve. There will be software and tools to do this, and it will be a natural part of the flow. But we’ve got to think of security like putting it into the water. You can dial up the level of security for a nuclear submarine, or dial it down for a Nest thermostat. That can be adjusted to fit different markets. But you still need security everywhere.

Ancajas: And at the end of the day, the mandate did work in this scenario. You got it into the water.

Paliwal: We are look looking at this with things like social media, and our demands for more privacy and security are going up. We need regulations if we are going to have as many connected devices as we have in our lives, and as many AI related outputs. There have to be some mandates coming from governments about basic levels of security. These are the things a bank knows not to do, but for a medical device there is no such level of security. So this goes back to regulations. We don’t want to throttle innovation, but we do need some basic regulations to have your keys encrypted ‘this much.’ Or maybe it’s, ‘These are the algorithms that are allowed and this is how you secure assets that are critical to the user.’ This is one way of changing that behavior.

Savage: That might just be the cost of playing in certain markets. You’re not going to get a pacemaker if it’s unsecured.