Is it possible to read, modify and write back the modified value during a single 'touch' of a Mifare Classic card? All the tutorials only read or write during a single 'touch', not both. If so, are there any caveats that attention must be paid to?
With devices I've worked with (android with nxp controllers, hid omnikey and 6055b reader), yes. Naturally, a read and write will take longer than just a read but can be done in a reasonable amount of time
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 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 understand that the EM4100 cards contain only read-only data, and no new data can be written to it. So my question is: who writes the initial data? Is it like a cd (write once) or does it have some kind of id/code on it when you buy it?
Thanks!
Tekin.
EM4100 is normally read only chip (chip spec on http://www.mikroe.com/download/eng/documents/development-tools/components/em4100_datasheet.pdf).
You have to order the good programming from your manufacturer/reseller and it will be done on the factory.
Depending on your use case, you can also purchase EM4100-like chip which behave just like these (in read at least) but are R&W with appropriate hardware.
As part of my university project I am trying to read NFC data (13.56MHz) at a longer range (~60 cm). I have already developed code that reads data from the card at close proximity, using libnfc and a standard USB based NFC reader.
I am facing the challenge to read data from distance. All the information I have seen out there seems to be a few years old with unsupported hardware.
My initial thoughts were to try to find a NFC reader that I could just plugged a bigger antenna, as you can do with 802.11 wireless technology...
I would appreciate some tips on how to achieve my goal, what type of hardware would I need? And could I still use libnfc and my code?
Cheers
The current state of the NFV standard relates to the RFID standard ISO14443, which is a shortrange system. The NFC forum works on adding ISO15693 to the NFC standard, which allows longrange applications. Some NFC devices do support ISO15693 already.
With a proper longrange reader and a large antenna, 60cm with ISO15693 tags is possible.
However, aside of the type of RFID used in the tags, there is also the issue of the RF power for the reader antenna. A mobile device, like a phone, does not have enough energy to power a longrange antenna to read over 60cm distance.
I'm hoping to connect two USB barcode scanners to a single computer, allowing two people to scan ticket barcodes simultaneously. If both people scan at the same time, however, the input from STDIN will get messy.
Is there a way to set up different STDIN streams, each tied to a specific USB port? The console script is in Ruby, though pointers in any language would be much appreciated.
Try connecting 2 USB barcode scanners first and test if what you are afraid of happens. I suspect all barcode digits are sent in a single burst while interrupts from other keyboard-like devices are on hold - so you won't get two barcodes "interlaced" together.
It's impossible to have more than one stdin, not literally. Other options will depend based on the OS you are on - on linux maybe the drivers provide you different character devices for different scanners. On Windows i believe you will have to learn talking the USB HID protocol... best if you don't have to do any of that.
To answer your question directly, there is no way to have more than one STDIN. You're best bet would be to read the data from a file (I would think you should have a character device or something for this scanner)
What if you use a Mutex to synchronize them so only one scan can be processed at a time?
Here's a tutorial on working with threads in Ruby
http://ruby-doc.org/docs/ProgrammingRuby/html/tut_threads.html