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.

So, about the Internet of Things, as suggested by @tcarlyle, I looked at Everythng. I really liked it, and their basic engine is very interesting. What they are doing in the social area is interesting, as they take a fresh look at advertising (with real interaction). Their offer is definitely worth looking at if you want to do something with objects. And the fact that they are looking in parallel at smart and “dumb” objects makes their initiative even more appealing.

However, I still get the feeling that there is a strong interest in going one step further, really exploring VRM here. For instance, on approach like Onecub, which helps users organize and manage their incoming e-mails from retailers and service providers, sounds really interesting. This kind of engine, connected to Everythng’s “thing” engine, could efficiently link the Internet of People with the Internet of Things, because we certainly don’t want to get unfiltered messages from all the things we know (and their makers/vendors/distributors). By the way, @Onecub, I would love to take a look at your private beta.

In the end, it looks more and more that some experimentation will be possible without necessarily having to go through too much of a backend effort, building on these upcoming technologies. Which brings me to the implementation side, with NFC. I have tried a few applications that perform actions when scanning tags.

The first one I tried was Tagstand’s NFC Tag Launcher. This application seems to work nicely, but it requires to use their own tags (they supposedly ship some free, but only in the US). I did try it anyway, because their application can also perform some actions when connecting to a Bluetooth device or to a Wifi network. That’s actually interesting, as such events can happen when arriving in the car or at home. For me, turning my phone’s loud ringtone on automatically when I get home is useful.

The second one I tried was NFC ReTAG Free. This app does about the same thing as the previous one, but it can do it with any NFC tag, including my old conference badges (and I have enough of these to organize quite a few experiments). This application works fine, and I have been able to associate some behavior to old badges. Sadly, in practice, the app is made less interesting by Android’s design choices when several NFC applications are available. Like in other cases, a chooser is displayed, that allows me to choose in a single click between the various tag-reading applications. However, this chooser does not include an option that allows me to make a permanent choice: a chooser is displayed every time.

If I try to second guess Google’s intentions, I would say that they simply want to avoid applications that would hijack all NFC interactions. However, Google also describes the main value of NFC as the streamlining of the interaction: you read a tag, and you immediately get what you want. In that particular case, this value falls as a collateral damage to another policy.

If we dig a bit deeper, this shows that the preferred model for Android NFC is a closed model, in which an application is associated to a set of tags, issued by the same company. In that case, they will use private NDEF content, which guarantees them that their tags will trigger their applications. Open models, in which a tag can be used freely by several applications (letting a user select a preferred app) is more difficult. I still believe that such applications are very promising for NFC, in particular in publc spaces, but the interaction may not be as fluid, at least to start with.

Now that the Layar app is reading QR-codes, we can see how similar applications may rapidly become the front-end to our smartphones, and NFC tags will be losing some of their competitive advantage if they can’t trigger this app automatically. Let’s hope that this feature will keep evolve in future releases of Android.

Connecting home appliances sounds kind of obvious, and the ubiquitous availability of smartphones and tablets makes it even more obvious. I have many times left my clean laundry sit in the washer for hours, just because I turned the thing on and forgot about it; no doubt that a message on the phone in my pocket would be a welcome reminder.

The devices shown by LG seem to be rather high-end stuff, with rather large LCD screens for the interface (and no buttons, so these screens must be tactile). Apparently, these devices are running Android, which could mean that we will soon find Android applications targeted at washers and refrigerators. This is great news at least for one point: I have no doubt that independent developers can imagine applications on appliances that LG wouldn’t dream about, and opening this market could lead to real improvements.

Now, I am wondering: do we need a smartphone in every home appliance? Do we need a 7″ screen on every appliance? A few rich geeks may answer yes, but most people are quite likely to stick with much simpler interfaces and cheaper electronics. You may have guessed already where I am heading: Java Card 3.0 Connected is the way to go. It has many qualities required to do that:

• Web-based application model. A Java Card 3.0 servlet can provide the required communication link between an appliance and the controlling device, using a fairly simple and well-known application model.
• Dynamic management of applications. With the addition of GlobalPlatform specs, Java Card 3.0 supports a wide range of application management models, and it could in particular be used in an application store model. For those who doubt, we can remind that the Java Card/GlobalPlatform is already used on a few billion devices, so scaling up is not a major issue here.
• Small footprint, possible single-chip integration. Adding a full Android device to a US$1,000 washer is not a big issue, but adding the same device to a US$100 coffee machine will have a significant impact on its price.

Of course, it lacks a few things, in particular regarding I/O’s. In order to control an appliance, Java Card 3.0 needs to be able to control a few I/O ports, including a small display. But these APIs already exist in other embedded Java dialects such as MIDP, so why not doing it?

The bottom line is here that we can achieve with Java Card 3.0 Connected results that are quite similar to what is possible with Android, while making it accessible to a much wider range of devices. The only question is: Who is going to define the few missing APIs and make a reference design for a network extension board for appliances? I would definitely like to be part of that, but I’m not the one who will do the electronics part.