ISO14443 communication (iso14_apdu) not working?

J.Vega · 2012-07-24 15:49:09

Heyho!

I've recently started my master's thesis about the new German identification card (which uses an ISO14443 compliant RFID chip) and I'm trying to use the Proxmark III for analysis.
At the moment I'm trying to execute the initial steps of a protocol that is implemented on these cards (and the corresponding reader devices), which is called PACE. However, I have not been able to set up a basic communication between the Proxmark and the card.
Attached are my modifications to the code from the subversion repository (rev. 603) as a patch. The function I wrote is called PaceIso14443a (starts at line 26 of the patch).
I use iso14443a_select_card to perform the anticollision procedure and select the card. This works just fine. After that, I try to use iso14_apdu to send a packet to the card.
As far as I can tell, the iso14_apdu function does exactly what it should, according to ISO14443-4 (prepend PCB and CID, append CRC). However the function always returns 1 and in the response data array, I find a single byte with the value 0xFA. I don't think this is a "real" response from the card, since a response APDU would consist of at least 2 status bytes and these would not begin with 0xFA according to ISO7816-4.

Can anyone tell me what might be the problem here? I didn't see another use of the iso14_apdu function, so I couldn't test wether it works in other cases and it's just my implementation that's wrong. Also I have no experience in Verilog, so I can't check wether the FPGA is doing the right thing.

Here's the patch:
http://pastebin.com/8CNri3TY
(Edit: Changed URL Tue Jul 24 14:57:11 UTC 2012, excluded changes to Makefile.common in the diff)

Thanks in advance for any help!

Last edited by J.Vega (2012-07-24 15:58:45)

J.Vega · 2012-07-25 13:40:44

I found one error in my code so far. When calling iso14443a_select_card, I didn't pass it a pointer to a iso14a_card_select_t struct, so it couldn't save the UID and thus didn't send the RATS to the card. I fixed that and now the card answers the RATS with its ATS. However, it still does not seem to respond to my self-constructed APDU. The return code of iso14_apdu is still 1 and the only data I get is still 0xFA.
What's even more puzzling is the output of "hf 14a list" after calling "hf 14a reader" once and "hf 14a pace 1" 4 times after that:

recorded activity:          
 ETU     :rssi: who bytes          
---------+----+----+-----------          
 +      0:    :     52              
 +    236:   0: TAG 08  00              
 +      0:    :     93  20              
 +    452:   0: TAG 08  92  b0  ab  81              
 +      0:    :     93  70  08  92  b0  ab  81  91  00              
 +    308:   0: TAG 20  fc  70              
 +      0:    :     e0  80  31  73              
 +    916:   0: TAG 09  78  77  d4  02  00  00  90  00  90  85              
 +      0:    :     52              
 +    236:   0: TAG 08  00              
 +      0:    :     93  20              
 +    452:   0: TAG 08  73  a4  e2  3d              
 +      0:    :     93  70  08  73  a4  e2  3d  cd  a0              
 +    308:   0: TAG 20  fc  70              
 +      0:    :     e0  80  31  73              
 +    916:   0: TAG 09  78  77  d4  02  00  00  90  00  90  85              
 +      0:    :     0a  00  00  22  c1  a4  0f  80  0a  04  00  7f  00  07  02  02  04  02  01  83  01  02  4d  88              
 +      0:    :     52              
 +    236:   0: TAG 08  00              
 +      0:    :     93  20              
 +    452:   0: TAG 08  65  c2  80  2f              
 +      0:    :     93  70  08  65  c2  80  2f  14  9e              
 +    308:   0: TAG 20  fc  70              
 +      0:    :     e0  80  31  73              
 +    916:   0: TAG 09  78  77  d4  02  00  00  90  00  90  85              
 +      0:    :     0a  00  00  22  c1  a4  0f  80  0a  04  00  7f  00  07  02  02  04  02  01  83  01  02  4d  88              
 +      0:    :     52              
 +    236:   0: TAG 08  00              
 +      0:    :     93  20              
 +    452:   0: TAG 08  46  e0  93  3d              
 +      0:    :     93  70  08  46  e0  93  3d  63  0e              
 +    308:   0: TAG 20  fc  70              
 +      0:    :     e0  80  31  73              
 +    916:   0: TAG 09  78  77  d4  02  00  00  90  00  90  85              
 +      0:    :     0a  00  00  22  c1  a4  0f  80  0a  04  00  7f  00  07  02  02  04  02  01  83  01  02  4d  88              
 +      0:    :     52              
 +    236:   0: TAG 08  00              
 +      0:    :     93  20              
 +    452:   0: TAG 08  6d  f2  8f  18              
 +      0:    :     93  70  08  6d  f2  8f  18  96  3b              
 +    308:   0: TAG 20  fc  70              
 +      0:    :     e0  80  31  73              
 +    916:   0: TAG 09  78  77  d4  02  00  00  90  00  90  85              
 +      0:    :     0a  00  00  22  c1  a4  0f  80  0a  04  00  7f  00  07  02  02  04  02  01  83  01  02  4d  88              
 +933822050:   0: TAG 19  ee! 5f  d5! ee! 84  8b  fa! 1b  29! 5f  d5! 30  42  6c! f2  ee  b1  97  d5  b7  d6! 69  b9  82! aa! c0! a6! e4  a7! 21  d6  01  4d! ed  84  0c! 14  d6! da  d9! 5a  13! c0  2f! ab! 6d  3b  50  45!    !crc

This looks like the tag answered, but with some syntactically incorrect data (parity bits and crc checksum mismatch from what I can tell by reading the source). However, once I call "hf 14a pace 1" again, the line with the tag's response disappears from the log and sometimes reappears below the newly recorded traffic (but sometimes does not). This (and the strange timestamp) leads me to believe that the tag's response actually never happened, but instead the logging errorneously prints this line.
Still, the essence is that I do not get valid return values from iso14_apdu. If the tag doesn't answer, I expect it to return -1. If the tag answers, I expect it to return at least 2 (SW1/SW2) and find a valid status code in the received data.

Does anyone have an idea where the (next) problem might be? Judging from the logged traffic I'd say that the communication is correct up to the point where the tag stops responding.

New patch is here:
http://pastebin.com/mMhhJ49j

Last edited by J.Vega (2012-07-25 13:45:23)

rule · 2012-07-25 19:59:57

Hey hey,

Great work! The last error is because you received a frame that was longer than 64 bytes. The current proxmark code does not allow that (buffers are to small, and parity bits are stored in 64 or even 32 bit integer). You can look into this particular problem yourself, or I can do it, sadly I have a lot stuff planned these 2 months.

If you are interested to become an SVN committer, you can email me your google account. I'll add you to the google code respository.

Cheers,

Roel

J.Vega · 2012-07-25 21:57:12

Thanks for the help!
I'll look into the problem right away. It probably helps me understanding the whole firmware better
Also I'll be happy to share my code, I'll drop You a mail.

Last edited by J.Vega (2012-07-25 22:03:42)

vivat · 2012-07-26 11:16:43

Your trace looks quite similar to rfid-enabled e-passport. RFIDIOT can work with them.

J.Vega · 2012-07-26 20:23:59

Indeed, the protocols are quite similar. The problems are:
1. RFIDIOT doesn't work with the Proxmark as far as I can see, I would like to make use of the customizable firmware (better to measure timings right on the device than to measure them on the PC where additional fluctuation by the USB communication is introduced) and the Proxmark is the only reader I have at my disposal
2. The protocols are not really the same, so using RFIDIOT wouldn't be that much of a gain as I would still have to implement them

J.Vega · 2012-08-01 12:23:10

I found out some new things:

The buffers I use are big enough to hold received answers. The 64-byte limitation only holds if you use BigBuf to store the answers. I'm not sure if there is still a problem with the parity bits, I will look into this next.
My mistake was that I didn't save the return code of iso14_apdu but instead checked the return code of the previous call to the card select function. That one returned 1, so I thought I had received one byte. Truth is, iso14_apdu returned -1, which indicates that no answer at all was received. I don't know why the tag doesn't answer, does anyone have an idea?
The supposed answer in the log must be some kind of error, this data was never received by the proxmark (otherwise I would have gotten it from iso14_apdu).

J.Vega · 2012-08-12 00:39:02

Found the problem!

I had to send a Protocol and Parameter Selection Request (see ISO14443-4) to the card with both the DRI and the DSI in PPS1 set to 0 (so D is 1). The request then looks like this:

Packet:            D0             11                   00                    52     A6
Description:       PPSS(CID 0)    PPS1 transmitted     DRI/DSI 0 => D=1      CRC    CRC

Apparently the proxmark is yet unable to communicate with the card if D is set to a value other than 1. I'm not sure how the values actually influence the transfer, but if I understand it correctly, it has something to do with bitrates. I guess the proxmark doesn't have the ability yet to transfer/receive at bitrates other than the default (or it does and you have to set it up somewhere, but I'm still not enough into the whole firmware to have found anything related to that).

However, using this PPS Request, I was able to get the card to respond to higher level commands, such as ISO7816 APDUs (wrapped in an ISO14443-4 I-Block of course). That finally enables me to continue working on the more interesting parts

rrookie · 2012-12-19 21:36:04

J.Vega or Anybody,

is there more information available on this. I have a similar problem using "hf 14a snoop". As soon as the reader sends the command

d0 11 0a 08 09

my card (German transportation card, called eTicket) responds with

d0 73 87

and then Capturing/Listing is corrupted.

How can I make PM3 use the new bitrate ?

Tahnks,
rrookie

J.Vega · 2012-12-20 01:27:06

Sorry but as far as I know, You're out of luck. The card and the original reader switch to another data rate after that and the Proxmark as of now is unable to capture the traffic from there on.
I *believe* You might be able to change the frequency of the FPGA's clock accordingly, but I haven't tried that myself yet so I can't guarantee that this is even possible.

Proxmark3 community

Announcement

#1 2012-07-24 15:49:09

ISO14443 communication (iso14_apdu) not working?

#2 2012-07-25 13:40:44

Re: ISO14443 communication (iso14_apdu) not working?

#3 2012-07-25 19:59:57

Re: ISO14443 communication (iso14_apdu) not working?

#4 2012-07-25 21:57:12

Re: ISO14443 communication (iso14_apdu) not working?

#5 2012-07-26 11:16:43

Re: ISO14443 communication (iso14_apdu) not working?

#6 2012-07-26 20:23:59

Re: ISO14443 communication (iso14_apdu) not working?

#7 2012-08-01 12:23:10

Re: ISO14443 communication (iso14_apdu) not working?

#8 2012-08-12 00:39:02

Re: ISO14443 communication (iso14_apdu) not working?

#9 2012-12-19 21:36:04

Re: ISO14443 communication (iso14_apdu) not working?

#10 2012-12-20 01:27:06

Re: ISO14443 communication (iso14_apdu) not working?

Board footer