Is software-based card simulation on NFC a major benefit or a security nightmare ?)

Software Card Emulation in NFC-enabled Mobile Phones:

GreatAdvantage or Security Nightmare?

Michael Roland

NFC Research Lab Hagenberg

University of Applied Sciences Upper Austria

Softwarepark 11,423 2 Hagenberg/Austria

Michael.roland@fh-hagenberg.at

Translation:

Some translation errors were modified. In addition, to unify with the mobile payment standard, the secure element translation was changed from the security module to the Security Unit.

(Translation is for reference only. If you have any questions, refer to the original article)

Vocabulary

Near Field Communication (NFC) Near-Field Communication Technology

Big players industry giants refer to device providers or mobile operators.

Secure element Security Unit, a hardware-based smart card chip for security card Simulation

Google Wallet, a Google payment application

Trusted Service Manager (TSM)

UICC (Universe Integrate Crcult Card) multi-function integrated circuit Card

Form factor appearance

Summary

Software-based card simulation is a new method for implementing interaction between NFC mobile phones and existing contactless smart card systems. It was first implemented by Research In Motion on Blackberry phones. This method makes the card simulation function more simple and open under strict control. In this way, developers can bypass security units (usually controlled by industry giants) and provide opportunities to implement innovative NFC applications. However, this method may also reduce the security of NFC applications and provide malicious attacks. Based on the current application and the latest research results, this paper evaluates the advantages and disadvantages of the software card simulation method.

1. Introduction

With the emergence of NFC, more and more NFC devices and applications are available in the market. However, the full potential of NFC cannot be controlled by all developers. In particular, the security unit SE (secure element) is a hardware-based card-based analog smart card chip used for security. It is still under the strict control of equipment manufacturers and mobile operators.

At the same time, in order to interact with existing RFID systems, including access control, ticket cards and payment systems, cards must be simulated in some way on NFC devices. On NFC devices, security units are used to store important security applications, including credit card, access control, and public transportation applications. The NFC controller on the device can use security units like conventional smart cards without contact.

In the payment field, this NFC technology is the most promising one, and its application is currently heavily dependent on security units. Many companies want to be authorized to use security units in order to gain a share of this field. Therefore, many developers call for a simpler card simulation function.

One of the methods is the software card simulation method (for short, the software SE) implemented by RIM on the BlackBerry platform ). Applications on NFC mobile phones can interact with existing RFID systems without the need for security units. The first thing about this technology is that it will bring significant progress to NFC devices. First, the technology opened the door for developers to implement the card simulation function, which was previously strictly controlled. Second, this will increase the range of NFC technologies used, resulting in an increase in requirements for NFC devices. Finally, NFC will be promoted to become a truly widely used technology. However, in addition to these benefits, there are many negative problems.

This document introduces NFC technology and its operation modes, and further explains the types of card simulation and their usage in NFC devices. Finally, based on the current application and the latest research results, this paper evaluates the advantages and disadvantages of software card simulation,

2. NFC

Near FieldCommunication (NFC) Near-field communication technology was first standardized by ECMA (ECMA-340, ECMA-352) and then adopted by ISO/IEC (ISO/IEC18092, ISO/IEC 21481 ). NFC is an improvement in the near-range radio frequency identification (RFID) technology for inductive coupling. Based on ISO/IEC 14443 and FeliCa (jis x 6319-4) standards, NFC can be compatible with existing smart card systems. Recent standardization work includes compatibility with ISO/IEC 15693 near-distance inductive coupling systems. In addition to standardization, more specific data formats, protocols, interoperability, demand books, device authentication and NFC applications work by the NFC Forum (NFC Forum: http://www.nfc-forum.org.

One basic principle of NFC technology is to "complete at a contact ". This means that a simple contact between an object or NFC device and another NFC device triggers interaction. These objects are called NFC tags (RFID sensor-based non-contact storage chips ). These tags can store content such as Internet address URLs, phone numbers, text messages, SMS messages, and e-commerce cards. Users can use tags to access NFC devices to obtain the information.

NFC terminals can work in three ways: active, passive, and bidirectional;

1. Card simulation mode. NFC is simulated as a card.

2. reader mode. NFC simulates the reader as the reader to read and write the card.

3. Two-way data sharing mode. Two NFC terminals exchange data and can be used for initial verification of Bluetooth and wireless connections.

Figure 1 shows the transmission of NFC data in an NFC mobile phone. The application processor is the main processing unit of the mobile phone. The NFC controller is the core component of the NFC function in the device. It includes an NFC modem and command and data preprocessing. The Security Unit is a smart card chip that can perform secure hardware-based card simulation. Path 1 is the command and data stream between the application processor and the NFC controller. The path exists in point-to-point mode, card reader mode, and software card simulation mode. Path 2 is the command and Data Interaction Between the Security Unit and the NFC controller, which exists in the secure hardware-based card simulation mode. A security unit can not only interact with external users through an NFC interface, but also be connected to the master controller. In this way, the information in the security unit can be controlled through the mobile phone or cellular network. Path 4 indicates that the security unit is connected to the master controller or the NFC interface is connected through Path 3. The two modes of Path 2 and Path 3 are usually only one of them. That is to say, only one of the two modes is activated at the same time.

Note: When NFC works in the Card simulation mode, Path 1 is based on the software Card simulation, that is, the Host Card mode. Path 2 is based on the hardware Card simulation, that is, the Virtual Card mode. Path 3 and 4 indicate the security unit control through the mobile phone. The path used depends on the hardware type of SE. Mobile phone access to the SE is called the wired card mode. For example, you need to use this method when initializing or downloading the app to the SE. In wired card mode, the virtual CARD mode or host CARD mode is blocked.

2.1-card Simulation

There are multiple ways to simulate an NFC card. The analog mode can be distinguished by communication standards, protocol layers, command sets, and NFC device components for specific simulated operations.

There are three communication standards available: ISO/IEC 14443 Type A, ISO/IEC 14443 TypeB and FeliCa (jis x 6319-4). The support for these three standards depends on the NFC controller, geographical location of security units and applications. For example, ISO/IEC 14443 Type A and ISO/IEC 14443 TypeB are widely used in Europe, while FeliCa (jis x 6319-4) is mainly used in Japan.

Another difference is that NFC device components are simulated. On the one hand, card simulation can be performed on software, that is, the device application processor. On the other hand, card simulation can be performed by a dedicated smart card chip, that is, a security unit.

2.2 Security Unit

The Security Unit is a dedicated microprocessor chip for NFC devices. The chip can be integrated with the NFC controller. It can also be integrated into other smart card/security devices in NFC devices. These integrated chips can be UICC multi-functional integrated circuit cards (SIM cards in most cases) or SD secure digital memory cards.

Many security units (such as NXP SmartMX) use standard smart card chips, including contact or non-contact smart cards. Its software and hardware architecture are the same. The only difference is that their external interfaces are different. Common smart cards have ISO/IEC 7816-3 (contact type) or antenna (non-contact type) interfaces, while security units are outside of these interfaces, it also connects to an NFC controller through a direct interface (for example, an NFC Line Interface NFC-WI, or a single line protocol SWP ).

Security units have the same high security standards as conventional smart cards. It provides secure storage, secure execution environment, and hardware-based encryption algorithms. The Security Unit chip is used to read and operate stored data and defend against various attacks. Its chips, operating systems, and design processes have all been evaluated and certified with high security standards. For example, Common Criteria protection profiles for smartcardmicrochips. Therefore, security units meet security-related applications, such as payment and access control management systems.

An important unresolved security issue in smart cards is the scenario of a relay attack. "Relay attack" refers to the communication with a smart card that is relayed to a relatively long distance through another carrier. Attackers can remotely and illegally use the victim's smart card. Hancke first confirmed this type of Anti-contact smart card relay attack. He used the signal layer communication between the smart card and the RFID card reader to implement the relay attack. Kfir and Wool greatly increase the communication distance and can easily use their smart cards without your knowledge. Roland etal reveals that security units can attack not only through non-contact interfaces, but also through software running on mobile app processors. Anderson indicates that NFC mobile phones are ideal for anti-contact smart card relay attacks. Francis et shows that two NFC mobile phone Bluetooth or other wireless communication methods can be used as an attack platform to initiate a relay attack on NFC point-to-point communication and non-contact smart card communication.

3. software-based card Simulation

Software card simulation is a new method for card simulation on NFC mobile phones. RIM was first introduced on the BlackBerry platform. In addition to supporting multiple security units, the BlackBerry 7 platform supports simulating NFC tags and smart cards through mobile application controllers.

By specifying an NDEF message, the application can simulate a tag of NFC Forum type 4, and the message can be saved in a virtual tag. This type of 4-label protocol is automatically processed by the BlackBerry system. An NFC device working in this mode can be used to exchange data with another NFC device working in reader mode.

Applications can also comprehensively simulate smart cards that comply with the ISO/IEC 14443-4 standard, including type A and type B. Applications can specify static attributes of a simulated card (such as unique ID (UID) and historical data of an ISO/IEC 14443 Type A card ), information Protocol Data Unit exchange based on the block Exchange Protocol specified by ISO/IEC14443-4 (although the API allows applications to define UID casually, but considering the security factor, this function is not available on existing devices ). Developers can simulate applications as smart cards by registering on the BlackBerry system. When a command is obtained from an external RFID/NFC reader, the system notifies the application through a callback function and passes the obtained command as a parameter to the callback function. The application can perform corresponding processing through parameters, and the return value of the callback function can be returned to the reader.

Figure 2 demonstrates the command flow simulated by the software card. Arrows 1 to 4 show the Command Flow of the RFID/NFC reader to the callback function registered in the application, the arrows 5 to 8 indicate the process from the application to the RFID/NFC reader.

So far, Blackberry is the only mobile phone that supports software card simulation. However, the recently released third-party firmware-based CyanogenMod patch enables NFC mobile phones with NXP PN544 to feature software card simulation.

In addition to NFC mobile phones, other devices, such as NFC readers, can simulate software cards without security units. For example, acs acr 122U NFC reader and dedicated card simulation devices (such as Proxmark, OpenPICC, iaik hf rfid DemoTag)

3.1 advantages of software card Simulation

Card simulation is regarded as the most promising field in NFC technology. The main reason is that compared with other work models, card simulation has the most profitable prospects. In addition, existing smart card systems such as payment, ticketing, and access control are generally composed of fixed reader devices and user groups with smart cards/non-contact tags. Therefore, adding user-side functions (Smart Card/non-contact tags) to mobile phones is a realistic and urgent requirement.

Although the NFC community has always asked for card simulation, card simulation, especially card simulation involving security units, has always been a complex field. So far, security units in embedded systems are usually controlled by handheld device manufacturers or operated by TSM. If UICC (SIM) is used as a security unit, Mobile Network Operator MNO controls the Security Unit. The battle for Security Unit Control in NFC mobile phones has already started. Therefore, the first obstacle to Security Unit access is that different security units are controlled by different departments. Another obstacle is that the operator of a security unit is unlikely to allow its competitors to run similar services in their modules. For example, Google Wallet is unlikely to coexist with a mobile phone in the Isis wallet, especially sharing a security unit. The third obstacle is the overhead of application access security units. In addition to the storage space overhead of a security unit, security-related applications on a security unit should require some mode of security authentication.

All of these obstacles limit the possibility of General developers using security units for their applications (perhaps not for giants in the mobile and payment sectors ). As a solution to the above problems, RIM provided a software card Simulation Method on its Blackberry phone. In this mode, any developer can develop applications based on the card simulation technology, which provides the possibility to develop applications that interact with existing infrastructure with fixed reader. That is to say, developers can develop mobile-Based Access Control, payment, public transportation and ticketing applications for systems that use RFID cards and smart cards.

Another advantage of software card simulation is that it can communicate with NFC devices that do not have a full-featured point-to-point mode. For example, the Android system only supports Android Beam for point-to-point communication. However, Android Beam is based on Google's NDEF Push Protocol NPP and Simple NDEF Exchange Protocol (Simple NDEF ExchangeProtocol SNEP ), when two NFC mobile phones are in contact with each other, only one message can be sent in one direction. Therefore, software card simulation can be used as an alternative to point-to-point communication between NFC mobile phones. In addition, many non-contact smart card readers based on PC platforms do not support point-to-point mode. For example, Reiner SCTcyberJack RFID basic (used in the new German ID Card System) and hid omnikey 5321. However, these devices can communicate with NFC mobile phones in simulated card mode. Therefore, no additional NFC hardware is required, the software card simulation method enables communication between mobile phones and these PC systems.

The further advantage is that compared with the point-to-point mode, the software and driver for software card simulation on the PC platform is better. Non-contact smart card readers have been standardized on PCs/SC and are integrated into most operating systems by default. Even a platform like Java SE has standard APIs for non-contact smart cards. Point-to-Point Mode only has limited support and is only supported by some third-party libraries such as libnfc4 and libnfc-llcp5. In addition, the NFC Point-to-Point Protocol Stack is

Application Layer Protocol (NDEF message)

Based on

NPP, SNEP (or directly use another application layer protocol)

Based on

LLCP (NFC LogicalLink Control Protocol NFC Logical Link Control Protocol)

Based on

NFC-DEP (NFC DataExchange Protocol NFC data exchange Protocol, for example, ISO/IEC 18092-compliant underlying point-to-point communication Protocol)

In comparison, the protocol stack in the following reader mode is simpler:

Application Layer Protocol (compliant with ISO/IEC 7816-4)

Based on

ISO-DEP (compliant with ISO/IEC 14443-4 communication protocols)

Generally, software card simulation is a great opportunity for developers, rather than industry giants, to expand functions from simple NFC tag applications.

3.2 disadvantages and security problems

All of the above benefits come at a cost. In addition to the technical limitations of the current software card simulation, there are major security issues. Applications running on mobile app processors do not have data security storage and reliability execution environments in security units. Unless the application processor can provide some form of trusted computing technology. However, most mobile phones currently do not have this function.

There is no secure storage function, so card simulation applications have to store sensitive data themselves (such as access control system passwords, payment system private keys, and ticket card accounts ). Moreover, there is no secure execution environment, leading to interference from other applications (including malicious applications. For example, Google Wallet has recently discovered a major security risk. Although Google Wallet uses security units, applications cache important security data into the phone memory as private data of applications, attackers can obtain credit card numbers, account balances, card holder information, and even wallet PIN codes through these caches.

Based on the value of this sensitive information, it may be worth taking risks in some cases. For example, a one-way pass in public transportation or a ticket to a theme park. However, the payment system or access control system is different. For example, the credit card or the access card information of a building cannot be simply stored in the memory of a mobile phone that is easily stolen.

However, the use of software card simulation can also achieve a certain degree of security applications. One key is to store the virtual card in a secure remote location, while the mobile phone only acts as an access proxy.

Figure 3 shows the Online card simulation system based on virtual cards. The mobile phone forwards the commands obtained from the POS machine to the virtual card stored in the remote server. The reply of the virtual card is sent to the POS terminal through the mobile phone.

The access to the virtual card must be safe and can prevent unauthorized credit card access in communications. For example, you can use encrypted and authenticated channels and enter passwords to protect your applications. However, given the fact that data is easily stolen in mobile apps, it is very difficult to create secure channels that cannot be stolen by other apps. In addition, to establish a secure connection with a remote service, a stable Internet connection is required, not all application environments have this condition.

Security issues in software card simulation are not just about data storage. Another problem is using the software card to simulate the app's mobile phone as an attack tool. Francis et al's research shows that mobile phones with NFC functions can achieve remote point-to-point attack. Similar attacks can also attack non-contact smart card systems. (Cf. Hancke, Kr, Wool, Hanckeet al ). In the past, attackers had to prepare dedicated devices (for example, card simulators used to forward Smart Card signals between RFID/NFC reader and relay processor ). Currently, these dedicated devices do not have the appearance of common NFC devices (such as smart cards or mobile phones ). However, mobile phones that support software card simulation have an ideal shape and have a variety of network interfaces (Bluetooth, WIFI, GSM, UMTS, etc.) required to establish a Relay channel ).

Francis et al proves that a non-contact smart card can be easily attacked by two NFC mobile phones: An NFC mobile phone acts as a proxy between the smart card and the relay channel and works in reader mode. Another NFC mobile phone acts as a proxy between an RFID/NFC reader (such as a POS machine) and a Relay channel, working in the card simulation mode. Roland et al even demonstrated that the pure software application in the victim's mobile phone is enough to act as a proxy between a security unit and a Relay channel.

Software card simulation also has technical and security restrictions. In the nxp nfc controller, the software-based card simulation can only use a UID within a range (the UID number segment is retained as a random number ). The specified UID is used in APIs on the BlackBerry platform, but this function is replaced by security issues. Therefore, only random UID can be used for existing devices. This restriction hinders the application of software card simulation in UID-based systems, but also prevents clone attacks in pure UID application systems (such as some access control systems.

Moreover, the Blackberry software card simulation feature, including the features recently added to the Android third-party CyanogenMod firmware, only supports smart cards that comply with the ISO/IEC 14443-4 standard. Systems whose underlying protocols are proprietary protocols, such as MIFARE Classic of NXP, cannot be simulated. Therefore, software card simulation cannot be used in all existing RFID systems.

4. Conclusion

This article evaluates the advantages and disadvantages of software-based card simulation. Software card simulation breaks through the limitations of existing security unit-based solutions and provides developers with new opportunities. This technology can easily integrate NFC-enabled mobile phones with existing contactless smart card systems. In addition, compared with the point-to-point mode, the reader-to-point mode is more advantageous for communication between devices and card simulation devices, because the reader-to-point mode is more widely used than the point-to-point mode. The cost of these advantages is security issues. In this case, the contents in the simulated card are more difficult to protect, and the software card simulation turns the NFC mobile phone into an ideal tool platform to implement the relay tool for the smart card or other card simulation equipment. Finally, equipment and chip manufacturers impose restrictions on software card simulation on some applications. Although most software card Simulation Applications can be implemented in point-to-point mode, the use of point-to-point mode usually requires a large number of upgrades to the existing infrastructure.

In my opinion, communication between multiple NFC devices does not need to be simulated using software cards, because applications can use point-to-point mode, which is specially designed for communication between NFC devices. However, the advantage of using software card simulation is that it can support existing hardware systems. Therefore, the development of software card simulation functions cannot be prevented simply because developers create insecure applications or such technologies are maliciously used. Application Security should not rely on technologies that may be maliciously used, but on improving the system's resistance to attacks. After all, we can see from the CyanogenMod patch package that it is unrealistic to restrict the use of this function.

5. Thank you

This paper is part of the "4EMOBILITY" project in the EU's Regio 2007-2013 (Regio 13) program, sponsored by Europeanregional development fund ERDF and LandOberosterreich, Austria.

6. References (omitted)