No memory, no chocolate!

There has been some excitement lately about the fact that more and more phones are now getting embedded SE’s (eSE’s), associated to a NFC interface. Some of this excitement came from the ability to manage third-party applications on this embedded SE, as enabled by a whole range of GlobalPlatform specifications, and by the emergence of TSM (Trusted Service Manager) offers.

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.


Best wishes and post-holiday rant

First, since this is my first post of the year, let me wish you all the best for 2012, hoping that it will bring a lot of interesting things around mobile security, Java Card, and all these things. My first post will be a rant about something that is very-much holiday-related for me: package deliveries.


Google’s vision of Secure Elements

Google has launched its Google Wallet service, which uses a secure element in the phone to provide some security. Of course, Java card is in every one of these secure elements, but it is not the point today. I have just stumbled upon the Google Wallet page. Initially, I was looking for information about how


My first week at Oracle

The break is over! After a month spent on various family activities, I am back to work. My new job is related to the Product Management of Java Card at Oracle. This is at the same time very close to what I did previously (Java Card has been close to the center of my activities


Java Card is 15 years old

I just realized that I missed Java Card’s 15th birthday. This birthday was sometime in the end of October, 1996. I don’t have the exact date, because the only document I have is the Java Card API: Specification of the Java Virtual Machine and Application Programmer’s Interface, version 0.13, dated October 10, 1996. Although this


The misuse of bytecode verification

Bytecode verification has been an interesting debate since the very beginning of Java Card. Back then, in 1997, Java was very much about Java applets, and the bytecode verifier was the essential piece of software that allowed untrusted code to run in a browser efficiently (i.e., without doing expensive runtime checks, and without having to


Visting Gemalto in Gémenos

During the past few months, I have very often visited Gemalto in Gémenos or La Ciotat. I didn’t like it much, since it kept me away from my family. However, although I am very happy right now in Sophia Antipolis and don’t want to move from there, I was born and raised in Marseille, and


Hijacking NFC Tags

I have been thinking about tags for as a background task for a while, and one of my directions has been to look at the “hijacking” of tags. Here, I am not talking of replacing some tags by other tags (for instance pushing toward a competitor of a smart poster’s rightfful owner), as thie defnitely


Open Source, GlobalPlatform, and Java Card

The two concepts of open source and smart cards have not gone well together. There are some projects about specific applications and corresponding terminal-side software, such as the Muscle project for Linux, and the JMRTD library for e-passports (if you have one that you want me to mention, let me know). However, there are really


My Last Day at Trusted Logic

Today is my last day at Trusted Logic, after a bit more than 11 years. It has been a great adventure, and I really enjoyed the small company feeling, where one has to deal with one thousand different activities, giving many opportunities to learn on different fields. As I try to think about successes and