 Hello. Thank you to be here today. We're going to start. We're going to talk about NFC payments, the auto relay and replay attacks. Basically, who am I? I'm a security researcher. I'm working California. I present here in DEF CON like two years ago about Samsung Pay. Also last year I present about exploiting all my information with Bluetooth audio. This is my third time in DEF CON in a row. I'm probably co-founder of a woman in tech fund which basically is a foundation that helps women to come to a conference like security and technology calls. Basically this type is how we can move transactions from one place to another. And we're going to research about how we can implement replay attacks and relays using this technology. And of course using open source tools to do that. In this case I'm using the same device to move one transaction from one device, in this case a Samsung device acting as POS on a Samsung Pay technology. A little bit about the content of this stack. It's about an intro to NFC. We're going to talk about MED flow process and also the fraud vector of this technology. I'm going to talk about also the previous work from Peter Fillmore and Mr. Roland. And also about NFC emulation which is one of the keys in this attack. Replay attacks from, in this case I'm going to use Google Pay flow. And relay attacks for any kind of device implementing HTC or secure elements for Apple Pay. Also how we can strike chips data implementing NFC. A new attack that I call a relay for replay. I also call it a smart relay attack. And how this could affect new technology to come. Basically NFC technology is part of like, you can have two devices that they need to be close to each other to make a transaction or a communication between of them. We're talking about 10 centimeters. But that doesn't mean that we can make an amplitude of this signal to communicate two devices in a low range. NFC is in the high frequency and the RFID spectrum. Basically it's implementing passive technology. One of the characteristics of NFC technology and the payment systems is that it implements 13.56 MHz passive mode which basically it needs on our device to boot up the another, for example in this case it could be the cell phone or a smart card, credit card. It's widely implemented. Basically many devices implement NFC and use the ESO 14.4 3A. In this particular case we're going to attack just about bank systems. One of the main questions that many people ask is how this process start. Basically when you approach to a terminal to make a payment, the terminal start the transaction, not the smart card or the device like Apple Pay or Samsung Pay. Always the terminal start the communication with the devices. For example this is a transaction implementing the feedback as a smart watch. Basically you have to have in mind how this works. Basically you are in the shell, you test the command and the system responds back. It could be with right answer or wrong answer but basically it's in the way that it works. With four commands we can make a transaction basically. This is how NFC works. We're going to get in details about these transactions and a few slides. A little bit about the MIFS law, how this transaction works. The POS detects the card or the smart card. Unleash the applications, select applications, get data, implement the fraud vectors, also the managed risk. Some actions from the card for the POS simultaneously and after that the complete transaction. The complete transaction doesn't mean it could be successful transaction, it could be a declined transaction but the transaction has to be finished some way or another. A little bit about the tokenization process. Basically the tokenization process is how you convert a physical card to a virtual credit card. This process basically is when you're making a payment with Samsung Pay, let's say, every time you're making a purchase, the system is generating a new card. This is for a to avoid fraud attacks. For example, if someone is able to intercept a token, he can use just for one time but not for more times. The idea of this tokenization process to add security to the physical cards, instead of using the physical card numbers, we are using a scramble data, let's say. How the tokenization process works? Basically when you use your cell phone to make a payment, it could be Apple Pay or Samsung Pay or whatever. The terminal that takes the token, on this token, it sends the payment network and we have another party working on it, which basically is a token service provider, which relates the token with the physical card number. After it relates the transaction, it sends out to the bank and accepts a reclined transaction. Some of the technology about NFC, basically we have secure element for Apple Pay, Samsung Pay, and hotspot emulation for Google Pay, the new version of Android Pay. Some of the characteristics of this technology is that secure element is more than 20 years implemented. It has smart card, receipt actives, and also it has self encryption. Self encryption, I mean, you have cryptograms inside of the device so you can validate the transactions. In the hotspot emulation, on the other side, we have limit use keys, tokenization process, cloud cryptograms, and transaction risk analysis. And this part is like the Google Pay technology. Basically when you add your card to the Google Pay, it downloads 4 or 5 tokens to your device and you can use these tokens to make payments. After you finish this pile of tokens, it downloads more tokens. So you can use them. Then it's a fraud factor. The motivation about this attack is because you have low limits, but higher in other countries. Basically, if you install $50 in the United States, if you move this $50 to another country, that $50 will increase in value in another country. You don't have any additional calcholder verification, which basically if it's less than $50, you don't need a PIN or signature on anything like that. And also from my perspective, the fraud is considered an accepted risk. And the main thing is that NFC is implemented in many IoT devices. Attack is a while. We noticed that a few years ago in 2015, one guy was in the metro in the subway using a POS basically to get close to the people and try to get the NFC transactions, making offline transactions. And after that, he invalidated them with using online transactions. The previous work about this NFC, basically, Mr. Roland presented a replay attack about MasterCard in 2013, which he said if you implement the unique number to zero, you can, let's say, guess it, which is going to be the CBC. And for transactions, three of them went through. So it was a very good attack. In 2015, Peter Fillmore presented a black hat about how you can turn on the MasterCard and the IP. Instead of using all the security and NFC transactions, you can reduce it to the MasterCard level, which basically you can use this against the Visa cards. Also about the previous work in that year, the men in the NFC, guys from Asia present two boards, which basically was a client on a server, which you can implement to make a relay attack using SDR technology. Basically, it's a specific channel to make this relay attack. Some of the limitations, he was a private prototype and he has a special design. Let's talk a little bit about NFC emulation. NFC emulation is where you can have a NFC reader and behaves like a SmartCard or like NFC. Basically NFC has three modes, which is reader and writer, peer-to-peer communications, and emulation mode. And you can change the configuration of the reader to do different things. So the art of this part is how we can put the emulation mode in a NFC reader. In this case, it's a ACR122. Basically, you can initialize a target, this NFC reader, implementing some native commands, OAPD commands. You can see all these commands in the data sheet of this reader. But thanks to Adam Maluriyev, he created a library, which basically you have all the commands to this reader so you can put it right away into emulation mode. Also, he has a Python script to emulate something just for testing, basically. So having this idea, how we can make a replay attack? A replay attack basically is how we can block a transaction from a device to the POS or the point of cell systems or the terminal and we can intercept that token. Intercepting token is like I can have that transaction and replay it later probably two or three hours later in different locations. So I present a bug to a Google Pay. I discovered a bug about that. You can make a replay in the Google Pay this year. I basically reported it. And the answer that I got was it couldn't be fixed it because it is intent behavior of the payment system. Basically, the flexibility that we have in the system, who gets to the Boundary Laboratories that we can find in different devices. So for example, in this case, I'm going to make a replay attack. I have this Google Pay device. And I have a square device which I'm going to validate the transaction. This one is a pocket chip, which I have a ACR122, which basically is going to act a reader initially to read the transaction from Google Pay. I'm going to capture the token. And after that, I'm going to put the same reader in emulation mode. So I'm going to emulate the transaction using the square, in this case, MAPOS, to make a transaction for $1.01. And the transaction goes through. Basically this type of attack I'm using, I get the transaction and basically I convert it to magnetic stripe data transaction, putting lower the levels of security of the NFC. It could be with different kind of devices. This example was a pocket chip, but it could be an Arvino. It could be Raspberry Pi or any other devices. In this case, it's a Raspberry Pi implementing a PM532 chip, which basically is very cheap, around $15. But this is the problem that I made. It was called NF copy. Basically it's a Raspberry Pi 0, ACR122, a leap of 3.7 volts, and a booster, which basically moves the 3.8 volts to 5 volts. Some of the characteristics of this attack is that all these devices is portable. You have reader and emulator simultaneously. You have Wi-Fi connectivity, and of course it's customizable. So let's try to make a replay demo. Basically in this case, sorry, I have a Google Pay, and I'm going to use a transaction in different ATM, in this case a grocery machine. I'm going to capture the token of Google Pay, using the same technique, intercepting the transaction, lowering the security level, and the transaction, I make a payment and a terminal. This kind of transaction goes through because we are implementing a, I can say, cryptogram that is already validated before, which basically is going to go through the transaction. I call it cloud validate cryptograms. Let's talk a little bit about relay attacks. Relay attack is when you have, it's a minute in the middle, and you have two nodes, basically you need two devices, one close to the NFC device, and another one close to the MPOS or POS or terminal, which is going to make a transaction in the same time that another person is making them. If we talk about the distance between the two devices, we can increase the distance implementing SGR for example, or Wi-Fi connectivity. But many people start using SGR because you have a specific channel to make a relay attack. Some of the inconvenience of these attacks is that you have delays and timeouts and the protocol. MIVA specifies that you can make, you need to make a transaction in 500 milliseconds but that's enforcing the terminal, the POS, to finish the transactions if it takes longer, which basically I can make transactions in 4.5 seconds without any problem. That means if I'm making a relay, it could take 2 or 3 seconds to make a transaction and it's going to go through. For this, for this project, I make a project called Sentinel us, which basically is the same kind of device I use for the NFC copy, but I add a SGR transfer server, which is basically let's say CC 1101. The CC 1101 basically is a cheap device, five dollars anyway. It has different frequencies, different modulations. I'm not using that one because it's powerful. I'm using it because it's cheap. So you can try it at home. The configuration to connect to the Raspberry Pi is very straightforward. It's using the SPI protocol. But we noticed that we have many cables so we designed a small board so you can plug and play with it. Another inconvenience in the library of this CC 1101 is that you only can send 60 bytes in each packet. So for the simple, if we have a common APDU for 200 bytes, we need to make chunks of it. Basically, chunks of 60 bytes. We are in time and we're in time of this kind of attack, but because the MEB flexibility, we can make a relay attack. So basically the characteristic of this project is that we have two readers and two emulators simultaneously, Wi-Fi connectivity, customizing all the chip and we have a SGR support which basically is the CC 1101. So the demo of this attack basically, I'm using this device, MPOS, it's acting a terminal and I'm going to make a relay attack. You are going to see what is another device that I'm getting this data which basically is a smart card from Visa. Sorry, it's kind of framing a little bit. So you see it was very quickly a transmission implementing the SGR. In less than one second, you can have all the data. And we are talking about around 15 meters of distance. So basically here is another device and the smart card is under it. Another type of attack I want to talk about is how to extract data from chip and pink cards using NFC. If we think about it, we have two different Isos. We have contact and contactless, but they share the same APD layer which basically you can send comments from one technology to another and they are going to respond. It could be wrong answer or right answer, but they are going to respond. It's like when you are making a SQL injection and you got this kind of errors and you know that something is there. It's the same thing with APD use. For this project, I changed the reader. Instead of using the ACR122, I'm using a USB smart card reader. And I changed the protocol. Instead of using a block byte protocol, I'm using a byte to byte protocol. So let's play a demo to show you how this works. Basically it's a relay attack. In this place, we have the card connected to the USB. We have the SGR connection to this device and this device, the Samsung device is going to act as POS or terminal. So I'm going to run it. The MPOS is going to start sending NFC comments and you can see it's already in the chip and pink card data which could be useful to strike let's say RSA certificates, but also data like the name of the card which is user 2 and things like that. So let's talk a little bit about relay for replay attacks. Basically relay for replay attacks is how we can make a smart relays. We talk about secure elements which is one of the best secure technologies. The main point about this technology is you cannot make a replay attack. Why? Because basically when you intercept the transaction, it has a cryptogram moment which is a challenge that the terminal sends to the device and the device has to answer it correctly at the same time. So in this particular case, I'm using a Fitbit Ionic. I'm going to talk a little bit more about this. And this part where is the red tag which basically is the cryptogram section and the blue one which basically is the application transaction counter. Are there two only things that are changing in each transaction and the secure element? So the question here is, I intercept a transaction and when the terminal sending the challenge and I answer with the capture transaction, it's going to be a different cryptogram or it's not going to be the right cryptogram. So the transaction is going to be the client. But what happens if we intercept the transaction and we make a relay just using the cryptogram and the application transaction counter? So instead of making a relay with hundreds and hundreds of bytes, we just need 20 bytes which basically are the cryptogram and application transaction counter. So let's say I capture a transaction from someone using secure element and I put it in one of the devices. So let's say I have computer 1 and computer 2. When the POS asked me for the PPC, the computer is going to answer with the preview safe transaction. And after I got the challenge, the computer 1 is going to send the challenge to computer 2 and the computer 2 to the smart device and it's going to get it straightforward with the cryptogram and transmit it back to the POS. So in this case, I'm using this preview-savage data to have less time making the relay attack which basically I improve it like in three seconds. So instead of using like, let's say 3.5 seconds, I can do it in 1.5 using this technique for secure elements. So basically I have a smart watch, the Fitbit. I already have a previous safe transaction. Probably you can see in the back there which all the APDs. And I'm going to run it using a secure element of this tool. When I run it instead of sending all the data back and forward, I am just going to get the cryptogram and the application transaction counter and the transaction is approved. Because the only thing that changed in the transaction is the cryptogram and the application transaction counter. So if after all of this relay and the play attacks, you think that you can make it better, probably you can use something like this which is more interesting. And you and Twitter get close to the person and get a transaction accepted. So about new technology. We have new technology for the cards implementing NFC basically to get into the cards. And some of the boards that are implementing uses NFC. How this could affect this new technology to come. If they are not going to use a, let's say in this case encryption and the communication, we're going to have problems making relays and replay attacks. This is a protocol that board implementing the NFC 3320. We basically, they are in some cards already. So I don't have the, I didn't have the chance to test it, but I would love to do it. So new attack vectors. We can make relay with a new technology like Laura's. She's cheap. I'm very useful. In this particular case, I have a smart card. I'm using a, another device that Samsung, behaving as MPOS. And I can get the data from the card basically, using this technology. With Laura, you can cap kilometers of distance in some of the cases depending on how it's set up. Also, let's talk a little bit about how you can use NFC and web browsers, which is something that nobody talks about it. Many people start trying to work with ACR122 connecting to the computer and trying to use an library in the, in the browsers, but they have many problems to communicate it with it. I found a reason to it. I found that they have the Chrome that you can use USB and they have a specific library to do that. And in this library, they have support for Arduinos already. So what about instead of connecting directly the NFC reader, what about you connect the NFC and the Arduino and we communicate with the Arduino. Yeah, Arduino communicates with the NFC. So basically it's very straightforward technology. You can have basically terminal and the web browser and communicate with the NFC reader to put the emulation mode peer-to-peer communication or whatever. So in this case, we're going to read, we're going to emulate NFC transaction using a web browser. So in this case, I'm going to run a script using the Chrome and I can get transaction very quickly. So this is a new type of attack that you can use it in different web browser, in this case Chrome web browser. Some of the protocols that probably could implement to prevent this type of attacks is distance-bounded protocols, which is very difficult because you need to know the timing exactly when a transaction is happening. And it's very difficult if you have many different applications open already and at the same time you're making a transaction, the transaction can be delayed. So it's very difficult to do it. What we need is basically a new update of the MEV in the United States and all of America continent. But the problem is the hardware. Basically you make an update and the MEV, you need to replace all this hardware for all the stores, which basically is very difficult, very expensive. So some of the conclusion of this attack, an attacker that doesn't need a specialized sophisticated hardware or software to make problem transactions. A mobile phone can be used as simple as an effort. Also you can use a replayer to make a transaction and this flexibility that we have in the system. If the companies keep designing this product with the proper protections against the new technology that's come, there are going to be effects for many years. Please, if you have any questions, prefer to go. Sorry. It doesn't matter which car. It could be any kind of visa car, master car bridge or whatever. I'm using Wells Fargo because it's the only I have in my hand. I need a spire. So you can use it. Do you have any questions? Thank you. Thank you to be here. Appreciate it.