Side-channel Attacks

This post will give you an introduction to Side-channel Attacks by looking at some common vulnerabilities and concrete attacks that try to exploit those.
But first: What actually is a Side-channel attack in general?

A Side-channel Attack is an attack on a system, most probably a “secure” system, that does extract secret data by using special properties of the implementation rather that direct access by brute-force or theoretical weaknesses.
You often try to derive the information by looking at properties that are maybe only indirectly coupled to the data. Most of the time those properties are of a physical nature, like time, magentic fields or accoustic waves but sometimes more abstract events like interrupts or traps of a CPU or MMU can be used.

Timing Attacks

This is the most often exploited Side-channel and there are many attacks that are trying to gain information by the execution time of a program.

A classical example for this type of attack is the exploitation of the non-constant execution time of most strcmp, strncmp or memcmp implementations.
A typical implementation of strcmp could look like this:

int strcmp(const char* s1, const char* s2){
    while(*s1 && (*s1++ == *s2++));

    return *(const unsigned char*)s2-*(const unsigned char*)s2;
}

Did you notice that the method ends the loop as soon as the first character missmatch happens?

If you use one of those functions to check the equality of a secret data input, for example to check that the entered password matches the one from the database, an attacker could easily loop over any valid char and pass it to your function. If the chars do not match, the loop finishes in the first iteration. If the char matches however, the loop will have a second iteration, resulting in a slightly increased execution time.

Of course this is a slightly constructed case which would need clear text password saving and the above, totally unoptimized strcmp implementation. A more realistic implementation would, for example, compare a whole page at a time if possible. However, it still shows the basic principle of a timing attack.

Elecro-Magnetic Attacks

The basic idea of this type of attack is to use an antenna to receive the electro magnetic radiations from another device. The emissions maybe aren’t even generated by an explicit RF frontend in the attacked device but are rather the emissions from the fast rising and falling edges of modern high speed busses. Remember Fourier? Note that an ideal square wave has an infinite number of harmonics at every integer multiple of the main frequency. Thats a broad band of emissions we can pick up. Just look for a harmonic in a spot of the spectrum where the noise floor is low enough so you get a nice SNR.

A typical example for this attack is called “Van Eck-Phreaking”, named after Wim van Eck who first had the Idea for this vulnerability. This attack does use the magnetic field that is emitted by the deflection coils of CRTs to reconstruct the image that is currently displayed by the monitor. Since the electro magnetic field can relatively easy pass through walls, you can easily pick up the radiation from another, close by room that is out of sight.

Since CRTs are not in broad use anymore on could think this attack is obsolete. However, already in 2006 a group of security researchers of the Computer Laboratory at Cambridge have demonstrated a variant of this attack where they were able to pick up the emissions of a TFT monitor 25 meters away and reconstruct the signal.

Acoustic Crypto-analysis

Just like the EM emissions used for the electro magnetic attacks, all electric devices radiate information in another spectrum as well; in form of acoustic waves. However, while electro magnetic radiation can be avoided relatively easy using different metal shields, acoustic radiation is much harder to block.

You may ask yourself where all these acoustic waves come from. The answer is: lots of small speakers inside every electronic device. No, really. Every device you use throughout the day has lots of inductors and capacitors inside. They are used for example in switch-mode power supplies to convert the battery voltage of your mobile to a usable level for the CPU or to decouple switching noise from nearby data lines that would otherwise introduce ripple on those power lines. With other words, without them your phone would constantly crash or not work at all.
So, you need them, but why should they be speakers?

Do you know these little tweeters that are used in singing birthday cards? They use a physical effect called piezoelectricity. This effect causes certain materials to change their size if a voltage is applied to them. The tweeters have a piezoelectric crystal right under the metal cap that will then vibrate if you connect it to a signal source. The same effect works by the way the other way around to convert a physical impact into electricity. This is used in your electric lighter to create the spark to ignite the gas.

Nice to know, but what has this to do with capacitors? The most widely used type of capacitor is a ceramic capacitor. Ceramic capacitors are basically two electrodes in a electrolyte. This electrolyte, most of the time, is Barium Titanate (BaTiO3) which happens to be highly piezoelectric.

An inductor on the other hand, is nothing but a coil, and a coil will produce a magnetic field when current is flowing through it. So it is basically also an electro magnet. This magnetic field then again will have a physical effect on the coil itself, in other words it will shrink or grow. Now, if the current through the inductor changes, it will also change the magnetic field. If this change in current happens between, say 20Hz to 20kHz it will result in the inductor emitting a faint humming sound. If the change in current is now related to the current state of your security system, you can be in risk of having a vulnerability.

All of this may sound very abstract and theoretical, but there are many known attacks that use exactly this “leakage”. In my opinion the most impressive of these attacks is an attack on the GnuPG implementation to extract the private key using nothing but the radiated “sound” of a laptop. The attack was developed by Adi Shamir, Daniel Genkin and Eran Tromer in 2013.
They were able to perform this attack using the microphone of a simple mobile phone if they could get within 30cm of the laptop, or from up to 4m away when using a (maybe more suspiciously looking) parabolic microphone.

Differential-Fault Analysis

This kind of attack is very widely defined and basically always involves to modify the device in a way it was not intended to be modified and watch if the output somehow is affected by the change.

A really good example of a attack that uses differential-fault analysis was given by Dmitry Nedospasov (@nedos) on The Amp Hour #303. As a part of his PhD he extracted private keys out of smartcards by decapping the embedded ICs and using an focused ion beam to modify the silicon. The problem was that there was no way of directly extracting the saved private key. However, it was possible to set specific bits of the key in an intermediate stage during the encryption. Now it was simply a matter of encrypting the same message to get a deterministic result, but setting one bit at a time of the private key in the intermediate stage.

If the encryption then yielded another message than the encryption cycles before, the bit in the key was a 0. If the cycle yielded the same message, the bit already was a 1. Repeat this process, one bit at a time and you get the whole key, although you never had direct access to the key.

Walther Kriha told me another attack that uses this method. A password check in an old UNIX System would involve a strcmp between the entered and the correct password. The user of course had no access to the memory where the correct password was stored. However the strcmp method would use the exact string the user provided. In other words, the user had full control over the allocation of the string where the password was stored, and then strcmp worked on exactly that string. Now it was possible to allocate the string over a page boundary where the next page was not allocated. This would cause the MMU to trigger a SEGFAULT if and only if the strcmp tried to access the non allocated page. This then means all the letters in the string until the page boundary matched the correct password, because otherwise the strcmp would not have tried to access this page. This attack would work even if it is a constant-time implementation of strcmp as described in the first attack.

Data remanence

This type of attack works on data that is not securely deleted or somehow expected to “not be there anymore”©. The first thing that comes to mind when thinking of remanence is possibly the multi-wipe method of hard disks with random data to “securely” wipe them. However, this technique is not that big of a risk with modern hard drives.

However there are still some attacks that rely on data remanence. For example there is an attack called FROST that allowed the extraction of the key used for the whole disk encryption feature in android phones. The attack involved freezing the phone under attack while the phone was restarted into a special recovery ROM. Normally the RAM that holds the keys is a volatile memory that looses its content during the power cycle, however due to the lowered temperature of the die, the data remains in the cells and can then be searched for the keys by the recovery ROM.
The attack however was only possible with the 4.0 Version of Android.

Conclusion

The attacks that are featured in this article are only a small excerpt of all the possibilities your software or hardware may be vulnerable to.

There are certain standards for hardware like TEMPEST, an NSA specification and NATO certification for devices that do not leak information in the form of EM-, RF- or audible emisions.

For software there are several coding guidlines, like the Coding Rules from cryptocoding.net.

Although it is a good idea to follow those rules when implementing a high security product, there is no way to ever make sure your product isn’t vulnerable to any form of a Side-channel Attack. Also don’t ever dare to implement a common cryptographic algorithm yourself, even if you may think you just have to follow those rules. Always prefer a well-aged implementation to your custom one. They probably learned it the hard way so you don’t have to.

So the only real conclusion can be that instead of prematurely changing all of your code base to use secure implementations of strcmp, malloc and other functions in the stdlib and coating you product with a big layer of lead to avid any radiation, you should design the architecture of your product in a way that even if an attacker gets access to your system in a way he should not be able to access it, the damage stays as small as possible.

Further Questions and Research Topics

  • Secure stdlib: A platform independent implementation with O(1) complexity or an implementation that does not early terminate for all algorithms to minimize surface area for timing attacks.
  • SDR – a new era of electro-magnetic attacks?: With more and more integration in the RF field and cheap, wide band SDR solutions readily available, EM-attacks are getting simpler and cheaper to perform.
  • Learning Side Channels: Use deep learning or other AI algorithms to find and exploit side channel attack vectors. Side Channel Attacks often need huge amounts of data on the input (a high resolution, multidimensional input vector, e.g. time, voltage, magnetic field, current, …) to find a simple output (e.g. a private key, an exploitable fault). AI algorithms often are used to solve exactly those problems.