Proxmark3 community

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Ultralight - C, 3des authentication

I found a rather strange behavior for UL-C today, 

if PM3 act as a reader and you use any decrypt key,  its up to the reader to act responsivly and close the communication channel if the auth failed. This goes for the  "read" command.  The tag happily allows you to read afterwards anyway.

I wonder if that is the same for the write aswell.   Have someone here noticed this?

It is a magic UL-C tag I noticed this with.

Updated UL-C doc http://www.nxp.com/documents/data_sheet/MF0ICU2.pdf

--------------

pm3 --> hf mfu cauth k 4
enc(RndB) :89 b0 7b 35 a1 b3 f4 7e     --<TAG NONCE
      RndA   :01 01 01 01 01 01 01 01       --<OUR NONCE (really random)
      RndB   :11 11 11 11 11 11 11 11         --<DECRYPTED TAG NONCE
     RA+B   :01 01 01 01 01 01 01 01 11 11 11 11 11 11 11 11   --< OUR NONCE + ROL(TAG NONCE)
enc(RA+B) :6f 1e bb fc 25 f7 26 e5 23 46 0c b2 b3 45 26 a3  --< enc above.
enc(RndA') :a9 2f 0f 8e c5 87 66 2d        --< TAG ENC RESPONSE OF OUR NONCE

pm3 --> hf list 14a
Recorded Activity (TraceLen = 218 bytes)

Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iso14443a - All times are in carrier periods (1/13.56Mhz)
iClass    - Timings are not as accurate

     Start |       End | Src | Data (! denotes parity error)                                   | CRC | Annotation         |

-----------|-----------|-----|-----------------------------------------------------------------|-----|--------------------|

          0 |        992 | Rdr |52                                                               |     | WUPA
       2228 |       4596 | Tag |44  00                                                           |     |
       7040 |       9504 | Rdr |93  20                                                           |     | ANTICOLL
      10676 |      16564 | Tag |88  04  22  33  9d                                               |     |
      18560 |      29024 | Rdr |93  70  88  04  22  33  9d  20  1e                               |  ok | SELECT_UID
      30260 |      33780 | Tag |04  da  17                                                       |     |
      35072 |      37536 | Rdr |95  20                                                           |     | ANTICOLL-2
      38708 |      44532 | Tag |44  55  66  77  00                                               |     |
      46592 |      57056 | Rdr |95  70  44  55  66  77  00  7a  b8                               |  ok | ANTICOLL-2
      58292 |      61876 | Tag |00  fe  51                                                       |     |
      65280 |      70048 | Rdr |1a  00  41  76                                                   |  ok | ?
      98356 |     111156 | Tag |af  89  b0  7b  35  a1  b3  f4  7e  6c  4c                       |  ok |
    1699712 |    1721760 | Rdr |af  6f  1e  bb  fc  25  f7  26  e5  23  46  0c  b2  b3  45  26   |     |
           |           |     | a3  0c  1a                                                      |  ok | ?
    1791156 |    1803956 | Tag |00  a9  2f  0f  8e  c5  87  66  2d  8b  fd                       |  ok |

------ from trace.
TAG NONCE               : 89  b0  7b  35  a1  b3  f4  7e
READER                     : 6f  1e  bb  fc  25  f7  26  e5  23  46  0c  b2  b3  45  26  a3
TAG ENC_OUR NONCE : a9  2f  0f  8e  c5  87  66  2d

QUESTIONS?
--- FINDING OUT TAG'S KEY?

Since we are in control of the reader,  we should be able to do a offline attack.
1) take the TAG NONCE into a fast pwd breaker which deals with 3des.
with collisions in mind, there should be eventually a hit.
2) verify found pwd with a AUTH command.
     
--- FINDING OUT READER'S KEY?

Since we are in control of the tag, (PM3 sim?) we should be able to do a offline attack.

1) We can present a known nonce like:  10 10 10 10 10 10 10 10 (important it looks the same after a ROL)
2) the reader will decrypt our nonce and rol it,  and encrypt it,  then send it back to us.
3) so we should send (READER RESP)  23  46  0c  b2  b3  45  26  a3   (second half) into a fast pwd breaker which deals with 3des.
4) verify found pwd with a AUTH command

Question is if someone has used john the ripper or hashcat ?  Can someone explain how to use it to me?

ref:
john the ripper http://www.openwall.com/john/
hashcat http://hashcat.net/

Andy Davies of Pentura did a brute-force version like this:  http://pastebin.com/iz07583h/

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: Ultralight - C, 3des authentication

I've implemented a setpwd  for UL-C,  and tested some more against my magic UL-C tag.
Funny thing still is that the tag answers even if the password is wrong.   It leaves everything up to the reader to decide.
It should have answered a NACK  when it detected it was a wrong password.

* This could be the magic tag's special behavior. *

But since I don't have a real UL-C tag to test it with, I wonder if someone has tested against a real UL-C tag?

pm3 --> hf mfu cauth k 0
     RndA  :01 01 01 01 01 01 01 01
     enc(RndB):f4 03 79 ab 9e 0e c5 33
     RndB:1c 04 6e fa 23 4c 7e 4a
     A+B:01 01 01 01 01 01 01 01 04 6e fa 23 4c 7e 4a 1c
enc(A+B):aa bc 71 12 c1 38 8a 33 6f 77 90 b8 3d 8b fb 46
enc(RndA'):bc 2e cf f7 51 a5 77 01
--> : 02 2a 33 8b dc 6f 97 1c   : <-- Should be equal to our RndA

pm3 --> hf mfu setpwd 01010101010101010101010101010101
Ultralight-C new password: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

pm3 --> hf mfu cauth k 0
     RndA  :01 01 01 01 01 01 01 01
     enc(RndB):89 b0 7b 35 a1 b3 f4 7e
     RndB:49 7c ce 32 a6 96 02 19
     A+B:01 01 01 01 01 01 01 01 7c ce 32 a6 96 02 19 49
enc(A+B):94 ca 64 7e 5d c0 1f 84 36 50 13 2b 3c 77 15 95
enc(RndA'):82 63 e0 f4 d5 3c 90 90
--> : de 73 fb d8 de c3 02 ef   : <-- Should be equal to our RndA

pm3 --> hf mfu cauth k 4
     RndA  :01 01 01 01 01 01 01 01
     enc(RndB):89 b0 7b 35 a1 b3 f4 7e
     RndB:11 11 11 11 11 11 11 11
     A+B:01 01 01 01 01 01 01 01 11 11 11 11 11 11 11 11
enc(A+B):6f 1e bb fc 25 f7 26 e5 23 46 0c b2 b3 45 26 a3
enc(RndA'):a9 2f 0f 8e c5 87 66 2d
--> : 01 01 01 01 01 01 01 01   : <-- Should be equal to our RndA

thefkboss

Contributor

Registered: 2008-10-26

Posts: 198

Re: Ultralight - C, 3des authentication

https://itooktheredpill.irgendwo.org/2010/side-channel-analysis-on-rfid-tags/
may be this could help

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: Ultralight - C, 3des authentication

Hm, DPA side-channel analyse is interesting but I don't have the setup for it.

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: Ultralight - C, 3des authentication

strange, when I run the auth command agains my magic UL-C tags,  I always get the same nonce back.
Doesn't matter which tag I take.    Someone else who has UL-C which can test this?

-- auth block 0
hf 14a raw -s -c 1a00

received 7 octets
00 00 00 00 00 00 00
received 11 octets
AF 89 B0 7B 35 A1 B3 F4 7E 6C 4C    --<< always this one

marshmellow

Contributor

From: US

Registered: 2013-06-10

Posts: 2,302

Re: Ultralight - C, 3des authentication

i will test this first thing tomorrow morning

marshmellow

Contributor

From: US

Registered: 2013-06-10

Posts: 2,302

Re: Ultralight - C, 3des authentication

i receive different each time:

proxmark3> hf 14a raw -s -c 1a00
received 7 octets
04 B8 73 7A E0 2B 80
received 11 octets
AF CC 1A 44 48 F2 E4 FF CD 6E BD
proxmark3> hf 14a raw -s -c 1a00
received 7 octets
04 B8 73 7A E0 2B 80
received 11 octets
AF 91 77 F3 40 8F 72 46 A4 A8 AA
proxmark3> hf 14a raw -s -c 1a00
received 7 octets
04 B8 73 7A E0 2B 80
received 11 octets
AF BC 7A 5F 28 83 78 A7 0D AB EE
proxmark3> hf 14a raw -s -c 1a00
received 7 octets
04 B8 73 7A E0 2B 80
received 11 octets
AF 81 12 D4 24 3D 82 E4 5A 84 E6

Genuine NXP Ultralight C

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: Ultralight - C, 3des authentication

Good,
then we got a way of identifying a Magic UL-C tag..  Or at least take a stab at analysing the entropy of the prng inside.

I know I've read this somewhere, but how do we do that..   collecting say 1 000 000 nonces then map it to a 2:d plan and see if we can detect some irregular patterns..   Last time I looked into this was when the debate about DNS randomess..