Logical Attacks in the Java Card security landscape

Logical attacks on Java Card have been known for a long time, and they have also been a focus of a lot of academic research, which still continues today. Earlier this week at Cardis 2016, there have been two presentations on logical attacks. I will not discuss the details of the attacks that are being disclosed; the important thing is that the publicly available information about logical attacks is increasing regularly over time.

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.

No Comments

Leave a Reply

Your email is never shared.Required fields are marked *