contactless-smartcard

I am reading several hundred bytes from a DESFire card using APDU commands. The data application is authenticated, and the response MAC'ed. I submit a series of READ_DATA commands (0xBD), each retrieving 54 bytes+MAC while increasing read offset for each command. Will this operation go much quicker if I use a long READ with ADDITIONAL_FRAME (AF) instead of many sequential reads? I understand that a simple AF is 1 byte vs 8 bytes for a full READ DATA command, thus reducing the number of bytes transferred by ~10%. But will use of AF give additional performance benefits, for example because of

Is it possible using ATR to determine whether I have ISO14443A or ISO14443B type card? If yes, how? Michael Roland As mictter correctly explained , a real AT R only exists for ISO 7816 contact cards. I can follow the argumentation that the ISO 14443 equivalent could be the ATQA/ATQB as this is the first answer you get from tags after activation, though I would rather say that the equvalent of the ATR is a combination of ATQA + SAK + ATS (for Type A) and a combination of ATQB + Answer to ATTRIB (for Type B). Regarding the ATR you see, I assume that this is a PC/SC-emulated ATR according to the

I am developing an Android app which has function to read data from a smart card. By default, NFC Controllers support APDU command with maximum transceive length is 261 bytes in single command. Because of large data need to be read on the card, the speed of reading is very slow. Are there any Android phones which support extended APDUs allow to send more than 261 bytes in single APDU ? Or are there any ways to modify the maximum transceive length by calling Android API to allow to do that? I have found some topic: link In which they increased the hard-coded value in the NativeNfcManager.java

This question is specifically about MIFARE Ultralight C/EV1, or MIFARE DESFire EV1, or even NTAG cards. I want to implement a system of tokens, so that each time a normal user reads one of those cards they'll get one available token; that token will "pop out" from the NFC card they're reading. In other words, every time that NFC chip is read, it will issue a different usable token from the card's storage. Is this possible to implement? Common non-programmable smart cards usually provide one of (or some combination) of the following: fuse bits -- a memory area where values of individual bits

What I am trying to achieve is to send APDU command to MIFARE Classic 1K card to change its A and B keys. I was able to establish a connection with the card and use a default key ( FFFFFFFFFFFF ) to read block 0 and block 1. I used HID MifareSamples application for it. Now, I would like to change A key from default to something else. I found a solution here, at stackoverflow ( Mifare Change KEY A and B ) which suggests that I have to send this APDU: New key A = 00 11 22 33 44 55 Access bits not overwritten Key B not used (so FF FF FF FF FF FF) => Write to Sector Trailer 00 11 22 33 44 55 FF 0F

My aim is to have only KEY A authentification and disable Key B (used space to store data). I read these documentations: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf http://dangerousthings.com/wp-content/uploads/2012/08/NFC-Access-Control-for-Mifare-S50.pdf I understand how to calculate the hexadecimal values of these three bytes. But I don't understand how to choose the good data block and access byte rules : Data Block rule Here, I want to keep only key A (R & Write data) and deactivate Key B. I choosed the first rule: C1=0 C2= C3=0. Is this right? Access byte rule I would like to

I'm new to this field, I got a Nexus S ( CyanogenMod11 = Android Kitkat 4.4.2) And I need to use HCE (Host-Based Card Emulation) mode in order to emulate a contactless card. Any guidance on the steps and the tips I need to follow in order to accomplish this? ( - Do I need to program the simulated Secure Element? put it on cloud? ) P.S: I have to use the new Reader Mode also, because my app is going to be read by another Android NfC-enabled phone and not by an NFC reader. Thank you. Michael Roland Before CyanogenMod 11, CyanogenMod supported its own host-based card emulation functionality. You