Security Risks Grow Worse

Semiconductor Engineering sat down to discuss security issues for connected devices with Marc Canel, vice president of security at ARM; Paul Kocher, president and chief scientist for the Cryptography Research division of Rambus; Michael Poitner, global segment marketing manager at NXP; Felix Baum, hypervisor product manager in the Embedded Software Division at Mentor Graphics; and Bernard Murphy, chief technology officer at Atrenta. What follows are excerpts of that conversation.

SE: How big a role does training play in security?

Murphy: There’s a story about traffic lights that support encryption, but it’s not enabled or they have the same key. The same is true of smart meters. They support encryption, but it’s not enabled. It’s a cost issue. If you have to train the engineer to mess with all this complexity, that adds to your cost.

SE: We typically deal with this in standards, but those standards usually are promulgated in very narrow markets. New ones may be connected to those markets over time. How do we deal with that?

Kocher: In the early days of aviation the airlines got together and asked the government to regulate safety. People were dying and it was keeping the public away from airplanes, so even if an airline was doing a good job these issues made everyone look bad. There is a possibility that someday we’ll end up with connected devices being highly regulated. I dread that, but I don’t see any other long-term solution because marketing messages are completely uncorrelated to technical reality. Right now people claim security on things that aren’t secure.

Baum: I hope we won’t end up there, too. I used to work in mil/aero. One of the things that hopefully will happen is there will be a crisis or two that won’t be big enough to get government attention, but there will be enough attention in the industry for people to look at adjoining markets. So they might look at mobile payments and entertainment and say, ‘Those guys have a standard. Maybe we can massage that standard and apply it to our industry and stand behind it.’

Canel: One of the big issues for service providers is they will be pushing requirements on technology. That’s going to be certification. It will be the requirement they will have to have to manage liability. Service providers need to be able to insure their business operations. They need to understand their liability. On an industry-by-industry basis, we will see certifications emerge. There will be some standard that will be based on the product that requires certification. For service providers to make money, they need to understand the cost and risk of their business. Therefore, they need to certify things.

Kocher: There are two versions of certification and liability. There are companies that will check a box, and they will look for the cheapest way to get a product out the door. They want the least intrusive, least comprehensive evaluation possible. And then there are companies that have been hacked that want to understand their risk and mitigate it. If you get check boxes without teeth behind the consequences, it doesn’t help. If you can get liability and skin in the game for companies that control the risk, it would be transformative.

Canel: It’s the latter. Major service providers who take care of tens of millions of customers won’t be able to get by just with check-box requirements.

Poitner: We have a lot of experience with those certification programs. There are a lot of them out there. But even in the payment industry, you have a couple of big retail chains that were supposed to comply with it. They had service providers with holes in their systems, so their data got out. In the smart grid space in some countries, standards are strictly enforced. But there are a lot of industries and even countries with gateways where it isn’t strictly enforced.

Baum: There are certifications today where it is process-driven. You can show the requirements and the testing and how it went purely from a process standpoint. For security it is very different. When you ship your device, you run the certification, attach the device, run software, boot it up, certify it will all the paperwork and then you’re done. That doesn’t work for security.

Kocher: Or you’re done and you don’t fix the bugs because it would mean violating your certification.

Baum: In aerospace, once you build something and launch it, to go and change it is impossible. Changing everything would be a nightmare. And you can’t just re-test one piece.

SE: Are the vendors talking to each other about security, or is it just the criminals?

Murphy: A lot of people are going to post and attend conferences.

Kocher: It’s not just the conferences. It’s the e-mails and conversations behind them. Conversations are happening.

Poitner: A lot of the service providers are getting more involved in security architectures.

SE: So who’s winning? Is it the good guys or the bad guys?

Kocher: From the standpoint of the value created by this industry, the attacks are staying relatively constant. It’s just that the amount of value being created is going up and the value of the attacks is going up, too.

Murphy: With security you will always pull ahead and fall behind. But how do you implement security mechanisms that more automatically deal with the evolution of the threat?

Kocher: We have mathematical constructions. The triple DES (data encryption standard) cypher developed in the 1970s is still strong today. The basic mathematics in cryptography, if we can match the mathematical strength, should be able to last 50 to 100 years.

Murphy: One thing to look at is whether you can consider methods that assume something will fail or an attack will succeed in places. We think of security as an atomic thing—how do you make a piece of hardware as secure as possible. You really have to think about a whole system. If a part of a system fails, how do you prevent the whole system from failing? Can you contain a failure in a sub-part of that system? That’s something we need to think about, and it’s a way of looking at evolving threats. You may not know what caused a failure, but you should be able to contain it.

Canel: When you have the right mathematical systems in place—the correct encryption engines—then you know that if you have a good overall system architecture, you are setting up the foundation for something that is robust. But you have to have good encryption engines with protection mechanisms for the data, the end point, and the server.

Kocher: There are a lot of containment solutions that are beginning to appear. NXP chips are a good example. What happens in your processor is going to be independent of another chip, so it’s going to be decoupled even if the processor fails. The CryptoManager cores we build function within a chip as a separate security perimeter. The Trust Zone in ARM’s processors is another example of a containment strategy. There are different tradeoffs between cost and complexity and how many compartments you have and how they’re separated from each other and what your memory efficiency is, but certainly that’s a way to deal with some subsets of a problem—although certainly not all of them.

Poitner: You mentioned the cryptography and the mathematics behind it. If that’s really strong, then the attacks will not be targeting the mathematics because that’s proven. But they may attack other things like where the key is stored. It’s not usually the cryptography that fails. It’s the other things.

Baum: And it doesn’t really matter how good your encryption engine is or how robust your SoC is, or how good the underlying architecture is. With the IoT we’re talking about the consumer market, and no matter how good your SoC is, if you don’t enable the security it doesn’t matter. If you put a car key on top of your car and walk away, there’s a good chance it will get stolen.

SE: Security is being done in pieces like all electronics, where it’s a divide-and-conquer approach. The problem is those pieces have to work together. Is there any progress in making things work together?

Canel: That’s why Apple is so successful and why service providers love to work with them. It’s a closed ecosystem with a well-defined security model and they know what they’re dealing with. It’s a large ecosystem and it’s an affluent one on top of that. In the rest of the industry we’re dealing with fragmentation. We need to find those leading service providers who can mandate security.

Kocher: But even if you look at Google and Android, they’ve struggled to keep security patches fresh. If Google has trouble, how are we going to solve this? It may benefit Apple in the short term, but in the long term the industry is going to rally around this problem and find solutions.

Poitner: The service providers are in the middle of this.

Baum: From a software perspective, what we see is that people don’t just grab an RTOS and use it. They want this and that and that. And we have to enable it, and we build in hypervisors because we want separation. So if you’re driving a car and your kid is in the back seat playing Angry Birds and he downloads a patch that breaks it, you don’t want to have that affect the instrument cluster. There is the ability for a single company or two to solve this. You can break it, but the damage is minimal.

Canel: One problem with the electronics supply chain is that the liability is with the OEM, not the suppliers. All the devices have the ability to download applications, but the OEM is not going to take liability for applications downloaded in the device. How do you manage all of that when you try to offer high-value services?

Murphy: This is where metrics come in. Wouldn’t it be wonderful if you could define how secure something is and put a set of numbers of that? There has been a lot of interest in how to define security metrics.

Kocher: One other problem with the resilient approach, aside from just economics, is that the most frightening threats involve people with modest resources who hire someone like a college undergraduate to find a bug. If the attack unfolds very slowly you can deal with it. If it happens quickly, you have to respond with stronger defenses. We need to focus on defenses that are more reliable and durable. We already have mathematical defenses. Turning that into something that can stand up to a level of threat gets us part of the way there. Turning off an application that is behaving badly but doesn’t damage the hardware—that’s something you can handle through risk management later.