Practical hardware and software add-ons to enhance the security of mobile device operations

This chapter describes and compares four fundamental approaches to storing payment keys and executing payment applications on mobile phones during Near Field Communication (NFC) payments at the Point Of Sale (POS). Even though the comparison hinges mainly on security, i.e., how well the keys and payment application are protected against misuse, other criteria such as additional hardware requirements, availability, management complexity, and performance are also identified and discussed. The first approach, the Secure Element (SE), provides a fully isolated hardware tamperresistant environment. The second, Host Card Emulation (HCE), no longer requires dedicated hardware and thus allows the payment app to be executed on the mobile phone OS along with other apps. In this context, the integrity of the large and complex phone OSs—a very strong assumption—is required to protect the payment keys, which in turn gives rise to the third approach, SE in the Cloud, consisting of HCE along with cloud services. The fourth approach, Trusted Execution Environment (TEE), leverages shared hardware to protect the payment keys and execute the payment application. Unlike SEs, TEEs are not fully isolated and share hardware resources with untrusted software running on the mobile phone, so they can be seen as an intermediate approach between the phone OSs and the SEs in terms of afforded security benefits*. M OBILE PHONES supporting NFC—a contactless, low-power technology enabling devices to communicate over distances in the order of a few centimeters—can act like a smart card when presented to a contactless terminal in the so-called card emulation mode. One of the main use cases of this mode is payments at the POS, which constitutes the focus of this chapter. Using mobile phones instead of (contactless) cards is advantageous due to the phones’ central role, their ubiquity, and connectivity capabilities. Yet, despite those advantages and the fact that the core NFC technology has been available for several years, there is still no global, established pay-with-your-phone mechanism. This lack can partially be explained by the complexity of the NFC ecosystem, i.e., the variety of stakeholders, including banks, Mobile Network Operators (MNOs), phone manufacturers, etc. These stakeholders often have competing interests in the recurring revenue *The contents of this chapter have been adapted from: D. Ortiz-Yepes. A review of technical approaches to realize NFC mobile payments. IEEE Security & Privacy [153]. 12 2. Technical approaches to realize NFC mobile payments generated when transactions take place. Traditionally, only financial institutions and payment networks have shared the per-transaction commission. With phone payments, such a commission is to be shared between more entities, which is clearly unappealing to established stakeholders. So far no mobile payment scheme at the POS has achieved prevalence. There have been attempts backed by powerful players but some of them have disappeared without ever gaining popularity, or evolved by dropping, adapting and mixing particular basic technologies. For example, Softcard—initially known as Isis Mobile Wallet—was one of such schemes backed in the USA by AT&T, T-Mobile and Verizon that shut down at the end on March 2015 without ever gaining much popularity [50]. Google Wallet, which has also failed to reach popularity, was launched several years ago to be used to pay in stores, but it currently seems limited to send money within the USA [97]. Apple Pay was introduced in September 2014 for the latest generation of iOS devices [7]. Samsung Pay [172] and Android Pay [95] have been recently introduced at the end of September 2015 for selected Samsung and Android devices, respectively. Given this dynamic and fragmented landscape, instead of focusing on these particular payment schemes, we aim to address in this article the fundamentals of how any of them—even new ones—work from a technical standpoint. When NFC phones (or payments cards) are used at the POS, a distinction can be made between closed and open loop payment systems. In the former (closed-loop) a limited number of entities that know each other beforehand allow money to flow in and out of the system, e.g., a payment app that can be used to buy coffee only at the shops of a given franchise [189]. In the latter (open-loop), a large number of entities (merchants and banks) that do not previously know one another allow such money flow, e.g., Visa and MasterCard branded systems. We focus on the latter type since it is the most scalable and challenging. To achieve interoperability, open-loop systems are almost always based on the EMV specifications [69]. During a contactless EMV payment, the terminal and the payment application executing on the phone exchange information about the transaction. At the end, the phone returns the result of a cryptographic computation, i.e., a cryptogram, using a secret key that is only known by the payment application and the customer’s bank. It is paramount to protect such a key, and in general all keys involved in the payment protocol, as well the payment application against misuse. Security is clearly an important requirement for mobile payments, and the most important criterion that we will use to compare approaches to realize NFC payments. We identify an attacker or adversary who may try to perform a payment not intended by the legitimate user. For this purpose, such an adversary may need one or more of the following capabilities: • Observing user interaction to learn information entered by the user or presented on the phone. • Installing or replacing apps to capture user input, get hold of keys provided by a server, extract keys from the phone memory, or conduct malware-based relay attacks (explained below). 2. Technical approaches to realize NFC mobile payments 13 • Compromising the phone to subvert security mechanisms provided by the mobile OS intended to isolate apps and ensure that files can only be accessed by the apps that created them. These mechanisms, based on access control and encryption, e.g., [9, 96], are usually employed by payment apps to protect their keys. A phone compromise can be achieved, for example, by exploiting a vulnerability and giving the attacker super-user privileges. Apps can bypass the security mechanisms provided by the mobile OS when a user roots or jailbreaks her phone [81]. In these cases an attacker can compromise the phone just by being able to install or replace apps. There is usually some mechanism implicating the user during the payment. It may consist of a simple proof-of-involvement: unlocking the phone, pressing a physical button, tapping on the touchscreen; or an authentication mechanism: entering a PIN, placing a finger in the phone’s fingerprint sensor, etc. It makes sense having such a mechanism insofar it makes hardware-based relay attacks harder or infeasible. In these attacks the adversary uses two NFC devices that communicate with one another in real-time. The first device is placed at the payment terminal to conduct the transaction posing as the user’s phone. The second is placed in the vicinity of the user’s phone (which may be on a pocket or backpack) posing as the payment terminal. If no user interaction is required, the user’s phone will readily participate in the relayed transaction. It is possible to have schemes with no user interaction, but preventing hardware-based relay attacks would be very difficult, as it is with contactless payment cards [121, 181]. A more involved type of relay attack (malware-based) does not require the second device. Instead, the attacker’s device at the payment terminal communicates directly with a malicious application running on the user’s phone which tries to directly use the payment keys, or trick the payment application to do so [168]. There are other criteria besides security that we will use in this chapter to compare technical approaches to realize NFC payments. Namely: Additional hardware Any hardware required on the mobile phone beyond the NFC antenna and controller to conduct NFC payments. The less required hardware, the better. Availability The user should not be prevented from paying with her phone for technical reasons. Each additional requirement beyond the phone being present hinders this criterion, e.g., special payment terminals, network connectivity, a non-discharged phone (to run a payment app), etc. Management complexity and cost The amount of effort and investment that is required to enable the user to pay with her phone. The lower the management complexity and cost, the better. Performance The time that it takes between tapping the phone and receiving indication that it can be removed from the terminal should be less than 400 msec [70]. If pre14 2. Technical approaches to realize NFC mobile payments tapping or post-tapping is required, it should be as quick as possible in order not to get in the way of the payment process. The rest of this chapter surveys technical approaches at the phone side to store payment keys and execute the payment application. Particularly, the Secure Element (SE) in Section 2.1, Host Card Emulation (HCE) in Section 2.2, SE in the Cloud in Section 2.3, Trusted Execution Environments (TEEs) in Section 2.4, and combined approaches in Section 2.5. These approaches are then compared in Table 2.1 (page 22). Finally, Section 2.6 presents a review of related literature, followed by a summary in Section 2.7, and an outlook in Section 2.8. 2.1. Secure Element (SE)