Side-Channel Attacks Make Devices Vulnerable

The number and type of attack vectors are increasing as more of the world becomes connected and vulnerable to hackers.

popularity

As the world begins to take security more seriously, it becomes evident that a device is only as secure as its weakest component. No device can be made secure by protecting against a single kind of attack.

Hypervisors add a layer of separation between tasks making sure that one task cannot steal secrets from another. Protection of the JTAG port is necessary to prevent access underneath the hypervisor layer and get to the bare metal of the system. Encryption and root of trust can add additional layers of protection. But even then, the system may not be secure.

Every electronic device emits information about what it is doing, and that information can be used to pry open its defenses. These types of attack are generally referred to as side-channel attacks, and they look at characteristics such as power, radiation or timing to infer what the system is doing.

“The industry is waking up to security and there are constantly articles in the news about some hack, breach or network problems related to malicious attacks,” says Angela Raucher, product line manager for ARC EM processors at Synopsys. “It is a focus for anyone developing SoCs right now because they have learned that just adding security in the network or in the device or the platform is not good enough. You have to start at the SoC level or there will continue to be vulnerabilities in the system.”

Michael Chen, director of early stage programs in the System Level Engineering division of Mentor Graphics, explains that “people are doing a fairly simply power or differential power analysis. There are lots of side channels, not just power. It is any way to extract information from a device. This is usually done using some sort of microwave power reading antenna and is done post silicon.”

Here are some examples:

Simple Power Analysis (SPA). This is simply looking at the power consumed by a device while it is doing a security sensitive operation. The power consumed by a processor varies depending upon the instruction being performed and loops and repeated operations that often happen when performing encryption or decryption, can be detected. “With simple power analysis, you can see the differences within a single trace on an oscilloscope,” says Chen.

Differential Power Analysis (DPA). These types of hack require not only scanning the data stream but the use of statistical analysis methods to obtain the necessary data. The statistical functions perform noise filtering. DPA identifies correlated regions in a device’s power consumption and requires little or no information about the target implementation. “With differential power analysis, you are not looking at a single trace, you are essentially doing big data analysis, a type of analysis that can detect even a very minor difference in the trace (so small that in theory you shouldn’t be able to see it),” adds Chen. “You probably cannot hide it completely.”

Differential Fault Analysis (DFA). While not the focus of this article, encryption keys can be obtained by subjecting the device to faults, such as by changing the voltage, changing the frequency of operation, or any other form of non-typical usage.

This is not trivial. “Hackers will spend a lot of time trying to get specific data and will work through the security methods,” adds Raucher. “They are not just breaking a lock and gaining access to a house. With side channel they will spend days, weeks, or months analyzing devices to get the necessary information.”

“There are two problems,” Chen points out. “First, can I simulate it so that I could prevent this from happening and predict that I have a side channel issue? And second, what can I do during the design phase to mitigate it?”

Analysis
There are differing opinions about the ability and effectiveness of analysis. The problem is the accuracy of the information that is available using simple RTL analysis. “In the digital realm, you can perform analysis using toggle information, but that may not be accurate enough,” explains Chen. “The model would require good correlation between the toggles and the power that is dissipated, including leakage and that other things do not matter. This could give you enough information to discern any differences, but for differential power you will have to run thousands if not millions of cycles.”

That may not be a problem given that emulators and FPGA prototypes can run in the MHz range. “When running on an FPGA prototype or emulator you still have toggle information, but the implementations on both of those are different because synthesis for an ASIC is different from an emulator,” continues Chen. “Even then, it is arguable if the circuit would be exactly the same because of the optimizations used for both.”

The only way to be certain would be to run SPICE simulation, but for large circuits that is very time consuming. This effectively means that you cannot perform analysis on this problem before the chip has been fabricated. But that would be too late for mitigation, so designers have to be proactive.

Mitigation
“The goal is not to detect and counteract an attack while it’s happening,” says Muhammad Zakir, lead application engineer at Ansys. “Instead you have to design the chip to minimize physical effects that may be correlated to sensitive data transmission, preventing hackers from successfully exploiting these physical signatures.”

So how does one go about that? “You want to make the power signature independent of the activity and there are techniques that can be used but most cost power,” says Drew Wingard, chief technology officer at Sonics. “As a recovering bipolar designer, it is common to use differential signals. And if you send all of your signals that way, then you have signals flipping both ways and you tend not to see power spikes. Current becomes independent of activity. So you don’t have a differential power signature. But going back to bipolar would be extreme.”

But the techniques that are used do borrow from this notion. “Mitigation is somewhat obvious in that if you are worried about a particular trace emanating information, then you balance it,” explains Chen. “Make sure that the design and traces are laid out in a way so that they are the same and you don’t have transitions to 1 or 0 show up. You can do this by balancing it, by masking it, by adding additional noise so that you can’t see it.”

Consider AES, a very common encryption algorithm. “Hackers know the common methods for implementing AES and they can see the necessary patterns. They are able to detect that pattern and then expect when the key is being transferred,” says Raucher. “Then they can decode that using information from the physical implementation.”

This may appear to be a good reason to keep away from an open-source implementation, but it’s not that simple. “When there is a standard there are a limited number of ways in which it can be implemented, so it doesn’t really matter if it is open source,” adds Raucher. “At the end of the day there are a limited number of ways.”

Raucher outlines a few techniques that can help. “The first is uniform timing, so that data dependency on instructions and cycle count variations are eliminated. If you have an add function and a multiply function, then you can tell when they are being performed, which is often the case in key generation. We can add NOPs or other functions that do not impact the code so that the timing becomes uniform. That does have a performance impact. Another way is through timing and power randomization. Using a true random number generator, which most SoCs with security functions will need, the PRNG presents a random number. This can be used in the pipeline to insert branch-to-self instructions or NOPs such that power the signature is modified.”

A growing problem
Devices such as SmartCards and phones that are enabled for financial transactions have been aware of these problems for a long time and have taken many countermeasures. Most of them have dedicated crypto engines for doing the sensitive operations. But newly emerging markets, such as home automation and (IoT) are too cost sensitive and they are resorting to doing these functions on a generic processor. In addition, many of these devices are single function and that makes things worse. The more complex the device, the more obfuscation that comes for free.

“Nobody is paying attention to IoT and it is so full of holes that can easily be attacked,” says Chen. “However, it is not side-channel in the same way as stealing credit cards. “It is about enabling access. People are trying to make money so hard that they aren’t yet taking the time and attention necessary to prevent attacks.”

Raucher agrees. “In IoT you look at the number of devices on the network, and if they are connected as peers then the weakest link in the chain sets the level of vulnerability. Some people don’t even know what side-channel attacks are. If they are not building in protection, they become the weakest link and are the easy prey for the hackers. It depends on how much of a priority someone makes it. How secure do they need to be? Some hardware crypto engines have had this kind of functionality for some time, but now running software crypto makes it a priority for standard processors.”

To save area and energy, low-power processors are being used to run crypto functions such as AES and RSA. Markets such as IoT and mobile devices also have areas constraints. As data is being processed, it is important that they are protected and that you can safely perform these functions without leaking that type of information.

“That is why we created an ARC processor with SecureShield, which has some features added to prevent side-channel attacks,” adds Raucher. “The implementation of side-channel attack features can be turned on and off dynamically. You only use it when you are doing something sensitive. An operating system call would not need this capability compared to transmitting a secret key.”

Are you protected?
There are some metrics, such as Welch’s t-test, which can assess the chances that you have a possible leakage. “We could try and measure some of these things, but there may be some false negative and positives coming from these conventional methods,” says Chen. “It is not yet well enough understood. The bottom line is that it is really difficult to do it through simulation.”

Raucher says that her team does “a lot of simulation that show the power signatures and to check on the level of obfuscation that is injected. This can be balanced for each customer’s requirements in terms of security and performance. We also work with Riscure, a company that specializes in side-channel attacks. They have test equipment that can do the analysis and have been helping to review our implementation and validate that it had the required level of protection.”

One paper, entitled “A testing methodology for side­channel resistance validation”, authored by Gilbert Goodwill et al. of the Cryptography Research unit of Rambus, states that “the goal of a side-channel resistance validation program is to assess whether a cryptographic module utilizing side‐channel analysis countermeasures can provide resistance to these attacks commensurate with the desired security level.”

How difficult is this type of attack? They found that with an unprotected AES128 algorithm running on a generic processor, it was possible to crack the device with only 4 minutes of sample data collected and 10 minutes of analysis. When the same algorithm was implemented in an FPGA board, it increased the collection time to 50 minutes plus 12 minutes for analysis. Using that same board, but with a DPA-protected implementation, they were not able to crack it even after obtaining 3 hours of trace data. The statistics they collected also indicated that obtaining more traces would not enable them to crack the device.

This is one opportunity that embedded FPGAs are targeting. “An eFPGA not only adds flexibility with the programmability of the solution but also adds additional security because there is nothing going out of the chip,” says Yoan Dupret, business development manager for Menta. “You can also regularly change the algorithms in a random way. Plus, to break it, you now need to know both the bitstream content and the architecture of the eFPGA before you would be able to decode anything. This makes reverse engineering very difficult.”

Conclusion
There are still many devices that haven’t been hacked and the manufacturers of those devices probably still believe that their devices are unhackable. Lightbulbs never had to have security built into them, but they do now. Security didn’t matter until they become connected. Now they provide a way into your network.

“Almost everything is eventually hackable, but what we have done will add time to that effort,” says Raucher. “There are things that can be done at the chip level—not just in the processor—that will make things better, such as adding electromagnetic shielding and inputs on the scan chain. The processor is just one piece, but there are multiple levels of being able to offer protection.”

One can only hope that more companies take hacking seriously, but early indications are that it is still an afterthought.

Related Stories
Grappling With IoT Security
Updating connected devices creates a whole new challenge as threats continue to evolve
System Research Bits
Monitor side-channel signals for IoT device security
Rising Threats From Differential Power Analysis
How DPA has evolved and why it’s so dangerous to the IoE.
System Research Bits (Feb 9, 2016)
Hack-proof RFID chips



Leave a Reply


(Note: This name will be displayed publicly)