New Attacks On The MIFARE DESFire EV1 Smartcard Used In Public Transportation

okay hello everyone my name is Rory Flynn and this is figgity writes new attacks on the Mifare DESFire ev1 smart card used in public transportation so a bit about me I'm a security engineer in Dublin for those of you who aren't from Ireland or geographically unaware Dublin is about two hours by bus from Belfast you cross a little border there but mojo is kind of ruined the rest of this joke so maybe if besides is in January next one so I've just finished four years of computer science and Trinity College Dublin um I am a CTF player and I also co-founded Trinity CTF which is a CTF or Oneida Trinity I've made a few small security

disclosures nothing too big to companies in the past um and this is also my first ever conference talk so so big thanks to besides both of us for the opportunity so what's the Mifare DESFire ev1 it's a bit of a mouthful it's the chip in a lot of public transport cards so for example the leap card is used in Dublin and other places in the Republic of Ireland and the Oyster card is used in London and both of these cards contain the Mifare as far an Eevee one more specifically it's a contactless smartcard chip originally made by Philips but then later acquired by an XP the Mifare brawn there's an entire range of smart cards not just the DESFire ev1

the Mifare range has 77 percent of the transport ticketing sector so it's pretty much a huge monopoly the Mifare cards you may have heard them before because they have a certain reputation for security the Mifare classic was fully cracked around 2008 2009 by various researchers i'm is now considered fully broken no one should use it for access control or for public transport applications NXP actually sued radboud university knee my knee Megan who did this research in Dutch course in 2008 as a nine to prevent publication of that research there's a great contemporary account of that kind of process and how nxp came to see the researchers and in the paper called the fall of a tiny star by these

two people so moving on to other DES fire I sorry other my fire cards the future the next generation of cards so we had the the DES fire some call it the ev0 it's a model before the one we're talking about today so some researchers in Brewer University to become in Germany finally could do differential power analysis so this is where you do really finite power measurements to determine and what operations for processor and the card is doing and from this they were able to determine the master key for any card just by measuring power when it's communicating with a with a reader so the card I'm talking about today that as far evreyone is currently uncracked and there has

been some research about the tree random number generator from these people but we haven't seen any practical attacks just yes so it's in that context that I give legal disclaimers yes there are multiple so the first legal disclaimer um I carried out this research from my computer science undergrad project and however this talk today is in a personal capacity it doesn't represent my employer and it doesn't necessarily represent the opinions of Trinity College Dublin the second legal disclaimer is that none of the information presented here today wasn't aimed under non-disclosure agreement I didn't interact with any system that I didn't have fully permission to to interact with and I legitimately pay for all my public transport thanks for

asking so the overall aim of my research project was to see if I can attack a simulated ticketing system using the Mifare DESFire ev1 so the documentation through this is all under NDA as I mentioned so you would have to sign an NDA if you wanted to learn even just how to use the caret . and so that's obviously not acceptable if I want to talk about it later so some open-source developers have made a fully compatible C API for further DESFire ev1 so you can create applications different for different types of scenarios and it obviously handles all of the like cryptographic state and the complex stuff so you can clean gain a lot of information about

how the card works from this library so then I used Lib free fare to create a simulated public transporta on blank DESFire ev1 cards for various standard things you'd want to do for a public transport like topping up a card tagging on ticketing that sort of thing and then use this device which is called the proxmark 3 to snoop on communications between my genuine Reader and my genuine card to basically analyze it at that protocol level the proxmark 3 I think there might be a new version out now but it's basically a our microcontroller and an FPGA the FPGA does all of the fasts like radio related stuff demodulation modulation that sort of thing and then the you have the

microcontroller for your your programs as well so the DES fire eveyone is fundamentally an authenticated file system using cryptography a card is divided up into a number of apps these apps might serve a purpose so you might have one for particular transport operator and another for another one another app for bike rental that sort of thing these apps have a number of files associated with them and these files grant permissions to particular keys within the app so there's a number of cryptographic keys associated with enough and then those keys are given permission to do particular operations such as like read write read only write only read and rice or change configuration that sort of thing there's different types of files

as well which I'll get into during the presentation so there's various communications modes you can use when communicating with such as for eveyone broadly we're only concerned with the bottom two categories there the on the right legacy mode and modern mode so debug mode plain texts like no one should be really using that in a real life system no one really does so it's mostly for debugging your application legacy modes you can use three days or single days in legacy mode and those can be broken into max communications or inside for communications the modern modes then you can use another variant of three days it's basically the same thing but it's in a modern mode and you

can use AES and same goes for those two modes as well max and in Seyfert we found you can find through non invasive methods that the leap carrot is currently using legacy modes and the Oyster card is currently using modern modes so the communications will use cipher block chaining and this is kind of important later so if you're operating in a in ciphered mode for example you're basically transmitting the cipher text output of the CBC operation whereas if you're using CBC marked mode you're transmitting plaintext but you're also transmitting a part of the final block of ciphertext to basically prove that you authenticate it that plaintext that you're authorized to send that plaintext so there is a number

of keys associated with with the app with each app however you don't use them directly in the CBC operation instead you negotiate a session key with the card the card on the reader negotiate a session key and they do this through a process where they kind of prove to each other that they both know the key and the byproduct of this is a random of hopefully fully random session key that's unique to that particular session so that brings me to the first attack which is credit replay attack so this attack is mostly relevant to top up machines there's top of machines on the O'Connell Street in Dublin and so obviously in operation you do with your

card all the time is you use it as a story to follow you and you top you have to top up and put money on the card so I wrote kind of a simulation of this for the Mifare DESFire basically simulating where someone's phone is going off here it's not mine I think that would be curl whoever's looking for their phone it's here Thanks no worries no worries yep so basically this is a an app that I wrote for crediting a certain file by a certain amount and this is using legacy mode so it basically just increases it sends a command to the card let me see if I can get my ex yeah so no that's

refusing laser no come on there we go so yeah a nice little laser pointer so basically this command will say top of file number 1 by 2 and and then commit the transaction are we going to more use of it what transactions mean later hmm so if we run this if we run this particular piece of code and then we observe using the the proxmark what bytes get transmitted between the caret and the reader we can see you know we got this huge kind of dump of stuff and I've kind of tried to interpret here what the those mean so here you can see that there's an authentication procedure application selection integration procedure that's where the session key

is negotiated that I mentioned earlier and then we have a credit command so this is legacy mode encrypted with 3 days so that's actually one block of encrypted 3 days saying top-up file number 1 by 2 literally just increment the value in this file by 2 and then we commit the transaction so if we run that again we got a different credit command so this is because the session key for the second run and the first run are different because you've negotiated a new session key so this prevents you being able to just take the credit command and just play that back to the car at a later date and increment your balance so that's good well whatever

happens if we credit twice in the same authentication session so if we just issue that credit command twice so this has a cumulative effect so this script should increment by 2 and then by 2 again so we should get 4 so something yeah strange happens they're getting cryptids of the same value and this introduces a replayability within the session where an attacker can replay the credit command multiple times to accumulate balance that they are not authorized to do so so what's the reason for this so before each command is is transmitted and the initialization vector for the CBC mode is reset to all null bytes and basically why you should use an initialization vector in general

with a random nonce is to prevent the same plaintext getting encrypted to the same ciphertext so how would this look in reality um so I've introduced the concept of this relay in the middle it's kind of like a mom in the middle attack so you place this device between the genuine top of machine from the genuine card and you relay commands and and basically raw bytes and between the genuine machine the genuine top of machine and the genuine card and you can also do some processing which I'll mention there so in this scenario the top of machine issues one credit command because you've topped up by two year-old in a genuine way that goes we like that

through to the genuine card or before we commit the transaction so when the relay sees that there's a commit transaction command coming through we just replay the credit command the same credit command multiple times to the carat in this way we can increment the balance and beyond that authorized by the top of machine so the affected modes for this attack are the legacy modes this is because that reset of the initialization vector to zero before each command transmission only happens in legacy mode in modern mode you don't resize you resize to zero at the start of the entire communication some modern mode is unaffected by this so the second attack is the faked ok response and this attack mostly concerns

barriers so fire based systems you approach with your transport card you tag on it deducts the balance and records that you've made a journey and you can proceed to your train when you exit the train on the other side at the end of your journey and it will record that you've finished your journey and give you back a certain amount of balance so to mimic this I implemented a simple tag on program and lip reefer it's basically just writes h4 hello g4 goodbye just showing kind of a tag on behavior so let's look at that with the proxmark see what bites are transmitted so we can see I forget my laser pointer come on well we can see that when the reader

writes data to the carriage the carried responds with 0 0 which is ok I wrote that data to that sector thank you so there's other data there right so there's the final 2 bytes that's a CRC it's just for data corruption checking I'm so it's not actually a cryptographic tag or anything so yeah so the this is ultimately spoof Abel right because the card could just lie and say yeah I wrote that data definitely so an attack for this looks something like this so we have the genuine entrance barrier and we have our relay again we allow everything through to the card that is a read and then when the entrance buyer says okay write this data saying you made

this journey and that um that we deducted your balance the relay just responds for the card saying yeah I totally wrote that thank you so yes so that response is spoofed so we've gotten through the barrier now what we've gotten through the barrier but the card isn't tagged on we don't have a valid ticket um so on the other side right the exit barrier should say you've got no ticket you know you don't you're committing an offense here so you would think that so I discussed this with my friend Connell during the year while I was working on the undergrad project and Connell said well one time that the barrier was broken when he entered the station and

when he exited it it charged him maximum fare so this is what transport operators will do if he don't have a valid tag down ticket they'll just charge you the maximum fare assuming that you went the full length of the line the maximum length so hot tip to Connell for that tip because this enables us to do the exact same thing at the other side so when the barrier tries to write the fine of you know five or six euro or if you're in the UK like a million pounds the yeah the relay responds for you and you're like okay I definitely have that fine on my record and the barrier opens so in this way you can commit fraud on

public transport you're welcome so the defected loads for this again are just the legacy modes and the reasoning for this is that in modern modes the cards response is associated with encrypted data or a Mac I'm depending on what mode you're operating in so the barrier can actually check like hey did you actually write off enough so modern modes are unaffected by this particular attack so the third attack is the suspended commish and this attack relates to barrier lift systems so I'm not sure if Belfast has a barrier lift system transport example but an example of this in Dublin is the Lewis right there's no one stopping you from getting on a Lewis without a ticket you're on

the honor system and you will be checked as well that you've tagged on to a reader on the side of the platform and that you tag off then at the end of the journey so there's no barriers involved so it's kind of a different dynamic so let's see if we can travel for free on such systems this is an example of I think the Netherlands you just tagged on to your train there's no barriers down below yeah so I rewrote the target on application to use a modern mode AES and also teased transactions so just to explain what transactions there who has heard of a database transaction ok a good for you these are almost the exact

same as database transactions so for those of you don't know what they are a database transaction essentially until you commit it none of the changes have been made so you can make a series of changes to your database and until you commit that transaction none of it has happened so there's a simple similar idea with the transport smart cards and that's an anti tearing mechanism so transactions are used to prevent data corruption when you for example remove your card in the middle of all of these data rights going on and you end up with like a corrupt card so they have this idea of committing a transaction as the final step and to ensure that your card

doesn't end up in a corrupt state so here I kind of tried to to write that logic in live free fur it's the same hellogoodbye example and what using transactions and also using a modern a modern encryption mode that as far evreyone and which hopefully will result in a successful attack so the thing we notice here is that the commit transaction and command is always the last thing in the transmission almost always because if you think about it that's the last thing you want to do is just say okay finalize because otherwise you know someone could remove the power from the card after the commit transaction so this diagram looks a lot more complex and that's because it

is it's kind of awful to explain as well but someone just I was going through this presentation yesterday with a few friends and they said well you should have called this Schrodinger's commit because you can kind of commit and not commit you know it's kind of like life but you have you have a tag on point right which is like this yoke umm so that's on the left in this diagram you have your relay in the middle again on your genuine card so you allow all of these commands to go through to the carriage right including the right data once and until we can miss this transaction none of that data has been written to

permanent memory yes so what we can do in a barrier lift system is have a relay and we get to the commit transaction point and we just store that command in the memory of the relay keep our genuine card powered on and then keep pirate on throughout our journey if we get inspected on that journey we can allow the commit transaction come on through to the card this gives us a valid tagged on card however if we get to the end of our journey and we haven't been inspected we can just power off the card simulating you're kind of an error or a corruption and that write data never happened it's as if the card was never

tagged on so that's that's one way to do fraud so um this attack affects both legacy and modern modes and it's kind of more of a logical attack so I went through a disclosure process obviously with the card manufacturer nxp um obviously this was in the context of the legal action over the Mifare classic so my supervisor in Trinity was a great help kind of for giving me legitimacy to the process and organizing for it to take place so I decided to send the final PDF of the paper to an XPS product security incident response team this is something they set up after the Mifare classic debacle and so they have a defined procedure for security researchers to

report vulnerabilities to and XP and an XP do a really wide range of products they make a lot of processors crypto processors I think the Yubikey was using an XP tip as well so it's really a huge organization so it's well worth their while having this system oh I'm so they sent us in an out acknowledgement of receipt the next morning Fairplay that's great and after five days you know reading the paper obviously it's pretty long paper and they gave us an initial response so they said the attacks one and two which are the credit replay and the faked ok response they're known to an XP customers are told not to use backward compatibility modes and not only that

but the Chrome Common Criteria evaluation for the card says not to use these modes I would dispute that point count criteria evaluation says not use single des it doesn't apply to the the three days legacy mode and they also said that the NDA documentation is much more explicit about telling people enough to use backwards compatibility modes I don't have sighted that documentation but we have to trust that it's correct so attack number three technology its new to an XP and they did say however it would affect likely affect other smart cards using that transaction-oriented model and what I next people consider countermeasures and new designs just implementing a Timex on the carrot they also kind of

like left the ball in our course by saying like okay so this is what we know we don't know about that one okay keep us updated what you would want to do about your findings which in the context that the Mifare classic stuff is ominous AF so we requested a conference call to discuss a bit further with NIT P on that call we asked directly an XP confirmed that they don't plan to notify customers of of these attacks and we were aware that despite an XPS advice about backward compatibility modes that the leap card was using a legacy encryption was possibly vulnerable to these attacks and nxp have them listed as a customer success story on their website so we

asked for a contact in the national transporters already of ireland and to just kind of do disclosure with them as well and we also told NH p that we plan to publish in four to five months so we went through the disclosure process with the MTA the National Transport Authority in Ireland they're responsible for the leap card system which covers a few different operators in Dublin its Dublin bus Irish rail and the Lewis system so we got a contact through an XP and also through the Irish national cybersecurity center we were kind of putting out multiple failures at the same time so we met with them in person it was a really productive conversation on a really technical level so we were

able to talk with some of their engineers who work directly with with the leap card systems so attack one doesn't affect the leap card because they don't use this thing called a value file a value file is the is the only file you can use with the credited operation so they just write bounces directly as bytes to the cards on a standard file so attack 1 doesn't affect them by attacks 2 & 3 do affect them and what we discussed you know feasibility of things we actually gave them a demo of attack 1 yeah long story two attacks 2 & 3 do affect them um and we kind of discussed the practicalities of the attack right so right like our

demo was like a bunch of wires and a laptop and you know multiple cards like elastic bonded to a reader and you know it was it was hard to imagine probably someone practically doing this like going out to their books and being like hey and like a massive array of wires coming out of their cars but you know so that was part of the discussion and we also discussed the possible back-end mitigations they could do so how could they detect someone using attack 2 & 3 and we talked about like balance reconciliations so all of the barriers and stations and stuff I'm upload on a batch basis all of their transactions so there is a possibility

of detecting well those balances don't add up I'm on the backend and possibly taking action against that person or blocking the card so I gave an XP and NTA a right to reply to this presentation and both of them are availing of that today so I'll just read verbatim what they've supplied so an XP is supplied these two slides so NXP likes to thank the researchers for their responsible disclosure we acknowledge all three vulnerabilities attacks number one and number two are not new they're related to the first generation dies fire I'm a three ICD 4G secure messaging protocol that nxp recommended already for several years since 2009 to no longer use the new versions eveyone eb-2 of the chip still support

the old vulnerable protocol for backwards compatibility reasons however unless the old protocol is actually used the attack is not applicable attack number three is not specific for this product will only work when neither the entrance nor the exit is gated so our list system can be detected by back-end systems if this anomalous behavior takes place repeatedly and it can then lead to black listing the card it will also be solved from card side in the next generation of my ideas for that is under development a timeout is implemented to prevent the withholding of the transaction so an ta also gave us a statement I've kind of summarized their points because it's kind of lone also I have like 15 minutes

left so I kind of need to fill time so here's the statement from n ta n ta was happy to work with Rory and T City on this investigation and wants to thank them for following best practice in how these vulnerabilities were reported and to meet with n ta to discuss their findings n ta is conscious that the security of the leap card scheme is dependent on a complex supply chain over which n th is not a full control an NT a is very aware that vulnerabilities and underlying technologies could seriously damage the reputation of this game regarding the exploits NT a has a series of black and mitigations in place for the attacks that were demonstrated

including automated alerts and we have discussed one of the issues with the card manufacturer as its remediation is outside of our control leap cards can also be blocked if necessary which is a mitigating factor however there is a financial incentive for people to utilize these exploits so an ta is concerned about the potential impacts should they be weaponized or made more portable currently the transport operators have Revenue inspectors that patrol the transport network and would detect where a card was not updated if the tag on was route was not written to the before the inspector reached the cardholder on the other hand currently it would require less effort to not tag on at all rather than use utilize these

exploits however there will always be someone who tries to fair of age no matter how secure the ticketing system for example the Lewes tram network is entirely open and on the railway there are many unmanned stations meaning the customers can enter without paying if they really want to so for the time being we don't think that these issues greatly increase our risk and revenue protection methods for countering fare evasion such as onboard inspections will continue to be required however we recognize that this is only true until the next exploit is discovered so I have a few people to thank and many thanks to my supervisor dr. Steven Farrell eternally he was my supervisor for the

whole project and was really helpful with coordinating disclosure with the various parties I'm thanks to Bari Dorgan and Patricio Simeone at the MTA and thanks to Hans the young a10 XP for being our contact for the responsible disclosure and thanks also to Angie Watson who is with the AI TSO and he helped us draft a pre disclosure earlier this week to the NC NC s ce c isp thread sharing program also to Kevin Foley who helped us wit contacts at the MTA and there's huge open source work that went on and that really helped with this project and contributors to the proxmark projects and the live free fair projects in particular and we're great so thank

you to them and thank you very much for listening you can download the presentation from that QR code yes so thank you very much and any questions [Applause] exactly no I'm not click enough - you're good after - that was really great thank you very much for a first-time talk it was brilliant guys anyone any questions I think we all are

is there any great talk by the way thank you is there any sort of small-scale version of that relay that can be bought online Oh or do you if not do you think it would be feasible to build something smaller I think it would absolutely be feasible so the reason like there's not a demo here today is because the demo that we did have was kind of fudged because it was all running in user space so we have to manually increase the time I've for a transaction so I didn't feel comfortable kind of displaying something that was fudged but in hardware obviously you don't have those limitations so like one of the the reasons we were running into timing

issues with the with the relay that we did have was the proxmark was using like usb polling and there's like a time on laughs so I wasn't working all the time I think it definitely can be miniaturized and in like hardware that could fit in a wallet which is obviously you know it's a lot easier to disguise a wallet and a lot of people keep their cards in their wallets and so I think yes it could it could be done but you know whether like it's worth your while going through that process yeah okay guys any other questions oh nice one say there's talked is about TransLink the how to go of them yet are you discussed

anything with them unfortunately I'm not a regular visitor to Northern Ireland I should be more often though it's a beautiful part of the country so I haven't talked to TransLink as I mentioned the are pre disclosure to NCS see I am told that there is a few transport operators that are signed up to those alerts so they got a kind of a advance alert earlier in the week obviously ideally an XP would be talking to these people but they're not so that's their choice um yeah if anyone wants to contact me as I said email and Twitter there Thanks anyone else nope okay I'm gonna keep his captive here for a couple of minutes anyway we're just waiting on lunch can

wait so rather than everybody highlight and give the staff no room if you don't mind just chilling here for a few months once again Roy thank you very much for your talk was really good [Applause]