A Practical Attack on the MIFARE Classic

A Practical A ttac k on the MIF ARE Classic Gerhard de Koning Gans, J aap-Henk Ho e pma n, and Flavio D. Garcia Institute fo r Computing and Information Sciences Radb oud U n ivers ity Nijmege n P .O. Box 9010, 6500 GL Nijmegen, The Netherlands gkoningg@s ci.ru.nl , jhh@cs.ru. nl , flaviog@cs .ru.nl Abstract. The mif are Cl assic is the most widely used con tactless smart card in the market. Its design and implementa tion d etails are kept secret by its manuf acturer. This pap er studies the architecture of the card and the comm unication proto col b etw een card and reader. Then it gives a practical, lo w-cost, attac k that reco v ers secret i nformation from the memory of the card. Due to a weakness in th e pseudo-rand om generator, w e are able to recov er the ke ystream generated b y the C R YPTO1 stream cipher. W e e xploit the malleabili ty of the stream cipher to read al l memory blo c ks of the first sector of the card. Moreo ver, w e are able to read any sector of the memory of the card, pro vided t hat we kn o w one memory b lock within this sector. Finally , and perhaps more damaging, the same holds for mo difying memory blocks. 1 In tro duction RFID and contactless smart cards hav e b ecome p erv asive tec hnologies now adays. Over the la st few years, more and more systems adopted this technology as replace- men t for barco des, magnetic strip e cards and paper tick ets for a v ariety of appli- cations. Contact-less cards consist of a small piece of memor y that can b e a c c essed wirelessly , but unlike RFID tags, they also hav e some computing capabilities. Most of these ca rds implement some sor t of simple symmetric-key cry ptography , which makes them suitable for a pplications that require access control. A n umber of high profile a pplications ma ke use of contactless sma r t cards for access control. F or example, they a re used for paymen t in several public transp ort systems like the Octopus ca rd 1 in Hong Ko ng, the Oys ter ca r d 2 in L ondon, and the OV -Chipk aart 3 in The Netherlands, among others. Man y countries have a lready incorp orated a co nt actless card in their electronic passp orts [ 3 ] a nd s everal car man- ufacturers ha ve it embedded in their car keys as an an ti-theft metho d. Many office buildings a nd even secured facilities like airpo rts and military bases , use co n tactless smart cards for a ccess control. 1 http://www .octopuscards .com/ 2 http://oys ter.tfl.gov.u k 3 http://www .ov- chipkaart.nl/ On the o ne hand, the wireles s interface has pra c tical adv ant ages: without me- chanical co mpo nents b et ween r eaders and cards, the sy s tem has lo wer maintenance costs, is more reliable, a nd has shorter reading times, providing higher throughput. On the other ha nd, it represents a p otential threat to priv acy [ 3 ] and it is susceptible to relay , replay and skimming attacks that were no t p oss ible b efore. There is a hu ge v ariety of cards on the mar ket. They differ in size, casing, memory and c omputing p ow er. They also differ in the s ecurity features they pr ovide. A well known and widely used sy s tem is mif are . mif are is a pro duct family from NXP semi- conductors (formerly Philips). According to NXP there are about 200 million mif are cards in use around the world, cov ering 85 % of the co nt actless s ma rtcard market. The mif are family co n tains four different types of cards: Ultralight, Standard, DES- Fire and SmartMX. The mif are Classic cards come in three different memory sizes: 320B, 1KB and 4KB. The mif are Classic is the most widely used con tactless c a rd in the market. Throughout this paper w e fo cus on this car d. mif are Classic provides m utual a uthen tication and data secrecy by means of the so ca lled CR YPTO1 strea m cipher. This cipher is a proprietar y alg orithm of NXP and its design is kept secret. Nohl and Pl¨ otz [ 7 ] have recently reverse engineered the hardware of the c hip and exp osed several weaknesses. Among them, due to a weakness on the ps e udo - random g enerator, is the observ ation that the 32- bit nonces used for authentication hav e only 1 6 bits of entropy . They also noticed that the pseudo-random gener ator is stateless. They claim to have knowledge of the exact encryption a lg orithm which would facilitate an o ff-line brute force a ttack o n the 48-bit keys. Such a n attack would b e feasible, in a reaso nable a mount o f time, especially if dedicated hardware is av ailable. Our Contribution W e used a Proxmark II I 4 to a nalyze mif are cards and mount an a ttack. T o do s o , we hav e implemented the ISO 1444 3 -A functionality on the Proxmark, since only ISO 14443-B was implement ed at tha t time. W e programmed bo th pro cessing a nd g eneration of reader- to -tag and tag-to-reader communication at ph ysical and higher levels of the proto col. The s ource co de of the firm ware is a v ailable in the public do main 5 . Concurrently , and indep endently from Nohl and Pl¨ otz results, we also noticed a weakness in the pseudo-random generator . Our co ntribution is threefold: First and foremost, using the weakness of the pseudo-random generator, a nd given a ccess to a par ticular mif are card, we are able to recov er the keystream g e ner ated b y the CR YPTO1 s tr eam cipher, without know- ing the encryption key . Secondly , w e describe in detail the communication b etw een tag and reader. Finally , w e explo it the malleabilit y of the stream cipher to read al l memory blo cks of the first sector (sector zero) of the card (without having access to the secret k ey). In gener al, we ar e able to read any sector of the memory of the card, provided that we know one memor y blo ck within this sector. After eav esdropping a transaction, we are a lw ays able to read the fir st 6 b ytes of ev ery blo ck in that sector, and in most ca ses also the last 6 byt es. This leaves only 4 unrevealed byt es in those blo cks. 4 http://cq. cx/proxmark3. pl 5 http://www .proxmark.org W e would like to s tress that we no tified NXP of our findings before publishing o ur results. More ov er, we gav e them the opp ortunity to discuss with us how to publish our results without damaging their (and their customer s) immediate in terests. They did not take a dv antage of this offer. Consequences of our attac k Any system using mif are Classic cards that relies on the se crecy or the authenticit y of the information stored on sector zero is now insecure. O ur attack recov ers, in a few minutes, al l secr et information in that sector. It also allows us to mo dify any informa tion stored there. This is also true for most of the data in the remaining sectors, dep ending on the sp ecific 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 progr ess. Outline of this pap er Section 2 descr ibes the a r chit ecture of the mif are c a rds and the communication proto col. Section 3 describ es the hardw are used to mount the at- tack. Section 4 discusses the pro to col by a sample trace. Section 5 ex p o s es weaknesses in the design of the cards. The attack itself is describ ed in Section 6 . Finally , Section 8 gives some co ncluding remark s and detailed sugge s tions for improv ement . 2 MIF ARE Classic Contactless sma rtcards are used in many applications nowada ys. Contactless cards are based on r adio fr e quency identific ation tech nology (RFID) [ 1 ]. In 1995 NXP , Philips a t that time, introduced mif are 6 . Some targ et applications o f mif are ar e public tra ns po rtation, access co n trol and even t tick eting. The mif are Classic [ 8 ] car d is a member of the mif are pro duct family and is c o mpliant with ISO 1444 3 up to part 3. ISO 1444 3 part 4 defines the high-level pro to c o l a nd here the implemen tation of NXP differs fr om the s ta ndard. Section 2.1 discusses the differen t parts o f the ISO standard. 2.1 Communica tion La yer The communication layer of the mif are Classic card is ba sed on the ISO 1 4 443 standard [ 4 ]. This ISO standard defines the communication for iden tification ca rds, contactless integrated circuit(s) cards and proximit y c ards. The standard consists of four parts. Part 1 describe s the physical characteristics and circumstances under which the card should be able to o p e r ate. Part 2 defines the comm unication b etw een the re a der and the card and vice versa. The data can be encoded and mo dulated in tw o w ays, type A and type B. mif are Cla s sic uses t yp e A. F or more detailed information a bo ut the comm unication on RFID we refer to the “RFID Handb o ok ” by Kla us Finkenzeller [ 1 ]. Part 3 descr ibes the initialization and anticollision proto col. The antic ol lision is 6 http://www .nxp.com needed in o rder to select a particular card when more car ds a re present within the reading range o f the reader. After a s uccessful initializa tion and a n ticollision the c a rd is in an a ctive state and rea dy to receive a command. Part 4 defines how commands ar e send. This is the p oint wher e mif are Classic differs from the I SO standard, using a propr ie ta ry and undisclosed pro to co l. The mif are Classic starts with an authent ication, after that all communi cation is encrypted. On every eight bits a par ity bit is computed to detect tra nsmission errors. In the mif are Classic proto col this parity bit is also encrypted whic h means that in tegrity checks are only p ossible in the application lay er. 2.2 Logical Structure A mif are Classic card is in principle a memory c a rd with few extra functionalities. The memor y is divided into data blo cks of 16 bytes. Those data blo cks are gr oup ed in to sectors. The mif are Class ic 1k card has 16 sectors o f 4 data blocks each. The first 3 2 s e c to rs of a mif are Classic 4k ca rd c o nsists of 4 data blocks a nd the remaining 8 sectors consist of 16 da ta blo cks. Every last data blo ck of a sector is c a lled se ctor tr ailer . A schematic o f the memory of a mif are Clas sic 4k ca rd is shown in Figure 1 . Note that blo ck 0 of s ector 0 con tains sp ecial da ta. The first 4 data bytes contain the unique iden tifier of the ca rd (UID) followed by its 1-byte bit c ount che ck (BCC). The bit count chec k is calcula ted by successively XOR-ing all UID bytes. The remaining b ytes are used to store ma n ufacturer data. This data blo ck is read-only . The reader Fig. 1: mif are Class ic 4 k Memory needs to authent icate for a sector b efor e any memor y op erations are allow ed. The sector trailer contains the secret keys A and B whic h are used for authentication. The ac c ess c onditions define which opera tions are av ailable for this sector. The sector tra iler ha s sp ecial acces s co nditions. Key A is never r e a dable a nd key B ca n b e configured as readable or not. In that case the memory is just used fo r data stor age and key B cannot b e used as a n authentication key . Besides the access conditions (AC) a nd keys, there is one data b yte (U) remaining which has no defined purp o se. A schematic of the sector trailer is sho wn in Figure 2a . A da ta block is used to store ar bitrary data or ca n b e configured as a value blo ck . When used a s a v alue blo ck a signed 4 - b yte v a lue is sto r ed twice no n- in verted and o nce inv erted. Inverted here means that every bit of the v alue is XOR-ed with 1. These four bytes are stored from the least significant byte on the left to the most s ignificant byte on the right . The four remaining bytes are used to store a 1- b yte blo ck a ddress that ca n b e us ed as a p ointer. (a) Sector T railer (b) V alue Block Fig. 2: Blo ck co n tents 2.3 Commands The command set of mif are Classic is small. Most co mmands ar e related to a data blo ck and require the reader to b e authen ticated for its co nt aining sector . The a ccess conditions are chec ked every time a command is executed to determine whether it is allow ed or not. A blo ck of data might b e configured to be read o nly . Another example of a res tr iction mig h t b e a v alue blo ck which can only b e decremented. Read and W rite The r ead and wr ite commands read or write one data block. This is either a data blo ck o r a v alue blo ck. The write command can b e us e d to format a data blo ck a s v alue blo ck o r just store arbitrar y data. Decremen t, Increment, R estore and T ransfer These commands ar e only al- low ed on data blo cks that are for matted as v alue blo cks. The incr ement a nd de cr e- ment commands will increment or decrement a v alue block with a given v alue and place the res ult in a memory r egister. The r estor e c o mmand lo ads a v alue in to the memory register without any change. Finally the memory reg ister is tra nsferred in the same blo ck or transferred to another blo ck b y the tr ansfer command. 2.4 Securit y F eatures The mif are Classic ca rd has some built-in security features. The communication is encrypted by the proprietary stream cipher CR YPTO 1. Keys The 48-bit keys used for authentication are stored in the s ector trailer of ea ch sector (see section 2.2 ). mif are Class ic use s symmetric keys. Authen tication Proto col mif are Classic makes use of a mutu al three pass au- then tication proto col that is based o n ISO 979 8-2 accor ding to the mif are do cu- men tation [ 8 ]. Howev er, it turned out that this is not completely true [ 2 ]. In this pap er w e only use the first initial nonce that is send by the card. The re ader sends a request for sector a uthen tication and the ca rd will r esp ond with a 32 -bit nonce N C . Then, the reader sends back a n 8- b yte answer to that nonce which also cont ains a reader ra ndom N R . This answer is the first encrypted messa ge after the start of the authent ication pro c e dur e. Finally , the card sends a 4-byte resp onse. As far as our attack is co ncerned this description captures all the necessar y information. 3 Hardw are and Soft w are An RFID system co ns ists of a transp onder (card) and a reader [ 1 ]. The reader contains a radio frequency mo dule, a co nt rol unit a nd a coupling elemen t to the ca rd. The card contains a coupling elemen t a nd a micro chip. The control unit of a mif are Class ic enabled reader is typically a mif are micro chip with a closed design. This micro chip communi cates with the application softw are and ex e c utes commands from it. Note that the a c tua l mo dulation of co mmands is done b y this micro chip and not b y the application so ft ware. The design of the micro chip of the card is c lo sed and so is the communi cation pro to co l betw een card and rea der. Fig. 3: The Proxmark II I W e wan t to ev aluate the secur it y pr op erties of the mif are system. Therefore we need hardware to eav esdrop a transa ction. It should a lso be po ssible to act like a mif are reader to commu nicate with the car d. The Proxmark I I I dev elop ed by Jonathan W esthues has these p ossibilities 7 . Because o f its flex- ible des ig n, it is p oss ible to adjust the Digital Signal Pro cessing to supp or t a sp ecific pr o to col. This device suppo rts b oth low frequency (125 kHz - 134 kHz) and high frequency (1 3.56 MHz) signal pro cessing . The signal from the antenna is routed through a Field Progr ammable Gate Arr ay (FPGA). This FP GA re- lays the sig na l to the micro controller and ca n b e used to perfor m some filtering oper ations b efor e relaying. The softw are implement ation allows the Proxmark to eav esdrop communication (Figure 4 ) b etw een a n RFID tag and a reader, em ulate a tag and a rea der. In this case our tag will b e the mif are Class ic card. Despite the basic hardware supp or t for these op era tions the actual pro cessing of the digitized signal a nd (de)mo dulation needs to b e programmed for each sp ecific application. The 7 Hardw are design and soft w are is publicly a v ailable at http://cq. cx/proxmark3. pl Fig. 4: Exp erimental Setup ph ysical layer of the mif are Cla ssic card is implemented acco r ding to the ISO1 4443- A standard [ 4 ]. W e had to implement the ISO144 43-A functionality since it was not implemen ted yet. This mea ns we had to prog ram b oth pr o cessing and g eneration of reader- to-tag and tag- to-reader co mm unication in the ph ysical lay er and higher level proto col. T o meet the requirements of a replay attack we added the functions ‘hi14asno op’ to make traces, ‘hi14areader ’ to act lik e a reader and ‘hi14 asim’ to sim- ulate a ca rd. W e a dded the p oss ibilit y to se nd custom parit y bits. This was needed beca use parity bits are part o f the encryption. 4 Comm unication Characteristics T o find out what the mif are Classic communication lo oks like we made tra ces o f transactions b et ween mif are rea ders and cards. This wa y , we gathered many tra c e s which gav e us some insights o n the high-level pro toc o l of mif are Classic. In this section we explain a trace we recor ded as an example, which is shown in Figure 5 . This tra ce contains every part o f a transa ction. W e r e fer to the s e q uence num ber (SEQ) of the messages we discuss. The messa ges from the reader are shown as PCD (Proximit y Coupling Device) messages a nd from the card as T AG messag es. The time betw een mess ages is sho wn in Elementary Time Units (ETU). One E TU is a quarter of the bit perio d, whic h e quals 1 .1 8 µ s. The messag es are repr esented in hexadecimal notation. If the parity bit of a byte is inco r rect 8 , this is shown by an excla mation mark. W e will discuss o nly the most significant mess ages. An ticollisi on The r eader starts the SE LECT pro cedur e. The reader s ends 93 20 (#3), on which the card will resp ond with its unique identifier (#4). The r e a der sends 93 70 follow ed b y the UID a nd t wo CRC b ytes (#5) to s elect the car d. Authen tication The ca rd is in the active s tate and r eady to handle any higher lay er commands. In Section 2.4 we discusse d the a uthen tication proto col. In Figure 5 , messages #7 to #1 0 corres po nd to the authent ication. 8 encrypted parit y bits sho w u p as parit y error in th e message ETU SEQ sender bytes 0 : 01 : PCD 26 64 : 02 : TAG 04 00 12097 : 03 : PCD 93 20 64 : 04 : TAG 2a 69 8d 43 8d 16305 : 05 : PCD 93 70 2a 69 8d 43 8d 52 55 64 : 06 : TAG 08 b6 dd 9 > > > > > > = > > > > > > ; Anticol lision 16504 : 07 : PCD 60 04 d1 3d 112 : 08 : TAG 3b ae 03 2d 6952 : 09 : PCD c4 ! 94 a1 d2 6e ! 96 86 ! 42 64 : 10 : TAG 84 66 ! 05 ! 9e ! 9 > > = > > ; Authentication 396196 : 11 : PCD a0 61 ! d3 ! e3 208 : 12 : TAG 0d 8442 : 13 : PCD 26 42 ea 1d f1 ! 68 ! 5120 : 14 : PCD 8d ! ca cd ea 2816 : 15 : TAG 06 ! 9 > > > > = > > > > ; Increment & T ransfer 1349238 : 16 : PCD 2a 2b 17 97 72 : 17 : TAG 49 ! 09 ! 3b ! 4e ! 9e ! 5e b0 06 d0 ! 07 ! 1a ! 4a ! b4 ! 5c b0 ! 4f c8 ! a4 ! 9 = ; Read Fig. 5: T ra ce of a card with default keys, recorded by the Proxmark I I I The authentication reques t of the reader is 6 0 04 d1 3d (#07 ). The first byte 60 stands for an authentication request with key A. F or authentication with key B, the first byte must b e 61 . The second byte indicates that the reader wan ts to authen ticate for blo ck 4. No te that blo ck 4 is pa rt o f secto r 1 and therefor e this is an authent ication request for sector 1 . The last tw o b ytes are CRC b ytes. Encrypted Communication After this succ e ssful authen tication the card is ready to handle commands for sector 1. The structure of the c o mmands can b e recognized clearly . Since we control the mif are Classic reader we knew which co mmands were sent. Message #11 to #15 s how how an incr ement is p er fo r med. The incr ement is immediately follow ed b y a r e ad command (#16 and #17). 5 W eakness in MIF ARE Classic Nohl and Pl¨ otz pa rtially recov ered the CR YPTO1 algo rithm that is used to encrypt the co mmunication b etw een the card and the reader [ 7 , 5 ]. The pseudo-ra ndom gener- ator on the car d, which initiates the algor ithm by g enerating a nonce, is w eak. In our analysis, we use this weakness to extend the work of Nohl and P l¨ otz with a practical attack, which delivers the needed known plaintext for brute-force, and a description of the mif a re Class ic proto co l. In this a ttack, w e do not need knowledge ab out the CR YPTO1 algorithm other than that it is a stream cipher which encrypts bitwise. During our exp eriments, independently , we a lso noted the weakness of the pseudo- random gener a tor of the c a rd by r equesting ma ny car d nonces. W e were able to request ab out 6 00,000 nonces every hour . Within one ho ur, a nonce reapp eared at least ab out four times. The nonce is generated b y a Line ar F e e db ack Shift R e gister (LFSR) [ 5 ] which shifts every 9.4 4 µ s. This is exactly one bit p erio d in the commu- nication. Therefor e a r andom nonce could theoretica lly r eapp e a r after 0 .6 18s, if the card is queried at exactly the right time. In a nother exp eriment, we tried to request a nonce at a fixed time after p ow ering-up 9 the card. This wa y , we could re duce the card nonces to ten different ones, which decreases the waiting time. Without kno wing the cr yptographic alg orithm, only a n online brute force attack on the key ca n b e mounted. Because o f the co mm unication delay , this w ould take 5ms for each attempt. An exhaustive k ey s e arch would then take 16,289,06 1 days, which equals ab out 44,62 7 y ears. When the cryptog raphic alg o rithm is known, an off-line brute force attack can b e mount ed using a few eavesdropped traces o f an authentication run. Nohl and Pl¨ otz state that with dedicated hardware of a r ound $ 17,000 this would take abo ut one hour. F or this attack to w ork, some known plain text is required. Our analys is pr ovides this plaint ext. 6 Keystream Reco v ery A ttac k In Sectio n 5 w e discusse d a weakness in the pseudo -random gener ator of the mif are Classic. In this section we deploy a metho d to recov er the keystream that was used in an ea rlier rec o rded transa ction b et ween a reader a nd a card. As a result the keystream of the communication will be recov ered. F or this attack we need to b e in p osses sion of the car d. The following r e a sons mak e this attack in teresting: 1. Our a ttack provides the known plain text necessary to mount a brute force attack on the key . 2. Using our attack we recov ered details ab out the byte commands. 3. Using the recov ered keystream w e can r e ad card co n tents without knowing the key . 4. Using the recov ered k eystream w e can also mo dify the con tent s of the car d with out knowing the key . 6.1 Keystream Reco v ery T o recov er the k eystream we exploit the weakness of the pseudo-ra ndo m g e ner ator. As it is this random nonce in com bination with only o ne v alid resp onse of the reader what determines the remaining keystream. F or this attack we need complete cont rol ov er the reader (Pr oxmark) and access to a (genuin e) card. The a ttac k cons ists of the following steps: 1. Eav esdrop the communication b etw een a reader and a card. This can be for example in an access control system or public transp ort system. 9 as was suggested b y N ohl and Pl¨ otz [ 7 ] 2. Mak e sure that the card will use the same keystream as in the reco rded comm u- nication. This is po ssible b e c a use the ca rd repea ts the same no nce in reaso nable time, and we completely cont rol the r eader. 3. Modify the plaintext, such that the card receives a command for whic h w e know plaint ext in the resp onse (e.g., by changing the block num ber in a rea d command). 4. F or eac h seg ment of known pla in text, compute the co rresp onding keystream seg- men t. 5. Use this keystream to partially decrypt the trace obtained in 1 . 6. T ry recovering more keystream bits b y shifting commands. The plaintext P 1 in the c o mm unication is XOR-ed bit wise with a keystream K which gives the encrypted data C 1 . When it is poss ible to use the same keystream on a different plaintext P 2 and either P 1 or P 2 is known, then bo th P 1 and P 2 are revealed. P 1 ⊕ K = C 1 P 2 ⊕ K = C 2  C 1 ⊕ C 2 ⇒ P 1 ⊕ P 2 ⊕ K ⊕ K ⇒ P 1 ⊕ P 2 (1) The w eak pseudo-random generator makes it p ossible to replay an earlier recorded transaction. W e can flip ciphertext bits to try to mo dify the first comma nd such that it gives another res ult. Another result gives us another plain text. The a ttack is ba s ed on this principle. 6.2 Keystream Mapping The data is encrypted bitwise. When the r eader sends or receives a message, the keystream is shifted the num ber o f bits in this messa ge on both the reader and ca rd side. This is needed to stay synchronized and use the same keystream bits to encrypt and decrypt. The stream cipher does not us e any feedbac k mechanism. Despite that, when we tr ie d to reveal the conten ts of a mess age sequence using a known keystream of an ear lier tr a ce, something wen t wrong . W e r ecorded an incr ement follow ed by a tr ansfer command. W e used this trace to a pply our attack and changed the first command to a r e ad command which consists of 4 command bytes and delivers 18 resp onse bytes. T ogether with the parity bits this makes it a 198 bit s tream. The plaint ext was kno wn and therefore we recov ered 198 k eystream bits. When we used this keystream to map it on the original tra ce of the incr ement (Figure 6 ), it turned o ut that the k eystream w as not in phase after the first co mma nd. The reason was the shor t 4-bit answer of the ca rd that is not follow ed by a par ity bit. In our orig ina l tra ce w e are now ha lf wa y the firs t resp onse b yte. This means that after 4 more bits we arrive at the pa rity bit in the or iginal trace. How ever, in our new tra ce we a re then half wa y the next command byte. T o correct this w e needed to throw awa y the keystream bit that was or ig inally used to encrypt the pa rity bit. But what to do when we need to decrypt a par it y bit in the new situation and w e are half wa y a b yte with r e s pect to the first trace? The solution is to encr ypt the parity bit with the next bit from the r ecov ered keystream and use this same keystream bit to decrypt the next data bit. F ro m this w e can conclude that parit y bits are encrypted with keystream bits that are also used to encr ypt databits. INCREMENT ACK VALUE TRANSFER ACK Plaintext c1 04 f6 8b 0a 01 00 00 00 bb 4a b0 04 ea 62 0a Ciphertext 4c 88 31 bc! 0a! e2 79!2a!14 35!6f! 04!81 2d!1e! 0c! Fig. 6 : Recov ering the Keystream and Commands The following metho d successfully maps the keystream o n another message sequence as we desc r ibed ab ov e. T ake the recov ered keystream and strip a ll the keystream bits from it that were at parity bit p ositions. The remaining keystream can be used to encrypt new messages. Every time a par ity bit needs to b e encrypted, use the nex t keystream bit without shifting the keystream, in all o ther ca ses use the next keystream bit and shift the keystream. 6.3 Authen tication Repla y T o replay an authen tication we first need a trace of a successful a uthen tication be- t ween a genuine mif are reader and ca rd. An exa mple of an authentication follow ed b y one read command is shown below. 1 PCD 60 03 6e 49 2 TAG e0 92 93 98 3 PCD ad e7 96! 4 8! 20! 22 df 93 4 TAG bf 06 91! 8 2 5 PCD b5! 0 5! 47 3f 6 TAG 3f 14 ! 4f e9! 86 38! 96! 85 3e! f3 e3! 3d! eb! 2b! a2 d4 dd 76! After w e recorded an authen tication betw een card and reader, we do no t mo dify the memory . This ens ur es that the memory of the car d r emains unaltered and therefor e it will return the sa me plain text. Now we will act like a mif are r eader and try to initiate the same authentication. In short: 1. W e recor ded a trace of a successful authen tication betw een a gen uine card and reader. 2. W e s end authentication reques ts (#1) until we get a nonce that is equal to the one (#2) in the o riginal trace. 3. W e send the recorded res po nse (#3) to this nonce. It consists of a v alid respo nse to the challenge nonce and a challenge fro m the rea der. 4. W e retrieve the resp onse (#4) to the challenge from the car d. 5. No w we are at the po int where we could r e s end the same command (#5) or attempt to mo dify it. 6.4 Reading Sector Zero W e will show that it is p ossible to read s e c to r 0 from a card without k nowing the key . W e o nly need one transactio n b etw een a genuine mif are rea der and ca rd. Every mif are Cla ssic ca rd has so me known memory conten ts. The pro duct infor mation published by NXP [ 8 ] gives this information. When a sector trailer is read the card will return logical ‘0’s instead o f k ey A beca use key A is not r eadable. If key B is not readable the card a lso re turns log ical ‘0’s. It depends o n the access conditions if key B is readable or not. The a ccess conditions Fig. 7 : Recov ering Sector Z ero can b e recov ered b y using the manu facturer data . Blo ck 0 contains the UID and BCC follow ed b y the manuf acturer data. The UID and BCC cov er 5 b ytes and are known. The rema ining 11 b ytes ar e cov ered by the manufacturer data. Some in vestigation on different car ds ( mif are Cla ssic 1k and 4k) revealed that the first 5 bytes of the manuf acturer data almost never ch ange. These bytes (MFR1) cov er the p o sitions of the acces s conditions (AC) and the unknown byte U, as shown in Figure 7 . This means that the keystream can b e recovered using the known MFR1 byt es by reading blo ck 0 and blo ck 3 (sector trailer) subsequently . Remember that the a c c e s s conditions are stored twice in 3 bytes. Once inv erted and once non-inv erted. This way it is e a sy to detect if we indeed revealed the access co nditions. The unknown b yte U can b e in any state when the card leaves the manufacturer but appea r s to be often 00 o r 69 . The acces s conditions tell us whether key B is readable or no t. In many cases k ey B is not rea da ble, for instance as in the OV-Chipk aart 10 that is used in the Dutc h public transp ort system. The fir st 5 bytes of the manufacturer da ta (MFR1 in Figure 7 ) recov ered the access conditions for sector 0. Because the acces s conditions for the sector tra iler define key B as not reada ble, we know the pla intext is zeros. Hence the who le sector trailer w as revealed and therefor e the cont ents of the whole sector 0 were r evealed as well. 7 Reading Higher Sectors In the higher sectors o f the mif are Classic c a rd we do not ha ve the adv ance of the manufacturer data. W e basically hav e the se ctor trailer and some unknown data blo cks. Because of key A we can re c over a lwa ys the first 10 keystream bytes. Key B is in most case s not reada ble and therefore will g ive 6 mor e keystream bytes, but leav es us with a ga p of 4 bytes (A C and U). Although it is harder to achiev e, there is a po ten tial threat fo r these sector s to b ecome compromised. 10 mif a re Classic 4k card 7.1 Proprietary Command Co des A t the time this r esearch was per formed, we were not aw are that the command co des, which we rev ealed with our attack, could already be found in example firmw are of NXP 11 . Note that the firmw are refers to the command co des sent fro m PC to reader. Our research shows that (p erhaps obviously) these are the same command co des sent from reader to ca rd. W e used a card in tra nspo rt configura tion with default keys and empty data blocks to reveal the encrypted commands use d in the high-level proto col. All the commands send by the rea der consist o f a co mmand byte, parameter byte and tw o CRC bytes. W e made several attempts to reveal the command by mo difying the ciphertext o f this command. The wa y to do this is to assume we actually know the co mmand. With this ‘knowledge’ we XOR the ciphertext whic h gives us the keystream. T o chec k if this is indeed the cor rect keystream, we XOR it with a new co mmand for which we know the resp ons e . If we guess ed the initial command right the resp onse of the card will b e that known resp onse. This metho d r evealed the comma nds shown in Fig ure 8 . Now, one could try to r eplay the same authentication a gain and try to execute a command that returns an ACK or NA CK in or der to recov er more keystream. Because an ACK or NACK is only 4 bits in size, it leav es so me spare bits for whic h we know the keystream. W e can use these bits to execute a nother command for which w e now know the plaintext. This delivers more known k eystream as a result, and this metho d can b e a pplied rep eatedly . How ever, this approa ch does only work if a de cr ement , incr ement o r tr ansfer is a llow ed. These are the commands that r eturn an ACK and therefore ar e in total s horter than the r e ad . W e can only se nd v alid commands b ecause otherwise the proto col abo rts. The r e ad comma nd returns 16 da ta b ytes and 2 CRC Fig. 8 : Command set of mif are Cla ssic 11 http://www .nxp.com/file s/markets/identification/download/MC081380.zip b ytes. On a write command the car d returns a 4-bit ACK, this indicates that the card is ready to r eceive 16 data bytes follow ed b y 2 CRC b ytes. The de cr ement , incr ement and r estor e commands a ll follow the s a me pro cedure. The card indicates that it is exp ecting a v alue from the r e a der by se nding a 4-bit ACK resp onse. This v alue is 4 bytes and is follow ed by 2 CRC bytes. F or the r estor e this v alue is send but no t used. The v alue is send as YY YY YY YY ZZ ZZ , where YY are the v a lue b ytes a nd ZZ the CRC bytes. Finally , a tr ansfer command is send to transfer the result of o ne of the previous commands to a memor y blo ck. The card resp onse is an ACK if it went w ell. Otherwise it resp onds with a NACK. The 4-bit A CK is 0xa . When a comma nd is not allow ed the card sends 0x4 . When a transmission e r ror is detected the card se nds 0x 5 . The card do es not even giv e a resp onse at all if the command is of the wr ong length. The proto col ab orts on every mistake or disallow ed c o mmand. 8 Conclusions & Recommendations W e hav e implemen ted a succe s sful attac k to r ecov er the keystream of an earlier recorded transaction b etw een a genuine mif are Classic re a der and card. W e used a mif are Classic rea der in combination with a ‘blank’ card with default keys to recov er the byte commands that are used in the pr oprietary proto co l. Knowin g the byte co mmands and a sufficien tly lo ng k eystream allowed us to p erform an y op eration as if we were in p osses sion of the secret key . W e mana ged to read al l memor y blocks of the sector zero o f the card, without having ac c e s s to the secr et key . In gener a l, we w ere able to r ead any sector of the memory of the card, provided that we know one memory blo ck within this sector. Moreov er, after recording a v alid transaction on any sector, w e were able to read the first 6 bytes of any blo ck in that s ector and also the last 6 bytes if key B is read o nly . Similarly , we are able to mo dify the informa tion stored in a particular se c to r. Consequences Fir s t of a ll, all data stored on the card (except the keys themselves) should no long er b e considere d secret. In par ticular, if the mif are Clas s ic car d is used to stor e per sonal information (like na me, date of birth, or travel information), this constitutes a direct priv acy risk. The security risk is rela tively low b ecause in general the s ecurity is guara n teed by the secr e c y of the keys. Note that in particular we ar e no t able to clone car ds, beca use the secret keys remain secret. Secondly , the integrit y and authenticit y of the data sto r ed on the ca rd can no longer b e relied on. This is quite a severe security r isk. This is particularly worrying in applications where the car d is used to store a certain v alue, like loyalt y p oints or, even worse, some fo r m of digital currency . The loy alty level or the v alue stor e d in the electronic pur s e could easily b e increased (or decreased, in a denial-of-s ervice t yp e of attack). Thirdly , knowledge of the plain text (or the keystream) is a necessary condition to per form brute force (or other mor e sophisticated) a ttacks to recov er the secret key . W e a re making go o d progress in developing a very efficient attack to recov er arbitra ry sector keys o f a mif are Classic c ard. Recommendations F or short term improvemen ts we recommend not to use sector zero to stor e secret information. Configure key B as readable and store random in- formation in it. Do not store se ns itiv e information in the first 6 bytes of any sector. Use multip le secto r authen tications in one tra nsaction to th wart attack ers in an at- tempt to recover plaint ext. This is only helpful when v a lue blo ck co mmands are not allow ed. V alue blo ck commands are shorter than a rea d co mmand and will e na ble a shift of the keystream. Another p os sibilit y , that might be viable for so me applica- tions, is to emplo y ano ther encr yption scheme like AES in the back office, a nd store only encrypted infor mation on the tags. T o preven t unauthorize d mo dification of a data blo ck, a n e x tra authen tication on this da ta could b e added. This authentication is then verified in the back office. Prop er fraud detection mechanisms and extra security features in the bac koffice are necessary to signal or ev en prevent the types of attac ks described ab ov e. In general, the ba ck office sys tems collecting and pro cessing data that comes fro m the readers are a very impor tant second line o f defense. On the long term these count ermeasur es will not b e sufficient. The mif are Classic card ha s a closed design. Security by obscurity has shown several times that at some po in t the details o f the system will b e re vealed co mpromising security [ 6 ]. Therefore we reco mmend to migr ate to more a dv anced cards with a n op en design ar chit ecture. References 1. Klaus Finkenzeller. RFID Handb o ok . John Wiley and Sons, 2nd edition, 200 3. 2. Fla vio D. Garcia, Gerhard de Koning Gans, Rub en Muijrers , Peter v an Rossum, Roel V erdult, and Ronny Wic hers Sc hreur. Dismantling MIF ARE Classic. F orthcoming. 3. J.-H. Ho epman, E. Hu bb ers, B. Jacobs, M. Oostdijk, and R. Wichers Schreur. Crossing Borders: Security and Priv acy Issues of the Europ ean e-Passport. I n Hiroshi Y oshiura, Kouic hi Sakurai, Kai Rannenb erg, Y uko Mura yama, and Shinichi Kaw am ura, editors, A dvanc es i n Inf ormation and Computer Se curity. I nternation al Workshop on Se curity (IWSEC 2006) , volume 4266 of L e ctur e Notes in Computer Scienc e , pages 152–167. Springer V erlag, 2006. 4. ISO/IEC 14443. Identific ation c ar ds - Contactless inte gr ate d cir cuit(s) c ar ds - Pr oximity c ar ds , 2001. 5. Starbug Karsten Nohl, David Ev ans and Henryk Pl¨ otz. Rev erse-Engineering a Crypto- graphic RFID T ag. 2008. USENIX Securit y S ymp osium. San Jose, CA. 31 July 2008. 6. Auguste Kerc khoffs. La cryptographie militaire. Journ al des scienc es militair es , IX, 1983. pp. 5–38 , Jan. 188 3, and pp. 161–191 , F eb. 1883. 7. Karsten N ohl and Hen ryk Pl¨ otz. MIF ARE, Little Security , Despite Obscurit y . Presenta- tion on the 24th Congress of the Chaos Computer Club in Berli n, December 2007. 8. NXP Semiconductors. MIF ARE Standar d 4KByte Car d IC functional sp e cific ation , F ebruary 2007.