Research Report on mobile payment based on HCE

Source: Internet
Author: User

 1. Concept

HCE (host-based card emulation), which is host-based card emulation. There are two ways to implement card emulation in an NFC-enabled mobile phone: One is hardware-based, called Virtual card mode, and one is software-based, called the host card mode, which is the way this article discusses.

In virtual card mode, Security module SE (secure elemen) is required, and SE provides secure storage of sensitive information and provides a secure execution environment for transactional transactions. The NFC chip acts as a non-contact front end, forwards commands received from the external reader to SE, which is then processed by SE and replied via the NFC controller.

In the host card mode, it is not necessary to provide SE, but by an application running in the phone or the server in the cloud to complete the function of SE, when the NFC chip received data from the operating system or sent to the mobile phone application, or through the mobile network sent to the cloud server to complete the interaction. Both of these methods are characterized by bypassing the limitations of the built-in SE of the phone.

  2.NFC Technology Brief

Near Field COMMUNICATION,NFC is a short-range, high-frequency radio technology that evolves from contactless radio frequency identification (RFID). The NFC operating frequency is 13.56Hz, the effective range is within 20cm, its transmission speed has 106 kbit/seconds, 212 kbit/seconds or 424 kbit/seconds three kinds. NFC has 3 modes of operation: Reader mode, point-to-point mode, and card emulation mode. In reader mode, an NFC device produces an RF field that reads and writes data from an external NFC tag that uses the same standard. In point-to-point mode, NFC can communicate with other NFC devices for point-to-point data transfer. Card simulation mode, the reader is an active device, generating RF field; NFC devices are passive devices that emulate an NFC-compliant contactless card to interact with the reader. The HCE technology discussed in this paper is mainly used in the mode of card simulation.

Traditional NFC terminals mainly include non-contact front end CLF (also known as NFC Controller), antenna (antenna), security module (secure Element,se) three main components. In the CLF provides a reading interface, peer interface, card simulation interface, respectively, corresponding to the above mentioned three modes of operation.

The main function of the security module SE is to realize the secure storage of the application and data, provide the security computing service externally, it is the core of the card simulation. The security module also communicates with the external read/write device through the non-connected front end, which realizes the security of the data storage and transaction process.

The contactless front end is also known as an NFC controller, and its functions include modulation and demodulation of RF signals, protocol processing of contactless communication. The contactless front end connects the RF antenna to achieve 13.56MHZ signal transmission and reception, on the other hand, communicates with the security module.

The antenna is integrated in the terminal and connected with the non-connected front end to achieve 13.56MHz RF signal transmission and reception.

In the implementation of NFC, the general non-connected front end, antennas are integrated in the mobile terminal, and the security module can be stored in different locations according to the situation. Depending on the location of the security module, NFC can be divided into different implementations.

  3. Card simulation based on security module

  Figure 1 Card emulation based on the security module

When using the Security module (SE) to provide card emulation, the security module communicates with the external read-write device through the contactless front end of the NFC chip, and the data is stored and processed in the security module. The user puts the phone into the recognition range of the NFC terminal, and the NFC controller forwards all data received from the external reader directly to the security module inside the phone, processed by the security module, and then sends the response data to the external read/write terminal via the NFC controller. The application on the phone was completely out of the process during the entire transaction. After the transaction process is complete, the mobile Android application can query the security module's transaction status and then notify the customer. Figure 1 depicts this process.

There are three solutions for the card simulation based on the security module, namely the NFC full terminal solution, the ENFC technology scheme and the NFC-SD technology solution.

NFC Full-terminal solution refers to the integration of security modules into the mobile phone terminal NFC solution, support multi-security domain, multi-application Security module architecture and the corresponding management technology, can be divided into security modules on different security domains to host different security requirements from different application providers of various applications, It also ensures data independence and data security across applications. The advantage of NFC all-terminal scheme is its standard maturity, which is recognized and supported by many terminal manufacturers. Due to the integration of security module and mobile phone, the problem of machine card interface and card compatibility is effectively avoided in this scheme. The disadvantage is that the security chip can not be separated from the mobile terminal, business initialization, personalization, Business update and management is not convenient, when users update the phone, all business needs to re-transfer to the new phone, high cost, long process. Google Wallet is a typical business based on the NFC all-terminal solution.

The ENFC technology solution is an NFC technology solution that uses the Sim/uim card as a security module, also known as a SWP (single-line communication protocol) or Nfc-sim scenario. The Sim/uim card is used as a security module to store sensitive data such as user payment accounts, keys, and to run payment applications, and the NFC controller in the mobile phone communicates with Sim/uim card via the SWP (single wire Protocol) protocol. As the Sim/uim card is an essential identification module for mobile users, the user is more receptive to the SIM card as a security module, and the distribution and service of the card and application can be easily promoted by means of the telecom operator's receiving channel. In addition, the SIM card and the terminal separation, the user's replacement phone will not affect the continued use of mobile payment business, more flexibility. Due to the many advantages of ENFC scheme, the telecom operators at home and abroad choose ENFC Scheme, so ENFC is the most likely mobile near-field payment technology in the industry. But ENFC solution also faces many difficulties, such as patents, norms, and more importantly, support ENFC mobile phone terminal is very few, ENFC industrial chain is immature, the technology of commercial still have a big obstacle, there is no more typical commercial case.

The NFC-SD technology solution is an NFC technology that uses a mobile Terminal smart SD card as a security module. Similar to the ENFC scheme, the smart SD card and the NFC controller chip are also connected with the SWP protocol, which can realize three modes of operation, such as card simulation, card reader and Point-to-point communication. With the NFC-SD Solution provider (service PROVIDER,SP), the SD card can be released on its own, so that the NFC business can be developed independently of the telecom operator, so financial institutions are more likely to adopt this approach when they take the lead. But the SD card program needs to support mobile phone support for the SWP-SD solution, and there are too few models on the market. Another SD card generally can only support one SP service, if the user wants to be able to use a variety of services, but also must be in the middle of different SD card switch, the switching process is cumbersome and expensive. Although the NFC-SD scheme was set by China UnionPay as its mobile site payment standard, the NFC-SD card scheme proved to be more difficult to implement.

With the full-terminal solution and the ENFC technology solution, although the problem of multi-application services is addressed, the control of SE is controlled by handset makers and mobile operators, and the third-party SP's own services to be deployed must communicate with the SE publishers, which has proven to be complex and time-consuming. In the case of the NFC-SD scheme, although the service provider can control SE, the solution is not supported by mobile phone manufacturers and mobile operators, and for users, it is necessary to switch the SD card to use multiple services. These factors limit the application of NFC technology in the mobile payment field. From the above analysis we can not be difficult to conclude that the crux of the problem is to the "mobile phone purse" a door-se control.

October 31, 2013, Google released the latest Android4.4 system, which refers to a new NFC technology, namely HCE (Host Card Emulation). Since its inception, HCE has aroused great concern, not only in this refreshing new technology itself, but also in the fact that it allows everyone in the industry to see the possibility of deploying NFC from a secure carrier (SE). HCE technology is significant to third-party service providers (SPS), which enables SPS to bring their services to market at lower development costs in less time, while users can more easily use services provided by multiple SPS.

  4. Host-based card emulation (HCE)

  Figure 2 Host-based card emulation

With host-based card emulation (HCE), the data received by the NFC Controller from the external read/write terminal is sent directly to the host system, not the security module. Figure 2 depicts this process.

  4.1 Supported NFC cards and protocols

The NFC standard supports many smart card protocols, and the Android4.4 system also supports many contactless smart card protocols, including financial payment cards, so using a phone can simulate different types of smart cards. Also, many NFC readers on the market support these protocols, including an NFC-enabled Android device as the card reader itself. With HCE technology, we can deploy an end-to-end NFC solution with only Android devices.

The Android4.4 system uses the ISO-DEP standard protocol developed by the NFC Forum (based on the ISO/IEC 14443-4 (ISO-DEP) standard) for data transmission, which is referred to as the Application Protocol Data unit (APDUs). In addition, in the digital protocol (equivalent to the MAC layer protocol), the Android system only requires support for the top-level nfc-a (ISO/IEC 14443-3 type A) technology, while support for Nfc-b technology (ISO/IEC 14443-3 type B) is optional , these technologies provide solutions that include initialization, conflict detection, and so on. The Android system is shown in HCE protocol stack 3.

  Figure 3 Android HCE protocol stack

  4.2 HCE Service

The HCE technology on the Android system is implemented through system services (HCE service). One of the great advantages of using a service is that it can be run in the background without the need for a user interface. This feature makes HCE technology very suitable for like membership cards, traffic cards, access cards such transactions, when users do not need to open the program, just to put the phone into the recognition of the NFC reader range, the transaction will be conducted in the background. Of course, if necessary, users can also open the UI interface. There is no difference between a mobile phone and an ordinary smart card.

In the above transaction we have a problem is not solved, when the user put the phone into the NFC reader recognition range, the Android system needs to know which hce the card reader really wants to interact with, so that it can send the received data to the corresponding service. The ISO/IEC 7816-4 specification solves the problem of service selection by defining a method for selecting the appropriate service through the application ID (AID). A 16-bit aid, if the phone simulates an existing NFC reader facility, then these NFC reader facilities will look for publicly-registered aid (similar to a port number). These smart cards, such as Visa Cards and MasterCard, can register the aid number as their exclusive identification mark. Conversely, if you want to deploy an NFC application for your new card-reader facility, you'll need to register your own aid. The aid registration process is defined in the ISO/IEC 7816-5 specification, and Google recommends that the aid number be registered as recommended in this specification to prevent conflicts with other Android programs.

  4.2.1 aid group

In some cases, in order to implement an application, the HCE service needs to register multiple aid numbers, and we need to ensure that the processing requests for these aid numbers are sent to the application, instead of the request for an aid number in the group to be sent to other applications.

All aid numbers in an aid group should be considered as a whole by the system, and for these aid numbers, the operating system will certainly guarantee the following:

All aid numbers in the aid group are routed to a HCE service;

No aid number in the aid group is routed to a HCE service;

In other words, there is absolutely no intermediate state, one of the aid in the group is routed to a HCE service, and the other one is routed to the other HCE service.

  4.2.2 Aid combination and transaction type

For the user, they don't focus on the aid and aid groups, they just focus on what is going on now, so Android4.4 defines the category. Each aid group corresponds to a category so that the system can organize the HCE service by type.

Android4.4 defines two types: category_payment (for industry-standard payment applications) and Category_other (other HCE applications). In the application's configuration file, we can declare the type of application. It is important to note that in the Category_payment type, only one aid group application can be available at any time, and the application represented by this aid group is generally able to read most of the bank card payment agreements and be able to use them at any one of the payment merchants. We should use Category_other for closed-loop payment applications such as stored-value cards that can only be used at a particular merchant. The aid group in this type can remain active for as long as it is necessary to be given priority by the NFC reader when the aid is selected.

 4.3 Implementing HCE Services

In the mobile phone with HCE technology to achieve NFC card simulation, first of all to create a processing transaction transaction HCE service. We can check the Feature_nfc_host_card_emulation feature to see if the phone supports HCE technology, and then make it known in the tags in the profile manifest that the program uses HCE technology.

Android4.4 provides a very convenient base class Hostapduservice for HCE services, and we can implement our own HCE services by inheriting Hostapduservice.

public class Myhostapduservice extends Hostapduservice {

@Override

Public byte[] PROCESSCOMMANDAPDU (byte[] APDU, Bundle extras) {

...

}

@Override

public void ondeactivated (int reason) {

...

}

}

Two abstract methods that we need to rewrite and implement are declared in Hostapduservice.

At any time, the PROCESSCOMMANDAPDU () method is called when the NFC Reader sends the Application Protocol Data unit (APDU) to the mobile service. APDUs is defined in the ISO/IEC 7816-4 specification as a protocol package for an application layer, APDUs is used for data exchange between the HCE service and the NFC reader. And this application-layer protocol is half-duplex: The NFC reader sends a command APDU to the phone, and then waits for the phone to reply to a APDU packet.

As mentioned earlier, the Android system uses aid to decide which HCE service to use to interact with the NFC reader. So in general, the first APDU sent by the NFC reader is the "Select Aid" APDU, which APDU contains the AID number of the NFC reader for the service that you want to talk to. The Android system extracts the aid number from the protocol package, sends it to the appropriate HCE service, and sends the subsequent APDU to the HCE service.

We can send a reply APDU by returning the array of bits in PROCESSCOMMANDAPDU. Because the Processcommandapdu method is called in the main thread, it cannot be blocked. We should return null immediately when the result cannot be calculated immediately in the program and replied to. Then do the corresponding work in other threads, and send the reply using the SENDRESPONSEAPDU () method defined in Hostapduservice after the result of the calculation is completed.

The Android system sends the APDU received from the NFC reader to the selected HCE service until it encounters the following two scenarios:

The 1.NFC reader sends another "SELECT AID" APDU command, and the operating system will re-select one of the other HCE services.

The connection between the 2.NFC card reader and the phone is interrupted.

When any of these conditions occur, the ondeactivated () method is called, and its arguments (reason) indicate which case is occurring.

To develop an existing NFC system, we only need to implement the application layer protocol that the NFC reader expects in the HCE service. Conversely, if you want to develop your own new NFC system, we need to define our own protocols and APDU sequences. In general, we should ensure that the data exchange uses very few APDU packets and a small amount of data, so that users do not have to spend a long time putting their phones on the NFC reader. A wise choice is to exchange no more than 1KB of data, such a communication usually only 300ms.

  4.4 Aid Conflict Resolution method

We can install multiple HCE services on the phone, and the same aid number may be registered by many HCE services. Android systems differ in how aid conflicts are resolved in different category. For example, for category_payment (Payment Class), the user can set the default payment application for such payments in the "Tap & Pay" option in the system's setup menu, and the default HCE service will be executed when the conflict occurs. For conflicts with the Category_other class, the Hand popup dialog lets the user select the app to execute. The Isdefaultserviceforcategory () interface allows you to see if the HCE service is the default service.

  4.5 compatible with traditional SE cards

The Android system uses the HCE technology simulation card to be compatible with other analog card technologies, i.e. other SE-based analog card technology can be used on Android phones using HCE technology, or vice versa, as long as the system supports HCE technology.

This compatibility is based on an aid routing principle: An NFC controller holds a routing table that consists of an aid and a destination address, which can be either a host (where the application is running) or a security module (SE) connected to it.

When the NFC reader sends a "Select Aid" APDU, the NFC controller resolves the aid and retrieves it in the routing table, sends the APDU to the corresponding destination address when there is a corresponding match in the routing table, and the subsequent APDU will be sent to the same destination address until the next " Select AID "APDU or connection interrupted.

  Figure 4 System with HCE and SE card simulation

If a match is not retrieved in the routing table, the NFC controller typically sends it to the default destination address. The default destination address from Android4.4 is the host, which means that the NFC Controller's routing table only needs to contain all the aid that is routed to the SE module.

When the user finishes upgrading the Android4.4 system, it must be re-registered in the NFC Controller's routing table if it wants to continue using its existing SE implementation, which means it is possible for the user to go to the counter and other places to do a re-upgrade.

  Discussion on the safety of 5.HCE

The HCE technology simply implements the HCE service that sends the NFC reader data to the operating system or returns the reply data to the NFC reader, while the processing of the data and the storage of sensitive information are not specifically implemented, so ultimately HCE technology is the Protocol and implementation of analog NFC and SE communication. However, HCE does not implement SE, just using NFC to communicate with SE to the NFC reader with the support of SE, in order to complete the NFC Business security guarantee in virtual SE way. Since there is no SE, what does HCE use to act as SE, the solution is either local software simulation or cloud server emulation.

For local software analog SE scenarios, user-sensitive information and transaction data are stored locally. Trading processes and data storage are managed by the operating system, which provides a basic security mechanism (such as operating systems can run each program in a sandbox), which prevents one application from accessing data from other applications. But the security of the Android system is inherently poor, so this security guarantee is very fragile. When an Android phone is rooted, the user can get the highest level of access to the system so that they can basically do whatever they like.

Compared to traditional SE-based NFC schemes, HCE technology may face the following risks:

1. The user can root the terminal, and the root user can obtain all the information stored in the application, including sensitive data such as payment vouchers, which are not to be seen by service providers, because this also gives malware access to sensitive information. In terms of statistics, only a handful of Android terminals are rooted, but this still means millions of levels of endpoints.

2. Malware can root the operating system itself. For the early stage of the Android system, due to the existence of some loopholes, resulting in a lot of malicious software can be directly rooted system. Although these vulnerabilities appear to be not particularly large in scope (such as if the user does not install an unknown source of Android software will not have this problem), but this is still a need to consider the issue. It is difficult to make up for a known vulnerability in Android because the lengthy update process of Android takes a long time to update most of the terminals on the market to the latest system version. If there is a bug in the system version that supports HCE, it also takes long enough to solve the problem of defects on the existing endpoint.

3. If the phone is lost or stolen, a malicious user can root the terminal or otherwise access the terminal's storage system, and obtain a variety of information stored in the application. This can be a fatal problem, such as malicious users can use these sensitive data to complete some pseudo-card transactions.

This shows that the Android system provides a very limited security mechanism, once the root of this mechanism has disappeared. Improving the security of HCE technology can be considered in two ways, one is to provide a more secure location for storing sensitive information, and the other is to provide a more secure mechanism to ensure the security of the information in this location.

  5.1 Where sensitive information is stored

While the HCE service is running on an Android system, the SP can require that sensitive information be stored and processed in a more secure location. There are four locations to choose from, and they all have a different balance between security and usage costs. Figure 5 depicts these four different options.

  Figure 5 Location where the HCE service stores sensitive information

  5.1.1 Host

This is the simplest, but least secure, way to implement data storage and processing directly on the host's application. In addition to the very basic security mechanisms provided by the operating system, there is no additional protection. It's easiest to implement, but there's no defense against root system.

  5.1.2 Cloud SE

In this way, the HCE service sends requests through the mobile network to the cloud, and the storage and processing of sensitive information is in the cloud server. The security aspect is higher than processing and storing directly on the host's application, but at this point the mobile network becomes more important. Network coverage and network latency can be a big problem, which is not available in a network where there is no coverage or poor signal. A mobile payment transaction takes less than a second, and the cloud SE solution does not guarantee this in speed. In addition, Cloud SE also has a certification problem, if the device to the Cloud SE certification in the HCE service, then the security of the cloud SE solution is greatly compromised. This problem can be completed by the user (such as login) certification, but the user experience is very poor. Or use a separate hardware SE to handle authentication issues. For now, this is the best solution for a more secure mobile payment service.

  5.1.3 Trusted Execution Environment (TEE)

  Figure 6 Trusted execution Environment

A trusted execution Environment (TEE) is an execution environment that is independent of the operating system and is dedicated to providing security services. Tee has its own independent software and hardware resources, external security services Interface, user sensitive information storage and processing are carried out in this environment. Since tee runs its own standalone system, the Android Master System will not be affected by root. Tee provides a higher level of security overall than cloud SE, but it still does not achieve the security provided by SE because it does not have an SE anti-tamper mechanism. The tee scheme is much like the traditional SE-based solution, so it is more complex to implement and its standards are not finalized.

 5.1.4 UICC or embedded SE

This approach provides the highest level of security, placing the storage and processing of sensitive information on a separate security module (SE). But doing so HCE technology has no advantage over the traditional SE-based card simulation scheme, and even adds to the complexity of the implementation (the traditional approach is direct to SE, which is now going through the operating system and reaching SE).

  5.2 Security Mechanisms

There are many methods to ensure the security of the application, in principle these methods can be used in the above four scenarios to achieve a more secure HCE payment scheme. Of course, the use of these mechanisms will increase the complexity of users, but also increase the developer's implementation difficulty. We have to make a tradeoff between security, user convenience, and cost to choose the right mechanism.

  5.2.1. User authentication

The use of user authentication mechanisms in payment transactions can significantly improve the security of transactions. Typical validation mechanisms are:

According to the information users know to verify: such as user name, password, PIN code, etc.;

Based on the user's behavior verification: the most typical is about off-site use rejection, if a payment is completed in a place soon after a very long time, then such a payment request can be refused;

Based on biometric validation: such as fingerprint recognition, voice recognition, facial recognition and iris Scan recognition, these biometric mechanisms have now aroused great concern and have been implemented on some mobile phones.

 5.2.2 Trading Restrictions

This is done by setting some restrictions on trading to reduce potential security risks, such as allowing only small payments, daily turnover not exceeding a certain amount, and foreign payments not allowed. Users can modify these limits, but they must enter a password so that the loss can be reduced even if the phone is stolen.

  5.2.3 Android System Check

The Android app can check to see if the system is rooted. You can link root to risk, and once the HCE program detects that the system is rooted, we can perform the appropriate action.

 5.2.4 Data Encryption

Sensitive data can be encrypted and stored in the HCE program, so that even malicious users and applications get the data that cannot be resolved. But doing so will also increase the complexity and cost of the application.

  6.HCE Technology Outlook

The undeniable point is that HCE technology provides an NFC service solution that is slightly less secure but very easy to deploy. HCE technology is critical to service providers, eliminating the need for SE to cut off many of the NFC payment stakeholder disputes, so they are a strong supporter of HCE technology. According to the latest news, MasterCard (MasterCard) has formally announced that it will launch the NFC specification for HCE technology, while Visa will include the support features of the HCE payment app in Visa ready program. The NFC Forum also HCE technology, and its various standards have supported HCE technology, including the NFC Controller Interface (NCI) specification, which combines the standards Organization (ISO) 14443 and the Japanese Industry standard (JIS) X 6319-4. The NFC forum points out that the NFC Forum will continue to keep track of new developments in HCE technology and continue to respond to market demands through standard development efforts, as many industry groups are now launching NFC services, and HCE technology will hopefully be a potential factor in accelerating the growth of the overall NFC market. Google is also a key player in promoting HCE technology, and in its latest Nexus 5 smartphones, it has applied HCE technology to Google wallets, paired with the Android 4.4 system, which allows paypass trading without the need for SE security components.

The biggest problem with HCE technology is its security. No hardware-level security is high, either on-premises or in cloud SE scenarios. For financial-level mobile payments, the most viable solution for HCE technology is to store payment data in the cloud and adopt technologies such as tokens or asymmetric keys to ensure that the data transfer channel from the HCE host to the cloud server is secure, based on the cloud SE approach. The security of the HCE can be improved and enhanced. Therefore, in the financial business, whether the HCE technology can be presenting illegal weapons, first of all, the visa, Master, UnionPay and other financial institutions can solve the local software, remote cloud SE security issues. At present, there are individual operators and banks in the small-scale trial of similar HCE technology means, hope to promote the development of mobile payments, but whether it can become a standard, the formation of scale, but also the time to test.

While the outlook for mobile payments at the financial level is not yet clear, there is much room for HCE technology for low-value closed-loop payments like membership cards, coupons, and e-tickets. These types of NFC application security requirements are not the same as a large amount of money in the bank's payment business, although the need to identify user identity, credential security, to avoid counterfeiting and forgery, but has not risen to the height of the financial business, it is important to find a balance between security, convenience and business development. The emergence of Google HCE for these non-financial payment category of the business opened a door, to a certain extent, to provide a safe simulation means, the economic solution se problem, for the booming business greatly help. Service providers are required to assess and determine the best way to store security credentials, and it is clear that different solutions will have pros and cons in different usage scenarios, and that security risks (Risk) and convenience must be chosen.

In short, HCE technology brings a change that brings value to the development and popularization of NFC, as well as a certain security risk. Security issues in mobile payments are critical, and solving this problem requires a complete security mechanism from financial service providers, communications operators, and Google. In addition, the emergence of HCE, for the traditional card factory, operators have produced a certain threat and challenge, whether to achieve the industry's mutual benefit, industrial parties need to weigh and consider.

Research Report on mobile payment based on HCE

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.