These days, Android is a bit of a hot topic, for many reasons that we all know. It seems that a new device is released every week, the operating system is open source, so everybody can at least play with it and integrate low-level software, applications can be deployed, and most likely much more.
Android does not offer a Secure Element interface. Of course, Android phones are able to interact with SIM cards, but applications have no access to the cards, or to any other Secure Element (SE). And of course, forget about NFC access. Will that last? Of course not, as manufacturers and other service providers will make sure that they can build Android applications that use secure elements.
Apparently, Giesecke&Devrient has really started that war, by announcing a security solution for devices running Android. This is a combination of two things: a MicroSD card that embeds a smart card chip, and software that allows the Android platform to access it.
Cartes is about 10 days from now, so we can expect a few more announcements and demos to be made there. Trusted Logic has already announced a NFC stack for Android, and I bet that more will come.
For now, we can take a closer look to the G&D solution, especially because they have published their software on a Google Code Project.
This project is still evolving, so what I am writing is is a snapshot of its state on November 4, 2009. One of the latest additions is a paper called Security and Trust for Android. This paper contains a lot of information, as well as a nice vision, but it is also a bit confusing, and remains a proposal, as stated in the introduction.
This paper deserves to be read, though. Its main vision is that there are many SE’s that can be used (SIM card, MicroSD, TrustZone, Software SE), with different properties, and in particular with different security levels. Nevertheless, the paper insists on the fact that all these SE’s should be accessible through a regular API, and that there should be a similar way to program applications on all these SE’s. Now, that’s an interesting vision, although it is kind of hard to achieve (for instance, SIMs and MicroSDs both use Java Card applets, whereas TrustZone and software SE’s are usually based on native applications.
I have not looked in great details at what they offer, and I have not tried to use the software. However, I did take a look at the samples, in particular at the one based on the native interface. This interface looks quite nice and simple, and the sample is far easier to read than the one based on PC/SC.
Basically, this effort looks like a good way of making a SE interface available on Android, and to offer a way to interface with a particular kind of SE. This looks like basic software, and I am sure that we will need to consider many more aspects, like security, access control, and more. However, this is not the goal here, as the proof-of-concept definitely is the important part. Completeness (and complexity) will come later.
I would love to say more about the technical details, but it is late, and trying these things out takes time. I will therefore come back later to that topic. For now, I will close with a few non-technical comments:
- I like the fact that G&D has made the software open source. Obviously, the Android drivers and APIs are not how they intend to make money, so this sounds like the natural thing to do. However, this is the smart card industry, and secret is usually considered better.
- Hopefully, G&D will also work with the other actors of the industry in order to make this API the best possible. Since this would add more weight to their proposal, it also sounds like a natural thing to do.
- Even more hopefully, the industry as a whole will make sure that the Android developer community actually understands how to use these Secure Elements. This will require a strong educational message, which is just started by the G&D white paper.
The last remark goes to the Secure MicroSD product, together with its Android integration. It is a composite product, integrating a large memory and a smart card microcontroller; in addition, it is integrated on a Web-oriented platform. Well, that sure looks like a great target for Java Card 3.0 and its servlets. This would even greatly simplify the API requirements at the Android level, and also greatly enhance the appeal of the solution to Android developers.