Looking at this from a Java Card point of view, the main question is to understand the limits of Java Card. Should it be just a smart card framework, or a more generic security framework? Are there good reasons to use or not use Java Card on a particular kind of security framework? That’s what we explore in this last installment of my farewell to Java Card.

What makes Java Card good?

Or in other terms, “what’s the value of Java Card”? Java Card is a security middleware framework, which presents a portable interface to security functions typically provided by smart card hardware, and it is valuable because:

• It allows the development of reference frameworks (such as the SIM toolkit framework), and of reference applications (like Visa’s payment application), which can then be made available on all Java Card-compliant devices.
• It provides to developers a security framework that is relatively easy to use, where all the key functions (cryptography, authentication) are already implemented and available with predictible qualities on many commercial platforms.
• It includes a full ecosystem, including laboratories and certification authorities that are specific to the security community.

That may not sound like much, but when it comes to programming security environments, this combination is quite unique.

What can Java Card run on?

That may first sound as a strange question, unless we reformulate it as “Beyond smart cards, what can Java Card run on”?

I have stated for quite a while that Java Card is suitable for any dedicated security subsystem. Such subsystems obviously include all kinds of smart cards and secure elements. Now, what about other security subsystems:

• In preparation for the deployment of eUICC, mobile chip vendors are getting ready to integrate a security element within the main mobile chipset (as they do with all new promising technologies). Here, the idea is to include secure hardware, similar to a secure element’s, and to use some kind of TEE to protect its access. This kind of security subsystem is quite obviously a Java Card target, at least because it will most likely need to support the SIM Toolkit Java Card framework.
• Going a step further, Java Card could run on any Trusted Execution Environment. Some experiments have been made, showing that Java Card could be successful in that area. The debate is here whether this extension of Java Card’s realm represents a risk (for the smart card/secure element industry) or an opportunity (for the security subsystem industry).
• Going even a bit further, Java Card can run on any system that offers virtualization and the ability to have a dedicated security VM. This could be very useful in particular for low-cost devices, where it doesn’t make financial sense to include a secure element or even a full-fledged TEE. Note that such a dedicated VM could still achieve a good security level, by leveraging hardware mechanisms like TrustZone (now available even on Cortex M cores), or software mechanisms like formally proven software stacks.

Note that such extensions could require an evolution of the Java Card platform, at least because the memory model of these chips is different from the model used in secure elements. In addition, some additional features may be required.

What uses for Java Card?

The final step is to combine the value of Java Card with these opportunities: How can Java Card bring significant added value in these areas? We can take a look at a few use cases:

• On mobile devices, eUICC is likely to be a game changer. The combination of secure element technology and TrustZone in a mobile processor allows the implementation of UICC-like functionality, and the flexibility required to manage the environments provided by several network operators can be easily addressed with Java Card, since most operators already use the technology and have applications ported to the platform. In addition, this secure environment could be leveraged in other ways: (1) the TEE is not clearly established today, so it could be replaced by this environment, which offers similar or higher security features; and (2) this secure environment could be leveraged to host the applications that run today in the mobile device’s embedded secure element, if implementers are able to prove that they can reach the required security level.
• In the IoT market, the opportunity is to address the security of endpoints (the things). This market remains wide open, with no established standard. Most actors also have limited security know-how, and development cycles are very short. The Java Card ecosystem can here prove to be an essential competitive advantage, as it is relatively easy to develop Java Card applications and evaluate their security. Yet, in this market, we are missing a category of actors that would build the basic security services and a framework to deploy them easily on top of the existing Java Card and GlobalPlatform frameworks.

I am sure that there is more, but these two markets represent the major opportunities available today.

Long live Java Card!

Java Card technology has dominated the smart card industry for a while, and it now faces the same challenges as this industry, which may also be a great opportunity. Security is becoming a priority in areas like mobile phones and IoT, but secure elements are being challenged by new technologies for the implementations of security subsystems.

Java Card has the ability to be one of the technologies that will bridge the “old” smart card world with this new world, and I will close this series by wishing the best to the Oracle, the Java Card Forum and the entire Java Card community, hoping that they will be able to seize this opportunity and keep Java Card great for many more years.

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 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!

Although this draft was officially authored by Sun Microsystems, Schlumberger played an important role there. This is why I am quite sure that the spec was released at the end of the month, since one of Schlumberger’s main patents on the topic was filed on October 25, 19996. The main topic of this patent is to use a high-level language to program a microcontroller, and it claims in particular the transformation of a class file into a more optimized format. Quite a good idea, at least sufficient to include this patent in the suit against Google‘s Android (which may be a proof that Android is yet another derivative of Java Card).

Good idea, but everybody trying to fit something on a card was ddoing just the same. The really brilliant idea was not to generate an optimized format, but to believe that it would be possible to start from something as different as Java. This was brilliant at the time, especially since in 1996, Java was definitely not mainstream technology, and was often considered as too expensive or too slow even on a PC. Now, that’s something for which the guys in Schlumberger can be congratulated.

Of course, they were not the only ones to try fitting unlikely things into a smart card. Researchers in Gemplus were more focused on object oriented technology, in particular Corba. And naturally, they needed to think about optimization in order to fit this into a card. They were using Forth as their base language for the Combo virtual machine. Even before that, as mentioned in this history of bytecode interpreters for smart cards, researchers at RD2P designed a bytecode interpreter, as early as 1990 (I can’t even imagine the memory sizes of cards at that time; if somebody knows, please leave a comment).

Now, the interesting part is that a patent has been filed in France (sorry, in French only). And one of the key elements of this patent was the fact that the programs are later compiled for the specific embedded virtual machine.

Not quite Java Card, though, because the patent only mentioned direct compilation from source code, not using an intermediary format (a.k.a. Java class file). The difference is slim, and I would be tempted to credit the French guys with the invention of optimized smart card code. However, there is something that the Schlumberger guys did much better: timing. The French patent, filed in 1990, was never extended into an international patent, whereas the American patent has been extended and mainained to this day.

As a final trivia note, did you smile when I mentioned that Android was a derivative of Java Card? Well, very indirectly, but somehow, a little bit. Java Card, after being initiated by Schlumberger, was maintained by Sun Microsystems. Sun’s Java Card team later convinced Sun to develop a slightly larger VM, the KVM, to address very small devices. This VM was then extended into MIDP, which became the leading platform for phones. And everybody knows that the Android team includes a number of ex-Sun employees who used to work on MIDP. So, yes, indeed, Android a a distant heir of Java Card.

However, there are really few open source developments in the area of smart card operating systems and runtime environments. This is why the recent release of the OPAL library by the University of Limoges is significant. This library offers a client-side implementation of the latest GlobalPlatform specifications, greatly simplifying the development of applications that manage applications on smart cards.

In particular, this development could be the basis for interoperable and open smart card testing tools. For instance, the Mesure project, which defines benchmarks for Java Card, could use an open and complete GlobalPlatform implementation.

Now, can we go further than that? Is it possible to really get into the smart cards, and have open source operating systems, or parts of operating systems? Well, there are a few good reasons not to do it:

• Licenses. The specificatoins like GlobalPlatform and Java Card are free to access, but after going through a click-wrap license, including some restrictions. For GlobalPlatform, the restricions are limited, mostly because GlobalPlatform is a community effort, and both the license to use the specification and to sell products bassed on it are free. The Java Card license is more restrictive, because it is owned by Oracle. Java Card is free for developers, but implementers need to pay a license.
• IP rights. The smart card industry is highly competitive, and has not always been very open source-friendly in the past. There are literally thousands of patents that have been filed on the technology, and it is hard not to infringe on any of them while writing a smart card operating system. Companies don’t have to enforce their IP, but they can, which means that any open source project is in under a constant threat.
• Security. This argument may not be as strong, but the smart card security community is very well organized, with manufacturers, labs, national authorities, etc. They have developed a significant set of documentation and guidelines aound Common Criteria certifications of cards, which is one of the best industry efforts available today. The industry may not be eager to see an active open-source community working on attacks and countermeasures in parallel to their own efforts. And if they are not happy, they may activate the IP rights argument.

Of course, there is here a difference between academic projects and industrial projects. Consider Simulity’s DKard project, a microcontroller (i.e., smart card) virtual machine based on Android’s Dalvik VM. Google may have published Android as an open-source project (we can assume that the spec lcense part is covered), but this doesn’t make them safe from IP rights. If they start encountering the slightest success, somebody will remember that they infringe on their IP; and since this somebody is likely to be much larger than Simulity, this is not good news.

From my point of view, we can close the industrial part. It would be foolish to start a company with a business model based on open source software for smart card operating systems, unless it is strongly backed by at least one major manufacturer, with the ability to protect the small player from IP claims by competitors.

Now, we are left with the academic projects. There is an active research community around smart cards, focusing in particular on security aspects, particularly in Europe. One of the main problems faced by this community is that they don’t have a good playground: there is no open smart card operating system platform on which they can experiment.

Card vendors are not too keen to see academics use their products for experiments and attacks, because they don’t want to see publications claiming that their card was broken. As a consequence, card development kits usually come with licenses and non disclosure agreements that do not allow the use of the cards for research purposes.

The “obvious” solution is to develop an open source platform, just for research purposes. But then, we get back to the licenses and IP and everything. There are several choices, every one with pros and cons:

• Implement Java Card. Here, a conflict is likely with the industry, especially if the implementation is good and can help outsiders develop/enhance their products.
• Implement something else. This could work, but the difficulty is to find the right balance between mimicking Java Card and differentiating from the spec.

I don’t believe that the solution is ready here. Without industry support, getting funding for the research will likely be difficult. And the industry players may not look forward to sueing a few academic institutions. In the end, the stakeholderes need to talk to each other, really looking for a solution that suits everybody. This discussion never really took place in the past, let’s hope that it will happen some day, so we can at least remember that we tried.

Thoughts and remarks welcome, as comments or direct contact.

Let’s start by secret keys, used in symmetric algorithms like AES and DES. Such keys are just random values of a given length, without any strong mathematical property((Keys must verify some properties, though, as some values will not provide an adequate protection; however, the probability to get one of these keys is quite low, and no test is usually performed on the keys that are generated on a smart card.

A secret key therefore starts its life as a byte array filled with random data. For a triple DES key, we need 16 bytes of data. Two origins are possible for this data: it may be imported from the outside through a personalization command, or it may be generated on the card using a random number generator. Here is an example using a RNG:

  byte[] keyBytes = JCSystem.getTransientByteArray(COD,16);
  RandomData rng = RandomData.getInstance(ALG_SECURE_RANDOM);

  rng.generateData(keyBytes,0,16);

The next step consists in creating the key object and assigning the random data to the key object:

  DESKey key = KeyBuilder.buildKey(ALG_DES, LENGTH_3DES_2KEY);
  key.setKey(keyBytes);

When that is done, the essential is done. At this point, applet developers are not responsible any more for the protection of the key. The Java Card platform is in charge of implementing the key container classes in a way that protects keys from disclosure at all times (when they are stored and when they are used). In most cases, this means that the key values will be encrypted using another key, managed by the platform.

Applet developers should refrain from any attempt to protect cryptographic keys when they are stored in Key objects. However, the values of keys still need to be protected, whenever they are not stored in the proper containers. For instance, the raw data used to initialize the key should be cleared after the initialization. The initialization code therefore is as follows:

  try {
    rng.generateData(keyBytes,0,16);
    key.setKey(keyBytes);
  } finally {
    Util.arrayFillNonAtomic(keyBytes,0);
  }

With private keys (used in assymetric algorithms like RSA), things are even simpler, since there is a dedicated class to generate key pairs (a public key and a private key). This means that the actual key values are kept during the entire process under the protection of the platform.

Basically, the two rules about keys are:

• Keys stored in Key container are protected by the platform, and only by the platform.
• Plaintext key values should not be stored in byte arrays, expect for very short periods of time when absolutely needed, and the values should be cleared when then are not used any more.

Following them is a good start in the proper protection of cryptographic keys.

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.

From Onzo’s Tim Holley and Oracle’s Jean-Yves Bitterlich, this is about Project Hydra. The project starts by healthcare issues caused by an aging population. The problem is to figure out what we can do at the infrastructure level to help addressing tomorrow’s growing helath issues of our elderly. This basically means being proactive.

Telehealth is possible, but the data needs to get out of the home. And since we are not talking about highly connected people, smart meters seem to be a solution. Smart meters bring a communication path into every home, and telehealth only transfers little data. The idea is to integrate new sensors (health sensors, like a scale or blood pressure) into the devices accessible from the smart meter infrastructure.

The idea is to add value-added services into smart meters, making it possible to get a better return on investment on the deployment of smart meters. This is the goal of Project Hydra in the UK. The idea is to integrate telehealth services of weight and blood pressure. The project combines a local Zigbee network to an external GPRS connection at the communication gateway shared by all the meters.

So, why smart cards in this project? The platform need to be able to evolve over time, with remote software updates, or added support for new devices over time. Of course, security is important as well, and isolating the applications from each other sounds like a good idea (the utility company doesn’t need to know about your blood pressure). All of this sounds good for Java Card:

• Protecting valuable assets. Yes, smart cards do that.
• Devices distributed in uncontrolled environment. Yes, we know how to handle that.
• Personalisation during deployment. GlobalPlatform has everything it takes to do that.
• Protecting assets of multiple stakeholders. Easy with a good firewall and a few Security Domains.
• Remote software updates. This one is trickier, but why not …
• High volume, low cost. Yes, we know how to do that.

All these issues have already been addressed by the smart card industry. An interesting bonus is here that smart cards also address some basic smart meter issues, (security in tariff upgrades, management of pre-paid accounts, protection against hacking, etc.)

Naturally, combining Java Card applets and GlobalPlatform security domains, every application gets its own little home in the home gateway. One interesting remark is that the smart card becomes a one-stop shop for people who want to deploy new applications into the smart meters. But then, this raises the question: who controls the smart card in the smart meter? In a deregulated market like in the UK, this question may not be as simple as it seems.

An important point is that applets may address some privacy issues by performing some basic processing directly in the home, and to only transfer select information (for instance, when blood pressure is over a given threshold).

In the architecture, the smart card is pretty much in control, and they have defined a SIM Toolkit-like way of working, in which the smart card provides the terminal with instructions about things to do, like send this data to the outside, or wake me up for the next measurement 24 hours from now.

Java Card 3 Connected would also allow the user to access its own data directly from a Web browser. This provides a partial answer to one of my favorite questions: Would the (younger) family members be allowed to get the information? They have more incentives than clinicians to actually use the information, and such a use raises very interesting security issues, and even more interesting privacy issues, because the elderly have a right to privacy, even with respect to their children.

Surprisingly, the main problem is here to be ready on time, because in many countries, the deployments are scheduled before 2020, which is awfully close when you don’t even have a specification.

Good luck to this project!