Article

Protecting against side channel attacks at the application layer

How changes to a device’s firmware can help protect a device against side channel attacks

It is common for embedded devices to leak information about their underlying operation through various side channels (changes power consumption, electromagnetic radiation, etc.). A skilled attacker may be able to use this information to extract sensitive information from the device. This series of articles examines how changes to the device’s firmware can help protect a device against such attacks; this may be useful in hardening devices where changes to the hardware are not possible.

Timing attacks

Overview

Timing attacks exploit a software vulnerability where a function’s execution time is dependent on the input conditions. The execution time for each input condition must be repeatable in order for this attack to succeed. Each instruction performed by the CPU is likely to have a unique power consumption fingerprint which makes it possible for an attacker to infer the operation of the device by precisely measuring the power consumption, Figure 1 shows an example of such a measurement. This article describes a typical timing attack and discusses how subtle changes to the software can help protect the device especially when modifying the hardware is impracticable.

In embedded systems there’s no substitute for implementing dedicated hardware to perform sensitive operations such as encryption. Hardware implementations of certain functionality can offer increased performance, security and energy efficiency however, it is not always feasible to implement a dedicated piece of hardware, either in the form of an FPGA or off the shelf IC, to perform these tasks.

Let’s use a hypothetical example of an embedded device which has already been deployed in the field. This device doesn’t need to perform any encryption so the decision was made to use a microcontroller without a dedicated encryption module in order to save on cost. However, the device does need to be accessed by engineers in order to perform maintenance, so a password protected serial interface is implemented. Later it is discovered that the engineer’s password can be deduced, one character at a time, by analysing the device’s power draw.

Can this be fixed easily? Does the product need to be recalled? Or, does the vendor just have to accept that their hardware is vulnerable and make improvements in the next hardware revision? Is all hope lost?

Analysing the current implementation

Before we look at the attack itself let’s examine the code which may be running on a device such as this, in particular we’ll focus on the code which checks the password.

If (strcmp(enteredPassword, engineersPassword) == 0) {
allowAdminAccess();
}

The default implementation of low level comparison functions commonly used in password checking, such as memcmp() and strcmp(), work by comparing each byte sequentially and returning when a mismatch is detected. The difference in execution time between a correct and an incorrect character can be observed by an attacker allowing them to infer the correct password by trying each character individually. Even an arbitrarily long and complex password could be deduced in a short period of time.

The attack

To attack a weak function such as this, one must obtain a graph of the device’s precise power consumption (while it performs the strcmp() function). The images below show a typical example of a power trace captured during a strcmp() operation. The traces are captured by sampling the device’s current draw four times faster than the device’s clock speed which results in four samples per clock cycle. The two images below show the difference in power consumption of two strcmp() functions. In the first example (Figure 1) the strings were completely different, i.e. there were no correct characters and the function returned a failure immediately. In the second example (Figure 2) the first two characters of each string were a match which meant the function executed slightly longer before returning with a failure.

graph1-sidechannel

Figure 1 – Power consumption measurement of a strcmp() function with 0 correct characters.

graph2-sidechannel

Figure 2 – Power consumption measurement of a strcmp() function with 2 correct characters.

In Figure 2 there are two extra, distinctive peaks where the two characters were matched (Highlighted by the green bars at around 160-220 samples). Moreover, the second half of both power traces are almost identical which means it would be feasible to automate the process of deducing the correct string.

Mitigations

In order to mitigate against this attack the developer would need to implement a custom string comparison function which does not leak any timing information. In this scenario there are some simple changes which will result in a more secure comparison function. In order to avoid leaking timing information, the function needs to execute for the same amount of time regardless of input. In order to achieve this, the function should check the entire string each time, regardless of whether the characters match or not, and contain a mechanism for detecting if a mismatch was detected.

char *enteredPass = enteredPassword;
char *engineerPass = storedEngineersPassword;
bool failed = 0;
for (i=0; i<MAX_PASSWORD_LENGTH; i++) {
if (
enteredPass[i] != engineerPass[i]){
failed = 1;
}
}

The code above successfully checks all the characters in the string and does not break early if a mismatch is found, however, there is a problem with this design.

At first glance, setting a flag in the case of a mismatch seems to be a valid solution but an attacker who is able to analyse the power trace is likely to spot this subtle change in code flow thereby negating any protection it offered. Any validity checks need to be performed outside of the comparison loop in order to effectively prevent this information leakage.

char *enteredPass = enteredPassword;
char *engineerPass = storedEngineerPassword;
char mismatch = 0;
for (i=0; i<MAX_PASSWORD_LENGTH; i++, enteredpass++, engineerpass++) {
mismatch |= *enteredPass ^ *engineerPass;
}
if (mismatch) {
lockOutUser();
} else {
openAdminSession();
}

The code above executes the same steps within the loop regardless of whether the characters match and the mismatch flag is set when the result of the XOR instruction is non-zero. No information about whether there was a character mismatch is leaked during the loop, at least not through differences in timing, because the XOR instruction takes the same amount of time to execute whether the result is a 0 or a 1. This means that an attacker can only tell whether their entire password guess was correct or not. The vendor can now generate a long, complex password to protect the engineer’s console safe in the knowledge that an attacker shouldn’t be able to gain access easily.

Summary

As demonstrated in this article, code which needs to perform sensitive operations, such as checking a password, may be vulnerable to side channel attacks if care is not taken when designing each function. In the above example it was the branch statements within the loop which were responsible to making this attack feasible. Changes to control flow are often visible through side channels which means that ‘if’ and ‘switch’ statements could potentially leak sensitive information if not used correctly.

This type of bug can be discovered during a code review of the firmware intended for the device. Having the code reviewed during product development means that code vulnerabilities, including potential timing attacks, can be mitigated early in the design phase before the final product is deployed.

 

 

Accreditations

As members of CHECK we are measured against high standards set by CESG for the services we provide to Her Majesty's Government.
We are certified in the ISO 9001 quality management system (QMS) in the UK, ensuring reliable delivery of our products and services.
We are certified to comply with ISO 14001 in the UK, an internationally accepted standard that outlines how to put an effective environmental management system in place.
MWR is certified to comply with ISO 27001 to help ensure our client information is managed securely.
As an Approved Scanning Vendor MWR are approved by PCI SSC to conduct external vulnerability scanning services to PCI DSS Requirement 11.2.2.
We are members of the Council of Registered Ethical Security Testers (CREST), an organisation serving the needs of the information security sector.
MWR is a supplier to the Crown Commercial Service (CCS), which provides commercial and procurement services to the UK public sector.
MWR is a Qualified Security Assessor, meaning we have been qualified by PCI to validate other organisation's adherence to PCI DSS.