I have a NFC card that implements Mifare Plus over IsoDep, NFCa, and NDEF.
I am communicating with the card via a PC dongle, and libNfc (not android).
I have read thru the 7816-4 but am still confused as to what the first steps I should be taking when communicating with the card. Should I for example be selecting the MF or EFDir? Reading from these files?
To program reading and writing NDEF data on a Type 4 Tag requires either the NFC Forum Type 4 Tag specification or learning from existing open source code. NFC Forum specifications must now be paid for, depending on budget the other approach may be more appealing. For someone suitably familiar with the Python programming language a source of inspiration may be the Type 4 Tag reader implementation of http://nfcpy.org, in file nfc/tag/tt4.py.
Related
I was wondering if it is possible to code on a NFC whatever we would code with Javacard ? I have a project where a smart card contains a biometric id to be scaned and and we want to do it wirelessly with a NFC. Do you think that is possible ? What are the boundaries of NFC ? Is it possible to do whatever we do with Javacard on NFC ? Sorry I have a lot of questions I'm not very familiar with the topic.
Yes it is possible for some Javacard's to be interacted with via NFC.
See https://github.com/OpenJavaCard/openjavacard-ndef as an example.
The answer is yes - many contactless and dual-interface cards are in fact running JavaCard applications. When you go to the higher protocol layers, the commands (APDUs) exchanged using NFC are basically the sames as using the contact interface.
In essence, NFC is a communication channel, while Javacard describes a programming framework (requiring a processor card with a certain processing power). Of course those two can be combined.
NFC is also used as term for rather dumb tags, which may provide some hardwired cryptography (as DESFire does) but not much beyond that except data storage space. There is no way, on which such a tag can process even the most basic "hello world" applet, and mastering the same communication technology does not not help much in that respect. Computing a digital signature can be considered as litmus test, what you really have.
I have a device that is emulating nfc tag using pn71501 chip. I don't know how exactly code works in that device but what I definitely know this chip can emulate tag using only ISO14443 standard. So both my readers can read this type of tags but by some reason I can read from this device is UID, nothing else. As I know reading memory from tag with ISO 14443 requires block authentication but it doesn't help for me. For reading tags using IDtronic EVO HF I use software downloaded from here: https://download.idtronic.de/Card%20Reader/Card%20Reader%20HF%20SET%20SDK.zip
For ACS ACR1252U I tried many different apps including my own apps and none of them could read it.
Interesting fact is that android and ios devices can read it.
If you look at the datasheet for that chip it says "PN7150 does not support a complete card protocol. This has to be handled by the host controller"
So the chip itself might not be doing any more than than ISO 14443 A-3 and B-2 parts which really only includes the Anticollision and UID and then storing/transmitting data is handled by the host controller using the higher level protocol parts.
Also the free software you get with card readers tend to be very basic and just reads the UID for inventory purposes, you have to write your own software if you want to do more with these readers and they usually like the ACR1252U have a datasheet on how to do this.
So the question is what is the host controller attached to the NCF chip doing and software it is running?
Update based on comments
I would assume that host controller does implement one of the higher level protocols for a Type 3 or 4 Tag (most likely Type 4)
The you just need to write a program for the USB readers to correctly issue the right commands to read the right type 3 or 4 Tag.
As noted the Android (or Iphone) "Taginfo" App from NXP implements reading using the Type 3 and 4 protocols, so this should tell you what the Tag is behaving as and the you can write the software for the USB readers to match.
Type 3 and 4 specifications
I'm trying to implement the functionality for emulating a Mifare One (1K/S50, ISO14443A) chip to be able to use a phone with NFC capability instead of a physical Mifare card or, if possible sending only the data to the reader.
I have this type of reader/writer: https://www.evelta.com/er302-high-frequency-nfc-writer-usb/
After looking around on forums, stackoverflow questions I found this article to be the best example:
https://medium.com/the-almanac/how-to-build-a-simple-smart-card-emulator-reader-for-android-7975fae4040f
I implemented the HCE part, run the program, and the reader beleives my phone is a Mifare chip, so far so good.
My problems:
No matter what "standard" Authentication key I tried to use...it gives me Auth error. I read this question about Auth: Authentication failure for Mifare 1K NFC tag using ACR122U NFC reader, it works on a physical Mifare card...but I don't know how to set or get to know the keys for the emulated one.
I don't get why this example emulates that exact Mifare chip type...even breakpoints don't work in the APDUService, but the reader detecting a Mifare cheap somehow.
After reading about it, I get I can't 100% emulate a physical card, so I have to send all the data I want in my APDU response with the service somehow (I beleive it's the transreceive part).
However I can't even authenticate.
I tried to look for other possible solutions:
AndroidBeam: Android - Android p2p...sounds simple, relatively high-level API, but it's being deprecated, moreover it's not guaranted that the reader will even use Android...it might be a 'simple' USB reader hardware like the one I use.
SecureElement: Ironically...it seems to be the most recommended, I read that 'yes, it's possible for mifare' and things like that, yet I couldn't find a good example of it and the official Google docs don't have any good example. I read that it's for "ISO/IEC 7816-4", but Mifare 1K is ISO14443A, so I'm a bit sceptic about this API.
"Simply" sending the data to the reader: If I could just simply "push" the data out to the reader when it's reading the phone without complicating the matter or emulating anything...it would be great but I don't know if it's even possible. This whole NFC topic seems to be more and more complex.
So alltogether I only need to do one thing: taking the data and send it to the reader.
I realized it's a fairy tale like illusion to beleive it's as simple as it sounds, still, I hope there is a way to do it.
If I could send the data in it's own, without emulating Mifare or anything...after all what matters is that the data on the card, not the type of the chip, the more simple the solution will be, the better.
Sorry for possible English grammar mistakes.
The problem is you cannot use HCE on Android to emulate a Mifare Classic 1K (https://www.nxp.com/docs/en/data-sheet/MF1S50YYX_V1.pdf) as this is a custom Type NFC card. As HCE is about emulating Type 4 cards. See https://developer.android.com/guide/topics/connectivity/nfc/hce#SupportedProtocols
And the below image helps understand the type.
You can see this from it's datasheet, nowhere does it talk about AID's and standard Type 4 NFC commands
Though Type 2 and Type 4 can share the Anti Collision mechanism and Reading the UID (which is part of the process) any other access methods are not shared.
Type 4 Spec for reference is at http://apps4android.org/nfc-specifications/NFCForum-TS-Type-4-Tag_2.0.pdf
I have seen some USB readers that offer on reader emulation of other card types but not HCE where the host does the emulation not the NFC hardware.
The Authentication on Type 4 Cards or emulated ones is handled differently.
You can emulate a MIFARE DESFire Card as that is a Type 4 card.
The specs of your card reader are not documented well and it looks very "lite" and that it does not support any of the higher level protocols needed to talk to non Mifare Classic cards. It could support them but as Mifare protocol was the original spec, it could be possible for it to be and old design and only support the Mifare protocol.
For my master thesis I'm investigating the possibility to use an NFC enabled phone for opening off-line door locks. These locks currently work with DESFire cards which contains authorisation data. Furthermore, the card is also used to update configurations and obtain maintenance messages to/from the lock. The goal is to update and read this information to/from the lock via an application on the phone that communicates with an external server over the internet ultimately making the exchange of this information more efficient.
Currently, I think the best choice for getting card emulation to work is to use an SD card with NFC and a secure element. This provides two possibilities:
1) A possibility is to implement a custom made java card applet that emulates a DESFire card. Theoretically, this should be feasible as DESFire cards optionally supports APDUs (ISO7816).
2) Some of the NFC SD cards available on the market offer DESFire emulation as a ROM.
I've the following questions:
For option 1 I wonder what will happen if the off-line lock / reader initiates communication using DESFire 'native' commands instead of APDUs. Is it possible to interpret non-APDU commands from java card? If not, it probably means it will not work?
Is it possible to manage the content of an emulated DESFire card in option 2? The NFC SD cards that I saw provides a proprietary API to access the secure element. It allows this by transceiving APDUs. The emulated DESFire, however, is not a java card applet in this case but it is a ROM which may or may not support this communication with APDUs.
I know this question is not strictly related to programming. But I found that there are quite some people on stackoverflow with expertise on NFC related topics. In fact, I found most of my information here.
Thanks
In order to answer 1 you would need to examine carefully ETSI 102 705 and see if the API lets you process CLT events (lower level protocol exchanges) instead of the contactless chip. I think this is unlikely.
In option 2 there surely is a way to manage the contents, otherwise the proposed desfire emulation would be totally worthless, but this might end up being partly proprietary, or requiring a substantial effort in cryptography, in which case you need to obtain the right keys.
All in all, if I were you, I would do ISO7816 (14443-4) card emulation using javacard, and forget about all the NXP proprietary stuff, which is built to make you buy licenses and associated software solutions.
I am often being asked about standards, the NFC is based on. I summarized my knowledge in the text below. I hope it can be an answer to such questions. Please feel free to correct it by posting comments and replies - I will include it into my text.
Since NFC is based on RFID, it is often seen as RFID extension, its form or subset. It is correct because many existing standards from RFID were adopted in the NFC. The NFC base standard for physical layer is NFCIP-1 (ISO 18092 or ECMA 340) - it standardizes communication between two NFC devices. The RF layer use in the NFCIP-1 is directly inherited from older ISO standards ISO 14443 (proximity contactless cards) more specifically the Type A protocol defined in that standard, and on Japanese JIS 6319-4 (on which Sony FeliCa is based, also used by the NFC Forum Type 3 Tag standard). The consequence of that is that NFC devices (reader/writer mode) is compatible with ISO 14443 smart cards.
NFCIP-1 defines newly the active mode. In this mode in which both communicating NFC devices must have own source of power for generating RF fields (i.e. two mobile devices or mobile device and NFC reader) and both can be initiators of the communication.
The 2nd major standard is NFCIP-2 (ISO 21481 or ECMA 352), which defines selection mechanism between different contactless technologies that operates on the same frequency 13.56Mhz. It is intended to be used by mobile devices that support communication according to ISO 18092, ISO 14443, but they be also compatible other contactless standards like ISO 15693.
In addition to that NFC Forum released also couple of other standards like NDEF (data format) RTD (record types for various purposes), and recommendations for NFC Handover and in particular use of the NFC for Bluetooth pairing. The Wi-Fi Alliance introduced NFC as the one of four ways to configure home networks.
NFC forum also defined LLCP protocol used on the top of NFCIP-1 in peer-to-peer communication. Another protocol used in peer-to-peer communication on the top of the LLCP is SNEP (Simple NDEF Exchange protocol), which allows the exchange of NDEF messages analogous to tag operation specifications.
NFC devices can in addition work in card emulation mode, which allows them to pretend they are passive contactless smart cards. This might be the most important mode, since it allows the mobile phones act as contactless payment cards. There are couple of standards for interconnection of NFC controller with secure element (element used for storing secure applications and sensitive data) used in card emulation mode - SWP (Not standard yet - see ETSI TS 102 613 V.9.1.0) and NFC-WI (ECMA-373).
I am not 100% sure about above text correctness, so my question is - is it correct or not? Is there anything you would add?
BR
STeN
Added comments from NFC guy
I am not sure your questions belong on SO, as they are not related to programming. Stil, I have some comments and additions.
NFC-IP1 is based on ISO 14443, more specifically the Type A protocol defined in that standard, and on JIS 6319-4 (on which Sony FeliCa is based, also used by the NFC Forum Type 3 Tag standard). NFC-IP1 is not based in any way on ISO 15693.
I don't think it is necessary for a device to support NFC-IP2 to be considered an NFC-enabled device. Also, LLCP does not require active mode.
When talking about NFC standards, I would also mention SNEP (Simple NDEF Exchange Protocol), which uses LLCP to exchange NDEF messages. Next to Bluetooth handover, NFC Connection Handover has also been standardized for WiFi by the WiFi Alliance.
Connecting a secure element to an NFC controller: the protocol is called SWP (not SWI). This protocol is typically used to connect a SIM card as a secure element to the NFC controller.
Another standard you may find worth mentioning is ISO 7816-4, as that is used by the NFC Forum Type 4 Tag standard.
ISO15693 standards compatibility was added in fall 2015 or so by NFC Forum.