Android secure element execution environment

In the previous post we gave a brief introduction of secure element (SE) support in mobile devices and showed how to communicate with the embedded SE in Android 4.x We'll now proceed to sending some actual command to the SE in order to find out more information about its OS and installed applications. Finally, we will discuss options for installing custom applets on the SE.

SE execution environments

The Android SE is essentially a smart card in a different package, so most standards and protocols originally developed for smart cards apply. Let's briefly review the relevant ones.

Smart cards have traditionally been file system-oriented and the main role of the OS was to handle file access and enforce access permissions. Newer cards support a VM running on top of the native OS that allows for the execution of 'platform independent' applications called applets, which make use of a well defined runtime library to implement their functionality. While different implementations of this paradigm exists, by far the most popular one is the Java Card runtime environment (JCRE). Applets are implemented in a restricted version of the Java language and use a subset of the runtime library, which offers basic classes for I/O, message parsing and cryptographic operations. While the JCRE specification fully defines the applet runtime environment, it does not specify how to load, initialize and delete applets on actual physical cards (tools are only provided for the JCRE emulator). Since one of the main applications of smart cards are various payment services, the application loading and initialization (often referred to as 'card personalization') process needs to be controlled and only authorized entities should be able to alter the card's and installed applications' state. A specification for securely managing applets was originally developed by Visa under the name Open Platform, and is now being maintained and developed by the GlobalPlatform (GP) organization under the name 'GlobalPlatform Card Specification' (GPCS). 

The Card Specification, as anything developed by a committee, is quite extensive and spans multiple documents. Those are quite abstract at times and make for a fun read, but the gist is that the card has a mandatory Card Manager component (also referred to as the 'Issuer Security Domain') that offers a well defined interface for card and individual application life cycle management. Executing Card Manager operations requires authentication using cryptographic keys saved on the card, and thus only an entity that knows those keys can change the state of the card (one of OP_READY, INITIALIZED, SECURED, CARD_LOCKED or TERMINATED) or manage applets. Additionally the GPCS defines secure communication protocols (called Secure Channel, SC) that besides authentication offer confidentiality and message integrity when communicating with the card.

SE communication protocols

As we showed in the previous post, Android's interface for communicating with the SE is the byte[] transceive(byte[] command) method of the NfcExecutionEnvironment class. The structure of the exchanged messages, called APDUs  (Application Protocol Data Unit) is defined in the ISO/IEC 7816-4: Organization, security and commands for interchange standard. The reader (also known as a Card Acceptance Device, CAD) sends command APDUs (sometimes referred to as C-APDUs) to the card, comprised of a mandatory 4-byte header with a command class (CLA), instruction (INS) and two parameters (P1 and P2). This is followed by the optional command data length (Lc), the actual data and finally the maximum number of response bytes expected, if any (Le). The card returns a response APDU (R-APDU) with a mandatory status word (SW1 and SW2) and optional response data. Historically, command APDU data has been limited to 255 bytes and response APDU data to 256 bytes. Recent cards and readers support extended APDUs with data length up to 65536 bytes, but those are not always usable, mostly for various compatibility reasons. The lower level  communication between the reader and the card is carried out by one of several transmission protocols, the most widely used ones being T=0 (byte-oriented) and T=1 (block-oriented). Both are defined in ISO 7816-3: Cards with contacts — Electrical interface and transmission protocols. The APDU exchange is not completely protocol-agnostic, because T=0 cannot directly send response data, but only notify the reader of the number of available bytes. Additional command APDUs (GET RESPONSE) need to be sent in order to retrieve the response data.

The original ISO 7816 standards were developed for contact cards, but the same APDU-based communication model is used for contactless cards as well. It is layered on top of the wireless transmission protocol defined by ISO/IEC 14443-4 which behaves much like T=1 for contact cards.

Exploring the Galaxy Nexus SE execution environment

With most of the theory out of the way, it is time to get our hands dirty and finally try to  communicate with the SE. As mentioned in the previous post, the SE in the Galaxy Nexus is a chip from NXP's SmartMX series. It runs a Java Card-compatible operating system and comes with a GlobalPlatform-compliant Card Manager. Additionally, it offers MIFARE Classic 4K emulation and a MIFARE4Mobile manager applet that allows for personalization of the emulated MIFARE tag. The MIFARE4Mobile specification is available for free, but comes with a non-disclosure, no-open-source, keep-it-shut agreement, so we will skip that and focus on the GlobalPlatform implementation. 

As we already pointed out, authentication is required for most of the Card Manager operations. The required keys are, naturally, not available and controlled by Google and their partners. Additionally, a number of subsequent failed authentication attempts (usually 10) will lock the Card Manager and make it impossible to install or remove applets, so trying out different keys is also not an option (and this is a good thing). However, the Card Manager does provide some information about itself and the runtime environment on the card in order to make it possible for clients to adjust their behaviour dynamically and be compatible with different cards. 

Since Java Card/GP is a multi-application environment, each application is identified by an AID (Application Identifier), consisting of a 5-byte RID (Registered Application Provider Identifier or Resource Identifier) and up to 11-byte PIX (Proprietary Identifier eXtension). Thus an AID can be from 5 to 16 bytes long. Before being able to send commands to particular applet it needs to be made active by issuing the SELECT (CLA='00', INS='A4') command with its AID. As all applications, the Card Manager is also identified by an AID, so our first step is to find this out. This can be achieved by issuing an empty SELECT which both selects the Card Manager and returns information about the card and the Issuer Security Domain. An empty select is simply a select without an AID specified, so the command becomes: 00 A4 04 00 00. Let's see what this produces:

--> 00A4040000
<-- 6F658408A000000003000000A5599F6501FF9F6E06479100783300734A06072A86488
6FC6B01600C060A2A864886FC6B02020101630906072A864886FC6B03640B06092A86488
6FC6B040215650B06092B8510864864020103660C060A2B060104012A026E0102 9000

A successful status (0x9000) and a long string of bytes. The format of this data is defined in Chapter 9. APDU Command Reference of the GPCS, and as most things in the smart card world is in TLV (Tag-Length-Value) format. In TLV each unit of data is described by a unique tag, followed by its length in bytes, and finally the actual data. Most structures are recursive, so the data can host another TLV structure, which in turns wraps another, and so on. Parsing this is not terribly hard, but it is not fun either, so we'll borrow some classes from the Java EMV Reader project to make our job a bit easier. You can see the full code in the sample project, but parsing the response produces something like this on a Galaxy Nexus:

SD FCI: Security Domain FCI
   AID: AID: a0 00 00 00 03 00 00 00
    RID: a0 00 00 00 03 (Visa International [US])
    PIX: 00 00 00

   Data field max length: 255
   Application prod. life cycle data: 479100783300
   Tag allocation authority (OID): globalPlatform 01
   Card management type and version (OID): globalPlatform 02020101
   Card identification scheme (OID): globalPlatform 03
   Global Platform version: 2.1.1
   Secure channel version: SC02 (options: 15)
   Card config details: 06092B8510864864020103
   Card/chip details: 060A2B060104012A026E0102


This shows as the AID of the Card Manager (A0 00 00 00 03 00 00 00), the version of the GP implementation (2.1.1) and the supported Secure Channel protocol (SC02, implementation option '15', which translates to: 'Initiation mode explicit, C-MAC on modified APDU, ICV set to zero, ICV encryption for CMAC session, 3 Secure Channel Keys') along with some proprietary data about the card configuration. Using the other GP command that don't require authentication, GET DATA, we can also get some information about the number and type of keys the Card Manager uses. The Key Information Template is marked by tag 'E0', so the command becomes 80 CA 00 E0 00. Executing it produces another TLV structure which when parsed spells this out:

Key: ID: 1, version: 1, type: DES (EBC/CBC), length: 128 bits
Key: ID: 2, version: 1, type: DES (EBC/CBC), length: 128 bits
Key: ID: 3, version: 1, type: DES (EBC/CBC), length: 128 bits
Key: ID: 1, version: 2, type: DES (EBC/CBC), length: 128 bits
Key: ID: 2, version: 2, type: DES (EBC/CBC), length: 128 bits
Key: ID: 3, version: 2, type: DES (EBC/CBC), length: 128 bits

This means that the Card Manager is configured with two versions of one key set, consisting of 3 double length DES keys (3DES where K3 = K1, aka DESede). The keys are used for authentication/encryption (S-ENC), data integrity (S-MAC) and data encryption (DEK), respectively. It is those keys we need to know in order to be able to install our own applets on the SE.

There is other information we can get from the Card Manager, such as the card issuer ID and the card image number, but it is of less interest. It is also possible to obtain information about the card manufacturer, card operating system version and release date by getting the Card Production Life Cycle Data (CPLC). This is done by issuing the GET DATA command with the '9F7F' tag: 80 CA 9F 7F 00. However, most of the CPLC data is encoded using proprietary tags and IDs so it is not very easy to read anything but the card serial number. Here's the output from a Galaxy Nexus:

CPLC
  IC Fabricator: 4790
  IC Type: 5044
  Operating System Provider Identifier: 4791
  Operating System Release Date: 0078
  Operating System Release Level: 3300
  IC Fabrication Date: 1017
  IC Serial Number: 082445XX
  IC Batch Identifier: 4645
  IC ModuleFabricator: 0000
  IC ModulePackaging Date: 0000
  ICC Manufacturer: 0000
  IC Embedding Date: 0000
  Prepersonalizer Identifier: 1726
  Prepersonalization Date: 3638
  Prepersonalization Equipment: 32343435
  Personalizer Identifier: 0000
  Personalization Date: 0000
  Personalization Equipment: 00000000

Getting an applet installed on the SE

No, this section doesn't tell you how to recover the Card Manager keys, so if that's what you are looking for, you can skip it. This is mostly speculation about different applet distribution models Google or carriers may (or may not) choose to use to allow third-party applets on their phones.

It should be clear by now that the only way to install an applet on the SE is to have access to the Card Manager keys. Since Google will obviously not give up the keys to production devices (unless they decide to scrap Google Wallet), there are two main alternatives for third parties that want to use the SE: 'development' devices with known keys, or some sort of an agreement with Google to have their applets approved and installed via Google's infrastructure. With Nexus-branded devices with an unlockable bootloader available on multiple carriers, as well directly from Google (at least in the US), it is unlikely that dedicated development devices will be sold again. That leaves delegated installation by Google or authorized partners. Let's see how this can be achieved.

The need to support multiple applications and load SE applets on mobile devices dynamically has been recognized by GlobalPlatform, and they have come up with, you guessed it, a standard that defines how this can be implemented. It is called Secure Element Remote Application Management and specifies an administration protocol for performing remote management of SE applets on a mobile device. Essentially, it involves securely downloading an applet and necessary provisioning scripts (created by a Service Provider) from an Admin Server, which are then forwarded by an Admin Agent running on the mobile device to the SE. The standard doesn't mandate a particular implementation, but in practice the process is carried out by downloading APDU scripts over HTTPS, which are then sent to the SE using one of the compatible GP secure channel protocols, such as SC02. As we shall see in the next article, a similar, though non-general and proprietary, scheme is already implemented in Google Wallet. If it were generalized to allow the installation of any (approved) applet, it could be used by applications that want to take advantage of the secure element: on first run they could check if the applet is installed, and if not, send a SE provisioning request to the Admin Server. It would then determine the proper Card Manager keys for the target device and prepare the necessary installation scripts. The role of the Admin Agent can be taken by the Google Play app which already has the necessary system permissions to install applications, and would only need to be extended to support SE access and Card Manager communication. As demonstrated by Google Wallet, this is already technologically possible. The difficulties for making it generally available are mostly contractual and/or political.

Since not all NFC-enabled phones with an embedded SE are produced or sold by Google, different vendors will control their respective Card Manager keys, and thus the Admin Server will need to know all of those in order to allow applet installation on all compatible devices. If UICCs are supported as a SE, this would be further complicated by the addition of new players: MNOs. Furthermore, service providers that deal with personal and/or financial information (pretty much all of the ones that matter do) require compliance with their own security standards, and that makes the job of the entity providing the Admin Server that much harder. The proposed solution to this is a neutral broker entity, called a Trusted Service Manager (TSM), that sets up both the required contractual agreements with all parties involved and takes care of securely distributing SE applications to supported mobile devices. The idea was originally introduced by the GSM Association a few years ago, and companies that offer TSM services exist today (most of those were already in the credit card provisioning business). RIM also provides a TSM service for their BlackBerries, but they have the benefit of being the manufacturer of all supported devices.

To sum this up: the only viable way of installing applets on the SE on commercial devices is by having them submitted to and delivered by a distribution service controlled by the device vendor or provided by a third-party TSM. Such a (general purpose) service is not yet available for Android, but is entirely technologically possible. If NFC payments and ticketing using Android do take off, more companies will want to jump on the bandwagon and contactless application distribution services will naturally follow, but this is sort of a chicken-and-egg problem. Even after they do become available, they will most likely deal only with major service providers such as credit card or transportation companies. Update: It seems Google's plan is to let third parties install their transport cards, loyalty cards, etc on the SE, but all under the Google Wallet umbrella, so a general purpose TSM might not be an option, at least for a while.

A more practical alternative for third-party developers is software card emulation. In this mode, the emulated card is not on a SE, but is actually implemented as a regular Android app. Once the NFC chip senses an external reader, it forwards communication to a registered app, which processes it and returns a response which the NFC chip simply relays. This obviously doesn't offer the same security as an SE, but comes with the advantage of not having to deal with MNOs, vendors or TSMs. This mode is not available in stock Android (and is unlikely to make it in the mainstream), but has been integrated into CyanogenMod and there are already commercial services that use it. For more info on the security implications of software card emulation, see this excellent paper.

Summary

We showed that the SE in recent Android phones offers a Java Card-compatible execution environment and implements GlobalPlatform specifications for card and applet management. Those require authentication using secret keys for all operations that change the card state. Because the keys for Android's SE are only available to Google and their partners, it is currently impossible for third parties to install applets on the SE, but that could change if general purpose TSM services targeting Android devices become available.

The final part of the series will look into the current Google Wallet implementation and explore how it makes use of the SE.

Comments

Geoff Flarity said…
I was too curious, so I answered my own question. Apparently Android Beam uses the NFC peer-peer mode. Which is fine as long as the reader supports it. Software Card Emulation mode will allow phones to completely mimmic existing cards, and hence work with a regular non peer-peer reader systems.

Is there something prevent retailers from updating their existing systems to support peer-peer mode? Seems this is just as likely as Google allowing all applications access to software card emulation? For example: http://www.engadget.com/2012/09/07/levelup-unveils-payment-docks-that-take-both-nfc-and-qr-codes/
Unknown said…
Well, first, P2P is fairly new, and second all existing infrastructure is based on the card-reader model. Add to that the heavy involvement of the financial industry/card companies in all related standards, I don't see this happening anytime soon. Technically it's doable, but someone has to come up with standards for secure P2P and what not, so it might take a while for the base technology to develop. Even after that, unless Visa and friends decide to support P2P, I don't think it will become ubiquitous.
Tanuj Mittal said…
Hi Nikolay

We're working on a project at our University and we're exploring ways to store data on secure element. Going the ASSD way is easier (and somewhat properly supported on Android), but seeing the latest trend, micro SD card slot is getting obsolete. So, I started exploring the embedded SE. Your blog is a great help.

Is it possible in any way to store data on eSE on Nexus 7 (which has the NXP chip)? I read about SEEK also, but nothing is very clear. They do have OpenMobile APIs for sending APDUs to the SE, but I'm not sure whether we need to have keys to interact with CardManager applet? Or can we directly talk to the eSE using APDU commands and store data?
Any help would be great.
Unknown said…
In order to install or write anything on the embedded SE, you will need the GP secure channel keys. Unless you have some kind of special development device, Google is never going to give them to you (because Google Wallet's security depends on the keys being kept secret). Basically, forget about the embedded SE. SEEK can give you access to the secure element on the SIM, but you sill need to know the keys. The upside is that getting a development SIM is somewhat easier.
Tanuj Mittal said…
Thanks a lot for all the information.
Unknown said…
This comment has been removed by the author.
David said…
Good day,

I've been trying to figure out. Is it possible to impersonate an embedded secure element? In other words, when requesting to generate a public/private key pair, can I be requesting from an Android device that has had their secure element removed and replace with another?

Thanks in advance
David said…
Also, I cannot find any documentation indicating remote attestation is possible on Android. Is it possible?
Unknown said…
Replacing an eSE involves desoldering chips from your device, if anyone did that you are already screwed. Also it depends on what you mean by 'impersonate': if the new eSE has the same applets and PIN, most apps wouldn't know the difference. If they are using a secure channel or at least a PIN that is stored on the device, they will get an auth error (unless the keys/PIN are the same).
Anonymous said…
Good Day,

Your articles are absolutely wonderful and have filled countless knowledge gaps for me, so thank you. I am hoping you might be able to help orient me towards a solution for a technical problem. I understand that today the only way of installing applets on the SE on commercial devices is through a TSM or the device vendor, however, I am working on solving how to deliver an applet to a wearable device (think fitness band) that contains BLE/NFC/SE and provision it OTA. Let's assume I have the necessary keys. Does the GP Secure Element Remote Application Management protocol work in a situation where the device does not have MNO capabilities or Wi-Fi?

The use case is turning a wearable band into a secure NFC payment and authentication device. The device would be paired with a mobile phone and certain applet settings would be controlled via a mobile app. However, the idea is that the user would not need to have the phone with them after everything is configured properly. Do you know if this is possible? Can you point me towards any specific documentation that would support this use case? Thank you so much, love your work!
Unknown said…
Documentation usually requires an NDA, so can't help you there. Also not clear if your wearable is even running Android?

You could send management commands over BLE, if the wearable is smart enough to translate commands received over BLE to APDUs for the SE. That would require that the Android device has the card manager (ISD) keys though, so you might want to stream the encrypted APDUs from your servers, kind of what the original Google Wallet did when initializing.

Popular posts from this blog

Decrypting Android M adopted storage

Unpacking Android backups

Using app encryption in Jelly Bean