Develop Reference

Verify the PIN code of a belgian EID card on a reader with PINPAD

All my attemps to verify a PIN code on a PINPAD reader ends up in failure, here is my situation:
Setup
Belgian EID card;
Vasco DIGIPASS 875, connected in Bluetooth;
Android application using the SDK from Vasco.
Situation
I've used APDU command to select and read files, to set the secure environment (MSE : SET), and after numerous research and merging of different solutions from different documentation, I can make the reader ask for my PIN code. But with my pseudo-APDU command, I receive a 69|C# response. The same process (reading files, set secure environment and verify the PIN) works fine on a USB reader with no PINPAD, so I guess that the APDU command is ok, but not the pseudo-APDU command that precedes.
Documentation used
The BEID documentation, PC/SC Spec part 10 (2.5.2) and supplement (2.2.1) and USB Smart Card devices for chapter from 6.1.11.3 to 6.1.11.6.
What did I understand?
The first part should be FF C2 01 06 for direct PIN verification on reader, followed by the size of the subsequent data.
Next should follow the structure from PC/SC part 10, with:
Timeout 1 & 2 (00 for default);
Format (should be 89 for me, as it should be 10001001 for 1 byte offset PIN, justified left and BCD);
PIN block format (should be 48 because 4 bit length included and 8 byte for the PIN block);
PIN length format (04: 4 bit offset in the PIN block);
Min/Max PIN length : 040C (but didn't work like that, 0404 is sure to work);
Validation condition is 02 for ok button;
Number of messages : 01 to use the one in the command;
Language is 0409 for english;
Message to display is 00 for enter PIN;
000000 because this field isn't used;
The length of the final APDU command to transmit once formatted with the PIN (0000000D is my guess);
And then the APDU command : 0020000108FFFFFFFFFFFFFFFF
Results
I have changed several times some values that I wasn't so sure (2, 3, 4, 11 and 12 for the padding characters already present or not), with no success, just different result codes sometimes.
What do I do wrong here ?
Thx in advance !

After a last round of research and checkup, I found another example showing me my mistake: the PIN block ! It was 47, because it didn't include the control/effective PIN length. So the correct answer for me was :
0xFF, 0xC2, 0x01, 0x06, // Base PPDU command
0x20, // Length of the data
0x00, // timeout
0x00, // timeout
0x89, // format
0x47, // PIN block
0x04, // PIN length format
0x04, // Min pin size
0x04, // Max pin size
0x02, // Entry validation condition
0x01, // Number of messages to display
0x04, 0x09, // English
0x00, // Message "Enter pin"
0x00, 0x00, 0x00, // Non significant here
0x00, 0x00, 0x00, 0x0D, // Length of the apdu once formatted
0x00, 0x20, 0x00, 0x01, // APDU command VERIFY
0x08, // APDU command Data length
0x20, // APDU command Control data + Effective PIN length
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF // APDU command PIN + filler

Native DESFire APDU Framing not worked

I'm using Galaxy A5, Android 5.0.2, SDK 21 with Android Studio 1.1.0
Android as PCD, and Mifare DESFire as PICC. Native DESFire APDU Framing didn't work, but ISO 7816-4 worked.
Example:
MIFARE DESFire SelectApplication with AID equal to 000000h (PICC level)
Command: 90 5a 00 00 03 00 00 00 00.
Expected response: 91 00.
Currently the response is 68 00.
Document reference: AN11004.pdf (page 33)
void SelectApp() {
_isoDep.connect();
byte[] reqSelectApp = new byte[]{(byte) 0x90, (byte) 0x5A, (byte) 0x00, (byte) 0x00, (byte) 0x03, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00};
byte[] resSelectApp = _isoDep.transceive(reqSelectApp);
_responseTextView.append(String.format("reqSelectApp: %s length:%d\n", BytesToHexStr(reqSelectApp), reqSelectApp.length));
_responseTextView.append(String.format("resSelectApp: %s length:%d\n", BytesToHexStr(resSelectApp), resSelectApp.length));
}
String BytesToHexStr(byte[] items) {
StringBuilder builder = new StringBuilder();
for (byte item : items) {
builder.append(String.format("%02X", item));
}
return builder.toString();
}
TagInfo scan (version 4.11.59 [β4011059])
INFO
IC manufacturer: NXP Semiconductors
IC type: Unknown IC
NDEF
No NFC data set storage:
EXTRA
TECH
Technologies supported:
ISO/IEC 14443-4 (Type A) compatible
ISO/IEC 14443-3 (Type A) compatible
ISO/IEC 14443-2 (Type A) compatible
Android technology information:
Tag description:
TAG: Tech [android.nfc.tech.IsoDep, android.nfc.tech.NfcA]
android.nfc.tech.IsoDep
Maximum transceive length: 261 bytes
Default maximum transceive time-out: 309 ms
Extended length APDUs not supported
android.nfc.tech.NfcA
Maximum transceive length: 253 bytes
Default maximum transceive time-out: 618 ms
No MIFARE Classic support present in Android
Detailed protocol information:
ID: 04:62:26:82:8A:29:80
ATQA: 0x4403
SAK: 0x20
ATS: 0x1078B3C402654B5450304432654B545000
Max. accepted frame size: 256 bytes (FSCI: 8)
Supported receive rates: 106, 212, 424 kbit/s (DR: 1, 2, 4)
Supported send rates: 106, 212, 424 kbit/s (DS: 1, 2, 4)
Different send and receive rates not supported
SFGT: 4.833 ms (SFGI: 4)
FWT: 1.237 s (FWI: 12)
NAD not supported
CID supported
Historical bytes: 0x654B5450304432654B5450 |eKTP0D2eKTP|

While the ATQA/SAK looks as if the card was DESFire (that's why my NFC TagInfo app detects it as such, but should give you either a read error or does indicate availability of a DESFire master application), the remaining parameters (particularly the historical bytes) clearly indicate that this is something other than a DESFire card.
Hence, don't expect the card to respond to DESFire commands (native or wrapped native). This also matches the behavior of the card as it responds with 68 00 (which indicates that the coding of the CLA byte (0x90 in your case) is not supported).

NFC PN544 NDEF read command flow

I'm using an AS3953 to emulate an NFC Tag, and was already able to read out a simple NDEF message using Samsung S4 or Fame with Broadcom chipsets,
now I'm trying to make it work with a HTC One SV which is using NXP PN544 controller,
the problem is that after my Tag sends the NDEF as an answer to a READ-BINARY from the Smarphone, it is requesting even more,
it's also strange, that it is reading the EF starting from 0x00 while the Broadcom devices start reading from 0x02, which makes more sense to me because address 0x00 and 0x01 contain the size information, which already has been read before,
is this the normal behaviour for PN544 ?
Thx for any ideas,
Andreas
-- ADF_NAME SELECT
0x00: 0x02
0x01: 0x00
0x02: 0xA4
0x03: 0x04
0x04: 0x00
0x05: 0x07
0x06: 0xD2
0x07: 0x76
0x08: 0x00
0x09: 0x00
0x0A: 0x85
0x0B: 0x01
0x0C: 0x01
0x0D: 0x00
>>0x02,0x90,0x00
-- CC_SELECT
0x00: 0x03
0x01: 0x00
0x02: 0xA4
0x03: 0x00
0x04: 0x0C
0x05: 0x02
0x06: 0xE1
0x07: 0x03
>>0x03,0x90,0x00
-- CC_READ
0x00: 0x02
0x01: 0x00
0x02: 0xB0
0x03: 0x00
0x04: 0x00
0x05: 0x0F
>> 0x02, // PCB
0x00,0x0F, // length of CC
0x20, // tag version 2.0
0x00,0x3B, // max length for read
0x00,0x34, // max length for write
0x04, // TLV 4:NDEF EF, 5:Propriety EF (more then one TLV block is allowed by NFC Forum)
0x06, // length info
0xE1,0x04, // NDEF file ID, values 0x0000,0xE102,0xE103,0x3F00,0x3FFF,0xFFFF are reserved
0x10,0x00, // N-max, max size of the file containing the NDEF message, valid range: 0005h to FFFEh
0x00,0x00, // read/write permissions, 0x00: full access
0x90,0x00); // OK
NDEF-SELECT
0x00: 0x03
0x01: 0x00
0x02: 0xA4
0x03: 0x00
0x04: 0x0C
0x05: 0x02
0x06: 0xE1
0x07: 0x04
>>0x03,0x90,0x00
NDEF-SIZE-READ
0x00: 0x02
0x01: 0x00
0x02: 0xB0
0x03: 0x00
0x04: 0x00
0x05: 0x02
>> 0x02,
0x00,0x0D, // length of NDEF message
0x90,0x00); // OK
NDEF-SELECT
0x00: 0x03
0x01: 0x00
0x02: 0xA4
0x03: 0x00
0x04: 0x0C
0x05: 0x02
0x06: 0xE1
0x07: 0x04
>>0x03,0x90,0x00
NDEF-READ
0x00: 0x02
0x01: 0x00
0x02: 0xB0
0x03: 0x00
0x04: 0x00 <- why does it start from 0x00 ?
0x05: 0x0D
>>
0x02, // PCB header
0xD1, // NDEF header, sizeNDEF counts from here (not including the 2 trailing bytes)
0x01, // type length
9, // payload length
'T', // type, for example: 'T'=Text
0x02, // payload: status bytes, UTF-8 ??
'e','n', // language code, for example: "en"
'h','e','l','l','o',0x0A, // text
0x90,0x00 ); // OK
why does the Reader request more ??
0x00: 0x03
0x01: 0x00
0x02: 0xB0
0x03: 0x00
0x04: 0x0D
0x05: 0x3B

It is not the chip that is deciding what commands get sent to your tag-emulation. That decission is made in the middle-ware NFC stack. These differ between Broadcom and NXP PN544 chips.
Regarding the command that you see: Just answer back according to the standard. If the binary-read command fails, then return a proper error-code.
The NFC middleware may send you this command just to see if an answer comes back. It sometimes does this to check if the tag is still in the field. You may also see strange commands that you don't expect because the NFC-stack is probing for rare or special tags that aren't 100% NDEF compatible and need special work-arounds (Old Mifare Desfire tags are one common example).

I just found out the reason: the HTC One SV with PN544 (Android 4.1.2) is requesting the correct length of the EF, but the request starts with an offset of zero, normally the offset should be 0x02, because the first two bytes contain the length information, that means that the apdu answer from the Tag is incomplete, the last two bytes of the message are missing. The software knows it and sends another read request to fetch the last 2 bytes. My apdu answer was hard coded to start at offset of 2

Android NFC IsoDep read file content

I'm trying to read some information out of an ISO/IEC 14443 Type A card.
After analysing the card with the android app NFC TagInfo, I found out, that the application (AID: 15845F) has the particular file (File ID: 01) that I need.
I already managed to connect to the card and to select the application.
String action = getIntent().getAction();
if (NfcAdapter.ACTION_TECH_DISCOVERED.equals(action))
{
Tag tagFromIntent = getIntent().getParcelableExtra(NfcAdapter.EXTRA_TAG);
Log.i(TAG, Arrays.toString(tagFromIntent.getTechList()));
IsoDep isoDep = IsoDep.get(tagFromIntent);
try
{
isoDep.connect();
byte[] SELECT = {
(byte) 0x00, // CLA = 00 (first interindustry command set)
(byte) 0xA4, // INS = A4 (SELECT)
(byte) 0x04, // P1 = 04 (select file by DF name)
(byte) 0x0C, // P2 = 0C (first or only file; no FCI)
(byte) 0x06, // Lc = 6 (data/AID has 6 bytes)
(byte) 0x31, (byte) 0x35,(byte) 0x38,(byte) 0x34,(byte) 0x35,(byte) 0x46 // AID = 15845F
};
byte[] result = isoDep.transceive(SELECT);
Log.i(TAG, "SELECT: " + bin2hex(result));
if (!(result[0] == (byte) 0x90 && result[1] == (byte) 0x00))
throw new IOException("could not select application");
byte[] GET_STRING = {
(byte) 0x00, // CLA Class
(byte) 0xB0, // INS Instruction
(byte) 0x00, // P1 Parameter 1
(byte) 0x00, // P2 Parameter 2
(byte) 0x04 // LE maximal number of bytes expected in result
};
result = isoDep.transceive(GET_STRING);
Log.i(TAG, "GET_STRING: " + bin2hex(result));
}
}
But my second query fails with the error code: 6A86 (Incorrect parameters P1-P2). I already googled a lot and found different documentations (for example: http://bit.ly/180b6tB), but I just could not understand, how I can implement the right values for P1 and P2.
EDIT
Tag type of the card using NFC TagInfo: ISO/IEC 14443-4 Smart Card, Mifare DESFire EV1 (MF3ICD81)
The SELECT command as used in the source code actually did not fail, but instead it returned a 9000 response. So this is why I assumed that everything is working fine.
You mentioned that NFC TagInfo does not provide the correct values for DF-names etc. Is the value 0x313538343546 correct and how did you find it out?
Can you provide me a short description, how I could get the data I want? Are there any other android apps that I can use to read the right DF-names, AIDs etc.? I basically need to get ONE file out of ONE application. I could also provide some screenshots of the information gathered with NFC TagInfo, if needed.
EDIT 2
I have rewritten the commands, but (as you proposed) kept them in the APDU wrapper. Therefore I ended up having two different commands, one for the selection of the application and the other one for the selection of the file.
private final byte[] NATIVE_SELECT_APP_COMMAND = new byte[]
{
(byte) 0x90, (byte) 0x5A, (byte) 0x00, (byte) 0x00, 3, // SELECT
(byte) 0x5F, (byte) 0x84, (byte) 0x15, (byte) 0x00 // APPLICATION ID
};
private final byte[] NATIVE_SELECT_FILE_COMMAND = new byte[]
{
(byte) 0x90, (byte) 0xBD, (byte) 0x00, (byte) 0x00, 7, // READ
(byte) 0x01, // FILE ID
(byte) 0x00, (byte) 0x00, (byte) 0x00, // OFFSET
(byte) 0x00, (byte) 0x00, (byte) 0x00, // LENGTH
(byte) 0x00
};
The search for a tutorial for native Mifire-Desfire commands was not successful, so I stick to the following tutorial: http://noobstah.blogspot.de/2013/04/mifare-desfire-ev1-and-android.html
This tutorial provides a card authentification, which I disabled, and also uses the transceive method, which for my understanding is not a proper way for executing native commands? Which method, purhaps even code snippit, is used for executing native commands? Which Android-Class should I use?
I have rewritten the class provided in the tutorial and uploaded it to pastebin. After executing the class I've got following results.
Select APPLICATION: 9100
Read DATA: 91AE
At this point I am quite stuck and do not know what steps I should do next. Was is actually the error or rather what changes in the queries should I perform, to get the data I want?

Given the information you extracted from NFC TagInfo and the commands you are trying to use, I assume the card is MIFARE DESFire EV1. Correct?
Regarding your selection command: NFC TagInfo does not currently read the DF name value used in the ISO command set for DESFire EV1. Thus, I assume that the DF-name that's setup for this application is actually 0x313538343546, otherwise the SELECT command should fail. Note, however, that this value is by no means derivable from the DESFire AID shown in NFC TagInfo! In fact the DF-name is a seperate value defined during application creation. (This is different from the previous DESFire version.)
Regarding your READ BINARY command: The command you used would imply that you previously selected a file. However, you only selected the application. Thus, you would either need to issue a SELECT command for the data file or use a short file ID within the READ BINARY command:
byte[] READ_BINARY = {
(byte) 0x00, // CLA Class
(byte) 0xB0, // INS Instruction
(byte) 0x80, // P1 (indicate use of SFI)
(byte) 0x01, // P2 (SFI = 0x01)
(byte) 0x04 // LE maximal number of bytes expected in result
};
However, when it comes to DESFire (EV1) I suggest that you rather stick to the DESFire native command set (either direct or wrapped) instead of using ISO 7816-4 APDUs.
With the native command set, you get the full functionality of MIFARE DESFire. Command wrapping is done by embedding native DESFire commands into a ISO 7816-4 APDU structure. The wrapping command looks like this:
0x90 CMD 0x00 0x00 LEN CMD-PARAM 0x00
Where CMD is the native DESFire command and CMD-PARAM are the commands parameters. The response is:
[DATA] 0x91 STATUS
Where status is the native DESFire status code. If STATUS is 0xAF, you can get the remaining response data by issuing this command:
0x90 0xAF 0x00 0x00 0x00
So in your case, you would issue a select application command for your application 0x15845F (mind the different byte order!):
0x90 0x5A 0x00 0x00 3 0x5F 0x84 0x15 0x00
|SELECT| |APPLICATION ID|
Then, you want to read the data file 0x01 (whole file, starting at offset 0):
0x90 0xBD 0x00 0x00 7 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
|READ| |FILE| OFFSET | LENGTH |
Regarding your question how to get the ISO DF names and ISO FIDs for your application, you can try the following commands:
Select master application:
905A00000300000000
Get applications including their DF names:
906D000000
Select your application:
905A0000035F841500
Get DESFire FIDs:
906F000000
Get ISO FIDs:
9061000000
You can always use the transceive() method of the IsoDep object. IsoDep (i.e. ISO/IEC 14443-4) is used anyways (for native DESFire commands, for wrapped native commands and for ISO 7816-4 commands).
The error code you received from the card (0xAE) indicates an authentication error (see this datasheet for further information: DESFire). Thus, the file allows authenticated read only (see the access conditions shown in NFC TagInfo).
Thus, in order to read this file, you will need to implement the authentication procedure.

Modify the access bits of the sector trailer Mifare Classic

how to Modify the access bits of the sector trailer in Mifare Classic 1k. I want toauthenticate sector.

Modifying access bits is carried out by the same methods as writing normal blocks. You only aim at block 3 of the sector you want to alter access to. Taking into account the specs of the access bits present in block 3 of each sector (see chapter 8.7.1 from spec). A valid control bits combination along with the desired keys (A + B) must be specified (read/write operations on Mifare Classic Cards are performed at a block level basis).
For example if you want keyA-or-keyB-read operations available on any block of the sector and keyB-only-write permissions you can use a combination of [C1, C2, C3] = [0x78, 0x77, 0x88]. As you have to specify A and B keys (assuming all 0xAA for A key and all 0xBB por B key) the block data to write would be (take into consideration that byte 9 is unused):
byte authBlockData[] = {(byte) 0xAA, (byte) 0xAA, (byte) 0xAA, (byte)
0xAA,(byte) 0xAA, (byte) 0xAA, 0x78, 0x77,
(byte) 0x88, 0x00, (byte) 0xBB,(byte) 0xBB,(byte) 0xBB,(byte) 0xBB,(byte)
0xBB,(byte) 0xBB};