The technology is now ready, and it has not evolved greatly in the past few years. Java Card and GlobalPlatform are mature, widely deployed technologies; many companies are able to develop and deploy cards. Of course, there are a few technical challenges remaining, to keep engineers busy. One of the most challenging tasks is the establishment of trust between the various actors of the industry; today, formal security certification is at the heart of this, but something a bit more innovative will most likely be required here.

The new frontier for cards and secure elements are applications. This is much harder than implementing technology, and requires a lot of innovation. Will we be able to differentiate smart cards from tags? Will we find a room for card applications between basic SIM authentication and TEE applications? Will there at some point be a way to work on this? That’s the Chip-to-Cloud challenge, and I hope to get a few interesting answers next September.

The Call for Papers is out now, so go ahead, propose things. I am convinced that this conference will remain one of the places where academics, industrial R&D, and technical marketing people are able to meet and exchange. See you there!

Just imagine a world where a company can deploy its preferred network security application on all devices, while benefitting from SE-based security, or where innovative ccompanies ccan design security applications that rely on SE applications. Sounds good? Well, too good, because this is just not our world, at least not today.

There is an obvious reason for this: the “owners” of these eSE’s, whether they are phone vendors (Nokia, Samsung, …), wallet vendors (Google, Isis, …), or others, are not opening their devices. It is therefore very difficult to load applications on them. The most open environment that I know is in France, with AFSCM, but as far as I know, this is an operator-dominated, SIM-based world, which has a long history of managing resource-constrained SIM cards.

So, why is it different with the relatively new players who own/manage embedded Secure Elements? My gut feeling is that memory limitations are part of the problem, if not the entire problem. If you think of an iPhone, memory is almost infinite: if you are missing memory, simply remove one or two songs out of the 2000 that your phone contains, and it fits. On an eSE, things are different: think of a 64k SE. If it already contains 4 applications, each using 15k of memory, there is no way to add a fifth one. The numbers are here very different, and the choices are much more limited. I don’t think that many iPhone users ever get to the point where they need to eliminate content that they really need to fit another content that they also really need. On a card, no such luck. And for a platform manager, this is very difficult to deal with, so their priority will be to get their applications on this, or at least the applications that can bring them immeddiate and/or obvious returns.

The problem is very different with a Trusted Execution Environment (TEE). Applications are here stored in the phone’s main memory, so there is no shortage of memory. This means that, for TEEs, it should not be too hard to actually use app stores or similar infrastructures. For eSE’s, we will need to work a bit more in order to achieve the same result.

My first post will be a rant about something that is very-much holiday-related for me: package deliveries. I am a big-time online shopper, which means that I often get deliveries. And of course, during the holiday season, I get a lot of deliveries, from many different vendors.

Until recently, My deliveries were all coming to the office, as this was a local tradition in our Trusted Logic office. However, now, I work in an office with much fewer people, and sometimes from home, so it is not as easy to organize deliveries at the office. So, this holiday season, I got everything shipped at home.

Of course, I live in a closed residence (some code is required to get in), and my postal address allows you to find my mailbox easily, but not necessarily my house (no street numbers). All of this makes me a perfect guinea pig for testing delivery services.

So far, the best service remains the basic Post Office service. They have the key to the mailbox, so they will use it for anything that fits in it. Just great. Of course, if it doesn’t fit, I have to run to the Post Office and stand in line for a while. Even their express service is worse, because they need a signature. So, if I’m not home, they will not leave the package, however small, and I’m back to the Post Office.

With other delivery companies, things get much worse. First, going to the Post Office is not an option, because their “regional center” is often 30 or 40 kilometers away. Then, they don’t have the key to my mailbox, so they won’t leave a package, however small.

And finally, they call you when they are blocked right in front of a locked gate, or waiting outside your door. Even for me who works close from home, this is not very easy to handle, because we are not always immediately available, and because the guy can’t wait indefinitely. In the end, the “express” package took 24 hours to rush from Hong Kong to Nice, and one full week to get delivered. Not efficient.

So, what’s missing? Let’s consider two things:

• I can’t manage the delivery. I can track the package, I can know that the delivery guy has started and will try delivering to an empty home, but I can’t do anything about it.
• I can’t sign off for a delivery when I am not home. So, the guys won’t leave the package in my mailbox.

Now, if we look at both issues, we easily find out that this is a trust issue: delivery companies are not sure of who I am, so they will not trust me. Why so? Because they are not able to associate me to my package when I am at home, in front of them.

This definitely looks like a problem that can be solved. Companies like TrustFabric already allow you to selectively share information with companies. They don’t support this yet, but there is definitely some information that I would like to share with delivery companies (possibly including a detailed map, GPS coordinates, or whatever may get them to me).

Having this link through a trusted third party also solves the other issue. If I simply associate my TrustFabric account to a public credential (OpenID or similar), I can now login to their site and update the directions for the delivery, to lead them to where I actually am, or to acknowledge the fact that I am allowing them to leave the package in my mailbox without a written signature (a digital one will do).

As TrustFabric and others are getting their offers ready, this is getting closer to reality. Let’s hope for this new year that they will cover this delivery nightmare, and I will not have to do the same rant.

Here is the sentence that first drew my attention:

A wallet you can lock. Stay safe with the Google Wallet PIN and with secure underlying technology.

This started again my love/hate relationship with Google. A wallet you can lock? It’s just brilliant, far better than anything else I have seen on the same topic. Where do they find these things? Now, let’s see how the rest fares, from their Security section.

Google Wallet stores your encrypted payment card credentials on a computer chip on your phone called the Secure Element.

Sounds good. The Secure Element is explicitly defined as a separate chip. I find it interesting that they feel the need to mention that the credentials are encrypted.

Think of the Secure Element as a separate computer, capable of running programs and storing data. The Secure Element is separate from your Android phone’s memory.

Once again, all of this sounds good. Very nice way to describe a smart card.

The chip is designed to only allow trusted programs on the Secure Element itself to access the payment credentials stored therein.

Uh oh! I really recognize my favorite Java Card firewall, isolating applications from each other. But I am a bit disappointed to read that the “chip” is designed to support that. Yes, the chip’s memory can only be accessed from the chip itself; but on the chip, the isolation is software-based.

Next step, the FAQ’s Security and Privacy section. Among basic questions about lost phones, there are two good questions related to secure elements:

• What is the Secure Element and how secure is it?
• Could a malicious application access my credit card on the Secure Element?

You can read the complete answers there. However, here is what should be the most important sentence, since it ends the answers to both questions:

There are multiple levels of protection for data stored on the Secure Element and it is protected at the hardware level from snooping or tampering.

Of course, smart card specialists know about all the terrible attacks hidden behind the “snooping and tampering”, and how to protect from them. But the sole mention of data is a bit disappointing.

The answers also mention several times that only the Google Wallet (and other authorized programs) can access the Secure Element, and that this access control is strictly enforced. This is good, and we all like the fact that access control is present.

Now, what’s missing? You may have guessed it from my “data only” disappointment. There is no mention of the fact that the secure element can do more than payment. So, Google, if you are reading this, I will go as far as writing the missing FAQ piece:

Can I use my Secure Element for protecting other assets?

Your Secure Element is a small but powerful chip, which runs its own applications to manage sensitive data. It can even host several applications, to provide different security-related services. Of course, since the access to the Secure Element is strictly controlled, only authorized developers can write applications for it. We have selected a limited number of partners, who provide applications that rely on the Secure Element to manage their security credentials. These offers include VPN application, secure authentication applications, and much more.

Hoping that it will become useful someday. And if you need more material on Java Card, just let me know.

It is not the first time that I consider joining this team (considering all kinds of positions). It never worked out with Sun, but Oracle offered me the change that I was waiting for at this time. Also, I appreciate the challenge of joining one of the leading Silicon Valley companies, even if I am only remotely connected to the heart of the company.

There are many challenges to be faced. Java Card currently dominates open smart cards, with very high penetration rates. Of course, I will work to make this domination continue, to make Java Card’s success continue in the coming years, and more importantly, to make Java Card the best answer to the challenges faced by the digital security industry.

This should be rather easy, as I still believe after 15 years that the Java Card technology is the best choice for the industry. Those who know me already know that I need to truly believe in what I sell, push, or promote. In the case of Java Card, this definitely is true, so I look forward to my new job with great envy and energy.

I will naturally attend the Cartes show in Paris. So, if you plan to attend, see you there next week. I may be stuck in meeting rooms most of the time, but you can still reach me at firstname . lastname at oracle.com .

Last but not least, I will keep this blog open for now. My bias in favor of Java Card won’t be really worse than what it already was, and hopefully, I will gain some freedom on other topics, and the tutorial will make a comeback.

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.

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.

The first thing to know is that it is much better to have a car when you visit Gemalto, because the sites are in industrial zones, and staying there will not be fun at all. I will not cover here the hotels in these areas, because they are way too depressing.

Staying in Gémenos

In Gémenos, the best place to stay by far is the Hostellerie de la Source. It is a very nice independent hotel, in a wonderful surrounding, and very nice tenants. The pool is very enjoyable, and the conteinental breakfast they offer is just perfect, at least for me. Some may be annoyed by the fact that they don’t have a restaurant, but I see this more as an opportunity to get out of the place and be active.

If you stay there, there is a restaurant at the entrance of the Gémenos village, Chez Marius. I really liked it, with good, simple meals, and a wide variety to choose from, including grilled meat and pizzas; also, they offer a 25€ 3-course menu that can be fully satisfactory.

Other restaurants that I liked in Gémenos include Le Clos, on the road from the village to Gemalto, on your left after the schools. A very nice place, with great pizzas. If you take the menu, and especially if you start with a pizza as first course, be ready to leave with a full stomach… I also tried the Bar Ideal (with a big sign reading “Goûtez la Provence”). I am not sure that everything they serve is good, but their aïoli was just great, with snails and mussels in addition to the traditional cod and vegetables. If you don’t fear garlic, their terrace is a nicce place to be in a spring or summer evening.

If you want to adventure outside of Gémenos, the Hotel du Parc offers a good restaurant (I haven’t tried the hotel, but the location sure looks nice), with reasonable prices.

Finally, if you are more into luxury, the Relais de la Magdeleine is a very nice restaurant, pricier than the others I have mentioned so far. I haven’t tried the hotel, but it should be nice.

Hiking around Gémenos

One of my favorite activities around Marseille is to go hiking in the small mountains surrounding the city. If you stay at La Source, you are quite likely to have a straight view into the Garlaban, which is famous (at least in France) for the Marcel Pagnol youth memories. Here is a hike up the Garlaban. Be careful, because it’s a bit long, and it took me over two hours of walking. Also, there are a lot of rocks on the trail, so good shoes are a good idea. I did this hike in the evenig of June 21st (the longest day), and ended at night, just in time to go to the Fête de la Musique in Gémenos. The view on top of the Garlaban is just wonderful, and definitely worth the hike.

On the opposite side of Gémenos, there is the Sainte-Baume mountain. It starts with the Vallée de Saint-Pons, which is a wondeful valley, with a small but powerful river in the middle. I did a hike through the valley and started climbing a bit from there. This is a wonderful hike, because itstarts with the lush valley, and then leaves it to climb for a while on the mountains, with the bushes of the maquis.

Another possibility is to drive up the mountain, to get better views. If you follow the road, you will get to the top, and then you can climb up to “The grotto” which is a catholic sacred site. I haven’t done this hike, but it is a really easy climb). Instead, I tried to climb the Pic de Bertagne, which gives its name to the street on which Gemalto is. This hike didn’t turn out well; halfway in the climb, I noticed fresh wild boar traces, heard a few boar noises, and decided that, alone, at dusk, it wasn’t worth it. I turned around, and climbed of the other side of the pass, to take my picnic sitting on the border of the mountain, which saved the hike. On the way back, I took a look at a path going down on the other side of the mountain, until night got me back. This basically show that, at the Col de l’Espigoulier, there are many options, and all of them are nice.

I hope that these little suggestions can help a few people have a good time around Gémenos, and enjoy the nature. This area is nice around all seasons, although the end of Spring is a really nice time to visit, especially with the long evenings.

Here, the idea is about developing an application that would run on NFC-enabled phone, and that would catch all NFC tag traffic, proposing whatever action the tag was meant to propose, but also proposing alternatives. Here are a few potential uses for it:

• Propose alternative opinions. For instance, let’s imagine that a Google tag on a restaurant window redirects you straight to Zagat. This application may offer you some alternatives, like Michelin or Yelp.
• Do something else with the tag. For instance, a tag installed by a city on a monument to provide tourist information could be used in an interaactive game. When the user scans the tag, something happens (for instance, some additional information is disclosed).

There may be a business model behind such an application, but we must remember that the title of this post include the term “hijack”. Using somebody else’s infrastructure that is left in the open may be acceptable/legal/moral, but if we go too far, I am sure that some countermeasures can be put in place. However, this sounds like an interesting non-commercial project. Here is how I see it:

• Community project. The open community is required in order to create the alternative content. Without content, this mombile application simply is another indirection when using tags, which is not good.
• Linked to other community projects. An obvious link is Wikipedia, which could provide alternative content for all kinds of monuments, public places, etc. But I am sure that there are other projects to draw from. The good thing about this is that it reduces the production of content to linking tags to new URL’s, which can be much faster than writing the content.
• An experiment with tags. What people do with tags today is very boring, and we are expecting more ideas to come. Such a project could be tthe base of a wider experiment based on tags.

I am not good at starting/managing developer communities, and I will soon have little time to do this. I have thought about a few things around this, that I would be happy to share with people interested to work on this, but my meager Web development skills have stopped me from starting a real implementation. This thing just sounds like a very nice group project on Mobile Web, with a mobile client, a Web site and database, a sprinkle of NFC for the hype, and much more later. If you’re interested, please drop me a line, as I would like to keep a (distant) eye on such a project.

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.