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.
Related
I tried to write a NDEF text message to an NFC NTAG 213 chip. I use the nfcpy library for that. The problem now is that I want to lock a specific NDEF text record on the chip and want to modify or add different records later on.
Generally you can only lock the whole chip with the nfcpy library. I consider to only lock the pages which are written for the records I want to lock. When I only lock the pages where the data is stored I can not write any other NDEF record to the chip.
Is there a way to create an offset or is there a specific padding mechanism for that? Or is it only possible to have several NDEF records in one order? So the only thing I want to achieve is have multiple records on the chip and one record should be read only.
If you look at the datasheet you can configure password protection on write operations, this might achieve what you want.
This is different to locking the chip at the Ndef level as that is a one way operation for the whole chip.
Thus with password on write operations only then the chip is effectively locked Unless you know the password where you can then re-write the whole Ndef message (The standard Ndef system only allows you to write whole Ndef messages, thus to add a ndef record all records have to be re-written)
While you can set the start block address of the password protection you cannot leave the first part open for writing while having the second part password protected because the whole ndef message re-writing (and because the first record size might change and the start address would have to change as well.
Detail example of setting a password at https://stackoverflow.com/a/22723250/2373819 (you will just have to adjust the memory locations used for your size of Tag)
thank you for the detailed answer. I think that it is a good solution with the password. I already suspected that the first block of the NDEF message changed when writing another message. My approach was that I can lock the first message manually with the lock bytes or in other areas with the dynamic lock bytes. But that doesn't seem to work because the header probably changes when writing another NDEF message/record.
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 want to create a NFC-enabled pass for ApplePay. My problem ist I dont know how I get the merchent the pass was used and how can I configure which mergents are allowed.
The idea is:
- User gets our loyality card
- User goes into the store and pays with ApplePay
- I get information were the user pays to manage loyality points
But I can' find a way in the documentation were I can define allowed stores, or how I get an feedback about buying something on a store.
I think this is the important part of the documentation:
The NFC-enabled pass will not function without a terminal compatible with the Apple value added services protocol. Each NFC-enabled pass contains a 64-byte data element which can identify a customer. This data element can represent a rewards card for a loyalty program, a stored value card, or a ticket. Apple Wallet only transmits this data element to an NFC-enabled terminal that is compatible with the Apple value added services protocol.
NFC-Enabled Pass Keys
NFC-enabled pass keys support sending reward card information as part of an Apple Pay transaction.
Important: NFC-enabled pass keys are only supported in passes that contain an Enhanced Passbook/NFC certificate. For more information, contact merchant support at https://developer.apple.com/contact/passkit/.
Passes can send reward card information to a terminal as part of an Apple Pay transaction. This feature requires a payment terminal that supports NFC-entitled passes. Specifically, the terminal must implement the Value Added Services Protocol.
Passes provide the required information using the nfc key. The value of this key is a dictionary containing the keys described in NFC Dictionary Keys. This functionality allows passes to act as the user’s credentials in the context of the NFC Value Added Service Protocol. It is available only for storeCard style passes.
Key name Type Description
nfc nfc dictionary Optional. Information used for Value Added
Service Protocol transactions. For
this dictionary’s keys, see
NFC Dictionary Keys.
Available in iOS 9.0.
NFC Dictionary Keys
Information about the NFC payload passed to an Apple Pay terminal.
Key name Type Description
message string Required. The payload to be transmitted to the Apple
Pay terminal. Must be 64 bytes or less. Messages
longer than 64 bytes are truncated by the system.
encryptionPublicKey string Optional. The public encryption key used by the
Value Added Services protocol. Use a Base64
encoded X.509 SubjectPublicKeyInfo structure
containing a ECDH public key for group P256.
But as I can see there is only a possibility to give a message, but not to define a merchant or to define a callback.
How will I know where the card is used? How can i define which merchants are allowed?
Thanks
It is not possible to determine when an ApplePay card is used other than from the terminal provider itself. You would need to have a NFC-enabled loyalty pass in the users wallet and use a VAS enabled NFC reader to read the relevant user data, then you would have application logic in your terminal to determine where the pass was used.
At PassNinja, we provide readers and an SDK that can read GPay and Apple Pay loyalty passes.
I am a software developer so I have quite a lot of reading to do on hardware. My questions is this :
My goal is to create an RFID tag that has dynamic data. So I plan to use a microcontroller to be the processor and input data to an RFID module. I have did some research on RFID in general, is it actually possible to change RFID/NFC tag values via wiring instead of and RFID writer?
I really hope someone could give me some guidiance on this.
There are commercial ICs available from different manufacturers - e.g. NXP's NTAG I2C or ST's ST25 Dynamic NFC Tags.
You can connect them to your µController and share data to a phone. Most conveniently in the form of an NDEF message, as this can be read by iPhones as well.
Also the other direction (phone to µC) works, e.g. for configuration or firmware upload purposes (restricted to Android).
Commercial rfid tags generally have a manufacturer assigned ID (similar to a MAC address. Additionally, programmable tags have a raw memory that you can directly write bytes into sections.
When you read one with a reader, you'll get back this ID and the byte contents of the section you ask for.
A more typical use would be using the id to access a dataset stored somewhere else. Storing data locally isn't impossible though, you can also get write once types, each memory section can't be overwritten. The accrual memory capacity tends to be extremely small, like long url only.
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.