Android Security

Mobile application platforms are interesting for smart card developers, because most mobile phones host some kind of a SIM card, which stands good chances to be a Java Card. Of course, if we are thinking in terms of Java Card 3.0, since the card is a Web server, there is very little to do in order to support cards.

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.

2 Comments

  • ismaila wane wrote:

    Thanks Eric for putting your perspective on this issue. We had similar conclusions on Android Forum last December.
    I am glad that someone of your caliber recognizes that Google needs to learn more about the importance of the SIM, and realize the opportunity with NFC. Funny enough, they are offering a 2D barcode solution for mobile phones. What’s next? RFID tags scanned with a JSR 257-like Android API?

    Looking forward to connecting with you some day.

    Kind regards,

    Ismaila Wane
    Contactless Data, Inc.

  • neil.young wrote:

    Hi,

    from your POV: Has something siginficantly changed here over the past few month? I mean devices are out now. What about SIM access capabilities?

    Regards

Leave a Reply

Your email is never shared.Required fields are marked *