What amazed me most during these presentations is the very low security level of some cards that are being sold in 2016. Among my surprises, I noted:

• Object meta-data in the heap. I would have expected the object meta-data (headers) to be separated from heap data in a dedicated array of handles. But apparently, there is a significant proportion of cards that don’t use that basic protection (actually, my surprise comes from the fact that cards have more and more memory, and handles help to manage large heaps with a 16-bit reference).
• Single key encryption key. In some cards, key material stored in SecretKey and PrivateKey objects are encrypted, but the same key is used for all objects. This weakness may be the most symptomatic of how logical attacks are being ignored, as it provides a good protection against hardware attacks (like a memory dump), but no protection at all from logical attacks that “jump” the firewall.
• No key encryption. Apparently, some cards don’t even bother to encrypt their secrets at all. That’s really bad, I even have trouble believing it (which explains the “apparently”). Yet, it only shows great disdain for any security, not just logical attacks.

The problem with the two first issues come from one of the most powerful features of logical attacks. These attacks run as a legitimate Java Card application, and they are able to impersonate an application. As such, they can defeat some protections (like the encryption of keys, or the integrity protections of a PIN counter) without breaking the protection itself. Basically, you don’t need the key if someone holds the door for you.

Now, we come to the main reason why logical attacks are not being considered. Most smart cards must undergo some kind of security evaluation before they reach the market. This evaluation is performed by security laboratories, including Riscure, which presented on of the Cardis papers. These laboratories find vulnerabilities, for instance using logical attacks, and they then try to build attacks from these vulnerabilities. A card will fail the evaluation only if such a complete attack can be built.

Furthermore, laboratories follow strict guidelines, often those defined in the Application of Smart Card Attack Potential to rate the difficulty of attacks, and only attacks that are rated under some predetermined level can be considered.

All of this make perfect sense, since the laboratory is supposed to evaluate the ability of a potential attacker with given skills and resources to “break” the card. For this reason, these evaluations have often focused greatly on cryptography: if an attacker is able to “guess” a secret/private key, then the card is most likely broken.

The problem with logical attacks is that, in order to be exploited, they need to be combined with other attacks. In particular, most (all) deployed cards only allow the loading of an application after a successful GlobalPlatform authentication. In order to exploit a logical attack, this authentication (or the checks related to that authentication) needs to be broken. This is a very strong condition, which makes it very unlikely. So, from a traditional smart card evaluation point of view, I admit that it makes perfect sense to ignore logical attacks as being a remote possibility of attack.

Before continuing, I need to distinguish between two kinds of security evaluations: black-box evaluations, in which the laboratory only has access to the cards, without any non-public documentation, and white-box evaluations, in which the laboratory has access to full information, including source code and tests.

Logical attacks are very interesting to learn about the targeted platform, and get information about the implementation options used by a card, and globally revere engineer the platform. As such, they are not useful in white-box evaluations, where reverse engineering is not required. However, they are very useful in black-box evaluation, because this is how an evaluator learns about the cards, and uses this knowledge to select the hardware attacks that are most likely to work. In a black-box evaluation, or in a real attack, logical attacks are an essential tool to optimize attacks. When they don’t work, the attacker is blind in performing attacks, and likely to waste a lot of time. In addition, the attacker will immediately get the feeling that the vendor has invested on the card’s security, which is bad news (from an attacker’s point of view).

The papers from Cardis 2016 are interesting in this perspective, because the researchers have started to investigate the cards a bit further. In particular, on some cards, they have identified the fact that the implementation of some APIs does not follow the Java Card specification, and/or uses proprietary bytecode instructions. Through that work, they are getting closer to “traditional” hacking, where vulnerabilities are found in the OS and exploited. They are not there yet, but it is coming.

Finally, and possibly most importantly, the smart card industry is evolving, in particular for the SIM market. There is a move toward eUICC, and possibly toward some kind of “software SIMs” that would leverage the security features of a device’s main chipset rather than run on a dedicated hardware. Such a software SIM would still be quite isolated from the main OS, for instance using TrustZone, but some researchers have shown that TrustZone software can be broken. And then, logical attacks become plausible, and very interesting for attackers, in particular for their application impersonation capabilities.

In my previous jobs, I have long fought the idea that the security of Java Card implementation should be left to competition as a differentiation feature for vendors, mostly because customers can’t tell the difference. As Java Card moves out of dedicated hardware, its security landscape is going to evolve, and hopefully this change will be considered by the industry.

The iPhone is a secure device, so the best way for Apple to refuse breaking the phone is to claim that they can’t do it. Here is the story line:

• The iPhone includes a secure element.
• The security code is stored and verified in the secure element.
• The phone encryption key also is stored in the secure element.
• In order to get that key from the secure element, the security code must be presented.
• We don’t know how to break into the secure element, so we can’t bypass that security mechanism.

It is a bit technical, but it is true from the point of view of Apple and “standard” developers. But the last statement (we don’t know how to break into the secure element) may not work for everybody.

First, regardless of the secure element, physical attacks are feasible, and there are many kinds. Some of them, like power analysis, do not even require to destroy the chip in any way. Of course, many such attacks will require “opening” the secure element to expose the chip and do other things that may destroy it. In the case of the FBI, who wants to attack a single chip that they must not destroy, this is not really nice.

Then, the secure element on the iPhone is most likely based on Java Card. This means that it is possible to load applications on it. Of course, Java Card includes security measures, so the application needs to be a malicious one; well, there are malicious applications around, and here, we are working with software. This makes a big difference. Now, here is the checklist for FBI:

1. Get Apple to provide 100 secure elements configured exactly like the targeted one, with the card management keys (required to load an app).
2. Get some hacker to develop a malicious application that gets the value of the code, or bypasses the code check, or gets the value of the encryption key, …
3. Establish an attack procedure and test it on actual phones.
4. Get Apple to provide the management key for the targeted phone.
5. Run the attack on the targeted phone, and bingo!

This is slightly different. Apple still needs to collaborate, but not at the same level. Step 4, in particular, is about providing a key that can only be used on the terrorist’s phone. Step 1 is a bit more difficult, since Apple needs to support hacking efforts on their phones.

There is also a need to get a hacker. This may not be as difficult as it sounds, because as far as I know, the population of hackers capable of doing such a thing is small but includes:

• security evaluators working at labs who necessarily have ties to NIST (very close to NSA, here), or to the equivalent in another country;
• people working in various companies and institutions who depend greatly on government contracts;
• and a few real hackers, who could do some work for money, fame, or both.

All these people, for various reasons, are far more vulnerable than Apple, and it is quite likely that FBI will be able to find one to cooperate with them.

And then, what’s left? Well, the security of some secure elements and Java Card implementations are really really good, and they will be protected against more attacks, performed by most attackers. Luckily, the handful of guys who may be able to break these implementations may not be willing to do so.

Still, it sounds like a good idea to support Apple here.

Final thought

This is now a problem that every security professional/company who is involved in the development, testing, or evaluation of consumer or industrial devices must think about: How will I react to injunctions from law enforcement? Should I make sure that I don’t know how to hack my device?

A few weeks ago, a friend sent me a link to the Cardis program, with the message “A bug in the verifier?”. Looking at the program, I saw a paper entitled Manipulating frame information with an Underflow attack undetected by the Off-Card Verifier, by Thales Communications and Security. This sounded like bad news, so I got a copy of the paper and read it.

The good news is that there is no bug. Nevertheless, reading the paper made me unhappy. As a consequence, the first version of this blog post was a flame, in which I qualified the paper of “dishonest, not innovative, and misleading”.

Publishing the flame triggered some discussions, with people at Thalès and with other people, in particular with Jean-Louis Lanet of XLIM. They provided me their views on the topic, and I have decided to revise my original flame into a more mundane and constructive post.

Dishonest, or just a bad title.

As mentioned above, the paper’s title is”Manipulating frame information with an Underflow attack undetected by the Off-Card Verifier”. However, section 3.2 of the paper surprisingly starts with the sentence: “The standard Oracle bytecode verifier detects the underflow attack”. There is no other reference to a verifier that would not detect that attack, and that makes the title sound really dishonest, at least the “undetected” part of it.

More specifically, it seems that the objective of the paper is not to point to an issue in the off-card verifier, as the title seems to, but rather to point to the fact that there exist ways to bypass the verification. A revision of the title in the proceedings would do just fine.

Not innovative, or not published.

The paper describes an attack that uses the dup_x instruction to perform a stack underflow. This stack underflow allows the authors to access the content of a stack frame, including the current context, and to change it. The question is: is this a new attack? As a virtual machine implementer and evaluator, I would say no immediately. This attack very easily comes to mind as soon as you know the content of a stack frame (as an implementer does). This attack has therefore been in my “bag of tricks” when I was an evaluator, and was even quite a practical one.

Now, the smart card industry is secretive, and evaluators are even more secretive. Very few actual attacks have been described in scientific papers. It seems that the attack to mention stack underflow is the EMAN2 attack described by Bouffard et al. at Cardis in 2011. However, they only abuse the return address, labeling the current context “unknown value”. In that context, it seems that this paper describes something that has not been published before. For this one, my apologies, as I forgot the secrecy of the industry, and kudos for actually publishing this rather than keeping it secret.

So now, the community knows that, unverified bytecode can lead on some cards to allowing an attacker to run attacker-provided code in a chosen context. This is about as bad as it gets, and now, additional attacks will fall in my “tricks” category, in which an attacker/evaluator uses a new illegal bytecode combination because the previously known ones don’t work on a card. I hope that we won’t see more scientific papers about such tricks (see Jean-Louis Lanet’s second comment about this).

Misleading, or missing its target.

Of course, since the off-card verifier catches all of these logical attacks, they are not supposed to occur in real life, where bytecode verifiers are systematically used.

Let’s make a parallel between two typical components, RSA and a virtual machine. RSA is a crypto algorithm, a function RSA(K,M) that takes as input a key K and a message M, and produces a result. Similarly, a virtual machine is a function VM(P,I), where P is a program (in bytecode) and I some input data, and produces a result. The RSA and VM functions share something important: the key K and the program P need to obey some properties. If the don’t, the algorithms don’t work.

If the RSA prime factors are not prime numbers, or if the program provided to the VM is not valid, their results may not be satisfactory: although they are functionally correct, they will not have the expected security properties. In order to avoid bad keys and bad programs, we use appropriate algorithms to perform primality checks, and to verify bytecode. Just as it is important to ensure that an attacker cannot tamper with the key generation scheme, it is important to ensure that bytecode is verified before to be executed. But is it sufficient?

Well, that may be sufficient if you run your VM or your RSA on a device that is physically protected from attackers. But on a smart card, it isn’t sufficient, at least for RSA. There have been many attacks published on smart card implementations of RSA, using fault induction, power analysis, and more. The VM is just as sensitive to these attacks; in particular, combined attacks can be used to dynamically create illegal code on a card, as mentioned in the paper.

If we continue the analogy, RSA is still used on cards, even though attacks exist. During security evaluations, the robustness of the implementation is verified by a lab, which ensures that well-known attacks don’t work. Naturally, the same thing must be done with the VM: a high-security implementation must include significant countermeasures against attacks on VM, such as combined attacks. The implementers have the choice of the countermeasures; they can include additional checks in the virtual machine, attempt to detect the faults, or both, or anything else, as long as it works.

According to my discussion with Thales, this is more or less the point that the paper tries to make, in particular in its last part. However, the paper insists on the malicious application rather than on the attacks, especially in its last sentence:

Finally, this paper shows that during open platform evaluations, it is necessary to take into account malicious applications, and make detailed analysis of each requirement included in the platform guidance.

I definitely agree on the platform guidance aspect. Requiring bytecode verification is not sufficient, as the management of the verification context is also important to avoid logical attacks. However, during evaluations, malicious applications are not the real issue, attacks on the virtual machine are. In that context, malicious applications are for now tied to combined attacks, where a fault triggers the logical attack. What the community often fails to understand is that, on a smart card, a virtual machine is a component like any other: it can be subject to physical attacks. And that’s the reason why specific countermeasures are required.

So what?

In Cardis, the proceedings are collected after the conference, so authors have an opportunity to revise their paper before publication. After our exchanges, I hope that some revisions will be made before publication, in particular on the title and on the last part (making a stronger point about evaluation requirements). And so, I replaced my flame with this.

The first presentation was given by Guillaume Barbu, from Oberthur, about combined attacks on Java Card 3 Connected. Combined attacks are interesting in principle, because they suppose that the attackers are intelligent enough to avoid bytecode verification, while still having the possibility to perform attacks.

A very short reminder on what this is about: in a combined attack, a legal Java Card application is designed to include code that is vulnerable by design to well-known hardware attacks. When the hardware attacks are applied, the legal application becomes a malicious application and performs an attack on the hosting card.

Nothing new here. Guillaume made a first presentation about this last year, and we made presentation about the same topic at Cardis in April. The novelty comes from the exploitation that Guillaume makes of combined attacks. Since he is targeting Java Card 3 Connected, his target is the pool of interned strings. Since strings are everywhere in JC3 Connected, and since they are often used to make security decisions, this attack could be very powerful. For instance, the parameters of permissions are strings, and playing with these strings could greatly extend the permissions granted to an application. These attacks are interesting, but, from the feedback I got, the countermeasures proposed by Guillaume are a bit weak. Well, this reminds us that Java Card 3 Connected remains an implementation challenge.

The other presentation was given by Emilie Faugeron, from Thales ITSEF. Thales has found a bug in a bytecode verifier, and discusses the consequences of such a bug. This story has been unfolding for a while, as the bug has been known from the card security community for a while. I am glad that it finally becomes public, which allows us to comment on it.

When there is a bug in the verifier, it means that a potential attacker could load a malicious applet on a card without being detected by the verifier. The consequences are basically the same as for combined attacks, with the advantage that there is no hardware attack to perform after the loading.

The question is here to know what we should do about it. Thales proposes to evaluate the bytecode verifiers (on-card and off-card) during a Common Criteria process. This sounds obvious at first, but there are significant differences between a bytecode verifier and a Java Card Virtual Machine:

• First, a bytecode verifier is a highly standardized piece of software. On other platforms, VM vendors are not allowed to modify the verifier’s reference implementation. The specification of a verifier is always the same, and it changes very rarely.
• In Java Card, there is an exception with on-card verifiers. Because of the high level of optimization required, a few differences may be expected. For instance, Trusted Logic’s verifier requires an initial normalization phase before to load the application; however, the combination of normalizer and verifier implements exactly the same specification as other verifiers.
• There are very few implementations of verifiers that are publicly used. The verifiers are always the same, and I would assume that Oracle’s verifier is the most commonly used. In that context, building a viable certification environment is hard.
• There already exists significant test suites for Java Card bytecode verifiers. Trusted Logic has one, of course, to test its own verifier. Oracle has a very significant one, which it uses to test its verifiers. And obviously, Thales has one now. And I assume that other actors have some.
• Testing a bytecode verifier is a hard task. A bytecode verifier is a static code analysis tool, and these tools are well-known to be very difficult to test, because of the level of abstraction required.

So, what can we do? One option is to follow Thales’ advice. This sounds tempting for me; I have strong ties with Trusted Labs, which could perform such evaluations, we have access to a test suite, and we have been developing and testing static analysis tools for about ten years. If I am wrong about the potential business, this is likely to happen.

The alternative way is to remind ourselves that a bytecode verifier should follow a reference design, preferably provided b yOracle. This is what happens on all other platforms, and there is no reason to keep a Java Card exception. For such pieces of sofftware, which evolve very slowly, nothing beats public scrutiny. There are many researchers (for instance, wy friends from Limoges and Nijmegen) who would love to take a look at a bytecode verifiers and its tests.

I don’t have a plan for this, but it really looks like, in this matter, collaboration between all actors sounds much better than competition between evaluation laboratories. We’ll see what happens.

A Java Card 3.0 card has plenty of countemreasures against logical attacks

• Context isolation. Objects from an application can’t be accessed from another application. This “firewall” si specific to Java Card.
• Code isolation. Code from an application cannot be accessed from other applications, making it difficult to indirectly access assets. This is the clas loader mechanism, inherited from Java.
• Bytecode verifier. Will reject all kinds of malicious applets, so logical attacks based on “bad” code can’t work any more.

A combined attack consists in loading an application that is well-formed, and will nevertheless attempt to act illegally, for instance by accessing another application’s data. Under normal conditions, the firewall will make this impossible. But if we add a fault attack at the right time, we can allow the illegal access.

The example given by the student consists in illegally accessing a method from another application. The class loader hierarchy normally makes this invisible. The idea behind the attack is to use a class with exactly the same definition on the attacker’s side.

Of course, if you attempt to cast a remote object into the attacker’s class, the different class loaders will lead to an exception. By putting a fault on the checkcast instruction, we can actually perform this cast and invoke the targeted method.

Of course, this is only the first step. The next step is to use another perturbation to defeat the firewall itself. Oberthur plans on using multithreading to do so (by abusing the context switches), but this is work in progress. There are other ways to achieve the same thing, but the multithreading idea is quite neat.

Their first attack (on checkcast) allows all previously published logical attacks based on type confusion to be made again.

The proposed countermeasure (redundancy) is not really good, as the virtual machine is being attacked here, and adding redundancy at that level could have a significant effect on the overall performance of the cards.

Logical attacks and combined attacks have been available for a while in evaluation labs. It is very nice, from an evaluator’s point of view, to see that this kind of work is now being published. This could mean that the level of paranoia is lowering in the smart card industry. The fact that a card vendor is publishing this makes it even stronger.

Now, the challenge is on the manufacturers, especially since the attacks described in the presentation also work perfectly on Java Card 2 cards. We now are in a state where there is a published vulnerability, which needs to be industrialized, and then exploited. Luckily, this will require significant efforts of reverse engineering, which will be made more difficult by what remains of the industry’s paranoia.

Also, let’s see what the academics working on attacks will make with that. There are still plenty of ideas and details of these attacks that remain confined in laboratories.

The news still needs further confirmation but if it is true, it gives a whole new meaning to “tamper evident”. The problem is here that, if you tamper with the device soon enough, then you don’t get any evidence. I am quite sure that these devices are supposed to be built in secure premises somewhere, but that somebody’s definition of security with weaker than expected.

What this story shows us is that we should not discard vulnerabilities just because they look impossible in “secure premises”. In particular, when most actors claim that loading unverified bytecode into cards is impossible because of the verifications performed in factories, they just forget one factor: given the right incentive, most people can take (a small) part in a criminal ring. I am not sure that the guy who actually rigged the devices in China made that much money, but if his factory also makes cards, it should have been possible to ask him to replace a CAP file by another one (with a Trojan, of course).

Of course, this can be considered as shameless advertising, since Trusted Labs offers consulting and services about this very problem. But it also is a candid view on the things that can happen anywhere when trust is placed upon human beings: social engineering works.

I cannot tell you much more about this hack, because Gowdiak asks for 20,000€ to get detailed information. However, based on the little information available, my personal guess is that the main problem is situated somewhere in the application manager. There are several reasons for that:

• First, the virtual machine is starting to be quite robust (Gowdiak has actually participated to that effort), and there have been significant reviews of the latest bytecode verifier. So, I would not say that the basic Java security features are broken.
• Then, the flaw appears to be in the management of permissions, allowing an untrusted application to run and/or be recognized as a manufacturer application (the most privileged kind of applications). This is typically part of the Application Manager.
• Finally, Adam Gowdiak claims that his attack is likely to work on other devices based on Sun’s RI of Java ME. It therefore means that part of the exploitation is in the portable part, and also that part of the attack is in the device-specific part.

There are many ways to achieve such a feast, depending on the kind of attack that one is ready to perform:

• The device’s security policy may be stored in a file. In that case, the security of Java relies on the security of the underlying file system.
• Application descriptors have to be stored somewhere. If the application manager does not check their consistency regularly, they could be modified.
• Application code is also stored somewhere. They are not supposed to be modified, but consistency checks are expensive.
• There are usually plenty of debugging features in a platform, that could be activated and used maliciously.

Exploitation of such vulnerabilities usually is surprisingly easy. One you have access to all privileges, it is quite easy to write applications that do bad things. The last thing that an attacker would need is a way to push applications without warning the user, and this could be feasible with manufacturer privileges (after all, it is practical for a manufacturer to do that). Once again, I can’t say if it is the case with this particular attack.

About Nokia, I am a bit sad that they get busted here, because they are among the good guys in terms of mobile security. I guess that this kind of publicity is the price to pay for being the world leader. The S40 platform is a bit like the Windows of mobile phones, and breaking it is more interesting than breaking any other phone platform. Also, the reaction from Nokia, as mentioned by the Register, “we do not currently believe these issues represent a significant risk to customers’ devices”, is a bit surprising, especially if we consider the definition of the issue by the same Register, “a miscreant exploiting them could do whatever they like to a Series 40 phone just by knowing the phone number”.

Finally, a note about Adam Gowdiak’s job. He did very good work in finding these flaws, and he is in trouble getting paid for it. I hope that Nokia, Sun, and others have paid the fee he asks for (which is not that big), but this remains an issue.I don’t know how much time Adam Gowdiak has spent on preparing this attack, but I am not sure that such work would be feasible in a consultancy mode. I have been involved in many security evaluations, and you don’t go very far for 20,000€. A complete security review of the S40 platform would cost may times that, and it is not that easy to find experts of Adam’s caliber. Nevertheless, the good old consultancy scheme presents some advantages for manufacturers. For instance, we at Trusted Labs have found many vulnerabilities on devices ranging from smart cards to payment terminals and mobile phones (including Java ME), but you have not heard about them, and you won’t hear about them any time soon, because all our work is performed under strong non-disclosure agreements.

Adam Gowdiak has acted responsibly by not posting any details and/or exploit code publicly. I am sure that most S40 phone owners never update their platform, so any flaw identified on such a platform is likely to stay around for years on millions of devices. Nevertheless, it is only a question of time before some bad guy gets the details of this attack: either through Adam directly (20,000€ is not that much, and some bad guys are very good at social engineering, for instance for posing as a manufacturer); or through an accomplice at a manufacturer; or even by rebuilding the attack as more and more information gets leaked.

When that happens, it will be interesting to see if it triggers a wave of malicious Java applications and other attacks on S40 devices. Only time will tell.