Author: Swati Sharma
Those were old days when you have to take out your wallet and pay by cash. Plastic money has brought a revolution in payment Industry, now it is time to wave your mobile phone to make payments. NFC is establishing a new milestone in Payment Industry. Near field communication (NFC) is a set of standards for smartphones and similar devices to establish radio communication with each other by touching them together or bringing them into close proximity, usually no more than a few centimeters.
NFC devices can be used in contactless payment systems, similar to those currently used in credit cards and electronic ticket smartcards, and allow mobile payment to replace or supplement these systems. For example, Google Wallet allows consumers to store credit card and store loyalty card information in a virtual wallet and then use an NFC-enabled device at terminals that also accept MasterCard and PayPass transactions.
Inherent security Risk in NFC
Although the communication range of NFC is limited to a few centimeters, NFC alone does not ensure secure communications. Unfortunately, as this technique is not part of the ISO standard, NFC offers no protection against eavesdropping and can be vulnerable to data modifications. Applications may use higher-layer cryptographic protocols (e.g., SSL) to establish a secure channel.
The RF signal for the wireless data transfer can be picked up with antennas. The distance from which an attacker is able to eavesdrop the RF signal depends on numerous parameters, but is typically a small number of meters. Also, eavesdropping is highly affected by the communication mode. A passive device that doesn’t generate its own RF field is much harder to eavesdrop on than an active device. An attacker can typically eavesdrop within 10m and 1m for active devices and passive devices, respectively.
It is easy to destroy data by using an RFID jammer. There is no way currently to prevent such an attack. However, if NFC devices check the RF field while they are sending, it is possible to detect attacks.
It is much more difficult to modify data in such a way that it appears to be valid to users. To modify transmitted data, an intruder has to deal with the single bits of the RF signal. The feasibility of this attack, (i.e., if it is possible to change the value of a bit from 0 to 1 or the other way around), is amongst others subject to the strength of the amplitude modulation. If data is transferred with the modified Miller coding and a modulation of 100%, only certain bits can be modified. A modulation ratio of 100% makes it possible to eliminate a pause of the RF signal, but not to generate a pause where no pause has been. Thus, only a 1 that is followed by another 1 might be changed. Transmitting Manchester-encoded data with a modulation ratio of 10% permits a modification attack on all bits.
Because NFC devices usually include ISO/IEC 14443 protocols, the relay attacks described are also feasible on NFC. For this attack the adversary has to forward the request of the reader to the victim and relay back its answer to the reader in real time, in order to carry out a task pretending to be the owner of the victim’s smart card. This is similar to a man-in-the-middle attack. For more information see a survey of practical relay attack concepts. One of libnfc code examples demonstrates a relay attack using only two stock commercial NFC devices. It has also been shown that this attack can be practically implemented using only two NFC-enabled mobile phones.
Losing the NFC RFID card or the mobile phone will open access to any finder and act as a single-factor authenticating entity. Mobile phones protected by a PIN code acts as a single authenticating factor. A way to defeat the lost-property threat requires an extended security concept that includes more than one physically independent authentication factor.
Lawfully opened access to a secure NFC function or data is protected by time-out closing after a period of inactivity. Attacks may happen despite provisions to shut down access to NFC after the bearer has become inactive. The known concepts described primarily do not address the geometric distance of a fraudulent attacker using a lost communication entity against lawful access from the actual location of the registered bearer. Additional features to cover such an attack scenario dynamically shall make use of a second wireless authentication factor that remains with the bearer in case of the lost NFC communicator. Relevant approaches are described as an electronic leash or its equivalent, a wireless key.
NFC and Chip card
NFC payment architecture
The banks are less sure about security than with a contactless card due to involvement of new partners. To the traditional partners, with the mobile phone NFC payment process, a few others are added:
- The telecom provider who issues the UICC card (which can be considered as a smart card)
- The handset provider (mobile phone handset which can be considered either as a POS or a smart card)
The payment process can be described as follows:
- The SIM card (UICC), via the mobile phone handset, is able to make small amount payments (20 € max).
- After four or five times (or Σ = 100 €), the payment application triggers off an authorization request to the issuing bank as shown following diagramo The base band has a POS emulation and calls the OTA platform via GSM.o The OTA platform connects to the authorization bank server
NFC authorization process
For NFC payment there are two safe types of flow:
- One for payment flow
SIM -> NFC Chip -> Merchant POS -> Acquiring bank -> Card Scheme -> Issuing Bank
- One for authorization flow
SIM -> Base band (POS emulation) -> OTA platform -> Issuing Bank
In terms of security, two domains are very critical
The NFC mobile phone which involves three main partners:
- The handset manufacturer: mobile phone with base band, NFC Chip, keyboard, screen…
- The SIM card (UICC): issued by a telecom provider and personalized, by a specialized company, with a Cardlet (include the software for banking payment)
- The OTA chain, which involves two main functions:
- The MIDlet personalization
- The Authorization flow
NFC payment with mobile phones involves far more partners than a face-to-face contactless card payment process. This increasing diversity of organizations involved in the card payment chain is supposed to be a factor of complexity and risk in the security chain.
The EMV and PayPass or PayWave compliant payment application, is stored on the chip of the contactless card, protected by the Global Platform mechanisms, in a dedicated Security Domain (SD). A Common Criteria analysis is possible, because both cards and applications are issued from the same structure with one single security policy (Common Criteria EAL 4 + or 5).
The NFC-enabled handset supporting an UICC (SIM) can either offer GSM/UMTS services, send and receive calls, SMS, etc., or perform a payment acting as a contactless card. The payment application is stored on the UICC in the mobile phone; both of them use a dedicated Security Domain (SD). The independence between the payment application and the GSM application is managed by a software firewall provided by the Java Virtual Machine (JVM). This firewall prevents applications from exchanging information between one another. A common criteria analysis is very difficult to carry out because the IUCC card, payment application and handset are issued by different structures with different security policies.
- The payment application embedded in the UICC must be certified as well as the chip (Common
- Criteria EAL 4 +) and must be EMV compliant
- The developments must respect the java Card global platform requirements (Security Domain in Secure Element) and the UICC must be able to create a secure channel with the bank authorization server. A Trusted Security Manager is necessary to separate the Telecom security layer and the bank security layer.
- Base band POS applications must be certified by banking system (PCI PED and PCI DSS for the POS MIDlet, etc)
The OTA must use the ISO 27005 standard in a certification process that will be defined by card schemes or banks. Security domains to be considered are:
NFC and PCI DSS compliance Requirements
PCI SSC and EMVco has not issue any guidelines as of now. While in implementation, NFC Inherent risk has to be addressed by securing the communication channel and fraud detection methods.
Security Risk for CDE
There is Security Risk that can arise due to NFC Inherent risk like card number is in clear text, sharing of sensitive data with third parties. There is a possibility that NFC security threats can exploit the vulnerability of the existing CDE.
Reference: Multiple whitepapers and other sources including PCI SSC documents have been referred for this article.