On the technical side, these financial applications are all SIM Toolkit applications. This means that the applications are actually running on the SIM card, simply delegating the interaction part to the mobile. The interface with the remote servers is usually performed using SMS. Of course, this is a financial system, so the level of security must be sufficient to reduce fraud to a minimum.

Among the features that contribute to the security of the system, we have:

• Private network. Mobile networks are private, which makes them more the information that circulates on them more difficult to attack than the information that flows on Internet.
• Application running on the SIM, with some cryptography. SIM cards aren’t the most secure smart cards, but getting access to the data stored on a SIM card remains a long and difficult process, even for card evaluators. So, stealing/forging keys is hard.
• SIM Toolkit driver buried deep in the phone’s software. Since the application logic is on the SIM card, the mobile phone only provides a generic driver that manages the user interaction. This driver is handled by the phone’s baseband processor, which is usually not the most accessible piece of software. As a result, it is difficult to attack this interaction

Don’t get me wrong; I am not claiming that the system cannot be attacked. I am just claiming that the inherent security properties of SIM Toolkit applications are sufficient to guarantee the security of the small data transfers performed daily in developed countries. Now, if you want to use that system to buy a €500,000 house, I may want to take a very different stand.

Actually, the main reason for which this reasoning cannot be extended to developed countries is that SIM Toolkit definitely went out of fashion with the advent of smartphones. The STK text-based interface is simply not acceptable on today’s phones, where we expect fully interactive applications.

That means that our current status is quite different with our smartphone applications:

• Internet connectivity. Forget the private network, we are connected directly to the Internet, and that’s where we want to do our transactions.
• Mobile applications. We get our applications from our local application store, so protecting data (both in storage and in communication) is a bit hard.
• Customized interactions. We like our interactions to be customized for each application. In many cases, the interaction at least partly comes from Internet, and HTML5 is going to make this more common. Here, no need to attack a low-level device driver to get to our stuff.

So far, this is fear-inducing rhetoric. You should be afraid, because your applications are not secure. Yet, there aren’t that many attacks, and mobile transactions are becoming more common on phones. With the announced success of NFC and the announced Google wallet, the future is looking bright in 2011. One of the reasons is that secure elements are becoming fashionable again on smartphones. Another one is that Apple, Google, and the others are keeping a rather tight control on our devices, and the users feel safe. Jailbreakers pose a small problem, but this is marginal for transactions (hint: if a payment application gets hacked on your jailbroken phone, “losing” the phone and denying the jailbreak sounds like a good option). Overall, I have no problem performing transactions with my phone today.

The really interesting question is: Would I feel just as safe if one of the financial app became as popular as M-Pesa is in Africa? A financial transaction application installed by 50 million users in Europe and the U.S. would sure make a tempting target for hackers around the world, especially with the average balance of our accounts.

In such a case, I would be tempted to say that the various stakeholders would like to have a few additional guarantees. The smart card and security industries have some answers to that: Let’s perform Common Criteria security certifications on cards to prove their security! Let’s add a security layer in the phone to enhance its security! Let’s obfuscate this application to make it more difficult to hack!

All of these things work, and some of them even work well. Each counteremasure makes the cost of attacking the system slightly higher. But all these things provide incremental improvements, and they are definitely not disruptive. Disruption is more likely to come from the outside, from the “hundreds of start-up companies” promised by Eric Schmidt around NFC.

An example: Bump. It is not about NFC, but it is a mobile security measure that “makes connecting as simple as bumping two phones into each other”. It relies on humans to perform most of the security checks, and leverages this on Internet. This is the way to go as our mobile devices become more personal, as they get closer to actually representing us on the Internet; the human being who holds the device will need to participate actively in the security protocols, and not only be entering a code. Disruption will come from those who make the security experience better, not from those who make the mobile experience more secure.

Wired claims that the intention behind the change is to force customers to buy two SIM cards: one for their iPhone, and one for their iPad. That’s an interesting hypothesis, and a possible new use case for SIM cards: use several formats to force customers to have several SIM cards. Of course, the network operators are accused of trying to get customers to get a mobile data subscription for each device they own.

Such a use of a SIM card certainly does not seem to make any good to anybody, and would reflect really short-term thinking from MNOs, and even worse thinking from SIM vendors if they started pushing this as an advantage of the multiple factors. Here are a few good reasons why this idea is bad:

• First, an iPhone is a phone, and an iPad isn’t. This means that, once you remove your SIM card from your iPhone, you can’t be reached on your mobile number. Unpractical, for the least.
• Then, an iPad is not as small as an iPhone, and it is much more likely to be used in WiFi than 3G, at least as long as there will not be a pricing plan that makes the use of 3G affordable.
• The contacts in the Mini-Sim and Micro-SIM are in the same configuration, which means that it is easy to build an adapter from Micro-SIM to Mini-SIM. So, if you have a Micro-SIM, you are able to use it in a device that requires a standard SIM card.

So, this definitely isn’t the killer use case that we are looking for. Locking in final customers, through formats or anything else, does not look like a promising use case for a product, and we should rather think of making these customers’ lives easier.

The interest of this project is to combine the expressive power of Java Card 3.0 with the sensors offered by the SunSPOT, such as accelerometers. Because the SunSPOT platform is extensible, it is also possible to experiment with sensors that are not supported by default.

In terms of implementation, it is in fact two different projects:

• A Java Card 3.0 experimentation on SPOT. It is just an expeimentation, because there has been no real attempt to make this implementation compliant to the Java Card 3.0 specification.
• The PlaySIM daughter board project. The idea is here to connect a phone’s SIM connector to the PlaySIM card, itself connected to a SunSPOT. In order to make things easy, the PlaySIM board includes an actual SIM card, which takes care of the GSM network authentication. The PlaySIM board therefore filters incoming commands, processes those related to high-level services, and forwards the basic GSM commands to the actual SIM card.
• An eGSM daughter board. The idea is here to provide a terminal for PlaySIM. This then allows some M2M experiments with SIM cards, and experiment with connected objects.

An interesting part of this approach is that any protocol can be intercepted, including the very basic and very widely available SIM Toolkit protocol. The SunSPOT will insert proactive commands that corresponds to the thing.

The PlaySIM project is actually an open source project, whose idea is to cooperate with universities, SIM card vendors, and developers. The content will be available in a few weeks on java.net. The cards should also be available for sale in a few weeks.

Of course, there are extensions on the road, and one of them is to be able to simulate a WLANSIM, which is one or Telenor R&D’s pet projects.

Once again, this project is worth following. Hopefully, I will be able to tell you more in a few weeks.

We have seen quite a few of them lately, so let’s take a look at the current offer, starting with the oldest ideas ((I haven’t named the companies providing the technologies, but they are fairly easy to find)):

• Add a memory card.This is one of the oldest ideas around, related to all kinds of MegaSIM approaches, offered by most card vendors these days.
• Add a banking card. The idea is here to offer mobile banking without having to certify the SIM chip/application itself. The idea is quite smart, but it faces significant logistical issues.
• Add a Zigbee interface. The idea is here related to convergence, since Zigbee mostly is a home automation interface. It allows a phone to integrate seamlessly in a low-cost home network, and to use it as a controller for our environment.
• Add a WiFi interface. This one is the first of three items whose goal mostly is to level the field between mobile phones. By putting a WiFi interface in the SIM card, a network operator can get a level field and deploy a WiFi-based offer.
• Add a GPS. With such a SIM card, every phone becomes GPS-enabled, allowing promising location-based applications to be deployed.
• Add an accelerometer. With such a SIM card, every phone becomes GPS-enabled, allowing promising location-based applications to be deployed.
• Add a NFC interface. This is not exactly SIM-based, since an external antenna is required. Globally, the idea is the same as with WiFi and GPS: compensate on the SIM card the problems of the mobile phone.

For the last four features, the core business model is to provide an interesting feature to (old, low-end) phones that don’t have it. Sales pitches always sound interesting, because there seems to be a good business model for all of these things, usually based on the line “With our SIM, [choose your category] applications become available on all phones, even the oldest ones”. However, an iPhone has all the features, and combines them for its best applications. If you add a feature on the SIM, you will still miss the others. And also, in two years from now, you will get a new phone with all the nice features, but you will still carry the same SIM, with the now useless feature.

The other cases sound more interesting, because they add to the SIM a feature that is unlikely to be present on a mobile phone.

Adding more memory (even gigabytes) can be extremely useful if you need to store some data (or even some applications, for instance if you have a Smart Card Web Server, or if you have a NFC phone). However, because SIM cards have a longer development cycle, there will always be a steep price premium for embedding memory on SIM cards. So, the idea may be good, but it is only as valuable as the content that can be stored on the memory card.

Adding a banking card can address a very difficult issue faced by mobile banking and other applications that required security certifications. The development cycle of SIM cards is rather short (usually under a year), whereas the development cycle of security-certified cards is closer to two years. Therefore, it is possible to develop a security-certified SIM card, but it is much more diffcult to develop a security-certified up-to-date SIM card, including all the latest options and gimmicks. By embedding a separate banking card with the SIM card, the idea is here to remove that problem, by certifiying the security-sensitive card, while integrating it with a SIM card of the latest generation. However, having two cards make some other things more difficult: the cards will not share any memory, they are likely to use different keys, etc. In addition, there will be an additional cost, and the business model is not necessarily better.

Adding a Zigbee interface also is quite interface. Zigbee is a wireless protocol that is used in various applications, and in particular in home automation. By including a Zigbee chip, the SIM may allow the mobile phone to become a wireless command for home automation. The idea is very appealing to me, because Zigbee is just asbent on mobile phones, so this SIM card brings real additional value. We can imagine this SIM being bundled with a home automation offer provided by a mobile operator with a partner. The main issue that I see here is the most generic one for SIM cards; SIM Toolkit applications are now rightfully considered as having a poor interface, and many frameworks don’t offer any other way to access a SIM card from a mobile phone. For instance, JSR-177 remains widely unsupported on Java ME phones, and the situation is not better in most application frameworks.

This last remark is not good for the Zigbee SIM, and it is not good either for any SIM that includes a feature that must be used from the phone. As a smart card guy, I really, really, don’t like that situation, but there is not much that I can do to promote the access of the SIM from mobile applications.

Well, no. Not at all.

I have browsed again through the API, and I have searched for the SIM word. There aren’t that many instances of it, and most of them illustrate automated uses of the SIM by the operating system (e.g., the SIM can override the default MSISDN string). Actual interactions with the SIM are limited to the android.telephony.gsm package, which is now basically limited to a SmsManager and SmsMessage classes (with an obvious use), and a new GsmCellLocation class, which is just as obvious.

So, as we can expect, nothing has changed, and Google keeps ignoring the SIM. Since then, I have looked at the iPhone API, and it is not any better. The SIM is considered purely as an authentication token for the GSM networks, which controls some network-related information. There are at least two possible reasons for that:

• Technical/naive reason. Android, like the iPhone, has been designed in a place where GSM is far from obvious, and only represents one of the choices for mobile telephony. It is therefore not a great idea to allow applications to use the SIM, because it will then mean that such applications will only be deployable on SIM-equipped phones. Of course, this remark does not hold in Europe, or in fact in most of the world, where SIM cards are present on every mobile phone. In Europe and in other places like South America, even Java Card is present on almost all phones (well, in their SIM cards). Of course, our view of the world is quite different.
• Business/political reason. Android, like the iPhone, has been designed independently of operators by a company with a very strong image. It is not in Google’s interest to allow operators to get control over the phone through the SIM. The interests of Google and operators are quite different, and the only reason that I could see to push Google toward the SIM is the contract that links operators with Google in the countries where Android-based phones are deployed.

So, don’t expect too much from Google about SIM cards. There are nevertheless a few reasons to hope. First, Android is an open source operating system, so we just have to get our act together and write the missing parts. After all, the low layers of the OS must be able to exchange a few APDU’s, so we just have to send a few more. Then, with smart card Web servers apparently on the rise, there may soon be a very easy way to access your SIM card from many devices, including Android devices. Once again, this represents a few lines of code, and even Vodafone can write them if they really want.

And anyway, the real problem is: who cares? If SFR brings us the “G2″ to France, I am seriously thinking of getting one to replace my old Windows Mobile phone. SIM access or not. The real important thing is for our industry to keep innovating, so that actors like Google feel compelled to allow mobile applications to use SIM-based services.