Even without Java Card 3, there are many similarities between smart cards and web servers:
- They both receive requests from unknown origin and process them.
- They both manage potentially sensitive data that they need to protect.
Of course, the exact attacks are different. Cross-site scripting is not really a smart card threat, but the countermeasure (careful input validation) is also valid for smart card applications. We have seen that in our example, by providing a few simple examples of attacks that could be performed if input is not validated. Other quality measures, like Error Handling, are also very important to avoid information leakage.
Another common requirement is the Encryption of Sensitive Data. It is strongly recommended on both Web servers and smart cards, but the reasons are here very different:
- On Web servers, the idea is that an attacker may gain illegal access to the Web server and then access directly its files and/or databases. If the content is appropriately encrypted, it can be protected against such attacks.
- On smart cards, the idea is that the card can be the target of physical attacks, which may be used to disclose part of its contents. If these contents are encrypted, the disclosure of the card’s content will not lead to a disclosure of the assets.
This tutorial entry is about these smart-card specific attacks. If we take a simple image, a smart card is like a server that would sit in the attacker’s office. The attacker can try many things to attack it, like injecting illegal code, observing sensitive operations, or inducing faults in the program execution. Let’s see which attacks can actually be used.
We will now take a look at the most common smart card attacks, discuss briefly how they can be implemented, and then how applications can defend against them. The objective is here to provide general principles, without getting too much into implementation details.
We will consider three different kinds of attacks:
- Side-channel attacks. Based on the observation of a side-effect of the computation.
- Fault induction attacks. Based on the inductions of fault at the silicon level.
- Illegal code attacks. Based on the execution of illegal Java bytecode.
We will describe these attacks separately, but one needs to understand that a complete attack path, allowing an attacker to (for instance) disclose our user’s passwords, is quite likely to be a combination of several attacks.
A side-channel attack, or observation attack, consists in observing an unintended effect of a computation. There are many such effects, including the timing of the computation, the data exchanged on the I/O channels, the power consumption, the electromagnetic noise, or any other effect of the computation.
Such attacks are considered as non-invasive, because they are performed on a working smart card chip, and they usually do not require the destruction of the card((Some effects need to be observed directly on the chip, requiring the partial destruction of the card’s body, but the chip will remain functional.)).
Here are a few examples of such attacks:
- Timing attack on a PIN comparison. The attack consists in measuring the time taken by a PIN comparison in order to figure out whether or not the comparison succeeded.
- Simple Power Analysis (SPA) attack on RSA. This attack consists in analyzing consumption patterns during the binary exponentiation in a RSA computation. The basic idea is that (1) for a ‘0’ bit, the exponentiation is a simple shift, (2) for a ‘1’ bit, the exponentiation is a shift and an addition, and (3) we are able to tell the difference in the consumption graph.
- Differential Power Analysis (DPA) on DES. The idea is the same, with a slight difference. The operation is performed many times on various data and conditions (but with the same key). By correlating all the results, the key should stand out (it is the common point between all these computations.
Attacks are not the main focus of this blog. For more details, look for other sources. For instance, you can take a look at Erik Poll’s slides on observation attacks. For a more detailed look at DPA, check on Cryptography Research’s bibliography.
Fault induction attacks
A fault induction attack, or perturbation attack, consists in taking an action that will provoke a fault in the chip’s silicon, and hope that this silicon fault will translate in an effect that it exploitable at the level of the software. Fault can be induced using may different means, including glitching (a surge of power on one of the card’s I/O ports), light/laser exposure (shining a strong light/laser on a part of the chip), exposure to a radioactive source. In fact, since the effect of fault induction is due to a physical property of silicon atoms, anything that can excite silicon atoms will do the job.
The effects on fault induction attacks are quite varied, depending on the part of the chip attacked. Here are a few possible effects:
- Perturbing EEPROM read operations. The fault will lead to the reading of a false value, but the EEPROM content is unchanged.
- Perturbing EEPROM write operations. The fault will lead to the writing of a false value, and the EEPROM content will be changed.
- Memory dump. It is a variant of the EEPROM read attack, in which the parameter that is modified is the target address, which is replaced by a random value. By performing it many times, we obtain a memory dump (more realistically, a puzzle that needs to be pieced together).
- “Zapping” a portion of code. Some faults may lead to the non-execution of some parts of the code, skipping over a crucial operation.
- Changing the result of a test. It can be possible to force the result of a test, or to force the choice of the branch in a conditional branch. In both cases, the idea is to avoid a “bad” decision.
- Modifying the PC. This results in a more or less random jump somewhere else in the code. If it is not too random, it can be interesting.
- Differential Fault Analysis (DFA). By modifying a single bit in the key in some RSA computations, the computed result is false, and it does not exhibit the same mathematical properties as the result cmputed with the real keys. It then becomes possible to guess the value of the original key.
Fault induction attacks are difficult to setup, and difficult to reproduce (i.e., to exploit massively). They also depend greatly on the properties of the chip. It is therefore quite difficult to predict which effects are possible on which chip. This is made even more obvious by the fact that modern smart card chips include many countermeasures against fault induction:
- Shielding (active or not). This countermeasure consists in including a mesh of wires on top of the chip (active or not), that makes it difficult to access to the active parts of the chip (CPU, memory).
- Detectors. It is possible to detect glitches by monitoring the current on the I/O ports; it is also possible to detect excessive light. However, detectors are expensive, so their number must remain limited.
- Chip self-destruction. As a complement to detectors, a fast self-destruction mechanism can be used in order to reduce the amount of failed attempts that an attacker can afford.
The number of countermeasures is very important, because there are many requirements for a successful fault induction attack. The attacker must gain access to the appropriate part of the chip, she then needs to perform the attack itself without being detected, and while being correctly synchronized in order to obtain the expected effect.
Once again, I will redirect readers to other sources for details. Once again, Erik Poll’s slides are a great introduction.
For general papers on smart card attacks, you can take a look at Marc Witteman’s Advances in Smartcard Security, or reports from Cambridge’s Computer Lab (on Tamper-resistance design, or on Semi-invasive Attacks). Many more references are available.
You will note on these papers that many more attacks are available. I have not mentioned them here, either because the countermeasures can only be implemented in hardware, or because the countermeasures are the same as for the attacks I already described.
Logical attacks come with software. If you write software, you can write malicious software, which can be used to setup a logical attack. On smart cards that support Java Card, it is possible to load and run software; there are two main kinds of logical attacksthat apply to this context, and they are described below.
Even though smart cards contain a relatively small amount of software, and even though this software usually is throughly tested, evaluated, and certified, it cannot be totally exempt from bugs. For instance, an error in a loop test can be difficult to detect, and then lead to a buffer overflow vulnerability. And like on PCs, once a bug has been discovered, it may be possible to exploit it in order to perform illegal operations.
Such bugs are definitely hard to find. I have found some over years of evaluation, and few of them were exploitable. As far as I know, none of them was easily exploitable on a deployed card, because logical attacks need to be loaded before they can be exploited, and loading applications on a deployed card is not easy. However, these bugs, and the related logical attacks, have been used several times in attacks that combined physical and logical attacks. And then, they can be really helpful.
Another way to attack a Java Card logically is to use illegal bytecode (or ill-formed applications). Without disclosing any secret, I can cite the Joint Interpretation Library’s Application of Attack Potentials to Smart Cards, which describe these attacks as malicious applications that are made of illegal sequences of byte-code instructions or that do not have valid bytecode parameters. In terms of conequences, we can also cite the same document, which says that in the most favourable cases, the attacker can retrieve information (e.g. a dump of memory), execute functions that usually require specific privileges or even switch to a context giving the full control over the card (JCRE context).
I will not provide more information on these attacks, which have not been much publicly described in the past (I must admit that the smart card industry is quite secretive). However, I will say that these attacks have been quite successful in the past, and that they still work today on the weakest platforms.
These comments conclude this entry on attacks. In the next entry, we will take a look at some simple countermeasures.