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.

2 Comments

  • Hello Eric,

    I’m not sure about the memory argument.

    I think smartcard manufacturers can provide easily smartcards with more memory. There are some residual products in the market with huge memory sizes (for a smartcard). I think they do not do so for 2 reasons:
    1.- They have no real demand for it
    2.- They want to have a portfolio high different prices and features (die size can’t justify difference between lower-end and higher-end model prices, IMHO).

    What do you think?

    I’m looking forward to more posts on TSM world.

    Regards,

    Josep

  • Hi Josep,

    I agree with you: large chips do exist, and they are not much used because of low demand. Here, I believe that the issue comes from the people who buy the embedded chip (device vendor, Google, whoever). The idea is to convince these buyers that, by adding a few cents to the eSE price, they can have a one dollar return.

Leave a Reply

Your email is never shared.Required fields are marked *