As discussed in earlier posts, the embedded secure element on Android devices is a generic computing environment, with its own processor, RAM and persistent storage, however modest those may be in comparison to the phone itself. This platform supports running multiple applications, developed in Javacard. Javacard is a very restricted subset of Java optimized for resource-constrained environments. It’s worth emphasizing that while Android SE is programmed in Javacard, not all smart cards are. Some accept native code applications– “native” to their underlying bare-metal architecture. Not to be outdone by Sun, there is also .NET Card supported by Microsoft as a scaled down version of its .NET platform for Redmond-sanctioned smartcard development. The Android SE is also Global Platform compliant. This grandiose-sounding standard sets down a uniform model for card management, independent of form factor and internal architecture. GP can manage SIM cards over-the-air for GSM networks, as well as chip-and-PIN credits card inserted into an ATM. It can install Javacard applets just as well as deliver native code or C# applications.
Our starting point for this discussion was: what functionality does Android SE expose out of the box? It turns out the answer is, very little. Global Platform only mandates a card manager. The card manager is not the analog for an operating system per se. It is more akin to a trusted installer service that provides the only way to add/remove applications from the card. Unlike other smart cards that have a single dedicated purpose such as transit and no provisions for being enhanced in the field, the Android SE starts out with a blank slate. There is no TPM-style functionality, password manager or EMV-payment capability exposed to the outside world when the chip rolls off the assembly line. The underlying hardware and operating environment are very much designed to support all of these scenarios. In fact between the certified tamper resistance, hardware acceleration for cryptography and rich library of primitives in Javacard, the SE makes for an ideal platform for such security-critical functionality. It takes an application (“applet” in preferred Javacard terminology) to package those raw capabilities and offer them up in a way accessible externally. For example, when Google Wallet is installed and set up with cards/offers, then appropriate applets are installed that collectively implement the Paypass protocol for contactless payments over NFC.
Global Platform spells out how code is delivered (INSTALL for load and LOAD) and instantiated (confusingly named INSTALL for install.) By analogy to the PC, the first one installs new software while the second starts a new process from an executable image on the machine. GP also provides mechanisms for listing applications, deleting them, creating new security domains (similar to “users”) and managing the life-cycle of the card. For instance, locking the card if the issuer wants to suspend usage temporarily, or terminating it in an irreversible manner.
The catch is card management operations require authentication, specifically as the owner of the Issuer Security Domain. Global Platform defines this protocol, based on symmetric cryptography and clearly showing its age with a heavy reliance on DES– specifically triple-DES configured with two independent keys as 2TDEA. Each SE internally has a unique set of secret keys, called ISD keys or colloquially card manager keys. Possession of these keys is required for successful authentication, which in turn is a prerequisite for privileged operations like applet installation. GP envisions ISD keys being guarded by a trusted services manager (TSM), responsible for remotely managing the card without relinquishing keys to intermediate systems. This model strives for end-to-end security from TSM to the card, by avoiding security dependencies on other entities existing along the path. That includes the Android device, which is one of the final hops on the way. Card management commands are received from the cloud and funneled over to the SE. Rooting or jail-breaking the host operating system affords no special privileges because the local device does not have ISD keys.
Returning to the original question then: installing new functionality on the embedded secure element is possible on devices where:
- The publisher of the application has card manager keys, or
- Existing TSM in possession of such keys can perform the installation
** For completeness: there can be more than one set of ISD keys. All of them have equivalent privileges, including the ability to change other ISD keys. For example the embedded SE in PN65N from NXP Semiconductors features four key slots, theoretically allowing up to four different parties to manage the card at once. (That chip and its successor power virtually all NFC-enabled Android handsets. Only the recent Nexus 4 phone and Nexus 10 tablet have different hardware.) This is akin to having multiple cooks in the kitchen. Global Platform spec version 2.2 — which is not supported– adds even more flexibility with delegated management. ISD keys can be used to create supplementary security domains (SSD) which are capable of installing/removing applets on their own, but not interfere with code installed into other SSDs. That gives rise to an unbounded number of participants with ability to deploy applets in parallel.