Smart Card Talk : May 2009 : Feature of the Month

Security of Proximity Mobile Payments

With implementations already in place in Europe and Japan, strong consumer interest, and the ability to leverage the contactless POS infrastructure already in place, NFC-enabled proximity mobile payments show much promise.

This article examines the security of such payments when deployed as part of a collaboration model, in which mobile operators, banks, and trusted services managers (TSMs) cooperate to deliver an end-to-end payment system. This model requires a complex supporting ecosystem, incorporating security mechanisms designed to protect the consumer’s payment account information and the payment application throughout the entire process. This includes the initial sending of account information from an issuing bank to a TSM, the provisioning of information onto the mobile phone, storing the information on the secure element in the phone, and using it at the merchant POS.

Delivering Financial Data Securely to the Mobile Device

Using a TSM for proximity mobile payments allows issuing banks or other service providers to abstract themselves from the complexities of the mobile landscape while enabling consumers to achieve the maximum benefit from a broad-service ecosystem.

Proximity mobile payments do not require account data to be stored on a physical card. The data originates at an issuing bank and is passed securely through a TSM to the secure element in the mobile handset. The data is protected by cryptography throughout the process and the TSM has a critical role in managing the security of the process.

Cryptography. Cryptography is the primary mechanism used to keep sensitive payment applications and account data secure in the mobile payment ecosystem. The secure transfer of account data from an issuing bank to the TSM relies on public key infrastructure (PKI) and encryption based on the secure sockets layer (SSL)/transport layer security (TLS) standard.

The TSM stores the account information in an encrypted database. When a mobile device requests personalization, three separate layers of encryption are established with a packet data connection.

  1. The mobile device establishes a packet connection across the MNO’s radio access network (RAN). This OTA communication is encrypted at OSI layer 1, based on protocols established by both the CDMA and GSM standards bodies. Security at this point is controlled by the MNO, because it manages the keys used to encrypt the data traffic. Data encryption on the RAN ensures privacy and confidentiality for data traffic between the MNO’s core network and the consumer’s mobile device. The OTA encryption layer adds another barrier to the potential for custody breach of account data due to radio sniffing.

  2. Once the packet connection is established, the personalization service agent application running on the handset (for example, a mobile wallet application) establishes a TLS secure communication session to the TSM’s personalization server at OSI layer 4, using credentials issued by a known certificate authority.

  3. When this connection is established, the TSM initiates another secure connection to the mobile device’s secure element using GlobalPlatform’s Secure Channel Protocol, which executes at OSI layer 7. This final layer of encryption is secured by keys that belong to the issuing bank.

The use of application layer security leverages multiple protection levels. After this last connection is established, at least one logical layer of encryption, secured by the issuing bank’s keys, always protects the data between the TSM’s most sensitive process and the secure element in the handset. This layer is established by GlobalPlatform’s Secure Channel Protocol. Most of the time two layers of encryption protect the data. While the data is traveling over the air, it is secured by three layers of encryption.

Key Management. Proper key management and security are essential to protect the system from attack and fraud. The key management process keeps the cryptographic keys secure. One of a TSM’s primary functions is to ensure the security of the keys at all times.

Keeping the keys secure entails ensuring both physical security and logical security. Physical security prevents physical access to the key management server (KMS) and its related hardware security module (HSM). Physical security includes the use of man traps, physical barriers, and alarm systems. Logical security involves processes, procedures, and software used to safeguard the keys. Examples of logical security include password requirements, key import requirements and procedures, firewall rules, and the use of proxy systems for communications.

Data Persistence. A TSM needs custody of a consumer’s account data for only the amount of time required to complete the mobile handset’s personalization process. The process could take from 30 seconds to hours, depending on factors such as quality of network coverage or user expertise.

The bank transmits the account data to the TSM only after the consumer is ready to begin the personalization process on the mobile device. If the issuing bank transmits the data to the TSM before the consumer indicates readiness, the data is stored until the consumer initiates the personalization. This scenario might involve the consumer entering an activation code into the handset that initiates the personalization process.

Securing the Stored Payment Application and Account Information

Multiple layers of security apply to each stage of the proximity mobile payments process. Within the mobile phone, both the payment application and consumer account information must be protected and different NFC applications must be able to work securely and independently of each other. This section reviews how data is securely stored in the mobile handset, how data and applications are securely accessed and used, and how the mobile phone communicates with the POS reader.

Currently, there are three options for storing applications and data securely in the mobile handset: universal subscriber identity module (USIM) cards, embedded secure elements, or SD (memory) cards. All three options rely on the presence of a secure element in the mobile device.

Function of the Secure Element. The secure element (secure memory and execution environment) is a dynamic environment in which application code and application data can be securely stored and administered and in which secure execution of applications occur. The element resides in highly secure crypto chips (usually a smart card chip). The element provides delimited memory for each application and functions that encrypt, decrypt, and sign the data packet. The secure element present in mobile devices is GlobalPlatform compliant to provide better interoperability.

Figure 1 illustrates alternatives for where the secure element can reside in a GSM or CDMA mobile phone. The first approach embeds a separate secure element directly in the handset (either mounted on the motherboard directly or connected in some way to the motherboard). A second approach is to embed the secure element into an SD card. A third approach is to embed the secure element in the USIM/SIM card. The industry is still evaluating the pros and cons of including multiple secure elements in a single mobile handset.

Security Domains and Hierarchy. The GlobalPlatform specification (Version 2.2) defines multiple security domains that use authorized and delegated management to allow an application to be loaded into the secure element. The collaboration model establishes the hierarchy for security domains.

Any GlobalPlatform-compliant secure element comes with one issuer security domain (ISD) and the option for multiple supplemental security domains (SSDs). As shown in Figure 5, the SSDs can be TSM security domains or domains belonging to service providers (such as credit card, ticket, prepaid/loyalty card, or transit card issuers). In addition, each secure element can have only one controlling authority security domain (CASD). This security domain architecture enables the service provider and trusted service manager to perform key management and application verification during load and installation processes.

The ISD is the portion of the secure element in which the MNO can store the keys for the following:

The ISD has privileges for global management, authorized management, and security domain management for the secure element. The ISD must be created during manufacturing and the key for card content management securely transferred from the manufacturer to the MNO. The ISD must authorize the creation of any SSDs. Only the ISD has the privileges to create an SSD and assign authorized or delegated management privileges.

An SSD can have its own card manager key for loading applications. The ISD can assign different sets of privileges (based, for example, on different business relationships) to the SSD designated as the TSM security domain and the SSD designated as the service provider security domain.

Chip-Level Security. The Smart Card Alliance white paper, What Makes a Smart Card Secure? describes the multi-layer security architecture of a smart card chip. Security features manufactured into the secure microcontrollers used in smart card chips can prevent attackers from accessing sensitive information stored on the card.

The SIMs and USIMs in mobile phones are smart card chips, and have built-in tamper-resistance. Smart card chips include a variety of hardware and software capabilities that detect and react to tampering attempts and help counter possible attacks. For example, the chips are manufactured with features such as extra metal layers, sensors to detect thermal and UV light attacks, and additional software and hardware circuitry to thwart differential power analysis.

With contact and contactless interfaces, increasingly powerful processors, a wide range of memory options, and flexible implementation of both symmetric and asymmetric cryptographic algorithms, smart card technology is a critical component of a secure system design.

API Interface to the Secure Element. An API between applications on the phone and the secure element is needed to enable over-the-air and local card management services. For phones that implement Java, two Java interfaces to the secure element are defined: JSR 177, to access SIM cards, and JSR 257, to access the NFC chip.

For phones that do not support Java, the handset and/or operating system vendor need to provide equivalent APIs to access the secure element and NFC chip.

A good practice is to require all phone applications that need to communicate to the secure element to be authenticated by a trusted entity (e.g., the carrier or handset vendor). The phone’s operating system will then prevent access to the secure element APIs by any non-trusted applications.

Communication between the NFC chip and the Contactless Reader. Communication between the application on the secure element and the contactless reader (via the NFC chip) is based on two standards: ISO/IEC 7816 and ISO/IEC 14443. ISO/IEC 14443 helps the reader and NFC chip establish the device parameters for NFC communication. The NFC chip and the contactless reader exchange data using an application protocol data unit (APDU). The structure of an APDU is defined by ISO/IEC 7816-4.

While the reader and the secure element are in communication, the NFC chip is in card emulation mode. The contactless reader communicates with the NFC chip to identify which card is being emulated. The contactless reader then sends commands appropriate for that card type (Visa payWave, MasterCard PayPass, American Express, Discover Zip or other branded card) to start communication with a specific applet.

Interaction between NFC Mobile Devices and POS Terminals

For a proximity mobile payment transaction to be possible the NFC-equipped mobile device must be loaded with a payment application and the merchant terminal must be configured to accept contactless transactions. The payment transaction is then performed much like a standard contactless credit or debit card transaction. The mobile device is presented to the terminal at the point at which a contactless payment card would be presented. The terminal initiates the transaction, not the mobile device, and the terminal does not attempt to read the mobile device until the transaction is initiated. The transaction communication between the mobile device and the terminal is instantaneous and the terminal displays an indication that the transaction is processing and complete.

Consumer Perception. From the perspective of the consumer, an NFC-enabled mobile phone behaves exactly like a contactless payment card during a transaction. The amount of interaction between the consumer and the phone depends largely on the implementation of the payment application on the phone, which is defined by the issuer or the payment brand. There is no specific requirement for consumer interaction, just as there is no requirement for a cardholder to interact with a contactless card during a transaction. The consumer only interacts with the terminal.

The payment application that is loaded to the mobile device may be designed such that the consumer must enter a passcode or present a fingerprint to the mobile device to initiate or respond to the terminal’s transaction initiation or to validate the transaction. Passcode entry is meant to provide the consumer with comfort or a sense of control over the transaction. If the consumer has multiple payment applications on the phone, each could feasibly have different user requirements for conducting a transaction.

The handset firmware can also determine accessibility to the payment application using the NFC modem. The configuration options available for the NFC modem in a handset vary by handset manufacturer. For example, one handset could have the following configuration options:

Multiple Applications. When more than one payment application is installed on a single handset, a mobile wallet can be loaded on the phone to manage the multiple application interfaces. The wallet enables the consumer to select a preferred payment or issuer brand for each transaction, analogous to a consumer opening a wallet or purse and selecting the card to use for a transaction.

A mobile wallet can also enable the consumer to designate one brand as a default payment brand. For example, if a person primarily uses a specific credit or debit card, that application can be set as the default payment brand. To use a different payment account in a retail outlet, the user would need to select a different payment brand.

Potential for MIDlet Use. A MIDlet is a Java 2-based mobile phone or pager application. Many types of MIDlet functions can be added to mobile handsets for marketing and handset navigation purposes. For example, the handset firmware can be set up to automatically open a MIDlet that displays a particular logo when a certain application is selected. When a bank payment application is used, the logo of that bank would then be displayed on the handset during or immediately after the transaction.

Online PIN Requirements. A PIN is not inherently required to use a proximity mobile payment application. However, an issuer can choose to require it in appropriate circumstances. The use of an online PIN entered at the point-of-sale is issuer-dependent and out of scope of this white paper.

Transaction Initiation and Completion. The terminal initiates communication with the mobile handset. The terminal does not constantly scan the nearby (two to four-inch range) area for an active mobile handset; rather, it only attempts to locate the mobile handset or contactless payment card when it prompts the user to present the device. Once the device is located, communication between the terminal and the handset takes place within 500 ms.

When a transaction ends, a final command is sent to the mobile device by the terminal. However, the terminal does not consider the communication to be complete until the mobile device is moved out of the field of communication. That is, another transaction cannot take place until the mobile device that executed the previous transaction is moved completely away from the contactless reader field and the cashier initiates a new transaction.

Payment Transaction Security. Proximity mobile payments leverage ISO/IEC 14443, the standard that governs communication between a contactless credit or debit payment device and terminal. Payment transactions invoke additional layers of security during transaction processing, regardless of whether the transaction is a magnetic stripe transaction or a contactless or mobile transaction.

In the case of a proximity mobile payment transaction, the first layer of security is provided by the secure element itself, which protects the payment application by storing it in restricted access memory. The payment application generates a dynamic cryptogram that is integrated into the transaction messaging/communication process with the terminal. The terminal and the merchant system perform risk management checks; the host system then completes an authorization function, which checks the authorization limit available and card validity, among other things. The security provided by an isolated component in the process does not accurately represent transaction security as a whole.

Mobile Device Lifecycle Considerations

The mobile phone industry is highly competitive and driven as much by fashion as by features and functionality. People often see a mobile phone as a fashion statement and change their phone style based on trends in the fashion industry. The twin influences of fashion and functionality have resulted in a continuing compression of the handset life span and pressure on the handset manufacturers to shorten the handset development and release cycle.

In addition, for all practical purposes, there is no connection between the MNO’s service contract and the phone used to fulfill the contract. It is common for consumers to change phones one or more times over the life of a service contract. When they do, the old phone ends up in a scrap drawer or the garbage. In the United States, the consumer generally has no need to do anything with the old phone when they discard it.

Mobile NFC Activation. The mobile payment application can be activated at the same time as the account-specific information is loaded onto the secure element, independent of the secure element form factor. Inactive mobile payment applications can be preloaded on a handset and delivered to consumers, who have the choice of whether and when to activate them. In the mobile NFC market, the payment application will be loaded in the secure element.

Once the handset manufacturer has released a mobile handset, an MNO purchases and inventories the phone. If the handset has an embedded secure element for the payment application, the application will already be on the phone but will need personalization and activation. It is also possible that the payment application could be loaded to the phone following release.

If the handsets are designed to be equipped with a USIM or SD device as the secure element, the handset will receive the payment application when the USIM or SD card is inserted into it. The MNO or handset vendor acting on behalf of the MNO (i.e., the retailer) adds the secure element when the phone is set up for the consumer. It is also possible that the retailer will have these secure elements prepackaged in the handset and inventory.

Since the payment application is not initially linked to the consumer, the consumer will be given instructions on how to personalize and activate their payment application. It is possible that the activation and personalization of the payment application can be performed at the retail outlet where the phone is sold.

Changing Mobile NFC Phones. The process of changing mobile NFC phones has different implications for managing the security of consumer data and payment applications resident on the secure element based on the model or type of secure element. Consumers will need to be educated to ensure that their personalized data and payment applications are securely transferred from one mobile NFC phone to a new phone.

As noted earlier, in the U.S., consumers have the habit of discarding “old” mobile phones when taking advantage of new handset functionality or fashion features. For 3G networks, the USIM card links the user’s service contract to the phone and is the location of the secure element for mobile payment applications. Accordingly, the subscriber’s identity and mobile payment applications will move with it as the USIM card is transferred from the old phone to the new NFC phone.

For handsets with SD cards or USIM cards, when a consumer buys a new phone, the consumer will need to remove the USIM card or SD card from the old phone and place it in the new phone. Once the card is removed, the old phone is no longer connected to the person in any way. All personalized data and applications have been moved to the new phone. Use of a removable USIM or SD card allows the consumer to control the payment application. If not switching issuing banks or mobile network providers, there is no need to contact the bank or the MNO when changing phones other than to confirm that the new handset is payment enabled.

On the other hand, if the secure element is integrated into the phone, changing phones will require that the payment application on the phone be de-activated, if not removed. This may be possible through a user interface on the phone, or via a set of instructions for the consumer to follow.

Lost or Stolen Phones. If a phone used for proximity mobile payments is lost or stolen, the security of the payment application is determined by the payment application’s implementation. In other words, if the handset is configured to require passcode activation of the payment application each time, the lost or stolen phone represents a minimal financial risk. The consumer would have to report the lost device to their bank, and the bank would have to send a payment application deactivation or block request through the TSM. However, the primary de-activation security will rely upon the host system as it does today with credit cards. If a card is lost or stolen, the consumer must report that fact to the issuer, who closes the account on the host system. When the account is closed on the host system, the card or phone will not be able to receive an authorization because the host system would also have been programmed to reject any new transaction requests. The only risk exposure would be linked to offline transaction limits that may have been configured for that consumer.


Both the financial and mobile industries have made much progress in defining how NFC-enabled mobile payments will take place and how financial information will be secured.

Security is bolstered by the use of industry standards and by the technology supporting proximity mobile payments. Industry organizations have defined standards-based approaches to ensuring that payment account information is delivered securely to the mobile phone and stored securely in the phone’s secure element. From the consumer’s perspective, the proximity mobile payment looks just like a contactless credit or debit card transaction. The NFC-enabled mobile phone leverages the existing ISO/IEC 14443 standard for communicating payment information from the phone to the merchant’s POS terminal. Payments are processed over the current secure financial networks, with all of the layers of robust security used with traditional financial payment transactions.

The rich functionality built into mobile phones can support additional mechanisms to secure the payment application and information. Requiring a passcode or a fingerprint to initiate or respond to the terminal’s attempt to initiate or validate a transaction can provide the consumer with additional comfort and a sense of control over a transaction. Appropriate risk analysis of an operational model for proximity mobile payments can identify where there is potential for fraud and misuse and assign responsibility, providing further confidence to the consumer that transactions using the phone are as safe and secure as transactions that use a contactless credit or debit card.

While implementations may vary, industry players are moving in a consistent direction. Industry organizations have made excellent progress in defining standards and specifications to ensure interoperability. Pilot studies in the United States and implementations worldwide have tested both the technology and the mobile payments process. Proximity mobile payments technology is solid. The largest remaining piece of the puzzle is the definition of a business model that accounts for the responsibilities and risks assumed by each stakeholder and defines how all stakeholders are rewarded.

With a proven technology, a merchant infrastructure that is ready to go, and features and capabilities that excite consumers, it is only a matter of time before industry first-movers in North America will come together and take advantage of consumers’ ever-growing love of mobile technology to launch proximity mobile payments.

About this Article

This article is an extract from the Smart Card Alliance Contactless and Mobile Payments Council white paper, Security of Proximity Mobile Payments.

Members involved in the development of this white paper included: Booz Allen Hamilton, Collis America, Cubic, Discover Financial Services, Giesecke & Devrient (G&D), IBM Global Business Services, IfD Consulting, Infineon Technologies, Keypoint Consulting, MasterCard Worldwide, VeriFone, Visa, and ViVOtech.

About the Smart Card Alliance Contactless and Mobile Payments Council

The Contactless and Mobile Payments Council is one of several Smart Card Alliance technology and industry councils. The Council was formed to focus on facilitating the adoption of contactless and mobile payments in the U.S. through education programs for consumers, merchants and issuers. The group is bringing together financial payments industry leaders, merchants and suppliers. The Council’s primary goal is to inform and educate the market about the value of contactless and mobile payment and work to address misconceptions about the capabilities and security of contactless technology. Council participation is open to any Smart Card Alliance member who wishes to contribute to the Council projects.