I'm creating a system that uses NTAG203 tags to identify accounts. The tags are formatted in the following way:
An Android app reads the tag's unique id.
The tag id is sent to a web server.
The web server creates a new account record, create a hash and salt from a combination of the new account id and the tag id and stores the hash and salt with the new account record.
The hash is returned to the Android app which then writes it on the tag.
When the tag is then scanned in future, the hash and tag id is sent to the web server for authentication.
My question is, how easy would it be to duplicate a tag like this? This would involve creating a tag with the same unique id, is this possible or can only NXP create the chips?
Creating or modifying a tag such that it is identical is probably rather hard. However, emulating such a tag is not so hard. Several hardware platforms or schematics for them that can do this can be found on the Internet.
In general, it is not a good idea to make your security depend on the uniqueness of the ID or address of a piece of hardware that was not designed for security.
You could use NDEF record type 'U' well known category type 1 (drop the http:\) or type 2 (drop the https:\) and write protect the tag after a successful write - remember that the OTP also should be set for the NDEF aspect to work else you will have either a TAG DISCOVERED or TECH DISCOVERED (which means either it has content but not NDEF else is an empty tag. Look up the NDEF standards for NFC, which are NOT part of the android framework, but is used by the framework.
Trap the tag ID (NDEF DISCOVERED or TECH DISCOVERED or TAG DISCOVERED) - if NDEF then do the server lookup, else treat as an empty tag - pass the Ident (remember its the 14A not 16A image value!) to the server for lookup, and on return perform a dead drop write (else display a button and let user press with tag present). The encoding and decoding action of the NDEF NFC will be then as per the user phone setting, and automatic by android.
The 'emulation' aspect of a ISO14443 (a,b,c) tag by a device is still in its infancy, but if an Ident is present, has got a lock field and user area that is consistent then it is fairly difficult to duplicate - but add in some obfuscation and it gets interesting. There is a requirement that certain areas cannot be written to, or the lock bits undone, will give you an idea if the tag is being emulated or not. The NTAG201/NTAG203/MIFARE tags are freely available, look on ebay.
Related
First, I want to apologize. I am complete noob in this area and many of my thoughts are probably misleading.
I need to verify that a user of my app is on a specific place in order to be authirized to perform an action. I want to use NFC for this purpose. The user have to put his smartphone by a NFC tag in order to be authorized to perform the action. Easy but I need it to be reasonably hackerproof. It means that the NFC tag must be impossible to clone without physical damage to the plastics around the NFC chip. It also means that the NFC chip must not contain only static data. The NFC chip must contain an app, that can receive some data (cryptographic challenge) and signs them using secure built-in private key (which must be unreadable through NFC interface). When the user wants to perform the action, he will ask server for the challenge, then he lets the chip to sign it, and then he sends the signed challenge back to the server which will verify the signature using known public key. This should be achievable using NFC JavaCard. But do these NFC JavaCards actually exist? I wasn't able to find a company which would be able to produce such NFC tags for me. When I try to explain my requirements to a NFC tags producer he looks like he has never heard of NFC JavaCards. I have tried about 10 producers without luck.
Can a commonly available chip meet my requirements? I mean a chip from the Mifare familly. I suspect that Mifare DESfire might be able to meet my requirements, but I am not sure.
Feel free to respond with an advertisement, because relevant advertisement is exactly what I look for :)
I try to collect some useful facts:
NFC is a very broad term, just finding that on both sides does not ensure interoperability.
Any ISO 14443 (one of the NFC flavours) compliant smart card with crypto functionality should be usable. Note, that a card with native OS may be a viable alternative to a JavaCard, since the functionality to sign a random number is pretty standard.
Any smart phone sporting a NFC chip can address such a card in principle. Unfortunately this is strongly dependent on the OS of the smart phone, for Android the relevant class to use is IsoDep, which gives you the APDU interface. After triggering the "card enters field" event, then the app receives a handle, via which further communication can take place.
Real smart cards can't be cloned, since you are not able to dump them; especially keys can't be read.
Now some things to consider:
Your approach looks unusual, which might become a problem. (To have a portable card somehow fixed to a wall, just to get the location; so you know where somebody is, but not who? While I don't consider cloning to be an issue, you somehow must ensure destruction in case of a theft attempt, which may collide with the distance topic below.)
I don't see, where the server comes into play. If not involved in the authorized action, provision of a random number is not sufficient reason.
Asymmetric key operations have a comparatively high power consumption, and this power has to be supplied via the electric field. This severely limits the distance between card and phone and may even require direct touch. While a power supply of its own would solve the issue in principle, it is not what ISO-14443 was designed for.
Yes JavaCards do exist.
https://github.com/OpenJavaCard/openjavacard-ndef is a project makes these JavaCards to output standard NDEF messages (thought note issue 4 in that there example uses the wrong APDU but that is easily changed)
This project also give a number of cards it is fully working and tested for
ACS ACOSJ - fully working
NXP JCOP J3D040/J3D081/J2E145 etc - fully working
Both ACS and Cardlogic do cards (just google the model numbers)
e.g.
https://www.acs.com.hk/en/products/405/acosj-java-card-combi/
https://www.smartcardfocus.com/shop/ilp/id~707/j3a081-80k/p/index.shtml
The answer a was looking for is not a chip which runs a custom code. Although this might be possible it is definitely not the best way to achieve the target.
I was looking for a solution that enables strong authentication using NFC data. There might be multiple chips that offers this, but probably the most available chip is NTAG 424 DNA TT. It works like this:
The chip has a memory, which is not readable through NFC. Private key is stored there.
The chip has a read counter. It increments everytime the data are read through NFC.
The chip can generate an AES-128 signature of string UID (chip serial number) + counter using the private key in the inaccessible part of the memory.
The chip can dynamicaly inject the data above into a URL that is stored in the readable memory.
So the solution will be like (I am waiting for delivery of NFC tags right now, so I don't know for sure yet):
Read the tag UID (serial number) and the actual counter value (should be 0 on an unused tag)
Generate the key-pair
Load private key to the chip
Load some data (URL, eg: https://my.app/) to the chip
Store UID, public-key, last-counter on the server
Configure the chip to inject UID, counter, signature to the URL stored on the chip
When a client reads the data, they should contain required variables, eg: https://my.app/?counter=1&uid=ff:ff:ff:ff&signature=xyz. Then on the server:
Fetch stored info (public-key, last-counter) using uid as a primary key
verifies the signature
verifies the counter that must be > last-counter
stores counter as the last-counter
successfully authorized
Is anyone able to hack this without reading the hidden memory of the chip which would require physical tampering with the chip?
I am trying to implement an authorization system based on general NFC tags. One of the concerns I want to address is tag cloning. I have read some literature ensuring tag authenticity by using a read-only tag ID written on the tags during manufacture. This ID is signed by the owner and written on the tag. This way, a cloned tag (which will have a different, tag-manufacturer assigned ID) can be detected by comparing tag IDs with the cloned signature.
My question is, is it safe to assume that all (or most) NFC tags will have such a coded-in, read-only ID which I may use for cloning detection?
Narrow your problem down first pick a tag type and manufacturer that is suitably secure for your needs.
A UID is a general property of most tags BUT different tags have different specifications. Some tags have a small UID size and thus UID re-use is likely. Different tags have different length UID's. Some are supposed to be set at the factory but clones allow them to be set later. Some specification state the tag UID is always writeable.
Also using Host Card Emulation, it possible to write program to brute force any security based on UID alone (time taken could vary depending on UID length used)
Various tags offer password protection and encryption of the data on the tag (older tag types can have weak encryption/password protection though).
Most of the of the password protection is done with a special area where a password can be written to by a Reader/Writer but can only be read by the tag itself.
If you do use the password protection features of some tags make sure you don't the same password for every instance of the system, make sure the Admin of the system is forced to set one for their systems.
Considering UID for authenticity check is not a good idea, because cloned cards can have the UID cloned exact same as that of original card.
I'm not sure about other manufacturers, but as I have worked a lot with NXP tags, I'm just gonna suggest a solution here, if that suits your requirements then you can go ahead. For working with NXP cards they have provided an open api called TapLinx, where you get an api for originality check. Using which you can get to know if the card is authentic or cloned. It will identify the cloned cards even if the UID is also cloned.
Do not rely on the UID as security mechanism. There are cloned chips on the market, as well as chips where you can program the UID yourself. On top we have seen mistakes from manufactureres, resulting in duplicate UIDs.
Better use your own numbering scheme. Ideally on a cryptographic basis.
I have one stupid question. I have mifare classic tags (1k). I want to hide content of this card (any data stored there). How to do it?
What about ndef records?
MFC (MiFare Classic) got reverse engineered completely, so storage should be considered read-write, and clear text, copiable/clonable, etc.
If you can afford encryption of the payload before putting it on the card, you may be able to make data confidential, but not "hide" it: third parties will be able to tell card is not blank, but will not be able to tell what is actually stored.
NDEF wont help you there.
MIFARE Classic allows to store data in sectors, which can be access protected. So authentication with the sector key needs to be done before any read operation (if configured that way).
"Generic" apps like NFC TagInfo usually try out "well-known" keys, before declaring a sector content "unknown". They don't try to hack the keys.
You can also use more advanced products, like MIFARE Plus or MIFARE DESFire, which both use AES cryptography for authentication and data encryption.
Came across a 2012 post Prevent copying nfc chip signal that advises:
"Recommend against using the tag's unique ID as a security feature."
Why, other than the reasons stated below, is it a security problem to use the unique ID as part of the message that generates a Message Authentication Code (MAC)?
My application is to use an RFID transponder's 8-byte fixed unique ID, a portion of the RFID's 100s of data bytes and some random data* to derive a MAC. This MAC will be used to authenticate the tag's message.
The primary reason for incorporating the unique ID into the MAC is that it prevents a simple copy of the tag's message and MAC to another tag does not yield a legitimate MAC.
The MAC needs to be of sufficient size, with/without the ID. MAC size target: 512 bits (32 bytes).
Known issues:
One known attack is to make a direct copy of the entire tag's data and ID and then port this to a tag simulator which can recreate the ID on a different tag. So using the ID does not help.
MAC variation that depends solely on the ID variation (the other data is the same), may help break the MAC. To secure against this vulnerability, the MAC must also depend on additional random data.
4 bytes of random data to ensure, should the data content be repeated, the variation of the MAC depends on more than the unique ID - in essence, extending the ID.
In this case you would not use the ID as a security feature, I would say. It would just be part of the input of the MAC generation. Using the ID as a security feature could for example be relying on the fact that the ID is unique. That is a dangerous assumption, because it can in fact be spoofed.
Can we duplicate the information? i mean:
i want to store a unique information in my tag(i want only one tag with unique information)
for example: boss having a tag ("my secured text")..
can employee do a same copy like("my secure text")in his tag?
AND IF boss's tag lost means how can he recreate the tag with same information ("my secure text")?
It sounds as if you do not want to have simple data storage tags (storing for example NDEF-formatted data). The data contents of such a simple tag can easily be copied from one tag to another. You should probably look into tags offering more sophisticated features such as authentication or encryption. An example of such a tag that is still affordable is the DESFire chip by NXP, see for feature description http://www.nxp.com/products/identification_and_security/smart_card_ics/mifare_smart_card_ics/mifare_desfire/
To recreate a lost tag, you need to keep a backup of the information stored on it.
you could use tagstand tasklauncher app to protect your data. The data in this software has 2 formats. one is for public, allowing all the user access it and the other is for private, which is stored in the local cellphone memory, and can be access only by the cellphone holder.
Wish this information may help you.