I'm new to the NFC standards and I have only played with Ntag203, Mifare Classic and Desfire. I'm trying to figure out what is the advantage of Desfire for our application.
I have looked through ISO 14443 and ISO 7816-4 standards and I can only figure out that the Desfire provides a standards compliant API to manage encryption to ensure interoperability between OEM client applications, readers and cards.
Let's say I am building a mobile client that needs to encrypt and store data using the same scheme as Desfire (AES or 3DES) - can I do that completely client side with , say ntag203, and not violate any security standards.
I have worked with PCI-DSS and am worried if this is some kind of mandatory technology to be able to process sensitive data like health records, payment balance, etc
Related
I am extremely new to NFC as a technology and have a very basic question. I am investigating the use of NFC tags in the field of authentication. At a broader level imagine a PKI architecture. A private key resides on the NFC tag, and an app can access it for authentication/signing/validation etc.
I understand that smart cards are the de-facto standards for such things, but the cost of NFC tags is far far less. My question is what level of protection is offered by NFC tags for such a scenario or is NFC tag a good choice for such a design?
Can I somehow ensure that a tag is readable by only a certain device? As in, can another user just use his phone/NFC reader to read the key on the tag? What methods are available to protect/restrict access to the data residing on the NFC tag?
There is nothing inherent in an NFC tag that restricts access to read the data to one device. For the most part everyone can read, and everyone can write if the tag has not been made read-only. Some of the newer NTAG series of chips have password features allowing only software with the password to write the tag.
All NFC tags come with a unique manufacturer supplied id that is often uses in security implementations. It is very difficult, but not impossible to clone that ID. It is very easy to close the data on an NFC tag. There are a new set of "secure" tags being developed, but these often have a server-side component. One thing to note, is that while the data on the tag can be read by anyone, that says nothing about what value they actually get.
Many people encrypt the data and store the encrypted value on the NFC tag. The decryption key is then known by the software and can then read and interpret the tag's data. This requires custom software as its not a part of the current NDEF spec. This is really the same as SSL, where someone can sniff the network traffic but not know what the actual data is. In general we advise customers to make the NFC tags as "dumb" as possible and leverage NDEF for the broadest compatibility without custom software.
DISCLAIMER: I am the CEO of GoToTags, an NFC software and tag solutions provider.
NFC tags are basically a data store. They may provide restrictions for accessing data, but they remain a data store. If you implement a PKI with a NFC tag, you only store keys on the tag, no computation is done on tag.
On the other hand, PKI smart cards store the keys, but they also provide the computing resources for calculations done with the keys. Moreover, they are designed in a way keys never leave the card (on demand or by side-channel attacks). This way, you may expect key not to leak.
Because they offer different services, NFC and PKI card interfaces complexities are not the same at all.
Note some PKI smart cards do offer a contactless interface. This is not NFC tag interface, but rather PKCS#15 over ISO14443-4.
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.
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'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.
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.