I'm working on a C platform and I want to read the AFL of a card.
If the previous command, select of the AID, don't give me a PDOL tag, it's ok: I can read the AFL without issues.
But I need to write a method that can generate a GET PROCESSING OPTION regardless the PDOL.
So the questions are:
How can I write an universal method that work despite the PDOL?
Have I to map every single possible TAG?
How can I format the GPO
command with the correct data? Look the following example:
SELECT AID Response
PDOL: 9F 1A 02
So I have to put the Terminal Country Code, in my case Italy: 380
So the GPO call is:
80 A0 00 00 04 83 02 03 80 00
But the response that I have is 6D 00: Instruction code not supported or invalid
Where am I wrong?
I'm programming on Ingenico Pos (Point of sale).
Good to know that you are aware with the concept of PDOL very well. As far I can understand with your question, you are comfortable to construct GPO command if PDOL is not present. I think You are in doubt to write a generic function to construct GPO APDU command.
First of all I want to tell you that if PDOL information is present in SELECT response then you should send PDOL data in GPO command APDU, otherwise card application may throw some error.
So you can set an indicator when you receive PDOL in SELECT command. If PDOL is not there you can simply send 80 A8 00 00 02 83 00 00 and if your indicator stated that PDOL is required then simply parse the PDOL and from SELECT response and prepare a value for PDOL data if you know (as you described in your question) to be send in GPO command APDU.
If you don't know what value then you can simply fill hexadecimal zeros in value field.
Taking your example : 80 A8 00 00 04 83 02 03 80 00. This is the correct command (I have corrected INS byte). Or you can also send 80 A8 00 00 04 83 02 00 00 00 (PDOL value is replace by zeros)
I think this explanation can help you to get the answers of both the questions. Try it and let us know if there is any further clarification needed.
You have two options:
Issue a command with data field of "8300" - 80 A8 00 00 02 83 00 00
Issue a command with data field of all hexadecimal zeroes - 80 A8 00 00 04 83 02 00 00 00
You receive the error, because in option 1 you omit the Le byte of the C-APDU - this byte is mandatory for all CASE 4 commands and in option 2 you give wrong INS byte, A0 instead of A8.
Card Issuers don't put just any tag and expect the terminal to provide the data. You can get the best practices(recommended tags) from each payment scheme you are certifying with. Besides, if it is some tag which you don't support, you can always zero fill and proceed.
Related
I have a USIM card and the Card Life Cycle is OP_READY:
Connected to the Card...
<--> [Mutual Auth]
---> 80 F2 80 00 02 4F 00
<--- 08 A0 00 00 00 03 00 00 00
01 <== LifeCycle = OP_READY
98
90 00
I want to change the card Life Cycle to SECURED. Based on the GlobalPlatform Card Specification I have to first change the card life cycle to INITIALIZED and then to SECURED state:
And this is the coding of differnet Life Cycles in SET STATUS APDU command:
So I tried to change the life cycle as below:
Connected to Card.
<--> [Mutual Auth with SecLevel = 0x00]
---> 80 F0 80 07 00
<--- **Fail** 6A 86
---> 80 F0 80 0F 00
<--- **Fail** 69 85
As you see above, I received 6A86 (INCORRECT P1-P2 Parameters) for INITIALIZED and 6985 (CONDITIONS OF USE NOT SATISFIED) for SECURED life cycle.
I also tried the same process with SecLevel=0x03, but nothing changes:
Connected to Card.
<--> [Mutual Auth with SecLevel = 0x03]
---> 84 F0 80 07 08 <MAC>
<--- **Fail** 6A 86
---> 84 F0 80 0F 08 <MAC>
<--- **Fail** 69 85
What is wrong?
It might be that your card is imposing additional requirements for the state change. If you have a manual consult it if some special behavior is described.
If this is not available my strongest guess would be that the card would like to see some keys to be personalized on the card before the state change is allowed. Use a PUT KEY command to update the keys. If updating the key using the same key version and index does not work try to create an additional key version.
Although unlikely to succeed, you can also try a STORE DATA command to set the life cycle status. The mapping guidelines, 6.13 allows to set the tag 9F70.
So I've been working on a Nodejs tag writer for the NTAG424 DNA and I am still getting the hang of APDU commands. I am tracing the steps of the example from https://www.nxp.com/docs/en/application-note/AN12196.pdf but the documentation is confusing at times. I am attempting to write to file02 to take advantage of the SUN/CMAC mirroring of the tag by using Cmd.WriteData in CommMode.Full. When I write the data I get an <9100> OK response code but in CommMode.Full I believe I should be receiving an encrypted response with more data. Then when I attempt to do Cmd.ChangeFileSetting after WriteData in CommMode.Full, I receive a <911e> error. I have looked up and down for 2 days at my code to see if maybe I fumbled the Initialization Vector or encrypted data step, but I think those parts are all good. I am truly lost as to why this is happening. I am using the example provided on the documentation mentioned above, except I modified the header for CMD.write data to make the command length valid (I was getting <917e> before I changed it from <80> to <98>) since I believe the documentation has a typo for this step.
CMD for WriteData to NDEF: 90 8d 00 00 9f 02 00 00 00 98 00 00 {encData} + {macT} + {LE}
CMD for ChangeFileSettings: 90 5f 00 00 19 02 {encData} + {macT} + {LE}
This is all in reference to 6.8.2 and 6.9 of the personalization example in the https://www.nxp.com/docs/en/application-note/AN12196.pdf document.
External Authentication:
FF 82 20 00 06 FF FF FF FF FF FF
What is the correct procedure to run External Authentication? Do we need to run Get Challenge before External Authentication?
If I send the apdu of external authentication to OMNIKEY smart card reader, it will return me 9000 which mean success.
But If I do the same step with Workabout Pro4 and it return 6D00?
6D00 is instruction code is not supported or invalid, but it was working with Omnikey smart card reader. How to solve this problem?
FYI: Read UID APDU Command is working on both devices: FF CA 00 00 00
I have tried many different ways but none is working.
Changing the shared_mode while connect card[Exclusive, Shared]
Lock the thread for specific process
Put the thread to wait for few seconds before sending APDU
Send Get Challenge apdu before external authentication but failed
I found the answer myself.
There are two Load Authentication Keys APDU commands:
FF 82 20 00 06 FF FF FF FF FF FF (Obsolete)
FF 86 00 00 05 01 00 [Block Number] [Key Type] [Key Number]
Use the second APDU command to do Load Authentication Keys then read/write the Mifare card content.
I now have a Hello World project according this link and I made its .cap
file successfully. I have "DE-ABCM_TB" reader and a SAM card also.
My applet AID is 01 02 03 04 05 06 07 08 09 00 00
I could select my applet on the card.( I sent SELECT APDU command via "DualCard
Ver 2.8"/ pcsc tab) . I now must be receive hello in hex format when I send
8000000000. But i receive 6C0B ! Why did I get this response and
how can I resolve this ? I searched but no solving found.
You didn't searched good enough!
If you do a quick look at status words table you will see SW1=6CXX means Wrong Le field; SW2 encodes the exact number of available data bytes
So you must send the below command:
80|00|00|00|0B!
Table of Status Words :
After selection of the card and RATS, i want to start the authentication.
In the mifare documentation is described that an 0A 00 should be sent. This data is supposed to be ISO14443-4. I have to frame it to fit ISO14443-3.
The Block format goes like that
PCB|CID|INF|EDC
In the PCB I am supposed to say if it is an I-block, R-block or S-block.
I saw an example in this thread where he sent something like that:
90 0A 00 00 01 00 00
Where is it documented this frame, it looks like none of the blocks described in ISO14443-4
The Block format PCB|CID|INF|EDC with I-block, R-block or S-block you described is actually ISO 7816-3 T=1 frame (not ISO 14443 frame, not ISO 7816-4 APDU). This is low-level ISO 7816 that implemented in driver level.
The thread you mentioned uses 7816 APDU.
1st "to card" is actually 7816 APDU: CLA=90 INS=0A P1=00 P2=00 LC=01 Data=00 Le=00
2nd "to card" is another APDU: CLA=90 INS=AF P1=00 P2=00 Lc=10 Data=43 9D 17 8E 9A 5F BA 70 8D 23 57 10 C9 32 D5 17 Le=00.
Depending on the version of Mifare DESFire, you can use native, native-wrapped or ISO 7816-4 command set styles.
7816 wraps Mifare native command as follow:
90 [mifare native ins] 00 00 Lc [data] 00
From the 2 commands above, native commands are 0x0A (Authenticate) & 0xAF (More data).
You can't get the mifare native command set documentation freely. You need to sign an NDA. However, take a look at this doc to see learn more: http://www.nxp.com/documents/application_note/AN11004.pdf
Another resource: http://ridrix.wordpress.com/2009/09/19/mifare-desfire-communication-example/
This is not a ISO 14443 frame; it is an ISO 7816-4 APDU.