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.
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'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.
Can someone explain what is the difference/relationship between the two?
Now I'm using GPShell + globalplatform + pcsclite too manipulate the NFC-enabled card. From my point of view (I don't know much about libnfc) pcsclite and libnfc do the same.
pcsclite (or rather PC/SC in general and not just the pcsclite implementation)
PC/SC is a smartcard API for the personal computer platform (initially mainly destop computers, but also servers, etc and even smartphones and other embedded systems). So PC/SC is a standard that provides interoperability between arbitrary smartcard readers and arbitrary PC platforms from different manufacturers. pcsclite is the implementation of this interoperability layer (from developer point of view basically providing a standardized API that is idependent of the smartcard and reader platform as well as the target OS). PC/SC comes from times before contactless smartcards and has since been extended to contactless smartcards and contactless memory cards.
libnfc
libnfc is a library for NFC controller chips and provides a standardized way to access an NFC interface. While this also permits access to contactless smartcards and memory cards/NFC tags, NFC controllers have much more capabilities (peer-to-peer mode communication and (host) card emulation). These capabilities are covered by libnfc (btw, there is not really a standard* defining the interfaces and layers of the software stack behind libnfc as is with PC/SC).
*) This is starting to change with the NFC Forum's NCI specification (at least for the lower levels).
To summarize, pcsclite is for access to smartcard readers (that could also be contactless smartcard readers) and libnfc is for access to NFC interfaces (which are something different than smartcard readers, though they may sometimes be used for the purpose of reading contactless smartcards). So, libnfc and pcsclite simply have a different purpose and comparing them is pretty much like comparing apples and oranges.
I am very new to the smart cards and I think I have misunderstood some things.
I want to be able to sign messages using ECDSA with the card's private key(s). Also have some custom logic for key derivation.
Is it possible with Mifare DESFire? If not, what other NFC smart cards could do that?
Thanks
No, MIFARE DESFire is a memory card (with some additional protection mechansims for authentication/access control and encryption) so it's not possible to run custom code on such a card. DESFire cards only have symmetric keys for authentication and support only (3)DES and AES (only EV1) encryption of the exchanged data.
If you want to be able to create digital signatures and do other asymmetric cryptography with a card, I suggest you look into processor smartcards. Besides contactless cards with pre-loaded cryptography applications, I suggest you look into Java Cards if you want to create your own card-side applications or if you want some existing open-source applets like OpenPGPcard. Note that you need to make sure that the card contains an asymmetric co-processor with support for ECDSA if you want to create an application that performs ECDSA signatures.
Keep in mind, however, that the NFC interface of mobile phones is typically designed for interaction with low-power NFC tags. Consequently, communication with processor cards (particularly in combination with cryptography) may result in problems.
Not on desfire but just get any smart card with contactless capabilities and implement something like ndef on top of it. Like Yubikey NEO's applet that generates a NDEF message with OTP keys, for example.
I'm wondering if NFC chips have some kind of unique identifier? I have Mifare Classic 1K and Mifare Ultralight C stickers that I want NFC phones to read using my android application, is there some common practice to protect the signal so someone can't just come in and scan the data using a generic app (NFC Reader), and write the data to another chip in order to fake my sticker signal. Or, is there a unique ID like how phone UUID works built in these chips?
I'm afraid with tags there is always the risk of evesdropping, man-in-the-middle or relay attacks. The best you could hope for would be encrypt the data using a pre-known secret on your device and the tag.
This still has the risk of the secret being found out and then copied.
NFC really isn't designed to be a highly secure platform.
For device to device you can implement protocols on TOP of the existing NFC stack (such as SSL) however this wouldn't work with pre-generated tags.
Yes each chip has an unique identifier, however the comments from the other people here about lack of security are of concern as this is the currently (growing) preferred hardware platform of choice for financial transactions of the future.
Cloning is a greater challenge than just sucking the data off one chip and replicating it on another.
What specific usage did you envisage for your 'highly secure' Android application?
You have MIFARE Ultralight C tags. These tags have functionality that allows one to protect access to data stored on the tag to be protected by 3DES-based authentication. That would prevent unauthorized read access.
In general, I would recommend against using the tag's unique ID as a security feature.