“Who controls the smartphone?” is the obvious question that can lead to generating profits from every transaction by the controlling parties.
NFC use on smartphones allows for 3 modes of operation: tag reading/writing, peer-to-peer and card emulation. The card emulation mode is the most interesting mode for the companies involved in such developments because it immediately generates cash flow. The business model is simple: one just needs to replace the existing cards (payment, transportation, etc.). A fraction of the millions of transactions performed everyday by those cards can then be transformed into profit for those controlling the smartphone.
Since 2005-2006, when NFC made its start, we have been witnessing a war among manufacturers; between those controlling the hardware and/or controlling its operating system, neither of which have strong ties with final users; and the cellphone carriers who are controlling the SIM and have strong customer relations through subscription plans.
From each side of the battlefield, the same argument is always pointed out: a transaction implies security requirements, and a security requirement implies embedded applications in a secured processor. The cellphone carriers argue that the SIM card is the best choice, since it is a secured processor and it is already present without any additional cost. The manufacturers argue that a secured processor (Secure Element) has to be added on the motherboard, the extra cost being minimal and the user being able to freely change transaction service providers without having to transfer his or her telephone service to a new vendor requiring a new SIM card.
In the middle of the battle ground, a new contender has emerged: the TSM (Trusted Service Manager), provides a unique and portable service whatever the underlying technical context, for a fee of course.
Until last week, the position of each party had remained frozen since the war started in 2005-2006. And then KitKat arrived.
KitKat is the code name for Android’s new 4.4 Operating System. And in the presentation of KitKat, from the second paragraph, one can read:
Android 4.4 introduces new platform support for secure NFC-based transactions through Host Card Emulation (HCE), for payments, loyalty programs, card access, transit passes, and other custom services. With HCE, any app on an Android device can emulate an NFC smart card, letting users tap to initiate transactions with an app of their choice — no provisioned secure element (SE) in the device is needed.(http://developer.android.com/about/versions/android-4.4.html)
Technically nothing really new; BlackBerry offered the same principle in the latest version of its OS. But Android’s market share is significantly different from BlackBerry’s market share! With this support, developers of sector-specific applications (access control, loyalty) finally have a solution to develop the card emulation mode on smartphones easily and without depending on anyone.
A few technical points to keep in mind:
1. Card emulation « within the host » (HCE) cannot work if the phone is turned off (deliberately turned off or out of battery), whereas within some SIM-centric or SE-centric architectures it is sometimes possible to perform a transaction with a turned off smartphone.
2. The main processor of the smartphone (baseband) isn’t a secure processor. Applications requiring a critical level of security (i.e., whenever the profits from the fraud is higher than the cost of the fraud: payment, public transportation, high security level access control, ID cards…) shouldn’t be implemented in this mode.
3. The transaction times may perform less well; furthermore, they may operate less consistently than a classic implementation within a secured processor – which by nature is independent from other applications running on the smartphone.
4. The technical architecture is based on ISO 14443 layer 4, type A, ISO 7816-4 for APDUs formalism, and ISO 7816-5 for the application selection by the reader thanks to a unique AID. Any application out of this frame wouldn’t qualify for the HCE porting. This is especially the case of some French « public transportation » implementations for which the readers only implement ISO 14443 type B.
Now, how do you implement that in the real world?
Step one, own a smartphone or a tablet running Android 4.4. Step two, download the latest SDK (API version 19). Step three, start coding!
(http://developer.android.com/reference/android/nfc/cardemulation/HostApduService.html)
1. Declare in the Manifest of your application that you want to create a HostApduService, and associate one or several AIDs,
2. Implement the method processCommandApdu which receives the C-APDU from the reader – and has to return the R-APDU to be re-sent. The first C-APDU received is the SELECT AID that activated your application,
3. Implement the method onDeactivated to perform the closing of the channel (reader lost, S-DESELECT reception, selection of another application).
JavaCard developers won’t be confused; the names are different but the overall mechanics are similar (except for the initial select).
Please note that processCommandApdu is called in the main thread of the application. If the answer isn’t immediately available (if it comes from a distant server or if a user input is needed, for example), the application logic has to return a “NULL”. In a second time the application will call the function sendResponseApdu to answer efficiently. In the meantime the OS and the NFC Chipset keep the reader waiting using S-WTX.
If you are interested in NFC applications, please check our NFC readers/encoders, H512 and NFC’Roll.