HCE has the potential to fuel the growth of mobile payments, so UL analyzed this new technology to identify both security risks and mitigation techniques.
WHY SECURING HCE MATTERS
Although mobile payments are expected to grow significantly over the next several years, industry analyst Gartner downgraded projections for NFC payments in its forecast for 2012 through 2017. “Near Field Communications’ (NFC’s) transaction value has been reduced by more than 40 percent throughout the forecast period due to disappointing adoption of NFC technology in all markets in 2012 and the fact that some high-profile services…are struggling to gain traction.”1 In response to this struggle, some service providers — most notably, Google with its Google Wallet offering — are turning to Host-based Card Emulation (HCE) as a simple, yet less secure way to offer NFC services. HCE has the potential to reinvigorate a more aggressive growth trajectory for mobile payments by opening NFC to a broader range of service providers. However, the security risks inherent to HCE must be mitigated
for this technology to achieve its potential.
The number of NFC-enabled devices in the market is projected to increase from 500 million in 2014 to 1 billion in 2018.2 One of the most attractive features of NFC is its ability to turn a smartphone into a credit or debit card that facilitates quick and easy “tap and pay” transactions, and it is the growth of this specific capability that has slowed relative to initial projections.3
NFC card emulation is the process that enables a mobile device to perform smart card and “mobile wallet” functionalities, including payments, loyalty programs, couponing, transit ticketing, identification and access control (i.e., designed limitations that enhance security by restricting access to systems, resources or data to users with proper credentials). The security of NFC card emulation is typically based on the use of a secure element (SE), a tamper-resistant chip inside the handset in which a card emulation application can perform cryptography and store sensitive data in a secure and trusted environment.4 The issuers of the SE (typically mobile network operators [MNOs] or device manufacturers) generally control access to the chip, which means that prospective service providers must get permission to access the SE. The lack of open access has proven to add significant complexity to the development and implementation of NFC card emulation services, which may have contributed to the slower-than-expected adoption of NFC.5
HCE allows a smart card to be emulated on a mobile phone without using an SE, so that during a transaction the data is routed directly to a smart card application running on the host CPU (i.e., central processing unit), rather than through the hardware-based security provided by an SE.6 More specifically, HCE enables NFC transactions to take place by using credentials stored in the main memory of an NFC-enabled mobile device or potentially in the cloud.7 By using HCE, service providers can develop and offer mobile wallet and other services without interaction with or permission from the SE issuer.8 Because of this, HCE is viewed as an important addition to NFC solutions that could potentially accelerate market growth.9
By providing an alternative, more simple (but less secure) way to provide an NFC card emulation service, HCE has great added value for service providers that can accept a reduced level of security in exchange for an improvement of other factors, such as time to market, development costs and the need to cooperate with other parties. In these cases, HCE would make life for a service provider considerably easier and could eliminate the role of SE issuers. We believe, however, that service providers should be fully aware of the security risks caused by not using the hardware-based security provided by the SE.10
WHAT DID UL DO?
UL performed an in-depth analysis of HCE technical functionality to fully understand the way HCE works and its implications for the NFC ecosystem. We then explored and analyzed different ways to compromise HCE-based NFC applications. We went beyond simply identifying and understanding the potential security risks of HCE — which could lead some service providers in specific circumstances to choose a conventional NFC alternative that uses the SE — and identified a series of risk mitigation techniques and software-based security mechanisms that could compensate for the lack of hardware-based security inherent to HCE-based NFC applications.11 Our comprehensive investigation produced the following insights and corresponding implications related to HCE security risks and potential mitigation techniques.
HCE introduces three key security risks that are not present in SE-based NFC services:
1. The user can root the device. This means that a user is able to access all of the information stored in applications on the device’s operating system (OS), including sensitive information such as payment credentials. Although a device can also be rooted in an SE-based environment, the payment credentials would not be stored in the OS. Typically, the service provider wants to prevent such user access because it means that malware can also access this data.12
2. Malware might be developed that could root the device, as has happened in the past. While these breaches had a limited reach (the malware was not available from official download channels and only targeted an older Android version), it is a potential risk that has to be considered, especially since it has proven to be difficult to fix an identified vulnerability in Android due to the system’s long update process.13Relative to the two HCE-related risks detailed above, the basic security features of Android offer limited protection, which can be circumvented relatively easily by rooting the device.14
3. In a situation where a handset is lost or stolen, a malicious user can access the device or device’s memory by connecting it to another device. This malicious user could then connect to all the information stored within the application and use it to make fraudulent payments.15
Mitigation Techniques For HCE-Related Security Risks
We believe that mitigating the HCE-related security risks can be done in two ways: providing a more secure location for storing sensitive data and applying security mechanisms to safeguard the data wherever it is stored.16
1. Potential locations to store sensitive data
Because the HCE service runs within the Android OS, a service provider may require a more secure location to store credentials, generate and process the data transfer and perform cryptography. We identify four location options, each representing a different balance between risk mitigation and associated costs.17
The host is the most basic location, involving the storing and processing of data within an application running on an Android OS on the handset. Apart from Android security mechanisms, such as sandboxing (isolating an application to prevent interaction with malware, intruders, system resources or other applications), no additional security would be added in terms of location for storage and processing. This location provides the least security and also no incremental cost.18
b. Cloud-based SE
In this approach, the storage and processing of sensitive data would be done via a server in the cloud to which an NFC device connects. A real issue is that a mobile payment transaction must be completed within a narrow time limit (400 milliseconds for the MasterCard PayPass – M/Chip or 170 milliseconds for the PayPass magstripe). A real-time calculation on a cloud-based SE cannot guarantee this kind of transaction speed given the dependence on internet availability and connection speed. Therefore, cloud-based SE solutions(e.g., Google Wallet) typically include a tokenization mechanism to allow transactions up to a certain number and value.19
Another important issue with any cloud-based SE is how to enable the handset to securely identify itself to the cloud. If credentials to the cloud-based SE were stored inside the HCE service, this would severely limit the extra security that could be supplied by the cloud-based SE solution. This problem could be resolved by requiring user interaction for accessing the cloud, which would, in turn, negatively impact the user experience. Another solution would be to use the hardware SE to authenticate toward the cloud-based SE.20
The Trusted Execution Environment (TEE) is a separate execution environment that runs alongside the OS and provides security services to that environment. The TEE functions by isolating access to its hardware and software security resources from the OS and its applications. The TEE runs its own separate OS and, therefore, cannot be compromised if the main OS is rooted. Because of this, the TEE provides a higher level of security than the basic host-based approach. The TEE does not achieve the security level provided by an SE, however,because it does not have the SE’s tamper resistance. Additionally, it is important to note that TEE standardization is still being finalized.21
d. UICC or embedded SE
Although this option offers the most advanced form of security on an Android device, it is questionable whether UICC or embedded SE, in combination with HCE, would make sense to a service provider. This option appears to provide no additional advantages relative to traditional, SE-based NFC. At the same time, UICC or embedded SE would add complexity in the routing through the Android OS, where a direct link to the SE is available.22
2. Security mechanisms
A wide range of mechanisms currently exists to make applications more secure. There are several that we believe are promising for HCE. In principle, these mechanisms can be applied to the four locations specified above and combined with each other to provide increased risk mitigation. There are trade-offs, however, involving security, end-user convenience and cost that the service provider should consider.23
a. User and hardware verification
Payment transactions can be made more secure by verification of the user and/or the hardware that is used in the transaction. Typical mechanisms to enhance security include the verification of username/password combinations or PIN; device ID, smart card reader or sticker; and biometrics, including use of fingerprint or iris scans and voice or facial recognition.24
b. Transaction constraints
To minimize the impact of potential security breaches, transactions could be limited in various ways, including allowing online-only transactions (checking transaction parameters in systems from the issuing bank), denying payments made in geographically distant places in quick succession and specifying the value or number of transactions per time frame and establishing country limitations.
We believe that a malicious user in a fake application would be unable to modify such transaction constraints because the issuer would sign the constraints with a key that is not on the card and, therefore, not present in the app. The constraints would then be protected from manipulation.25
In the scope of mobile payments, tokenization is often used as a mechanism to overcome timing issues of cloud-based SE solutions. With tokenization, sensitive data is replaced with unique identification symbols that retain all the essential information about the data without compromising its security.26 One issue with this technique is the tokens need to be stored in the application, where they are still at risk. However, the use of a token can be restricted in terms of how it is used — with a specific merchant, device, number of transactions or category of transactions — and the time frame for which it is valid. In most cases, a token can be used to authenticate only a limited number of times. When the tokens are used, new tokens will need to be retrieved. Thus, the risk is limited compared with the case where all payment details are stored inside the application. For the tokenization risk to remain limited, it should only be possible to retrieve tokens under certain requirements, such as for user verification or to push to the device from a different environment. MasterCard, Visa and American Express are currently standardizing a tokenization mechanism for online and mobile payments.27
d. Android OS checks
An Android application is able to verify system settings and can detect whether a device has been rooted. Given the risks associated with rooting, we believe an HCE service should check for this kind of setting and take appropriate action as soon as such a setting is detected.28
e. White-box cryptography
In card emulation, white-box cryptography can be used to hide sensitive data within the card emulation application. It does this by hiding the encryption/decryption key within the code of the cryptographic algorithm.29 This makes the key irretrievable even if the original source code is compromised. A drawback of white-box cryptography in card emulation is that the distribution of NFC payment applications becomes more complex and costly. The code of each application would need to be as unique as the key hidden inside the code. This requires the source code to be dynamically loaded into the application at the moment of personalization. A further drawback is that the process of hiding the key could impact the application’s performance.30
Overall, UL believes that HCE will accelerate the introduction of NFC services by providing an alternative means of delivering an NFC card emulation service without access to an SE. In effect, HCE “democratizes” NFC card emulation and may spur additional service innovation. At the same time, any service provider that is planning to offer HCE-based NFC services should consider the security implications of bypassing the SE because the Android OS, alone, is not a secure location to store sensitive data. We believe the alternative data storage locations and risk mitigation techniques we have identified can begin to provide the safeguards necessary to facilitate the expansion of secure HCE services on the market.31