There are multiple solutions for paying a merchant using NFC in your phone. Is it possible to, as a merchant, receive a contactless payment using only a mobile phone as a terminal?
It seems that additional reader is required (such as Square), why is that? Should a reader in the phone not be able to receive enough data to process the payment using PayPal, Google Wallet, etc?
From a technical perspective there's nothing that would prevent you to implement a payment terminal using the built-in NFC reader capabilities. All Android NFC devices are capable of speaking the reader-side of the ISO/IEC 14443 contactless smartcard protocol (as used by EMV payment cards).
However, there are a few other things that may inhibt such efforts:
If you want to use a ready-made (and certified) EMV kernel (i.e. the reader application), you might not be able to get one (either because manufacturers do not target Android, or because manufacturers fear the risk that their proprietary software is extracted from the device).
It's unlikey that an Android device (unless its sole purpose is being a payment terminal) would get certifications necessary for payment terminals (mainly because other software could bring transaction data, typed PINs, etc. at risk but also because many Android devices lack suitable protection features on the hardware level). Without those certifications, it's unlikely that you would be able to enrol your terminal with an acquirer that would process payment transactions received through the mobile phone.
Eventhough the NFC hardware supports reading ISO/IEC 14443 contactless smartcards, many Android devices are not too good at that. This is mainly due to bad* antenna design. (* actually not necessarily bad design but design goals targeting simple NFC tags and no contactless smartcards.)
I personally think that the latter two were the main reasons for Square to provide their own device. Though this is just pure speculation and not quoting from any official sources.
Related
Currently using React Native and attempting to use react-native-nfc-ios and react-native-nfc so I can have cross-device communication between ios and Android. I'm finding that they cannot communicate, however I think it's due to a broader issue (as other existing apps also don't work).
If I download a NFC reader app on iPhone 7, and an NFC writer app on Android they cannot communicate. Why is this?
Instructions to Duplicate
Turn on NFC Reader on iPhone 7
Put some arbitrary data in NFC write mode on Android
Bringing devices together has no effect.
Not understanding the intricacies of NFC, it's hard for me as a casual programmer to understand what the actual problem is.
I understand that IOS11 on iPhone 7 (plus) supports NFC read, and generally speaking there are card emulation, peer to peer, and read write modes.
Should they not communicate? The iPhone is not able to pick up the
Android writer. Why is this?
How does card emulation (I assume to be Apple Pay), differ from a write mode?
The reason is because Apple's iOS 11 update only allows reading from NFC tags (writing is only permitted for Apple Pay). At the moment, their software does not share the same enjoyment afforded by Android phones which enable card emulation, peer-to-peer, and reader/writer NFC usage. So our only hope is to wait for a software update that will finally enable this existing feature for developers to use.
I merely want to emulate a transit card with an Android application using HCE. I'm confused about the AID of the card. Do I have to know what the AID of the card is?
According to Host-based Card Emulation document:
If you are emulating cards for an existing NFC reader infrastructure,
the AIDs that those readers are looking for are typically well-known
and publicly registered (for example, the AIDs of payment networks
such as Visa and MasterCard).
So, what is the point?
P.S. I don't think the AID of my card is well-known. Even if it is, how do I know what it is?
Do I have to know what the AID of a card is for card emulation with Android HCE?
Yes, definitely! The AID is the name of your application. The reader will ask cards (emulated or not) if they contain an application with a certain name and will only communicate with those cards that contain the application that the reader supports.
How do I find the AID (or AIDs) of the applications on a certain card?
The most obvious way: Ask the system owner or manufacturer. If they don't tell you, you most probably should not be fiddling around with emulating the card anyways.
There are, of course, other ways to find out how the card works. Many cards follow some standards. Payment cards, for instance, usually implement EMV protocols. For transport cards there are also several standards, e.g. VDV-KA, ITSO, etc. You could try to find out if the card uses some standard/well-known application by doing some finger-printing (e.g. analyze the card to find out the card type, chip type, chip manufacturer, etc.) and by doing brute-foruce scans (e.g. try to select well-known application AIDs, try to enumerate files on the card, etc.) You should be able to find a couple of free tools that could help you with this.
Is knowing the AID enough to emulate (e.g. using HCE) a certain card
No, certainly not.
First of all, you also need to know and implement the protocol that the reader speaks with the application. While many smartcard applications use common command/response constructs (cf. ISO/IEC 7816-4 inter-industry commands), each application typically uses them in its slightly own way. If the application follows some standard, you can simply implement that standard. If the application uses some proprietary protocol, you are back at asking the system owner/manufacturer or at heavy trial-and-error.
Second, even the AID and the protocol are typically not enough to duplicate and emulate a specific card. Smartcards are usually designed to store some secret to usiquely identify and authenticate a card. These secrets typically cannot be extracted from a card. Hence, you cannot simply transfer that secret data into your HCE application.
Before implementing HCE is good to learn your native card application. At least read ATR/ATS of card to understand the chip manufacture and as second step sniff the communication flow between card and terminal for next analyzing. Google/Search your card solution.
The reason to register your application AID on Android device - to map Card AID to your HCE application.
"NFC TagInfo by NXP" - Android application, is good for quick NFC analyzing.
Card type description from ATR/ATS you can try resolve from ludovic rousseau smartcard list.
Some AIDs (payment cards mostly) listed in EFTlab AIDs collection.
Most important for your implementation is your transit card EMV/NFC communication flow and algorithms behind.
AIDs for Visa, Master card and other known companies are registered. You can find the AIDs in the below Wikipedia link
https://en.wikipedia.org/wiki/EMV
AIDs for the Visa from the above link
Visa - A0000000031010, A0000000032010, A0000000032020, A0000000038010
You can program NFC in different modes. The mission is to send bi-directional messages. In NFC there are multiple combined operation modes you can use to accomplish this:
Option 1
Phone > reader/writer mode
Card reader > card-emulation mode
This option is using the ISO-DEP (ISO/IEC 7816-4) protocol
Option 2
Phone > peer-to-peer
Card reader > peer to-peer
This option can use multiple P2P protocols e.g. SNEP
Option 3
Phone > Card emulation
Card reader > reader/writer mode
This option is using the ISO-DEP (ISO/IEC 7816-4) protocol
I have two questions in different aspects:
Usage aspect
With all three options you have bi-directional communication and you can send basically whatever you want. Why wouldn't you use one option above the others?
Security aspect
Security in the sense of vulnerability for abusing like eavesdropping, data destruction, data modification and man-in-the-middle-attacks.
I read option 3 (HCE) is also used for e.g. mobile payment. Is this the safe option, or is option 1 also safe, when you use additional measures like data encryption?
Thanks!
Why are there different operating modes?
The initial idea behind NFC is to combine existing standards (specifically ISO/IEC 14443 contactless smartcard technology and FeliCa/JIS X 6319-4) into a system that can both communicate with existing transponders/smartcards/tags, with existing reader infrastructure and that can be used to easily communicate with dedicated NFC devices.
The initial NFC standard (ISO/IEC 18092) therefore defines the peer-to-peer communication mode based on those existing protocols. In addition to being backwards compatible, the NFC standard allows two NFC devices to (automatically) handshake a connection between two NFC devices. This is not possible in a reader+card setup: neither two readers nor two cards can communicate with each other, so roles have to be predefined in a reader/card scenario.
Therefore, initially, reader writer mode was only intended to access NFC tags (passive data storage devices) and possibly contactless smartcards. Card emulation mode (HCE or SE based) was intended for interaction with existing ISO/IEC 14443 (or FeliCa) infrastructure (e.g. readers that were already in place before the evolution into NFC). And peer-to-peer mode was introdcued specifically for the communication between NFC devices.
Why can all modes nowadays be used for pretty much any scenario?
I guess that one of the driving factors for this development was that peer-to-peer mode on Android lacks API support. On Android peer-to-peer mode is only accessible through Android Beam and consequently not really usable for bidirectional communication. Another factor might be that the peer-to-peer mode protocol stack is more complex than that of reader writer mode (NFC-DEP + LLCP (+ SNEP) + application protocol vs. ISO-DEP + application protocol).
So option 1 is mainly used because it was (before Android 4.4) the only option to implement bidirectional communication over NFC. Since Android 4.4 also option 3 could be used to build similar scenarios.
Is option 3 more secure than the other options?
No, not at all. In all three scenarios, security must be handled by the application layer. The underlying communication protocols do not employ any encryption/integrity protection/etc. mechanisms.
The reason why option 3 is prefered for mobile payment is simply the backwards compatibility aspect: Using HCE you could implement an application that interacts with existing contactless smartcard readers (e.g. as they are used in EMV payment systems).
Apart from what is shown in the NXP websites regarding mifare plus and mifare desfire, considering the following factors:
Security
Speed of Readability
When stuck with a ferrite layer so that it can be stuck on a phone, which is better?
In the future if we want to get into payments, what is preferred?
The size of the nfc tag stickers are going to be 35mm diameter, does it make a difference what is the tag that is used?
The tags are going to be interacting with an nfc reader which is plugged in to an Android device. From an android POV, which is better? For ease of development and for more functionality which is more appropriate?
Thanks
MIFARE Plus is really meant as an upgrade for existing MIFARE Classic-based systems. It has a mode which is backward compatible with MIAFRE CLassic. It has the same fixed memory structure as MIFARE Classic: sectors with 3 blocks of 16 bytes of data and a block for the 2 access control keys. It is not ISO 14443-4 compliant.
MIFARE DESFire has a flexible memory structure: up to 28 "applications" (a kind op directories) with up to 32 files each. Access control is very flexible, too. It is ISO 14443-4 compliant and it can communicate in an ISO 7816-4 compliant mode. It can be configured as an NFC Forum Type 4 Tag, so that compliant systems (such as Android devices with NFC) will automatically read out the NDEF message. It is used in some payment systems.
EDIT:
The 2 products strive for somewhat different security goals, I would say. DESFire offers AES and 3DES for maximum flexibility, with encrypted, MACed or plain communication: your choice. Each application and file can be configured with its own access control keys. While MIFARE Plus aims to improve the security of MIFARE Classic, but its functionality is for the rest very similar to it. In addition, MIFARE Plus has a proximity check feature, while DESFire has no such thing.
They both support the same reading speeds (check the specs!). They will both perform OK on a ferrite layer and an antenna size of 35mm sounds OK. I have such DESfire tags, with and without ferrite, that work fine with an Android phone.
For ease of development, my preference is with DESFire. It is more flexible, both in communication options and data storage configuration. If you have an Android device with NFC capability, you can even configure DESFire as Type 4 Tag, which means that Android will read out any NDEF data automatically and deliver it to your app in an intent.
You seem to have an awful lot of questions here, some of which may not actually be relevant, but here goes:
Security - the DESFire has greater security functionality, gaining Common Criteria EAL 4+
Speed of Readability - They both can handle 848 kbit/sec
When stuck with a ferrite layer so that it can be stuck on a phone, which is better? - not really a question. They both cope with it, but I'd recommend glue as it is a better physical solution to prevent accidental loss.
In the future if we want to get into payments, what is preferred? - the DESFire has greater security functionality, so I would recommend it over the Plus
The size of the nfc tag stickers are going to be 35mm diameter, does it make a difference what is the tag that is used? - Form factor looks identical, so no.
The tags are going to be interacting with an nfc reader which is plugged in to an Android device. From an android POV, which is better? For ease of development and for more functionality which is more appropriate? - The command sets are similar, with the DESFire having an extra set of commands and the capability to run more applications, so based on your comment regarding functionality the DESFire offers more options.
How can I go about doing security testing of an Android NFC application? Is there is any tool or methodology that can be used to do security testing of an Android NFC application which does communication in P2P mode or Card Emulation mode?
Specialized tools to emulate P2P or tag communication exist, but these are generally extremely expensive. But before you go that route, it makes sense to consider against what kind of security threats you want to protect your NFC app. Android takes care of all the low-level NFC communication, so your app does not need to worry about that. Also parsing of NDEF data is done by the Android system. So I would say most things are taken care of for your app by the Android system and your app does not need to worry about it.
Check out this: http://en.wikipedia.org/wiki/Near_field_communication#Security_aspects
In relation to your comment on NFC Guy's post no Android doesn't for the most part, you're expected to deal with most of it yourself:
Eavesdropping is possible on an NFC connection, there's no encryption provided, if you want to keep information sent across an NFC connection secure then do some encryption at the application level. Devices such as the Proxmark3 can eavesdrop NFC communications: http://proxmark3.com/
Data modification is possible but it depends on the encoding of link... See the Wikipedia page for more about this, I don't have much knowledge at this level.
Relay attacks are possible on NFC connections, papers such as this one: http://eprint.iacr.org/2011/618.pdf show a practical implementation of them being carried out, just using a BlackBerry and a Nokia phone. You can try and detect them using distance bounding protocols or location based protocols although are somewhat inexact.