
Uh good morning everyone. Today I'll be speaking on the topic tap and pray. Uh so if you're wondering who will be listening to rant for the next 15 minutes, my name is Pranit Balamanja. Yeah, that's my surname. It's not an Indian curse word. Um I did my masters in cyber security from the uh University of Birmingham and I graduated 3 days ago. Yeah, thank you. Thank you. Yeah, I'm currently working as a in a contract job as a managed services security support analyst at recorder future and um my contract will be ending in December after which I'll be unemployed. So if you have any routineing jobs yeah bring it my way. I love movies, music
and magic. I I'm into film making and um I'm a trained karnatic singer and also I I like magic. I believe that some magic is real. Uh so if so let me before we dive into the topic let me take you to the introduction. U anybody who's not from 19th century and carrying gold coins in the pocket definitely know what EMV is and you probably have one on you right now. So EMV is a plastic bank card and it stands for Europe, Mastercard and Visa. It was introduced in the 1990s uh to make it easier for you to carry your money around and also make it more secure to carry your money around. But while they nailed the first part, the
second part is still in question. Um the organization that issue these bank cards get to choose the protocols from these specification toolkits. Uh some of them are uh there are three authentication methods the SDA, DDA and the CDA. The SDA stands for static data authentication, the dynamic data authentication and the combined data authentication. There are five card holder authentication methods that is none at all and then the signature online PIN offline plain text pin and offline encrypted PIN. And there are two transaction types that the terminal and the card talk to each other with that is online and offline. I'll speak about it later in the talk. Coming to the first section of my talk that is tap. What
happens when you tap a card on a terminal. So basically like I said before the organizations get to choose the protocol that they want. And uh this protocol okay uh this protocol is uh basically comes in three steps. Yeah. The first one is card authentication method. So this is a terminal's attempt to figure out if the card is genuine or not or if you're using some random card to make a payments. It checks the cryptographic signatures stored on the card and sometimes challenges it in a way so that uh the terminal checks that it responds in a way that only a real card does. If this step is weak or bypassed, you can basically use a free fake cards and
it'll slip right through. The second one is the card holder verification method. So this answers the question is the person using the card is really allowed to use the card. So this could be done using pins, signature and sometimes nothing at all. Uh this is a weak point number two because pin bypass track uh tricks and call back methods usually lets the attacker sidestep this process entirely. The third one is transaction authorization. The terminal and the card bundle all the transaction details and sends it sends a final cryptographic bundle to the bank and then the bank decides whether to accept, decline or even ask for more checks. uh this is where the EM is supposed to shine but by
extending extending the gap between the card and the terminal you'll be able to you'll be able to influence what the bank sees. So this is the actual setup. Uh this is how a pino method is u is performed. As you can see there is a there's a PC running a Python script and there's an FPJ port which separates the terminal and the real card. uh for uh the UK government doesn't like randomly give out registered uh payment you know terminals to students to smart students like me especially someone from cyber security so I had to find my way around it and I created my own terminal using a Linux host machine and um I've not taken
a photo of my circuit or the connection diagram so please use your imagination here I've used two readers that connects to my Linux host system and I've inserted real card in one of the readers and a fake card in the other reader uh so who are John citizen is I'm sorry your card is on the internet. Um and then I use a simple that emulates the uh that lets the fake card emulate the real card. Coming to the second section of my talk that is paying. So usually uh for a transaction to happen successfully the card in the terminal communicate with using APD commands and these are the four APD commands that it uses. The first one
being select. This is basically the card is saying yes I am an AMV card. I am a visa, debit card or credit card or the application that I support are withdraw, deposit etc. is basically a handshake that sets the whole transaction in motion. The second one it's get processing options which is GPO. The terminal asks the card which features it supposed and asks how it wants the transaction to run. The terminal sends values like transaction amount, date and even asks the card how it can proceed. The card replies with a flag saying that it supports so and so card holder verification methods and online or offline verification. And this is where the terminal learns what type of files
it needs to read from the card. And the reading happens in the third step which is the read record step where the terminal pulls data from specific files on the card. This includes the card number, the expiry date, the processing rules and even the risk parameters. And most of the human readable the juicy stuff lies in this when the lies in this uh command. The fourth one is generate AC. This is the moment where the card creates a cryptographic proof for the transaction. The terminal sends a transaction summary. The card sizes and sends back an authentication value. This is the closest that the EM gets to a security check. So during my project which I've done for my dissertation uh
here you can see that the select command selects the 1 pay.df01 application and even selects the visa debit card and uh that's my name right there that is found during the read record. I'm going to skip past because I might have forgot to censor some stuff and u as you can see the CVM is mentioned here CVM which is the card value verification method. um it's basically saying that it uses the plain text pin verification which by itself is bad and saying that you're using a plain text verification is much worse. It's like saying the magic trick and you can do the magic on your own. Now um coming to the EMV vulnerabilities that that I showed in the previous slide the
TV the which is the trans terminal verification results and the issuer application data were meant to record how the verification actually happened but you can easily influence it. A terminal might think a PIN is verified but when really the PIN wasn't even entered in the first place. The second one is the verification downgate attack. The attacker manipulates the APDS in the middle so that the terminal falls back to a weaker verification method. So the verification method was already weak at this point. Just just remove it. Just get rid of the CVM method. Um and the third one is the manin-the-middle attack. An attacker sits between the card and the terminal and is able to intercept all the traffic that goes in
the middle. That's how we saw my name in the in the previous slide. And um you an attacker if he's smart enough can go one step ahead and even manipulate the APD responses that are transferred between the card and the terminal and this is done uh this I did during my dissertation I did using the simpress to board. So simpress to board is basically a open hardware tool designed to sniff and relay the trans uh relay the traffic that happens between the card and the terminal. But what I've done is I've flashed a card emulator firmware into the SIM crystal board which lets me emulate the real card using the fake card and even lets me manipulate the APD
responses in between. So the real card was bad on its own. Now you have an evil twin reminds me of the you know the uh twin sisters from shining. So as you can see uh in my um in my connection setup there were two readers where I've inserted the real card into one of the readers and the fake card into the other. Now even after I remove the real card from the reader which says the card removed, you can still see that the fake card still responses as though it is a real card. It even sends down the ATR number which is same as my real card. And um coming to the final boss the pin
okay attack. So uh throughout the whole process you might have observed that EMV never forces the card EM never forces the card in the terminal to prove that a real pin has real pin check has happened. So in the man of the middle like attack you can just put these three lines of script in your python code when you're uh in the middle and then whenever 0020 which is a failed failed uh APD response it can be easily changed to 9,000 which is that the process has which shows that the process has completed and um the terminal just respond just listens to the card without even verifying it. is basically like my mom who's like reading news on WhatsApp
and it's which is clearly fake and she's like if WhatsApp is saying it then it has to be true right so yeah from the terminal's perspective the customer entered a valid pin but from the card's perspective nothing happened at all so you might be thinking that there is such clearly such a big issue there has to be some possible mitigations right and yeah you're right so by you can prevent relay attacks by implementing distance bounding protocols so you can increase the distance you can uh create a physical proximity between the card and the terminal and if there apart from a certain limit it the transaction is not supposed to happen and you can also limit transaction time uh window. So in
the man in the middle attack you can also uh include a mutual authentication between the card and the terminal uh at every stage of the transaction and you can also ensure that the APD the integrity of the APD commands are changed and if there is some tampering it has to be detected and you can prevent the pino attacks by cryptographically binding the pin verification results so that the card and the terminal both come to a single verification method agreement and they both work on the same routine. Um so you might yeah uh that those are the possible mitigations but clearly those are not implemented because spino attack is still possible to this day. So why
have the organizations not done it yet because they are busy playing the blame game the hot potato game where basically the fraud is not shifted uh the fraud is shifted like uh it has definitely reddish counterfeiting and stolen cards issues but overall the fraud has still arisen. This is basically making the attackers smarter day by day. And uh there's also clear incentive misalignment because uh fixing properly means changing hardware, the firmware, the terminals, the cards, the bank system and the entire protocol itself. So that's really expensive and it's politically messy because and the organization organizations rather make your card more colorful than fund these defenses. Uh and there's a clearly liability shift because if a transaction is signed then
it's the merchants's fault for accepting the transaction and if a pin is being used then it's your fault for losing the card who truly to lose the card. Um that's um so the rules decide who pays when things go wrong and not the tech. So now you might be wondering if the organization is not doing anything and if it's the system's fault there must be something that you can do right that is where we come to the final section of my talk which is just pray just pray that your card is not stolen and even if your card is stolen just pray that the attacker is not smart enough and even if your card is stolen
and the attacker is smart enough and even if you um and the attacker has enough money to buy all the tools that he needs to perform the attack. And if you're still not, you know, if you still not lost any money, then I think it's time for you to start believing that some magic is real. Thank you. That's my time. And thank you to Grant Angus for mentoring me through this talk.