Q & A: Side-channel attacks in wirelessly connected devices.

March 09, 2013

Bernard Cole-March 09, 2013

Editor’s Note: With the Spring 2013 Embedded Systems Conference at DESIGN West 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 organizations. These algorithms were made public and authorized 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 license 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.

< Previous
Page 1 of 2
Next >

Loading comments...

Parts Search Datasheets.com

Sponsored Blogs