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.

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.

But there remains two good reasons to look at the security of Android in greater details. First, for a while, most cards will be traditional SIM card, so accessing them will remain an issue of APDU’s and SIM Toolkit. Then, a SIM also is a secure token, which should only be accessed using reasonably good APIs, with some kind of access control.

So, let’s take a look at Android.

The Security Model

The description of Android’s security model fits in a single document about Security and Permissions. The basic security model is for now very simple. It relies on Linux user IDs for file and database access controls. Roughly, each application is associated to a unique User ID, and the files and databases it creates are only accessible to itself. Naturally, there are exceptions to that strict rule, here in two forms:

• First, an application can choose to make a file or database visible to all other applications, by using a specific option at creation time.
• Then, two or more applications can elect to share the same User ID, provided that they both declare the same ID, and that they are both signed by the same autority. This sounds a bit weak at first, but it greatly depends on who signs applications, and we don’t really know that yet.

The second part is about permissions. Here, we have a declarative model that is quite close to the models used in MIDP 2 or in Symbian v9. If an application wants to use a security-sensitive features, it needs to declare this need, and it will then need to be granted this right, through a mechanism that is not defined at this time.

The list of permissions is provided here, and it includes quite a variety of permissions:

• ACCESS_LOCATION, ACCESS_GPS, ACCESS_CELLID, for the right to access location information (one specific method, or a general permission).
• READ_CONTACTS and WRITE_CONTACTS, for the right to interact with the user’s list of contacts (no permission is defined for other PIM information).
• RECEIVE_SMS and RECEIVE_WAP_PUSH, for the right to wake up automatically on network events.
• Many more permissions, mostly Android-related, including the uncommented FOTA_UPDATE permission, which sounded interesting and actually is, since it allows an application to trigger an over-the-air operating system update.

For certification purposes, we would have loved to see the permission model in Android go the same way as in MIDP, where the 3.0 permissions are so fine-grained that they are provide a really interesting way for an application developer to declare the security requirements of its applications.

In the end, this security model is quite simpler than the one we have established for Java Card 3.0, which allows applications to share objects while keeping a fine-grained access control on these shared objects (instead of a black/white option of making objects invisible/shared.

The APIs

First, a little warning. This exercise is solely documentation-based, and some impressions would need to be confirmed through experimentation (which could be done when I have some time). The first thing I did was to search “SIM” in the Android documentation, and here are a few things that caught my eyes:

• IPhone.authenticateWithPin method. Not a good start. The documentation explicitly states that “This doesn’t actually authenticate against the SIM card, but rather compares against the SIM pin stored in memory”, but it does not mention any kind of limitation in the number of attempts. Operators are going to love that API, especially if applications get an unlimited number of attempts.
• android.telephony.gsm package. Definitely looks better, since this package gives access to the SIM phone book, and to the SMS sending interface. Very interesting, so let’s have a look at the details.
  • ISimPhoneBook interface. Provides access to phone book information stored in ADN EFs (it does not sound that it would support USIM’s extended phone book, but this needs to be checked). The bad news is here that the documentation does not mention the android.permission.READ_CONTACTS permission or the android.permission.WRITE_CONTACTS permission. As described, this API provides a good way to implement many attacks, from a dump of the SIM contacts to an illegal update of these contacts.
  • ISms interface. Provides access to low-level SMS data from the SIM card, and also includes an interesting sendRawPdu method. Depending about how “raw” this PDU is, it could lead to interesting things. However, the documentation is so thin that it is impossible to figure out what this can do. Of course, we will also expect some kind of access control to be activated when this feature will be used.
  • SmsManager class, which (together with a few other helper classes) can be used to send SMS. The methods look good, but there is still no access control here, although sending SMS messages may incur cost. This case is worse than others, because the permission does not even exist, and nothing says that the user will get a chance to confirm the sending of SMS messages. We would definitely need a android.permission.SEND_SMS.

Wrap-up

So, what can we conclude from all this? I will make two “nice” conclusions, but I will then associate them both to a “but”:

• Android includes a security model that can work, with permissions that have a decent level of granularity, although they haven’t reached the level that we have in MIDP (especially in the forthcoming 3.0 release),
• but the application of the model is sloppy for now, and the state of documentation shows that the APIs have not been thought with permissions. The SIM-related APIs are a perfect example: I am confident that some permissions will be added where needed most, but only as an afterthought. And if security is an afterthought, it is hard to make it really strong.
• Android has thought about the SIM, and has defined some APIs to access it, which provde a very low-level abstraction of a limited subset of the features of a SIM,
• but Android considers the SIM card solely as a security token with a fixed set of features, and not as an open security element. For Java Card specialists, this is a real disappointment. There are of course many ways to add support for a feature through the definition of new APIs, but it is once again annoying to think that the use of secure elements (SIM or others) will be an afterthought.

There are of course other little disappointments. Android has no support for contactless interfaces (at least, searches for contactless, RFID, and NFC all lead nowhere). No certification process has been defined, so we will have to wait to see how Google addresses the application certification swamp.

To conclude, I would say that Google still needs to learn more about SIM cards in particular and smart card in general. There are quite a few “killer” mobile applications that use secure elements, such as mobile payment, mobile ticketing, and everything NFC-based. ignoring that would not be good for Android.

Still at the SIM Summit, Intel’s David Gordon made a presentation about the use of SIM cards on mobile computers. His first graph show that all of today’s mobile PCs support WiFi, while only a few percent support some GSM/3G connection. The interesting part is that he also sees this number growing to around 60% by 2010. After all these years trying to get a smart card on a computer, the SIM card may be winning it again!

And then, things get better. Beyond is traditional role, Intel has been working with the GSM association to get the SIM to do even more things. They released a document in which they explain that the SIM may be used to unify access and authorization methods across the PC, and also for content storage and DRM. The document also contains numerous references to security, including a threat analysis, which outlines a man-in-the-middle attack. The document also provides some guidelines. One of them recommends to connect directly the USIM to the 3G module, and to severely restrict that applications have to it (in particular, no direct access). This is a bit sad for the Java Card developers who would have liked to access this SIM card.

David Gordon also claims that the SIM card may be used for customizing computers (just like Purple Labs would like them to customize mobile devices). Except for content storage (which I personally doubt, especially on a PC, except for personal and private content), all of this is pretty exciting, because it means that the SIM card would also be available for additional (Java Card) applications, and that the secure personal server is getting a bit closer to us.

David Gordon concludes with a less consensual idea, with a mention of the “Soft SIM”, all implemented in software. Of course, that may have a strong interest for Intel, but as they mention, “what about the commercial role of the SIM as operator’s agent?”. More on this in a few days.

Jean-Marie André, of Purple Labs, made a presentation at the SIM Summit in Prague. I could not attend it, but the slides are very interesting. They show the changes that new SIM architectures will bring to mobile devices. Some of them are expected, like adding USB host support; some of them cause design issues, like the placement of a NFC antenna (the largest it is, the better the more power is gives when battery is down). In terms of software, some changes are also required, like a TCP/IP stack.

Jean-Marie André also makes one very interesting remark: the SIM has a life of its own, as it can initiate calls, connect to the Internet, etc. In several use cases, such as the smart card Web server model, the SIM can initiate a connection, or receive an incoming connection from the outside. This means that the phone will have to act as a router for the SIM card (I am not sure that all device vendors agree on this one).

Finally, Jean-Marie André proposes a use case for large memory cards, which corresponds fairly well to the discourse I have been hearing from Bouygues Telecom’s Cédric Nicolas about large memory SIM cards. The memory can be used to store operator-specific software, which will then be loaded on the mobile device upon pairing with the SIM. This infrastructure is of course very interesting for Purple Labs’ business model, and I am convinced that it could be interesting for many mobile software developers. But once again, how will Nokia and the other device guys take this?