This thesis gives a wide overview of the problems of the Java Card technology regarding fault attacks. This post will not talk Java Card or Smart Card specification. It also not descript about their manufacturing or usages.
Including Faults
A Smart Card needs to protect against numerous things. Where a traditional computer needs secure protocols to ensure that no data is leaked, a Smart Card is a computer in a hostile environment. Similar to a safe, it needs to ensure that no secret data can be learned by for example putting an ear to the safe and listening what happens inside when you turn the lock. These so called “side channels” will not be discussed here.
Next to protocol attacks, Smart Cards add an extra dimension to protect: the computer needs to be physically safe from tampering. Again, comparing to a safe, it should not be possible to open the safe and look what’s inside the safe. It has to withstand a number of techniques which directly attack the processor or its memory. For example, by freezing the chip so that it retains its memory information and then reading memory somehow is something which normal PC’s not commonly have to protect against. Similarly, by placing a voltage meter on the memory bus, it might be possible to learn the value of private keys whilst they are moved in memory. A Smart Card, however, is at the mercy of its attacker if not properly protected.
However, it is also important that when an error occurs during the execution of the program, no program requirements are violated — i.e. no secret information is exposed, no permissions are unduly granted, etc. An attack requiring a fault to occur is called a fault attacks. Errors almost never occur naturally, as the programs are usually rigorously tested and hardware is expected to be “perfect”. Because of this, programs are often not protected against errors. Assuming however that such an error exists, it needs to be controlled: when there is a chance of one in a billion that a fault occurs, it might be infeasible for an attack to use the protocol until such an error occurs. For a Smart Card, however, the computer can be in the hands of the attacker. The attacker could of course try to inject a fault himself. A real-life example of this were “un-loopers”, in which Smart Cards which granted access to pay-TV channels were injected a fault so that a single branching statement was effected: instead of denying access, the branch giving access was chosen [Fault Attacks on RSA with CRT]. The following figure gives a simple view of the three considered layers of the Java Card enabled Smart Card:
An attack on any of these layers might potentially create a malfunctioning Smart Card. We here thus discuss each of the three layers.
Attacking the Application (Applet)
We first show how the security on the application level is handled. Any possible attacks due to interleaving should be handled by the JCRE. A quick glance at Application code shows that code generated for JavaCards goes through a number of steps:
1. Conversion .java to .class files
2. Conversion .class and .exp to .cap files and .exp files
3. Loading onto the card.
4. Execution on the card.
All of these depend on an amount of trust. The original files should be programmed correctly, else the compilation to class files leaves untrustworthy code. Similarly, the class files should remain corrects and unmodified when being converted to a cap file, and it should be exactly these files which are loaded onto the card. These should then be the same files which are executed. Throughout this process, the files should remain trusted. However, it (JavaCard Platform 2.2.1) is not required to have any verification on the.cap file during upload to assure it is of the proper format, as this could be too heavy a task for a SmartCard (or any other JavaCard enabled small device).
It is clear that there is a distinction between attacking the .class file, the .cap file, or when it is actually ’on-card’. We assume that attacks on a .class file are not very often to occur as these files are kept in a very trusted environment. Furthermore, we make a distinction between on-card attacks and off-card attacks: the one modifies the installed file, the others the .cap file. And, when modifying the application to actually produce a fault, the attack is not transient: any further use of the program continues to behave erroneously as the error persists. Yet when the ability is there to continually upload (correct) versions of the application, the problem can be circumvented by replacing the code. So the injected errors are not transient, but neither are they persistent.
Off-card Attacks
The .cap file format does not enforce any encryption. It is thus possible to modify directly. A Small modification are still possible, for example, a simple of code addition calculating “+” can be easily modified to multiple calculating “*” or “/”, or from the smaller value to larger. Such small modifications have no impact on the rest of the .cap file and can thus be done without any complication. It is noteworthy that modifying the .cap file requires very precise control. This means that the attack is harder to implement although, again, if it is possible to re-load the application, it becomes much easier as “trial and error” should do the trick.
On-card Attack
As it is unspecified where exactly the code on the card resides, this means that wanting to modify the code includes having to have an entire memory mapping of the card. At least knowledge of how data is stored in memory and knowing where the applications resides are mandatory. If this is possible then probably much better attacks are suitable. Yet it can be assumed that the same attacks can be mounted as were done in off-card attacks are similar; only the means are slightly different depending upon how the JCRE is implemented.
Attacking the JCRE
The Firewall
Assume a class A with a reference to class B. There’ll be a fault injected in the reference in A, so instead of pointing to B, it points to another instance of A. Now let there be an error in the reference to b1 such that it points to the value of the reference to b2 in a2, a2 now no lognger has an exact reference to b2. It is now possible to access and write to any value in the memory by have a1 defined the offset, and a2 write the data by doing a1-> ref_b = value fo the offset, and similarly, a2->ref_b = value for the value it should have.
This method was worked fine on some JRE’s. However, to work well on JCRE, it requires a lot of memory as the easiest way to ensure that such an exact fault occurs is by having the memory full of such structures, ensuring that there is a high chance of actually a faulty reference pointing to the value of the reference to another class. It can be used to modify the memory, thereby circumventing the firewall and writing into the memory of another applet.
Object Sharing
- AID impersonation: It is possible to create and upload an applet which has the exact same AID as an existing applet, thus making a mix-up of the two possible where the incorrect applet is used.
- Access to all Interface Methods of a Class: by having knowledge of the class, it is possible to typecast and receive access to all interface methods, even if they are not granted access to.
Especially AID impersonation could be used to impersonate applications, thereby possibly using a user-uploaded version of applications instead of those already installed. This then can break access to other applications as these use AID checks for access control.
Attacking the Smart Card Processor
Spike Attacks
By varying the power fed to the chip it is possible to disrupt a computation. In some cases, this can be enough to introduce a fault. A power spike can vary in some different variables: including height, shape, build up and power down, duration, etc. As a spike works by simply connecting to the power led to the chip, they do not need direct access to the chip and are non-invasive. Equipments requirements are totally dependent on the type of the spike to be generated, but are not necessarily expensive.
Glitch Attacks
Similar to spikes, it is sometimes possible to disturb the clock speed. For example, by doing an update cycle at double speed some instructions will be effected where others are not, so it is possible that old data is used as the new data hasn’t arrived yet. The introduced “glitch” can be used to influence conditional jumps; a shift register shifts twice instead of once, or not at all, etc. In general it is a wide class which can create a change in the program, and depending on that change an attack can be mounted. Similar to Spike Attacks, Glitch Attacks are non-invasive and do not require any expensive equipment.
Optical Attacks
By using focused light with specific wavelengths, it is possible to change the flipflops in a memory cell. By doing this, it is possible to change or modify the memory by using the photoelectric effect. These attacks require light to be able to reach the chip, and that any protective coating needs to be removed. However, as no contact is needed these attacks are generally seen as semi-invasive. As for equipment, in [Optical fault induction attacks] was shown that attacks can be done relatively cheaply with simple equipment, and also that they can be very precise, effecting only a single bit. However, they need not be precise at all.
Electromagnetic perturbation attacks (nhiễu điện từ)
By creating a strong electromagnetic source near memory the ions representing the states in the memory are moved around, and thereby the memory is disturbed. As this attack only requires to be near the processor, it need not be opened up as it can be done from outside. It is a non-invasive attack.
Sources from the Master’s thesis of K.O Gadellaa - TECHNISCHE UNIVERSITEIT EINDHOVEN – August 2005
Không có nhận xét nào:
Đăng nhận xét