Proxmark3 community

xr4ti

Member

Registered: 2012-09-18

Posts: 5

14B authentication doubts

Hi

I'm studying a 14B transport card. I've many traces of good communications with a valid reader. Data is transmitted clearly without any cipher, and after many traces I know which is about 90% of the transmited data.
In fact, with the proxmark If I send the first commands to the tag, I can know which is the money it has left, data about the last trip (data, hour, bus number, bus line, cost, previous money before that trip,..), last two money recharge info (amount, office).

Money recharges are done by smart card interface (not RFID).

The problem I'm having now, is that write commands (like the one for save a trip) are validated, I think is a mutual authentication with random challenges.

IT uses propietary commands, but there are structures like ISO 7816 (as the "90 00" ok response)

after REQB, ATQB, ATTRIB... There are 6 commands interchanged. First 4 reader commands are the same even with different tags, only to retrieve info.

In the five reader command, it sends the first 4 random bytes.

02 80 28 00 00 04 97 b2 0b 42 3a d5 0a
 1  2  3  4  5  6  7  8  9  10 11 12 13

byte 6 indicate that 4 bytes are transmited, 97 b2 0b 42.

Then the card answers with info about money, last trip.. (this same answers were send by the tag also on 3-4 commands :S), and in the end of the answer:


..... 80 4c ff 23 46 90 00 6b 7b
 
tag auth bytes: 4c ff 23 46


Then the reader sends the sixth command, which has info about the current trip to write it, and then another authentication 4 bytes are sent..
 
03 80 2a... trip info....00 52 7d f4 40 6b 04 22 cd
 
7d f4 40 6b are the bytes of the authentication this time.
 
And in the end the tag send it answer:
03 16 81 b1 01 90 00 e3 c1
 
16 81 b1 01 are tag autenth bytes and no more bytes are transmited.
 

I know them are random challenges because If I sent the same 5 first commands to the tag many times, the 5 answer authentication tag bytes varies a lot. I did that a lot of times, and got more than 1200 different numbers without any repeat (I tried this after read one of the Mifare study papers about it pseudoramdon "weakness")

If I sent bad 4 bytes, the tag don't accept the trip as its normal.

If any of you has any tip about can I try is wellcome because I only tried basic things like using card PUPI (Pseudo-Unique PICC Identifier) 0f 0d 17 12 as a key, calculating many hashes, CRC's, XOR'ings but its not easy for me to find a good combination.

 PUPI:    0f 0d 17 12
 reader:  97 b2 0b 42
 tag:     4c ff 23 46
 reader:  7d f4 40 6b
 tag:     16 81 b1 01
 
  

I can post a full trace if you want. I didn't post it now because I don't know if there are legal problems on that.

rule

Member

Registered: 2008-05-21

Posts: 417

Re: 14B authentication doubts

Could you say more about the system you are looking at? Does it involves a public transport scheme, or a (micro)payment scheme?

You are basically allowed to listen into all open (non-military/confidential) frequencies and record the transmitted information. As long as you are not violating other laws (like privacy), there is no problem in pasting a complete trace into this forum. Breaking the encryption with the purpose of abusing could be another violation, but if it is pure educational, you should have nothing to fear.

xr4ti

Member

Registered: 2012-09-18

Posts: 5

Re: 14B authentication doubts

Could you say more about the system you are looking at? Does it involves a public transport scheme, or a (micro)payment scheme?

You are basically allowed to listen into all open (non-military/confidential) frequencies and record the transmitted information. As long as you are not violating other laws (like privacy), there is no problem in pasting a complete trace into this forum. Breaking the encryption with the purpose of abusing could be another violation, but if it is pure educational, you should have nothing to fear.

ok thanks for the info. You are right, it's being done for educational purposes.

I don't know exactly what are you refering with the two schemes. Probably a hybrid?

The are two versions of the card, one is supposed to have two different wallets, one for public transport and another for pay city taxes (which I didn't use as now is not RFID). And the another card only has the transport wallet. I've one from each type and the commands transmited from the reader are the same.

There are also special rates for different cards - students, old people..But all of this is saved in a std card, one of the commands sent by reader recover the "special rates" with a limit number of trips and counter. Mines are standard, but did a few tests with one from a friend with the student rate.

You can charge it with money from propietary machines or even from a "bank ATM" (I'm not sure if it's this the word) using a proper credit/debt card. But it works "offline", money amount is supposed to be on the card.

what more do you want me to tell about it?

rule

Member

Registered: 2008-05-21

Posts: 417

Re: 14B authentication doubts

Not much more, I was just curious

It would be good to first figure out what it is you are dealing with. It does not seem to be a simple mutual authentication scheme, but more some integrity checks with use of an Message Authentication Code (MAC).

You mention you have send (replayed) several times the same reader messages to the card, but it responds always with different random bytes? Did the rest of the tag answer change as well, that would make sense, because it "signs" the message with the MAC that belongs to its current response. It accepts your recorded message + MAC, since you did not simply did not change the message, just replayed it.

Now what you could do is trying to figure out if you can shrink/extend the message with 1 bit/byte, or see if you can get a almost the same looking message/MAC and see how related the content of the message and the MAC is.

Also try to flip a one bit at the time in each reader byte to see which are actually part of the bytes where the MAC is calculated on. Maybe this first byte for example (sequence number?) is not part of it. If this is the case, you could try to send message 2 also as message 3, since you have a valid MAC, this could be accepted.

Can you also figure out if multiple tags accept the same recorded reader messages + MAC's (even if they have a different PUPI). That would suggest there is only one key/secret being used when constructing the MAC.

To be able to say more about a MAC, I think it could be useful to have a clear few of a few traces though, maybe there is a simple relation between them. However, they could as well used a very strong algorithm (but I suspect that if you generate a MAC of only 32-bit, it is probably pretty weak).

Cheers,

  Roel

xr4ti

Member

Registered: 2012-09-18

Posts: 5

Re: 14B authentication doubts

Thanks for your answer, probably I explained bad. If I replay the same messages it doesn't work, the tag answers with a 93 02 error code.
First 4 commands are about retrieve info about money, last trip... no auth here, near text-plained transmmited, you only have to make a few hex -> dec conversions to get data. If I replay this 4 first commands with the proxmark it works ok and the tag every time answers exactly the same  (bit by bit, so no MAC change here in case of using the MAC system)

5th command is the following:

02 80 28 00 00 04 97 b2 0b 42 3a d5 0a
 1  2  3  4  5  6  7  8  9  10 11 12 13

byte 6 indicates that 4 bytes are transmited. "97 b2 0b 42", and the 11 bit "3a" are the number of data bytes expected in the tag answer.

in the real world, the reader changes from 7th bit to 10 every trace. these are the first 4 bytes used on auth.

With the proxmark I maintain this 4 bytes in the same value for testing purpose. So..No MAC calculation change here in my proxmark tests.

and in the 5th answer from the tag, I've made just now two tests.

02 00 0e 00 52 00 01 06 41 11 09 01 00 28 01 30 39 8d 20 00 10 00 c2 01 01 09 23 00 10 01 0b 09 87 00 00 20 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 f1 4d 1b ec 90 00 81 11
02 00 0e 00 52 00 01 06 41 11 09 01 00 28 01 30 39 8d 20 00 10 00 c2 01 01 09 23 00 10 01 0b 09 87 00 00 20 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 98 d5 3c c3 90 00 f8 46 

there are the same bytes except the 4 end bytes before the CRC-B "f1 4d 1b ec" and "98 d5 3c c3" in the second.

All the first bytes don't change because there is info about last trip (which don't change, obviously) and about the card.  This seems to be random bytes.

Then, in the 6th command, is when the reader tries to write a new "trip"

for example this is a valid 6 command.
03 80 2a 01 00 24 00 0d 00 52 00 01 58 41 19 09 01 00 28 01 35 39 8d 19 29 10 00 c2 01 01 09 23 00 10 01 00 00 52 91 df b5 10 04 2f d2

the bytes "91 df b5 10" should be the MAC or the auth bytes the tag has to validate to accept the key and send an answer like this:

03 a4 99 ad 15 90 00 c6 57  with the 90 00 OK code. and 4 bytes of MAC or auth,

but with my replayed messages, it answers with:
03 93 02 8f 39

and the trip is not accepted. This is what I think it can't be a MAC system and seems like a mutual authenticacion or a similar one with random challenges.

but anyway, I'm thinking that If it was a MAC checking like you say (and could be) a replay should not work..Because in the saved trace is saved info that you wont get in the replay.

example:
trips in time : A - B

A is the previous trip, when you go to do the B trip info about A trip is recovered from the tag..  And you snoop that trace.

Then, you in your house make a test to replay the commands, but the tag then sends info about B trip instead A one and the trip counter will be increased in one...So if it was a MAC checking and uses the bytes that change it should be wrong as it is.

I will try to think more tomorrow or post a image with changes between traces.