In the following years, we wasted a lot of time working on a much more ambitious version of Java Card, which never made it, but we never worked on addressing this issue of unverified bytecode, mostly because we had the cryptographic protections provided by GlobalPlatform. If nobody can load unverified bytecode, where is the problem?

As an evaluator, this allowed me to reverse engineer many types of Java Card, as I was allowed to download unverified (and very much illegal) bytecode into cards. Over time, most virtual machines have included runtime countermeasures, and some implementations have been difficult to attack with illegal bytecode for quite a while.

Yet, Java Card has become an industry standard. Strong implementations exist, in which loading unverified bytecode is about impossible, and then, exploiting unverified bytecode is challenging. But on the other hand, weaker platforms also exist, and recently, following a combination of mistakes from various stakeholders, one of them was broken; luckily, by a researcher, not by a criminal.

The real surprise is not that this has happened. It is that it took over 25 years for it to happen. The lack of on-card verification has always been a weakness in the Java Card story. Over the past 25 years, there have been a few attempts to address the issue, but the industry never adopted them. Isn’t a solution to this issue a bit overdue?

The smart card industry is a small industry, with few actors, and Java Card has been a great success, its interoperability providing the basis for the deployment of billions of products every year. But the industry has been complacent, and although I am not part of it any more, I bear some of this responsibility since I have headed the Java Card Forum’s Technical Committee for a few years. I defended off-card bytecode verification many times, for instance in 2011 and quite vehemently in 2013.

But that was over 10 years ago, and I would now argue that it’s time to fix this issue. Despite minor updates, the core Java Card technology is over 25 years old. The similarity between the latest version of the Java Card Virtual Machine specification with its first interoperable version is striking. There have been almost no changes. The CAP file format is antiquated, and an update could allow all vendors to ensure that no illegal bytecode is allowed to run on the any card.

From a now outsider’s viewpoint, I believe that after the recent developments and an issue impacting the security of millions of unsuspecting users, the usual denials sound really out of touch with reality, so I am asking the Java Card community a simple question: Since you are pushing for Java Card to be the basis for our personal security, and asking us to trust you with our sensitive data, including our identity, isn’t it now the right time to put this bytecode issue behind us once and for all?

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.

I will refrain from commenting on the first paper because of my previous involvement with Oracle’s Java Card technology, but I would like to make a few comments on the second one.

First, this paper is very well-written, and the attacks are really easy to understand, at least if you have the appropriate background. The attacks are all interesting, and some of them, in particular on the logical part, seem a little bit too easy… Maybe some quality issues in some places.

I have two remarks, though.

First, the general comment about logical attacks that

the correctness implementation of the JCVM embedded on sensitive products must be carefully checked

is OK, but the following statement about the bytecode verifier (BCV) sounds strange:

Today, a huge part of the security of the products relies on the robustness of the BCV but these attacks demonstrate that the BCV is not always sufficient enough to protect the JCVM against this type of software attacks.

A BCV reasons on the application, and makes no claim that the applications will run securely on a buggy JCVM implementation. There is nothing to demonstrate here, because the BCV has never been intended to protect against this type of software attacks. We need to stress that there is nothing to be done at the level of the BCV to counter these attacks. Here, we need to verify the JCVM implementations.

The second remark is about a sentence in the conclusion, which states that

tests like TCK are not designed to find this kind of bugs in implementations.

That’s true for the stack overflow bug, which is an implementation bug. However, it is not obvious for the two other bugs:

• The firewall check on a cast should be tested by the TCK. I am actually surprised that it isn’t, but I don’t have access to the TCK these days.
• Similarly, the implementation bug on the switch instructions is a also a compliance issue, and should be somehow caught by the TCK (it is more of a corner case, though, so it raises the question of required TCK coverage).

In the end, I agree on the fact that labs should have a library of malicious applets of all kinds that they use in evaluations, but compliance issues should be as much as possible checked by the TCK.

API vs. APDU

Before Java Card, a smart card specification consisted in the definition of a set of APDU commands, with a precise syntax, and in most cases, a precise semantics associated to that syntax. With Java Card, for the first time, an API was designed to run inside the card.

At that time, some of us believed that this would lead rapidly to a paradigm shift in the card world, with the definition of card products shifting from the definition of APDUs (which are low-level communication protocol items) to a more noble definition of API, closer to a functional definition. That’s why we worked on the definition of the Java Card RMI protocol, whose objective was to allow the definition of interfaces to communicate with cards independently of protocols.

Well, we were wrong. Maybe not on the principles, but most definitely in practice. Nobody adopted the RMI protocol, and APDU protocols are still being defined today. In the world of smart cards, this makes sense, since low-level considerations remain a significant challenge (for instance, performance issues in some contactless transactions). In payment, mobile, and identity, APDU standards remain the norm everywhere.

Why did that happen? The answer is complex, but one major factor surely is the fact that Java Card is for obscure security specialists, and that the smart card protocols are only being exposed to a few developers. In such a context, there is no real need to simplify the interfaces exposed to developers.

What about new markets, though? Are there good reasons to define new APIs rather than new protocols? We can here consider two markets: Mobile TEE and IoT. In both cases, the market is sufficiently new to avoid compatibility issues. Even if standards like GlobalPlatform exist, they are not strong enough yet to be real obstacles.

Let’s start by the mobile TEE. The idea is here to isolate the security functionality of sensitive smartphone applications. By first looking at it, this looks like a fairly open model, where a developer would split an application into the security-sensitive part, which goes in the TEE, and the non-sensitive part, which runs on the “normal” OS. Well, that would work if developers had a clue about how to do this, but it sure isn’t the case. That’s why TEE providers are targeting “security providers”, i.e. developers who are working on security products. However, when taking a closer look, the requirements are always the same: authenticating users, protecting stored data (including keys and other credentials), and getting access to a little crypto to implement proprietary protocols. Most developers do not need in any way a full-fledged TEE with applications and more. All they need is a piece of trusted software that they can leverage in their applications without having to dive too deep in the security part. This may sound good for a supporter of APIs, but I am not sure, as “normal” developers need a generic API for their apps. The way in which these APIs are implemented is not their problem, and it is quite likely that at least part of this implementation will be on the “normal” side. In the end, the usual suspects (security specialists) will be designing the interface between the normal applications and the TEE, and they may be tempted to “optimize” things with low-level protocols.

IoT is different, though. It is interesting for at least two reasons: (1) there is no history and backward compatibility requirements, so why bother with APDUs? and (2) there is a wide variety of devices and applications. In addition, in IoT, we are quite likely to see situations where there is no secure element, so new frameworks have to be designed. Not sure where this is going, but I will sure follow what my ex-colleagues from Oracle are doing with this.

CAP file vs. class file

This debate has been very active during the design of Java Card 3.0 Connected, in which the class file ended up being selected. I was against the decision then, and I am still against it today. The class file is very nice, but it has not been designed with smart card and other limited environments in mind, so it makes perfect sense to design a more optimized format for constrained environments: the CAP file.

Here are a few good reasons to do so:

• Optimization. That’s the obvious one. We can optimize on size by reducing overhead, and we can also optimize on loading and linking times, exploiting Java Card’s limitations on dynamicity.
• Specialized instruction set. This may be considered as a special kind of optimization, but Java Card uses a specific instruction set, which includes in particular a few combined instructions that make programs smaller. This path has definitely not been fully exploited in Java Card.
• Enhanced provability. Java binaries are verifiable, and Java Card could benefit from specific verifications, for instance related to the management of objects. However, Java Card has not exploited this at any point, and bytecode verification has remained more of an issue throughout the years.

On the opposite, from my biased point of view, the only reason to use class files would be to use the same format as anybody else. But since we are not running the same programs, what is the point? Well, there is at least one: with class files, there wouldn’t be a debate about the suitability of bytecode verifiers, as no one is discussing the fact that the Java bytecode verifier is correct.

So, I hope that in the future, the CAP file remains, and that it evolves to integrates more aggressive optimizations, as well as a more sophisticated set of analyses that leverage the specific nature of Java Card code.

Interoperability vs. differentiation

This has been a recurrent discussion item at the Java Card Forum. What should be standardized, and what should be left as differentiators between the actors. Here are a few interesting topics here:

• Basic functionality should be interoperable. That’s been OK for a long time, and nobody dared going back on that one, at least officially. However, there have been some tensions there, in particular around SIM Toolkit. With proactive commands, it is possible to interrupt the execution of a SIM Toolkit routine while waiting for a response from the mobile, and during that time, other commands can be processed. This suspension mechanism, which is essential to the SIM Toolkit spec, has never been formalized in the Java Card platform, leaving an obvious interoperability gap.
• Performance is for differentiation. Another obvious one, although vendors have regularly stymied any effort to define a benchmark for Java Card, like the Mesure project. Performance is a differentiator, but it is better not to measure it correctly.
• Size is for differentiation. That sounds obvious too, but it has led to barrels of fun in real life. Obviously different platforms, even when running on the exact same chip, don’t occupy the same space, so the space left for applications and their data differs. Well, that’s expected, and totally static, so it can easily be considered. Things get more fun when we get to objects. Platforms use headers of different sizes, they don’t implement redundancy in the same way, the don’t manage memory in the same way. In the end, the same set of objects doesn’t occupy the same memory space on two different platforms, and this has been a great issue when cards are almost full.
• Security is not much for differentiation. At first, this looks like a good opportunity for differentiation, as vendors want to be able to claim that their products are “more secure” than their competitor’s products. As an evaluator, I noticed the wide differences in security features between the products, and implicitly supported this view. I now believe that standards are more important for security than differentiation. If we consider the mobile payment vertical, some people will claim that the combination of private platform certifications by Visa and others and of formal Common Criteria certifications bring the desired level of interoperability. Yet, in many cases, certification authorities want to see an application certified on every target platform, and rightly so, because the various platforms do not provide the same guarantees on individual functions; they globally achieve the desired global level of security, but they protect individual functions differently. In order to reduce this, I have pushed for security interoperability to be included in Java Card for many years, first by defining security annotations, and more recently by defining dedicated security APIs. The Protection Profile for Java Card 3.0.5 has not been released yet, so I can’t tell for sure, but I am afraid that the measures included in the latest specification will still not be sufficient to provide sufficient interoperability.

Another interesting thing about interoperability, as we are moving to a world where Java Card may be used on very different platforms: When we defined the Connected Edition, it was very different from the Classic Edition, but we nevertheless stated very stringent interoperability requirements: All Classic applications must run on a Connected platform.

As we may be moving toward another split of Java Card platforms with the rise of RAM-based platforms, I would like to see less stringent requirements. If we consider that Java Card Next will include a Classic and a RAM edition, I would require the following:

• Java Card Next Classic is just the next version following Java Card 3.0.5 Classic. Therefore, backward compatibility must be strict: all Java Card 3.0.5 Classic applications must run unchanged on a Java Card Next Classic platform, even without a recompile.
• Java Card Next RAM is a new platform. Applications developed specifically for this platform are only expected to run on that platform.
• Java Card Next Classic and Java Card Next RAM must be interoperable. It must be possible to write an application that runs on all Java Card Next platforms (Classic and RAM).

For an application provider, this would mean that the following options are available:

• Keep existing applications, and only support their deployment on Java Card Next Classic platforms (in addition to all previous Classic platforms). This could for instance make perfect sense for payment cards or identity cards, which will remain based on classical smart card chips.
• Write new applications specifically for the RAM platform, and only run them on Java Card Next platforms. This is suitable for applications without a strong history, which need to leverage the specific features of RAM platforms, for instance on a mobile TEE.
• Rewrite/write applications that work on both platforms. This is suitable for new applications that target a wide range of devices, like in IoT, where the same application coudl run on many different architectures.

Interoperability discussions are among the most obscure and technical in the Java Card community. It is a bit like politics: it is very easy to make broad statements that sound definitive, but reality is closer to economics, very complex and requires a deep technical understanding (and like economics, it is not a hard science, so debates can be very long). I’ll miss these discussions.

These 20 years have been quite an interesting ride. Java Card is an amazing technology, just as successful as it is understated. Java Card has been deployed on over 15 billion devices since the first deployments in 2000, its deployment numbers have been growing steadily for 15 years. With the current movements in the SIM industry, it is hard to guarantee that this growth will be sustained over the next years, but Java Card is at least guaranteed to have a very fat and very long tail before it disappears.

I will publish a few entries on Java Card, starting here with a few comments on how improbable this success has been over the years.

An immature technology for an immature industry

Initial work on Java Card started in 1996 at Schlumberger’s research team (now part of Gemalto), as all card vendors were looking for solutions to run scripts on smart cards, mostly for supporting the SIM Toolkit framework. At the time, every major vendor had developed a proprietary solution, usually based on an existing programming framework.

In 1997, smart card issuers were starting to ask for interoperability between vendors. The Java Card Forum was founded in the spring as an answer, although few of its members were convinced that it was the way to go forward. Sun Microsystems was invited as owner of the Java technology, smart card vendors became Java Card licensees, and Sun Microsystems took the responsibility of managing the specification and related technologies (reference implementation and compliance kit). Sun didn’t have any experience about smart cards, and in the first meetings, their representatives clearly showed it. Sun then hired Integrity Arts (a Gemplus spin-off) as consultant, and rapidly acquired them, getting expertise in-house.

Java was not well suited to the smart cards available then. The language was easy to learn, but the virtual machine brought an overhead in both size and performance. At the time, it would have been possible to design a more suitable standard for programming smart cards, but the industry has not been able to organize in order to define such a standard.

Java Card became an API specification rapidly with version 2.0, but this version was short-lived, and quickly replaced by version 2.1, which also included a virtual machine specification, and allowed binary Interoperability between products. At about that time, the mobile operators became really interested, a SIM toolkit API was defined, and the deployment began around 2000.

15 years later, this adoption of a poorly adapted technology by an immature industry has become an asset. Because Java Card was a bit too ambitious at the time, and thanks to the continuing success of the Java language, Java Card has now become a mainstream technology, which in 2015, fits the needs of the smart card market, and is present on most open smart cards, and roughly half of the microprocessor cards sold worldwide. In the end, it pays to be inadapted.

Mostly an ecosystem

In the late 1990’s, the first marketing sentences for Java Card were directly taken from Java, like “Millions of developers”, or “Write once, run anywhere”. The one specific marketing argument was about “Running multiple applications on your card”. Fifteen years later, here is a factual status:

• Hundreds of developers (tens of expert developers), mostly working for smart card vendors or for a few specialized consulting firms.
• Most applications written for a single card, or at least for a single issuer.
• Most applications written by a card vendor, and running only on a single vendor’s cards.
• Most cards running a single application.

The next question is: why is Java Card still around if it is not used? Well, in fact, it is being used, just not in the ways that people initially planned. In fact, an essential factor in the success of Java Card has been the certification of cards. In many cases, once a card is deployed, there is no (efficient) procedure to update the card to fix a bug or a vulnerability. Therefore, cards are heavily tested before to be deployed, and most vendors require several levels of certification, including a functional certification and a security certification.

These certification processes are costly, both in developer resources and in laboratory fees. Over the years, efficient certification has become an essential aspect of card development, and Java Card facilitated this in several ways:

• A reference for core functionality. The Java Card specification defines a set of core functions which can then be used to develop applications (cryptography, I/O, storage, appication isolation and sharing). It then becomes possible to test separately these core functions (by evaluating a Java Card platform) and the application using them (by evaluating a Java Card applet). This can lead to economies of scale.
• Reference applications. Some issuers and actors, notably Visa, have written reference versions of their applications, which have been thoroughly tested on compliant Java Card implementations. Vendors who use these reference implementations can simplify the certification process.
• Building experience beyond developers. Laboratories, certification authorities, security consultants all have worked with many Java Card platforms and applications over the years, and now feel confident about their ability to use, test and certify such cards in different configurations. This is the ecosystem part.

In the past few years, the strength of this ecosystem has been a key asset for Java Card, together with the fact that it remains today the dominant platform for defining APIs for smart cards, regardless of the target vertical (once again an ecosystem aspect).

Not dead, not frozen, just slow and conservative

Another striking feature of Java Card is its lack of evolution. The core features of the platform have remained vastly unchanged since release 2.1. Several attempts to make the platform evolve have failed over the years:

• Java Card RMI was introduced with Java Card 2.2, with the objective of making it easier to design new smart card applications, but it was never adopted by the community. Support of Java Card RMI has been optional in the latest releases, and it was close from being deprecated a few times.
• Java Card 3.0 Connected was a bolder attempt at reaching new markets, this time arounod Smart Card Web Servers. This specification is very nice, and it defines a Web application model that can be implemented in half a megabyte, all included (OS, VM, Web container, content management, and a few apps). Yet, smart card web servers never caught, and this specification has never been implemented in a real product since its 2009 release.
• An annotation framework for security interoperability was added recently, but the industry hasn’t been able to agree on a semantics for these annotations, and it has not been adopted.

In the latest 3.0.5 release, we have attempted to add a few simple things, hoping that they will be adopted, but this will only happen in a while, because of another interesting specificity of Java Card. It takes around a year to develop a new platform after the release of a specification, at least another year to get a full certification (functional and security), and another year to sell, produce and deploy it. That’s about 3 years between the specification and the actual availability of products.

This development rate partly explains the slow evolution of Java Card. The smart card ecosystem globally evolves very slowly, and to observers who are used to Web-like evolution, it may look life completely frozen. However, it keeps evolving at its specific and very slow rate. Since 2009, Java Card has become much better adapted to contactless cards, it has adopted a number of cryptographic technologies, and a few other features have evolved to follow the evolution of smart card hardware. Such changes are invisible to the non-specialist, but they keep the Java Card framework in synch with smart card technology, and this is what really counts.

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 question is to understand why automated analysis is required for NFC. One of the issues of NFC is the scalability of security evalution processes. There are good schemes forf so-called sensitive applets, which are relate to payment, identity, or other schemes that have strong certification requirements, usually requiring a full evaluation, incouding attacks.

The other applications, so called non-sensitive, are provided by security companies who do not require security certification. Some analysis is required, at least to make sure that they don’t interfere with the sensitive applications. Today, this analysis is performed manually by laboratories, which is error-prone, effort intensive, and not scalable.

Static analysis is a technology that allows us to completely automate this security analysis. This is done directly on the binary CAP file, without running the application, but simply by analyzing how the code could behave. It is possible to verify plenty of rules, including those defined by AFSCM or by GlobalPlatform. Luckily for Arya Security, these rules have been defined by people who were actually thinking about static analysis, and who made sure that the rules would be easy enough to analyze.

I strongly believe in static analysis, and I have written and talked about it multiple times. I am quite happy that some people get in this market and propose a tool for Java Card. I haven’t directly tried their tool, but I hope that its algorithms are good enough to avoid lost of false positives, and that they will be adopted.

The main barrier for them is actually NFC adoption. However, if it works, I am quite convinced that static analysis is the only way to go, because any non-automated techniques are not going to be scalable enough. Another company whose fate is linked to the success of NFC (in card emulation mode).

• 1996, Java on a smart card. That’s even more than 15 years ago, and that’s when some maniacs at Schlumberger’s Austin lab came up with the crazy idea of putting a Java virtual machine on a microcontroller with under 1k of RAM. It worked, and that was Cyberflex.
• 1997: the industry organizes. The Java Card Forum is created in April, and the Java Card 2.0 is released, with two demos at Cartes, Cyberflex and GemXpresso. Cyberflex gets the Sesames award that they deserved. Also, Java Card becomes a bit more Java-like, with data stored in objects rather than files, applets, and a few more things.
• 1998: OpenPlatform is created. OpenPlatform has been created by Visa, as the first initiative from issuers to work on the management of multi-application cards. A spec is rapidly issued, which is the ancestor of today’s GlobalPlatform Card Specification.
• 1999: Java Card 2.1 and interoperability. We took more time to release 2.1, because this was the release. The new features include binary interoperability, with the definition of the CAP file, the finalization of the application model, including transient objects and sharing.
• 1999: The SIM Toolkit API is released. This is the first hit for Java Card, which has been essential to its success in the mobile industry, still present in billions of cards.
• 2001: SIM Alliance release Interoperability Stepping Stones. This is a major industry forum, representing vendors, issuing a document that removes them a potential differentiation. Interoperability is not just for geeks any more.
• 2002: Java Card and RMI. This has been a long story, starting with the 1997 Cartes demo by Gemplus. Five years later, RMI gets in the Java Card spec as a mandatory feature, allowing Java Card developers to go beyond APDUs. Or not.
• 2009: Java Card 3.0, Connected Edition. That’s the end of a cycle in which we add more and more features. Starting in 2002 from forecasts of 1Mb chips in 2006 and a big need for content on cards, we went to high-speed communication, better VM, and a Web server. In the end, we had an iPhone, and rather small chips. And enough new features to last for 10 years.
• 2001: The first CC certificate. The Vocable was a bit crazy. Launched in 2000, the idea was to get a Common Criteria certification for a Java smart card. It was highly experimental, training the evaluation lab Serma about Java software, even discussing principles with the certification authority. But it worked, and we got the certificate. Certification matters.
• 2003: The Java Card Protection Profile. This initiative has defined a common base for the certification of Java Card products, and one of the most commonly used PPs, even today. It has also helped us grow a security ecosystem around the security of Java Card.
• 2010: EMVCo certifies a Java Card platform. It took a long time to convince issuers that it was interesting to certify platforms as well as applications. What got them there is NFC, because they now have to share a platform selected by others. And this is a great move ahead, because it is a first step toward security interoperability. We are not there yet, but Java Card is slowly getting there.
• 2009: NFC wallets require Java Card. This is important, because NFC is the first market in which Java Card is an obvious choice. Nobody has discussed this choice, since interoperability and openness are key properties. A very strong use case for Java Card.
• 2012: Embedding the card. With M2M and NFC embedded secure elements, there are talks about embedding Java Card. Once again, this is a strong use case, as the ability to add or update applications is important in this context. In a riskier move, I can mention eUICC, although network operators don’t like this much. The big news about embedded? It changes the control of the secure element, giving more power to device vendors, and taking it away from issuers.
• 2015: The Internet of Things. That’s a natural step. Everybody is talking about these billions of connected devices. At least some of them will need security, and Java Card will be around to provide this. It is recognized, and not linked to a single technology.
• 2020 and beyond: The security subsystem. That’s a bit far to bet on form factors, and I don’t know if secure elements will still be around, if they will be integrated in the main chipsets, or if software only will be needed, but I am convinced that a security subsystem will be around, and Java Card is a good candidate to run on it. Why? Because Java Card is small and constrained, but it is also provable in many ways, and can be evaluated with high assurance levels. And in security terms, these things matter.

To conclude, what is happening today? Well, Java Card security is drawing some interest from the research community, and we are seeing great results. For instance, Guillaume Barbu has done great work in his Ph.D. thesis about logical attacks and countermeasures. More work is happening at Limoges, Nijmegen, Royal Holloway, and more. Students who work on that then get jobs at evaluation labs, and we got presentations from Emilie Faugeron and Jean-Baptiste Machemie about new evaluation offers.

Of course, Java Card is everywhere around NFC, and it was present, explicitly or implicitly, in most presentations I saw from the NFC World Congress.

Finally, a personal note or this blog. I have been personnally involved almost full time on Java Card fornthe past 15 years, and I participated in a way or another to most of the events noted here, except of course the initial idea from the Schlumberger guys. I am very proud of everything we have achieved during these years, and I hope that many more people are just as proud of this success. After all, over 10,000,000,000 cards with Java Card have been produced, and this is a big number. Actually, I don’t know of any application framework that can show such numbers. So thank you everybody, and let’s continue for 15 more years!

Since then, there have been many debates about bytecode verification, and my own position has evolved over the years. Today, my opinion is a bit contrasted, some may even say contradictory. Nevertheless, here it is:

• Bytecode verification has limited use for Java Card runtime security.
• Extended bytecode verification is a very good tool for application vetting.

Let me give a few more details about these two opinions.

Bytecode verification and runtime security

The idea of runtime verification is that it is performed after getting the code, and right before to run it. The code that runs is therefore known correct, at least regarding bytecode execution (unrelated attacks remain possible, of course).

The first big issue with bytecode verification is that, in Java Card, with the split virtual machine model, verification is not performed on the card, but outside of the card, before/during/after converting the application into Java Card’s specific binary format (CAP file). Then, the application is sent to the card over some channel that may be attacked. Here, we rely on GlobalPlatform’s cryptography-based security to protect the integrity of the code. So, basically, we still need to establish trust, and we must say goodbye to the power of running untrusted code from arbitrary developers.

This is not a big issue in practice, because there is no business model that allows arbitrary code to be loaded on cards. However, this causes an organizational problem, as the verification process needs to be well organized. Researchers from Nijmegen and Limoges have shown that it is possible to fool the verification process with fake export files, and then load on a card verified code that will perform type confusion attacks.

Going beyond that, some people have designed applications that can be verified, but have been designed to be attacked through hardware attacks (fault induction, usually). Such attacks, usually known as hybrid attacks, completely fool the bytecode verification process.

Most security experts will then remind you at this point of the discussion that bytecode verification is only one part of the process, that GlobalPlatform is also important, that the origin of code is usually known, that this makes it very difficult to include attack code in an application, etc. By doing this, they are just about accepting the fact that bytecode verification is useless or at best marginally useful: the real security of cards is in the trust between issuers and application providers, and some cryptographic process. Basically, this works because the ecosystems are small enough to be controlled (which is true for cards, and fine for me).

Finally, some vendors claim to have developed defensive virtual machines, which do not require a bytecode verifier, and perform enough runtime verifications to accept any bytecode, good or bad, without any risk. In that case, bytecode verification is really useless, and I believe that it makes things much simpler. Of course, such virtual machines are difficult to design and implement efficiently, but this is definitely possible, and I think that it has been done in the past (or at least that some people has come very close to it).

To conclude, I will get back many years ago. In 2000, Trusted Logic was very proud of its on-card bytecode verifier; the technology worked, but it has not been widely adopted. I believe that the first factor was performance, as verification made the loading and linking process much slower. I also believe that a second factor, less obvious, is that on-card bytecode verification makes the card’s security more brittle, by encouraging VM developers to rely too much on static verification rather than runtime checks (which also prevent other runtime attacks, for instance using fault induction). More than ten years later, most people admit that this was not the way to go, and I just go one step further by stating that bytecode verification is not that useful for runtime security.

Bytecode verification and application vetting

Bytecode verification simply consists of a very simple static analysis of the application code. Basically, this is is a program proof, but a very simple one, whose complexity can be controlled. The objective of such simple proofs is not to demonstrate that a program is correct with respect to its specification, but that this program obeys a predefined set of properties.

For Java bytecode verification, these properties are related to the proper ues of the bytecode instructions. However, the same algorithms can be extended in order to prove many more properties, covering many aspects of application security. Among the things that can be proven, we have the following:

• Method M is not called.
• Method M is not called with arguments A1, …, An.
• Method M is always called before/after method N.
• Method M never throws a NullPointerException (or any other exception).
• Command INS can only return status codes SW1, …, SWn
• Toolkit buffers are only used when they are available.
• and many more.

Of course, there is no magic. When extending static analysis to many properties, it becomes more and more difficult to avoid false positives, i.e. errors that are caused by weaknesses in the algorithms. Put simply, an application is rejected although it is in fact correct.

Apart from working on the algorithms to make them better, there are two ways to deal with this issue:

• Providing the verification tool to developers, together with explanations about the rules to follow. Usually, it is rather simple for developers to ensure that their application can be verified, provided that they can use the tool throughout the development process.
• Use the tool in a vetting process as a guide for evaluators, who then perform additional verifications. In that case, broken rules are considered as warnings, and then verified by the evaluators. Simple applications can usually be verified easily, and more complex verification requires a few checks, simplified by the fact that the most boring tasks are performed automatically.

I believe in both approaches, but the second one has been proven efficient by my then colleagues of Trusted Labs. By using such a static analysis tool, they are able to optimize the vetting process of Java Card applications (and MIDlets, but this is another story) significantly, by allowing them to focus on the the most important parts of the applications.

In addition, this approach allows us to include many more security rules. For instance, hybrid applications must include code that can be modified into attack code through a simple attack. It is possible to build a library of patterns of such code sequences, and to check for them statically. Then, evaluators can be warned of the possible presence of an hybrid attack and check for it. This can be promising, because such checks (very boring to do, but very unlikely to lead to anything) are usually poorly performed by humans.

Finally, extended bytecode verification, or static analysis, has been proven to be a very efficient optimization tool. All optimizing compilers include a static analysis phase to perform their most complex optimizations. Java Card can take great advantage of this, because of the isolation between applications, and also because of the closed world hypothesis that is sometimes possible, when cards are closed (no additional applications can be downloaded).

So, bytecode verification has many uses in Java Card, but runtime security just isn’t the most compelling.