[continued from part II]
Opening the platform to third-parties
eSE nd UICC provide a high-level of security and physical tamper resistance. But the locked-down environment also presents a challenge for enabling a third-party ecosystem of developers. As previous posts explored, installing applications on the embedded secure element or UICC is not a free-for-all. Card “content management” in Global Platform terminology requires knowledge of the unique card manager keys for each particular unit. (This is a simplification; for more details see earlier post.) End users and application developers do not have direct possession of these keys. Instead they are wielded by a trusted third-party dubbed Trusted Services Manager or TSM who is called on to perform the privileged operations of installing, configuring and deleting applications. On paper Global Platform envisions many complex business models where an application provider can contract with TSM to install applets on its behalf. The latest iteration GP2.2 permits supplementary security domains to perform content management. TSM could inject an SSD for each third-party and delegate application management to individual providers.
Making such arrangements work in reality has been a different story. At least for Android, with the exception of proofs-of-concept and internal demos, embedded secure element has been used only for contactless payments with Google Wallet. Similarly UICC/SIM is being used only for enabling the same scenario with a competing product called the ISIS Wallet. If secure elements had been deployed in μSD form-factor, chances are they would not fare any better in supporting an ecosystem of third-party developers. While μSD is a removable component decoupled from handset manufacturer and carrier, there is still some entity wielding the card manager keys.
Another level of indirection
Compared to the tricky machinations required for third-parties to get their application on Global Platform-compliant secure elements, HCE greatly lowers the bar for adoption. Installing a vanilla Android app is sufficient, accessible to many developers unlike the more stringent criteria of earning the good graces of a wireless carrier. There is no need to coordinate with TSM or get permission from the handset manufacturer. Developers simply declare NFC services implemented by their code. When the phone is interacting with an external NFC reader and receives traffic, the operating system picks the intended destination by using the same trick NFC controller uses to juggle applets spread across two secure elements: AID-based routing.
As far as the NFC controller is concerned, all “host card emulation” traffic is delivered to a single endpoint represented by the Android NFC stack. There is no notion of different wallet applications or other user-level distinctions made. It is up to Android to handle that multiplexing by selectively delivering APDUs to the intended application.
AID routing in Android
Android relies on application manifests to work out this association. Every application interested in acting as a card-emulation target declares the application ID (“AID”) for which it can respond to commands. Much like the NFC controller or card manager, Android looks at the payload of incoming SELECT commands and picks an application for routing based on the AID specified in the command. This is a stateful decision. It affects not just that initial SELECT command but all subsequent APDUs. Traffic is delivered to that application until another SELECT command arrives to switch context to a different applet.
This model faces a couple of additional complications at Android level: multiple applications can claim the same AID. This can not arise on an ordinary GP-compliant smart-card. Only one applet can be installed with a given AID and the card manager will error-out on attempting to install a duplicate. Since there is no such thing as a “global-platform card manager” on Android, the system does not detect/stop such collisions. Instead they are handled by the familiar Android pattern of ranking user preference. Nothing prevents the installation of multiple “web-browser” applications claiming to handle http:// URLs but Android will resolve the ambiguity by prompting users. AID conflicts are resolved by a similar system although the user-interface is not well-defined at this point, with the curious exception of payment applications which are given their own real-estate in system settings. All other applications make do with an API to check if they are the preferred application and another API to be prompted to that spot.
Closely related to the problem multiple applications registering for an AID, Android allows “bundling” multiple AIDs such that an application will handle all of them or none of them. This avoids getting into a mix-and-match situation where commands associated with one AID is routed to Android application A, while commands for another one are routed to B due to conflict resolution. Such a mix-up can prevent both A & B from working correctly in scenarios when multiple card applications are involved for a particular scenario.
EMV is a very relevant example of what can go wrong if different AIDs are split across multiple Android applications. During a transaction, the point-of-sale readers first selects the PPSE (Proximity Payment System Environment) application to enumerate the available cards. Then it selects an application corresponding to one of the listed cards to carry out the payment, such as MasterCard Paypass. Consider two mobile wallets installed on the same Android device, each managing its own set of payment instruments. If PPSE implementation from wallet A is used to choose preferred credit card, but then Android switches to wallet B when Paypass AID is selected, the POS will be working with an inconsistent transaction state. (In fact the second wallet may not even have a payment instrument available corresponding to that AID, in which case the transaction will fail.)