NFC TimesThe premier source for news, analysis and commentary on
Near Field Communication and all contactless technology

The SIMalliance trade group and GlobalPlatform standards organization say they are working on what they predict will become a “de-facto standard” for the way apps on NFC phones communicate with secure elements.

The Open Mobile API, which the SIMalliance released last year, appears to already be popular among mobile operators, which are asking for it when they order Android NFC phones, according to the vendor group. The API, or application-programming interface, also could work on other operating platforms, such as BlackBerry OS and Windows Phone.

The API, however, still has not been adopted by Google, which controls the Android platform; or by other operating system providers, such as Research in Motion, owner of the BlackBerry OS; and Microsoft, keeper of Windows Phone.

Android appears to be the main focus of concern among mobile operators seeking to ensure smooth access to SIMs and other secure elements in the NFC phones they sell. That is why they are backing the Open Mobile API.

Update: Android, at present, has no standard, published, API enabling developers to create wallet apps on NFC handsets that can exchange information with secure elements. Google told NFC Times that while it hasn't released an API, the latest version of the operating system "changed the control mechanism" to make it easier for handset makers to work with the secure element. End update.

But backers of a standard API say that without one, there will be interoperability problems. Developers will create apps for Android phones manufactured by different handset makers and the apps will need to send commands to applications stored on secure elements, such as payment, transit ticketing and ID. But apps created for one handset maker, such as Samsung Electronics, might not work the same way on an Android phone made by HTC or LG Electronics, say the backers.

There also appears to be a hint of concern among mobile operators that see Google Wallet as a threat and fear that the lack of a standard, published, API for Android could somehow allow Google to control access to the secure elements on many or most Android phones.

No Backing Yet From Google
Google, which is facing its own problems from telcos in gaining access to the secure elements in Android phones, including its own Galaxy Nexus, said it has no intention of trying to control access to the secure chips. But it also is not supporting the Open Mobile API, at least not for now.

“Google has not taken an official position on the Open Mobile API,” a spokesman for the Web giant told NFC Times. 

He added that “we support consumer choice and believe that people should be able to choose any wallet on any phone.” That is likely a reference to the blocking move by large U.S. mobile carrier Verizon Wireless of the Google Wallet in the Galaxy Nexus, which Verizon put on sale last month.

Google does have an unpublished API for its Google Wallet apps that ties into the embedded secure element on its Nexus S 4G, still the only phone on the market that supports the wallet.

The Web giant has said it keeps the API unpublished for security reasons, a precaution that one security expert told NFC Times is reasonable given that Android is an open-source operating system and applications that run on secure elements, such as bank payment, and the corresponding apps on handsets, are sensitive. These applications and apps also are developed by specialists, not the typical app store developer.

But without Google’s blessing for the Open Mobile API to become part of the Android platform, mobile operators will have to specify support for the API for each of the Android NFC handset models they order. This may not be efficient but is better than having no common API at all, say backers of the API.

According to the SIMalliance, mobile operators are, in fact, asking for the API and handset makers are supporting it in their phones.

A source at the SIM vendor group, who asked not to be identified, told NFC Times that nine Android phone makers, including all of the major manufacturers supplying Android devices, are working with the API for their NFC models. Five Android models now on the market from five different phone makers support the software, the source said.

He declined to say which phones incorporate it, but the list no doubt includes the Galaxy S II from Samsung, though not the Nexus S 4G, which supports the Google Wallet. Other handset makers likely agreeing to build the API in their NFC phones based on operator orders are LG Electronics, HTC and Sony Ericsson, the latter wholly owned by Sony Corp.

The Open Mobile API also has the endorsement of the GSM Association, the trade group representing most operators worldwide. The GSMA sees the API as a standardized way for developers to access payment or other secure applications on SIM cards the operators issue in Android NFC phones.

A SIM-Centric API?
The GSMA called for the Open Mobile API to be adopted by Android handset makers in its NFC Handset APIs and Requirements document released in November. But in the same document, the association also calls for SIM cards to be designated as the default secure element in phones that support multiple secure elements, as many NFC phones will. Most mobile operators are anchoring their NFC revenue models to SIM cards.

All of this raises the question of just how secure-element agnostic the Open Mobile API will be, especially given that the SIMalliance’s largest members, Gemalto, Oberthur Technologies and Giesecke & Devrient, make a substantial share of their revenue from sales of SIM cards and all are offering high-priced NFC-enabled SIMs.

The SIMalliance insists the API is not designed only to connect handset apps to SIMs but to other secure elements, as well, namely embedded chips and microSD cards.

The agreement with GlobalPlatform helps to make that argument, since the U.S.-based consortium develops standards for all types of secure elements in NFC phones, not just SIMs.

Securing the Channel
GlobalPlatform’s work with SIMalliance, which was announced last week, is mainly intended to bring more safeguards to the communication between the insecure app on the handset and the secure application on the SIM, or UICC, as well as an embedded chip or microSD.

“Having a standardized approach to exchange information between a mobile application and a SE (secure element) application whatever the location, embedded SE, microSD, UICC, will facilitate the deployment of value added services,” GlobalPlatform Technical Director Gil Bernabeu told NFC Times in a statement. “This will, however, also facilitate the deployment of rogue applications. GlobalPlatform will provide a way to protect the SE from any rogue applications.”

He said the added security GlobalPlatform is providing to the Open Mobile API specification involves giving secure elements a way to tell handsets that it’s okay to access them. “When a mobile application wants to send a message to an SE application, the mobile will be able to verify if this mobile application is allowed to communicate with the SE,” said Bernabeu.

GlobalPlatform echoed the SIMalliance’s prediction that the Open Mobile API will become a de facto standard for communication between the secure element and phone apps.

Still, until Google, Research in Motion and Microsoft adopt the API, it will be hard to make that claim.

Without Google incorporating the Open Mobile API into the Android platform, mobile network operators will continue to have to specify that Android phone makers include support for the API in each of their NFC models.

Research in Motion and Microsoft have even more control over their respective platforms than Google so would need to adopt the API in order for it to benefit app developers.

The SIMalliance believes support from telcos and major Android handset makers is enough to at least classify the Open Mobile API as the “beginning of a de facto standard,” the SIMalliance source said. Besides, he added: “There is no other alternative.”