Beyond Java Card

When Java Card was created, the market for smart cards was quite simple: chip vendors would design specific chips, chip vendors would develop an operating system for the chips and produce cards embedding the chip. Since then, this market has become much more complicated. For traditional payment and ID, changes are minimal, as card vendors often keep a central role. On mobile phones, the security landscape has greatly evolved, with embedded SIM cards, secure elements offering multiple applications like mobile payment, and even security hardware embedded in main chipsets, for instance around a TrustZone architecture, which is used to control security interfaces like fingerprint scanners. Finally, there are new potential security requirements, such as the internet of things, where security is becoming important.

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.

Java Card LinkedIn stats

I was looking for updated statistics on Java Card, so I turned to LinkedIn to look at the Java Card skill. The information available is declining a bit (for instance, there is no trend or relationship to age any more, or at least I couldn’t find it). Yet, it reveals interesting information. Over 3000 people […]

Inside Java Card: From APDUs to CAP File and Interoperability

As promised in the previous post, here are a few Java Card stories. Over the almost 20 years of Java Card history, many design decisions have been taken on the product: some successful, some less successful. Here are a few stories of these discussions/decisions. API vs. APDU Before Java Card, a smart card specification consisted […]

Java Card, a farewell

My Oracle story has ended, and with it my Java Card story, at least for now. I started working on the technology in February 1997, and I have never been very far from the technology for almost 20 years. However, Java Card is not in the scope of my next job, as I will focus […]

Fiction (maybe): Who will refuse to break a secure element?

Apple is refusing to break an iPhone for the FBI. I believe that they are right to do so, but also that this position isn’t that easy to stand for everybody. So, here is a little fiction (well, I think it is fiction) about this. The iPhone is a secure device, so the best way […]

Fashion statement

I am just out of the Cartes show. A bit depressing, mostly because of the current circumstances and the number of “Absent exhibitors”. However, there werea few interesting highlights. One of them came in the Wearable and IoT conference track, in a presentation from Oberthur’s Olga Titova Candel about Wearable Payments for Fashion. The main […]

About PIN, the iPhone is about 20 years behind smart cards

I was astonished when I read this article on breaking the iPhone PIN. Some guy has built a device that can guess your iPhone PIN, and he is using a very old trick that was performed on cards years ago. Of course, the exercise is pointless; as noted in the original article, Apple can (will) […]

Did Apple just boost mobile security?

I have been working on mobile security for many years, and things haven’t moved much: justifying mobile security is always painful. Whyshould Ispend more money? There aren’t that many attacks! Some business use cases seemed like a good justification, but the economics are unclear and remain in the order of “if youget hacked, it could […]

The Off-Card Bytecode Verifier is fine, thank you!

REWRITTEN on 23 Nov. 2013. 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 […]

Twitter going feudal on security

I have recently experienced security issues with Twitter, as my account was in some way hacked. And I am not happy of the way Twitter handles this situation. First, here are the facts that I know: Two weeks ago, a got an e-mail from a colleague warning me that he just received a spam Direct […]