logo资料库

Attack.MIFARE(M1卡破解).pdf

第1页 / 共15页
第2页 / 共15页
第3页 / 共15页
第4页 / 共15页
第5页 / 共15页
第6页 / 共15页
第7页 / 共15页
第8页 / 共15页
资料共15页,剩余部分请下载后查看
A Practical Attack on the MIFARE Classic
Gerhard de Koning Gans, Jaap-Henk Hoepman, and Flavio D. Garcia
A Practical Attack on the MIFARE Classic Gerhard de Koning Gans, Jaap-Henk Hoepman, and Flavio D. Garcia Institute for Computing and Information Sciences Radboud University Nijmegen P.O. Box 9010, 6500 GL Nijmegen, The Netherlands gkoningg@sci.ru.nl, jhh@cs.ru.nl, flaviog@cs.ru.nl Abstract. The mifare Classic is the most widely used contactless smart card in the market. Its design and implementation details are kept secret by its manufacturer. This paper studies the architecture of the card and the communication protocol between card and reader. Then it gives a practical, low-cost, attack that recovers secret information from the memory of the card. Due to a weakness in the pseudo-random generator, we are able to recover the keystream generated by the CRYPTO1 stream cipher. We exploit the malleability of the stream cipher to read all memory blocks of the first sector of the card. Moreover, we are able to read any sector of the memory of the card, provided that we know one memory block within this sector. Finally, and perhaps more damaging, the same holds for modifying memory blocks. 1 Introduction RFID and contactless smart cards have become pervasive technologies nowadays. Over the last few years, more and more systems adopted this technology as replace- ment for barcodes, magnetic stripe cards and paper tickets for a variety of appli- cations. Contact-less cards consist of a small piece of memory that can be accessed wirelessly, but unlike RFID tags, they also have some computing capabilities. Most of these cards implement some sort of simple symmetric-key cryptography, which makes them suitable for applications that require access control. A number of high profile applications make use of contactless smart cards for access control. For example, they are used for payment in several public transport systems like the Octopus card1 in Hong Kong, the Oyster card2 in London, and the OV-Chipkaart3 in The Netherlands, among others. Many countries have already incorporated a contactless card in their electronic passports [3] and several car man- ufacturers have it embedded in their car keys as an anti-theft method. Many office buildings and even secured facilities like airports and military bases, use contactless smart cards for access control. 1 http://www.octopuscards.com/ 2 http://oyster.tfl.gov.uk 3 http://www.ov-chipkaart.nl/
On the one hand, the wireless interface has practical advantages: without me- chanical components between readers and cards, the system has lower maintenance costs, is more reliable, and has shorter reading times, providing higher throughput. On the other hand, it represents a potential threat to privacy [3] and it is susceptible to relay, replay and skimming attacks that were not possible before. There is a huge variety of cards on the market. They differ in size, casing, memory and computing power. They also differ in the security features they provide. A well known and widely used system is mifare. mifare is a product family from NXP semi- conductors (formerly Philips). According to NXP there are about 200 million mifare cards in use around the world, covering 85 % of the contactless smartcard market. The mifare family contains four different types of cards: Ultralight, Standard, DES- Fire and SmartMX. The mifare Classic cards come in three different memory sizes: 320B, 1KB and 4KB. The mifare Classic is the most widely used contactless card in the market. Throughout this paper we focus on this card. mifare Classic provides mutual authentication and data secrecy by means of the so called CRYPTO1 stream cipher. This cipher is a proprietary algorithm of NXP and its design is kept secret. Nohl and Pl¨otz [7] have recently reverse engineered the hardware of the chip and exposed several weaknesses. Among them, due to a weakness on the pseudo- random generator, is the observation that the 32-bit nonces used for authentication have only 16 bits of entropy. They also noticed that the pseudo-random generator is stateless. They claim to have knowledge of the exact encryption algorithm which would facilitate an off-line brute force attack on the 48-bit keys. Such an attack would be feasible, in a reasonable amount of time, especially if dedicated hardware is available. Our Contribution We used a Proxmark III4 to analyze mifare cards and mount an attack. To do so, we have implemented the ISO 14443-A functionality on the Proxmark, since only ISO 14443-B was implemented at that time. We programmed both processing and generation of reader-to-tag and tag-to-reader communication at physical and higher levels of the protocol. The source code of the firmware is available in the public domain5. Concurrently, and independently from Nohl and Pl¨otz results, we also noticed a weakness in the pseudo-random generator. Our contribution is threefold: First and foremost, using the weakness of the pseudo-random generator, and given access to a particular mifare card, we are able to recover the keystream generated by the CRYPTO1 stream cipher, without know- ing the encryption key. Secondly, we describe in detail the communication between tag and reader. Finally, we exploit the malleability of the stream cipher to read all memory blocks of the first sector (sector zero) of the card (without having access to the secret key). In general, we are able to read any sector of the memory of the card, provided that we know one memory block within this sector. After eavesdropping a transaction, we are always able to read the first 6 bytes of every block in that sector, and in most cases also the last 6 bytes. This leaves only 4 unrevealed bytes in those blocks. 4 http://cq.cx/proxmark3.pl 5 http://www.proxmark.org
We would like to stress that we notified NXP of our findings before publishing our results. Moreover, we gave them the opportunity to discuss with us how to publish our results without damaging their (and their customers) immediate interests. They did not take advantage of this offer. Consequences of our attack Any system using mifare Classic cards that relies on the secrecy or the authenticity of the information stored on sector zero is now insecure. Our attack recovers, in a few minutes, all secret information in that sector. It also allows us to modify any information stored there. This is also true for most of the data in the remaining sectors, depending on the specific scenario. Besides, our attack complements Nohl and Pl¨otz results providing the necessary plaintext for a brute force attack on the keys. This is currently work in progress. Outline of this paper Section 2 describes the architecture of the mifare cards and the communication protocol. Section 3 describes the hardware used to mount the at- tack. Section 4 discusses the protocol by a sample trace. Section 5 exposes weaknesses in the design of the cards. The attack itself is described in Section 6. Finally, Section 8 gives some concluding remarks and detailed suggestions for improvement. 2 MIFARE Classic Contactless smartcards are used in many applications nowadays. Contactless cards are based on radio frequency identification technology (RFID) [1]. In 1995 NXP, 6. Some target applications of mifare are Philips at that time, introduced mifare public transportation, access control and event ticketing. The mifare Classic [8] card is a member of the mifare product family and is compliant with ISO 14443 up to part 3. ISO 14443 part 4 defines the high-level protocol and here the implementation of NXP differs from the standard. Section 2.1 discusses the different parts of the ISO standard. 2.1 Communication Layer The communication layer of the mifare Classic card is based on the ISO 14443 standard [4]. This ISO standard defines the communication for identification cards, contactless integrated circuit(s) cards and proximity cards. The standard consists of four parts. Part 1 describes the physical characteristics and circumstances under which the card should be able to operate. Part 2 defines the communication between the reader and the card and vice versa. The data can be encoded and modulated in two ways, type A and type B. mifare Classic uses type A. For more detailed information about the communication on RFID we refer to the “RFID Handbook” by Klaus Finkenzeller [1]. Part 3 describes the initialization and anticollision protocol. The anticollision is 6 http://www.nxp.com
needed in order to select a particular card when more cards are present within the reading range of the reader. After a successful initialization and anticollision the card is in an active state and ready to receive a command. Part 4 defines how commands are send. This is the point where mifare Classic differs from the ISO standard, using a proprietary and undisclosed protocol. The mifare Classic starts with an authentication, after that all communication is encrypted. On every eight bits a parity bit is computed to detect transmission errors. In the mifare Classic protocol this parity bit is also encrypted which means that integrity checks are only possible in the application layer. 2.2 Logical Structure A mifare Classic card is in principle a memory card with few extra functionalities. The memory is divided into data blocks of 16 bytes. Those data blocks are grouped into sectors. The mifare Classic 1k card has 16 sectors of 4 data blocks each. The first 32 sectors of a mifare Classic 4k card consists of 4 data blocks and the remaining 8 sectors consist of 16 data blocks. Every last data block of a sector is called sector trailer. A schematic of the memory of a mifare Classic 4k card is shown in Figure 1. Note that block 0 of sector 0 contains special data. The first 4 data bytes contain the unique identifier of the card (UID) followed by its 1-byte bit count check (BCC). The bit count check is calculated by successively XOR-ing all UID bytes. The remaining bytes are used to store manufacturer data. This data block is read-only. The reader Fig. 1: mifare Classic 4k Memory needs to authenticate for a sector before any memory operations are allowed. The sector trailer contains the secret keys A and B which are used for authentication. The access conditions define which operations are available for this sector.
The sector trailer has special access conditions. Key A is never readable and key B can be configured as readable or not. In that case the memory is just used for data storage and key B cannot be used as an authentication key. Besides the access conditions (AC) and keys, there is one data byte (U) remaining which has no defined purpose. A schematic of the sector trailer is shown in Figure 2a. A data block is used to store arbitrary data or can be configured as a value block. When used as a value block a signed 4-byte value is stored twice non-inverted and once inverted. Inverted here means that every bit of the value is XOR-ed with 1. These four bytes are stored from the least significant byte on the left to the most significant byte on the right. The four remaining bytes are used to store a 1-byte block address that can be used as a pointer. (a) Sector Trailer (b) Value Block Fig. 2: Block contents 2.3 Commands The command set of mifare Classic is small. Most commands are related to a data block and require the reader to be authenticated for its containing sector. The access conditions are checked every time a command is executed to determine whether it is allowed or not. A block of data might be configured to be read only. Another example of a restriction might be a value block which can only be decremented. Read and Write The read and write commands read or write one data block. This is either a data block or a value block. The write command can be used to format a data block as value block or just store arbitrary data. Decrement, Increment, Restore and Transfer These commands are only al- lowed on data blocks that are formatted as value blocks. The increment and decre- ment commands will increment or decrement a value block with a given value and place the result in a memory register. The restore command loads a value into the memory register without any change. Finally the memory register is transferred in the same block or transferred to another block by the transfer command. 2.4 Security Features The mifare Classic card has some built-in security features. The communication is encrypted by the proprietary stream cipher CRYPTO1.
Keys The 48-bit keys used for authentication are stored in the sector trailer of each sector (see section 2.2). mifare Classic uses symmetric keys. Authentication Protocol mifare Classic makes use of a mutual three pass au- thentication protocol that is based on ISO 9798-2 according to the mifare docu- mentation [8]. However, it turned out that this is not completely true [2]. In this paper we only use the first initial nonce that is send by the card. The reader sends a request for sector authentication and the card will respond with a 32-bit nonce NC . Then, the reader sends back an 8-byte answer to that nonce which also contains a reader random NR. This answer is the first encrypted message after the start of the authentication procedure. Finally, the card sends a 4-byte response. As far as our attack is concerned this description captures all the necessary information. 3 Hardware and Software An RFID system consists of a transponder (card) and a reader [1]. The reader contains a radio frequency module, a control unit and a coupling element to the card. The card contains a coupling element and a microchip. The control unit of a mifare Classic enabled reader is typically a mifare microchip with a closed design. This microchip communicates with the application software and executes commands from it. Note that the actual modulation of commands is done by this microchip and not by the application software. The design of the microchip of the card is closed and so is the communication protocol between card and reader. We want to evaluate the security properties of the mifare system. Therefore we need hardware to eavesdrop a transaction. It should also be possible to act like a mifare reader to communicate with the card. The Proxmark III developed by Jonathan Westhues has these possibilities7. Because of its flex- ible design, it is possible to adjust the Digital Signal Processing to support a specific protocol. This device supports both low frequency (125 kHz - 134 kHz) and high frequency (13.56 MHz) signal processing. The signal from the antenna is routed through a Field Programmable Gate Array (FPGA). This FPGA re- lays the signal to the microcontroller and can be used to perform some filtering operations before relaying. The software implementation allows the Proxmark to eavesdrop communication (Figure 4) between an RFID tag and a reader, emulate a tag and a reader. In this case our tag will be the mifare Classic card. Despite the basic hardware support for these operations the actual processing of the digitized signal and (de)modulation needs to be programmed for each specific application. The Fig. 3: The Proxmark III 7 Hardware design and software is publicly available at http://cq.cx/proxmark3.pl
Fig. 4: Experimental Setup physical layer of the mifare Classic card is implemented according to the ISO14443- A standard [4]. We had to implement the ISO14443-A functionality since it was not implemented yet. This means we had to program both processing and generation of reader-to-tag and tag-to-reader communication in the physical layer and higher level protocol. To meet the requirements of a replay attack we added the functions ‘hi14asnoop’ to make traces, ‘hi14areader’ to act like a reader and ‘hi14asim’ to sim- ulate a card. We added the possibility to send custom parity bits. This was needed because parity bits are part of the encryption. 4 Communication Characteristics To find out what the mifare Classic communication looks like we made traces of transactions between mifare readers and cards. This way, we gathered many traces which gave us some insights on the high-level protocol of mifare Classic. In this section we explain a trace we recorded as an example, which is shown in Figure 5. This trace contains every part of a transaction. We refer to the sequence number (SEQ) of the messages we discuss. The messages from the reader are shown as PCD (Proximity Coupling Device) messages and from the card as TAG messages. The time between messages is shown in Elementary Time Units (ETU). One ETU is a quarter of the bit period, which equals 1.18 µs. The messages are represented in hexadecimal notation. If the parity bit of a byte is incorrect8, this is shown by an exclamation mark. We will discuss only the most significant messages. Anticollision The reader starts the SELECT procedure. The reader sends 93 20 (#3), on which the card will respond with its unique identifier (#4). The reader sends 93 70 followed by the UID and two CRC bytes (#5) to select the card. Authentication The card is in the active state and ready to handle any higher layer commands. In Section 2.4 we discussed the authentication protocol. In Figure 5, messages #7 to #10 correspond to the authentication. 8 encrypted parity bits show up as parity error in the message
ETU SEQ sender bytes 0 : 01 : PCD 64 : 02 : TAG 12097 : 03 : PCD 64 : 04 : TAG 16305 : 05 : PCD 64 : 06 : TAG 16504 : 07 : PCD 112 : 08 : TAG 6952 : 09 : PCD 64 : 10 : TAG 396196 : 11 : PCD 208 : 12 : TAG 8442 : 13 : PCD 5120 : 14 : PCD 2816 : 15 : TAG 1349238 : 16 : PCD 72 : 17 : TAG 26 04 00 93 20 2a 69 8d 43 8d 93 70 2a 69 8d 43 8d 52 55 08 b6 dd 60 04 d1 3d 3b ae 03 2d c4! 94 a1 d2 6e! 96 86! 42 84 66! 05! 9e! a0 61! d3! e3 0d 26 42 ea 1d f1! 68! 8d! ca cd ea 06! 2a 2b 17 97 49! 09! 3b! 4e! 9e! 5e b0 06 d0! 07! 1a! 4a! b4! 5c b0! 4f c8! a4!         Anticollision Authentication Increment & Transfer Read Fig. 5: Trace of a card with default keys, recorded by the Proxmark III The authentication request of the reader is 60 04 d1 3d (#07). The first byte 60 stands for an authentication request with key A. For authentication with key B, the first byte must be 61. The second byte indicates that the reader wants to authenticate for block 4. Note that block 4 is part of sector 1 and therefore this is an authentication request for sector 1. The last two bytes are CRC bytes. Encrypted Communication After this successful authentication the card is ready to handle commands for sector 1. The structure of the commands can be recognized clearly. Since we control the mifare Classic reader we knew which commands were sent. Message #11 to #15 show how an increment is performed. The increment is immediately followed by a read command (#16 and #17). 5 Weakness in MIFARE Classic Nohl and Pl¨otz partially recovered the CRYPTO1 algorithm that is used to encrypt the communication between the card and the reader [7,5]. The pseudo-random gener- ator on the card, which initiates the algorithm by generating a nonce, is weak. In our analysis, we use this weakness to extend the work of Nohl and Pl¨otz with a practical attack, which delivers the needed known plaintext for brute-force, and a description of the mifare Classic protocol. In this attack, we do not need knowledge about the CRYPTO1 algorithm other than that it is a stream cipher which encrypts bitwise. During our experiments, independently, we also noted the weakness of the pseudo- random generator of the card by requesting many card nonces. We were able to
分享到:
收藏