原创 Q & A: Side-channel attacks in the wireless realm

Note: As the Spring 2013 Embedded Systems Conference at DESIGN West is only weeks away, I recently had a chance to talk with Pankaj Rohatgi, technical director of hardware security solutions at Cryptography Research about one of the growing security problems in embedded systems: side channel attacks. He led two sessions at the recent RSA Conference on side channel attacks both from a key extraction perspective, looking at the NSA's Suite B cryptography; and from a developer's perspective—looking at proper and practical ways to test embedded devices to see if they are vulnerable to side channel attacks.

BC: Let's start from the beginning with a refresher on side channel attacks. What exactly are we talking about?
If you look at hardware devices which are doing security operations, most of the time they have a secret cryptographic key embedded in the hardware. When dealing with hardware or software, if you're using a secret cryptographic key, and if someone is able to monitor the power consumption of hardware or the emission coming from the device, you are able to recover the key using a set of techniques known as side channel attacks.

BC: Where is the side channel problem? Is it mostly mobile devices? Is it in all connected devices? Wireless devices?
The problem is universal with any connected device, but the implication of where attackers would focus on depends on the value being protected. So today we are seeing a lot of interest in the smart power grid space.

Traditionally, a lot of the concern has been in the financial industry, but today it is in the smart grid. There's a lot of interest there because at the substation level, some of the equipment can be quite damaging if someone was to attack it, as it is out there in the field and relatively open.

Additionally, we are seeing an interest in smart phones. At last year's RSA, we showed that if someone is within ten feet of a phone, it's possible to pick out a cryptographic operation that a phone might be doing.

BC: And what kinds of risks, in the case of smart phones for instance, do you see developing?
Smart phones present two major issues: one is transactions, while the other is content management.

In the case of content, studios are considering using smart phones for that kind of content. In fact, right now there is a lot of pressure on smart phone manufacturers to provide digital rights management on the smart phones they are producing because of this content issue.

With regard to transactions, much of the problem is that security techniques on these phones is the same as secure system design. When you hear people talking about the secure part of the phone and insecure part of the phone, they are talking about software. However, the issue with smart phones is that we're not just talking about software—we're dealing with a mobile phone. Possession of the phone itself creates issues, as an individual must place the phone next to a reader in order to make a payment, or theoretically open a secure door by putting the phone next to a reader.

BC: With regards to your presentations at RSA, you discussed how even mathematically secure cryptography could be infiltrated using side channel attacks. Could you provide some background on that session and how it applies to these threat vectors?
The first session involves the extraction of keys from devices executing Suite B algorithms. Suite B algorithms are used by the National Security Agency (NSA) for instances when they have to collaborate with other coalition partners like the Department of Defense, or if they are called in and need to work with non-government organisations. These algorithms were made public and authorised to protect classified, sensitive or top secret information.

So the first talk we are going to be presenting at the conference looks at what happens when you implement these algorithms in software and hardware—and how easy it can be for an attacker to extract the key just by observing the emissions of the device. We will show an example of each in the talk, using different algorithms and devices.

If you look at the algorithms from a mathematical perspective, they're highly secured. They've been designed to resist attack where the attacker can only see the input of the algorithm and the output. However, in real life what happens is you get a lot more information than just the input and the output.

There are a lot of side channels you can get. You can time how much it takes to do the operation, which is valuable extra information. You can see how the power of the consumption of your FPGA varies as it's computing the algorithm. You can see what emissions are coming out. This gives you extra information about the secret keys that are buried in the hardware. If the device does the operation repeatedly, and uses the key for a few hundred operations, it's possible to get enough information to recover that key.

BC: So the first session was essentially about demonstrating the problems of supposedly secure cryptography with regards to side channel attacks. What is the take-away for electrical engineers?
Yes. It's demonstrating the problems with side channels and kind of making the point that just because the algorithm is left for use by the NSA, it doesn't mean that the implementation is any stronger in terms of these attacks. If you go to the web and look for military grade encryption, you will find lots and lots of it. There are many products where people think that if it's good enough for the government, then the algorithm is safe for cryptographic purposes and therefore secure.

Now everyone wants to adopt Suite B because they are algorithms you can trust. Another place Suite B algorithms are used is in ID cards. It could be a driver's licence or a passport. So far, that's what happened, as people have implemented these algorithms and actually the security is not much higher, because you can have side channel vulnerabilities that can easily uncover these keys.

BC: That's a good segue into your second session, which deals with how to practically and effectively test for side channel leakage.
That's right. When we look around, we see that people recognise the problem of side channel. They see that smart phones have side channel problems, smart grid components have side channel problems, and hardware security modules have side channel problems. As a result, people are scrambling to put standards and requirements in place to do that.

For example, it is in the new draft version of their standards that are applied to all cryptographic modules and side channel requirements are being put in there. We have many customers who come to us, because we are seen as leaders in the side channel space, and they're saying, "What kind of requirements or qualification testing should we put in place for our suppliers? We recognise there is a problem and we want to know how they should be tested."

If you look at what the state of the art testing is, it is probably what general security testing was many years ago. It is done for common criteria, and financial devices. It follows more of a corrective methodology.

BC: What was that?
Corrective methodology. Where basically you give a device to someone and they try to break it, they try all different attacks on it. If they break the key, then that means it is insecure. However, if that's the way the product is going to be tested, it's going to be very costly and difficult to do.

For example, I'm a company who wants to create a side channel resistance product. How do I do that? I need to find a prototype. I'm going to need experts who know all about side channel and are going to try all kinds of attacks on it to see if the key can be extracted. Some people can afford that, but for most people it is too costly and time consuming. You can out-grow a team of experts on this topic so easily.

This is true in the security space as well. Previously, people wondered how to test security, and they would rely on hackers. The hackers try to break it and if they do, it is insecure, if they don't, then that's okay. And that's how it used to be. This is pretty much where we are today with side channel testing. It's hard to create a regime of testing that is cost effective or manufactured to find out what the problems are. We cannot be hiding these attackers.

What we are talking about in the second presentation is a methodology that we are proposing that will change the way testing is done for side channel. It will be more efficient, cost effective, and we are hoping it is equally as good as penetration testing. The idea is more for of an evaluation technique, where we have test vectors that we supply to your device and we look for specific leakage. We are not trying to attack and extract keys. We are only looking for a leakage.

Today when you look at security testing, they don't try to break them, they run some test vectors to see if there is a potential problem that can lead to attacks later on, and that is what we are doing with side channel attacks. We do some measurements and tests to see leakage. And that's all we really care about. We don't care about the keys. If you just want to qualify a device, you don't need to take that extra test.

BC: So theoretically, these tests could be done by non-experts?
Yes, that means the test can be done by someone who's not an expert. Someone with an electrical engineering degree who can take some measurements, can run the rest. It doesn't take very long—maybe a few hours—then you get the results. At that point, the designer can look at the results and fix the problem.

It is quick feedback on the problem and it doesn't require you to be an expert. That's our contribution to the community. We are proposing these tests and also asking others to contribute. We want a set of tests that can cover the various types of leakages that can result in problems. I think this is elevating the whole testing effort on the side channel attacks to a level that can be done at the test stage of the design. That's what we are talking about in the second presentation.

BC: And is this something to be applied broadly? Mobile developers? Embedded developers? They don't have to have someone on the team who is a crypto or anything? Just a specialist or someone who understands this set of procedures?
Yes. Indeed. And that's the purpose. The people who are developers or even testing labs, for example, if you look at Lift, they have this set of cryptographic modules. So it's also very checklist-based. They didn't know how to handle side channel so now that we came up with this approach, it was very well received by Lift and their programmers.

We were asked to present to their lab managers, so they could see that this is something they could do. Some of the crypto evaluations were easier, which are definitely quicker and cheaper. They're interested in this. We also see a lot of interest in the communities like smart phones. They are looking for quick ways to qualify their devices, or even internally test them for development.

BC: So because this doesn't involve any special software, it could be applied to almost any platform no matter how sophisticated or not sophisticated. I was thinking that since many of these systems get going with dozens of these devices in a home or in an building environment and they don't have a lot of resources. So you need to make sure that they are secure. And this would be a procedure that would allow you to fix this problem.
That's correct. We would expect or want someone to be a good double "E," though.