At the heart of an ARM Powered smartphone with NFC technology is the contactless front end or CLF. The CLF is responsible for managing radio-frequency communication at 13.56 MHz.
A mobile phone with NFC technology contains only one CLF. The CLF is connected to the ARM processor or application processor via UART, I²C, and SPI. These protocols are relatively basic and facilitate straightforward communication between the application processor and CLF via a typical Linux or UNIX-based kernel. Updating the firmware on the CLF is a typical operation performed over the UART serial line.
While a mobile phone with NFC technology contains only one CLF, the phone may contain multiple secure elements. A secure element may reside on the UICC card, on the microSD card, or embedded with the CLF on the PCB. Applets residing on each of the secure elements can serve both similar and different purposes. Both the secure element and the CLF are small, self-contained computers with I/O communications interfaces. In the case where multiple secure elements reside on the phone, each of the secure elements is a small, self-contained computer with I/O communication interfaces. A secure element differs from a normal computer in that it is embedded and has limited resources available for performing computations.
A typical secure element also contains dedicated hardware co-processors for performing common cryptographic operations. Implementing standard cryptographic algorithms at the software level on the secure element is not always practical due to the resource constraints of the secure element components. At a high level, the applet(s) 's responsibility resides on the secure element is to handle the secure storage and transmission of private data. For these types of use cases, encryption and decryption are common operations. Consequently, they are refactored into hardware blocks on most secure elements.
UICC-based SEs, eSEs, and microSD-based SEs all use cryptography to store private data. UICC-based SEs, eSEs, and microSD-based SEs are typically manufactured by different companies. Consequently, multiple types of operating systems run on secure elements.
When the secure element is packaged with the CLF on the PCB, it is called the embedded secure element (eSE). The eSE is connected to the CLF via S2C (NFC-WI) for such a configuration.
By design, the inclusion of the embedded SE into the IC package with the CLF means that the provisioning of trusted applets, such as those used for e-ticketing, can occur via a communications channel external to that of the carrier-controlled, baseband processor. Updates and network communication with a UICC-based SE occur via the baseband processor. On the contrary, an eSE is not typically provisioned by the MNO when the phone is purchased. If the user has access to the proper access keys, communication with an embedded SE (eSE) can occur via the CLF through the application processor. The eSE is connected to the CLF in the IC package via the S2C bus. The S2C or NFC-WI interface was initially proposed by Philips and subsequently standardized by ECMA. The S2C interface consists of two lines, SigIn and SigOut, implemented as two physical wires between the CLF and embedded secure element. This S2C protocol allows for full-duplex communication over two physical wires between the CLF and eSE. A common eSE is called the NXP SmartMX.
In contrast, the UICC on a mobile phone has traditionally been used by the mobile network operators (MNOs) for carrier-specific purposes such as network subscriber information. Mobile phones with NFC technology and a UICC also utilize the secure element on the UICC for e-ticketing applications. The MNOs have primarily been involved in utilizing the secure element on the UICC for storing private data. The UICC-based SE manufacturer is most likely some entity other than NXP. The applets that reside on the UICC-based SE are inherently the domain of the mobile network operators. Applets running on the UICC are used for multiple purposes, including carrier network and subscriber information and NFC e-ticketing applications. Applications responsible for storing private data are provisioned by trusted external entities associated with the MNOs. Currently, the UICC-based SE is provisioned by a trusted MNO entity prior to purchase. Carrier network activities such as call initiation and SMS receipt can be communicated to/from applets running on the UICC via the radio interface software layer running on the application processor's operating system as the application processor is connected to the baseband processor. This exchange occurs in the form of APDUs. APDUs are exchanged between a contactless point of sale terminal and an applet running on the UICC-based SE or eSE during an NFC e-ticketing activity.
Since the inception of NFC hardware on ARM Powered smartphones, NFC e-ticketing applets have been added to the secure element on the UICC. The UICC is physically connected to the phone's baseband processor. The UICC is connected to the CLF via the single wire protocol (SWP) for a phone with NFC technology. A single, physical wire is connected between the CLF and one of the contact pins on the UICC. SWP defines the connection between the UICC and CLF. SWP is intended for use when the UICC-based SE houses trusted applets responsible for e-ticketing applications and private data storage. SWP allows full-duplex communication over a single physical wire between the CLF and UICC. ETSI TS 102 613 defines the physical and data layers of SWP. SWP was established by Gemplus (now Gemalto).
In the United States, MNOs utilize the secure element on the UICC card for hosting e-ticketing applications and storing private data. Android phones with NFC technology may an application that uses the RF controller on the phone. If this is the case, the phone most likely contains a UICC-based secure element connected to the internal CLF via the SWP.
The mobile phone may contain an NXP PN544 pin-to-pin compatible PN65N, in which case, the SWP line is wired to the UICC SWP contact pin via a single physical wire. Alternatively, the phone may contain a PN544 CLF, in which case the same SWP line is wired to the UICC SWP contact pin via a single physical wire. When an embedded secure element is connected to the CLF via S2C (NFC-WI) and the CLF is also connected to the UICC-based SE over the single wire protocol (SWP), then applications (applets) can be selected by id from either secure element.
The provisioning of applets to either the eSE, microSD SE, or UICC-based SE occurs via different channels. The MNOs have primarily been responsible for the provisioning of applets to the UICC-based SE via trusted third parties. In contrast, device manufacturers can provision parts of the embedded secure element before it leaves the factory. The physical connection to the secure element is one of its key differentiating factors. Embedded secure elements are connected to the CLF via S2C. In contrast, UICCs use the SWP pin to connect with the CLF. When an e-ticketing transaction occurs via NFC, it does so over the contactless communication interface. The remote e-ticketing terminal sends information back and forth between the applet running on the secure element. This communication occurs via the CLF to the SE, either over the single wire connection to a UICC-based SE or over the two-wire (S2C) connection to the eSE; depending on which SE is running the issuers e-ticketing applet. The MNO may provision the UICC-based SE with special applications. The microSD card is also connected to the CLF; however, this is not mentioned since microSD-based secure elements are not as prevalent yet in the United States.
It has been the intent of the OEMs (not all), silicon manufacturers (not all), and those in favor of open ecosystems to utilize the onboard embedded secure element (eSE) for hosting the applications that are responsible for e-ticketing applications.
There are multiple parties involved in this ecosystem; they include and are not limited to trusted third parties responsible for provisioning applets to the secure element via the carrier network, credit card issuers, silicon manufacturers, original equipment manufacturers (OEMs), banks, mobile network operators (MNOs), software vendors such as Google, credit card manufacturers, credit card issuers global standards bodies such as ISO and EMVCo, trusted service managers, service providers, certificate authorities, industry associations such as Global Platform, and numerous regulating entities. The ecosystem is complex, and there are currently several successful efforts underway to standardize NFC technology and how it is used in the United States.
As a critical point to consider and in contrast to the solutions that have been implemented for the safe execution and storage of NFC related e-ticketing applications and private data, ARM TrustZone technology in the processor core can be utilized in a similar light to that of the technologies on the eSE, UICC-based SE, and microSD SE. ARM TrustZone technology provides an ideal platform for secure keypad entry and user authentication.
Post a Comment
Note: Only a member of this blog may post a comment.