 Okay, should we start? Yes, okay. So welcome to my presentation about a project which I did with a few friends of mine. So this project is called NFC gate. So it's all about NFC security analysis with smartphones. And I did this presentation, for this presentation only Max and me was involved. So what we are gonna talk about, first some basics which we need later in the talk. Then some motivation, so why did we do this project? Why is it interesting? Then we look into how NFC is implemented in Android. And we also needed some patches for the Android system to do the stuff we wanted to do. And then in the end some use cases. So what can you do with our app? What is possible? What are the drawbacks and so on. So and to spice things up, we have a few demos mixed in between. So NFC in a nutshell. NFC stands for near field communication. And it basically enables communication between two devices. So it's not like wifi or something where multiple clients can connect to one access point. No, it's basically just peer to peer. And it should only work in a range between five and 10 centimeters. So sorry, no one mile point. And folks say that we got nearly two billion devices which our NFC enabled in the year 2018. So this is pretty cool stuff if you want to mess with NFC. Oh, so how does the NFC devices look like in the wild? So on the upper left corner, these are the pretty standard tags which are used for various kinds of stuff. Also right here, this is just a credit card basically which many of them are also NFC enabled right now. There are also plans to enable NFC for debit cards in this year. So you might see debit cards which are NFC enabled in the near future. And these are the terminals which you know from your supermarket or something which you can basically use your NFC enabled credit card and just put it in front of it and you can pay with them. Then there are also many hotels which use NFC basically as an access system to get into your hotel room. And then also if you have a newer passport, this logo will tell you that it is also NFC enabled. I have a demo which might work later on in the talk. And then we have some payment systems which you can see here. They are used at universities for paying stuff on your Mensa and so on. And NFC devices are also, or in general NFC is also used for basically bootstrapping. So these Bluetooth speakers use NFC to shorten up the connection setup and you just hold your phone to the speaker and your smartphone is paired with the Bluetooth system. So this is pretty neat. So let's go to our first demo. This is basically, I don't know if I should come in front or not. The video angel will hate me but I will do it anyway. So this might as well be a access system for which you can also find in a hotel room or something. So this is, for those of you who can't really see it, it's basically on door which you can use an NFC card in front of it and it opens. If you hold the wrong card in front of it, it won't open. Simple as that. But with our app, we can, maybe we can't. It's just a light phone, it should be. So basically the door is checking certain values on this card and if the values are equal with what is stored in memory, the door opens. So let's see what happens if we, meh. Is this the right, oh no, that's the wrong phone, wrong phone, wrong, this one. So we can maybe, yes, read some values and then the door also opens. So what just happened? So every NFC tag, basically, the first thing it checks is an, or basically the first thing which is checked in a communication between a reader and a card is this UID and this UID should be a unique ID. So, but as you have seen, if we are possible to clone this UID somehow, we can basically break all these systems which just rely on this UID. So it's in general a bad idea just to rely on a basic UID. So more about these NFC tags. In general, there are passive, so you don't need any battery or something. There are, so we talk about this later, they use the frequency in 13.56 megahertz and you can also store data on them apart from the UID. If we compare this with RFID, RFID is mostly read only so you basically have just an identifier, you do just identify stuff. There's no real protocol which is spoken between the reader and the tag and but it works on higher ranges. So how does this communication between a tag and the reader, so this is our tag, this in our example is our reader, how does it look like? Really simple, the reader initiates an RF field. If you read standards, the reader is also called initiator. It initiates an RF field which also contains basically the first data it wants to send to the card. The card gets powered by the RF field and can use this RF field to basically send its answer back to the reader. So pretty simple, right? So one might think if this is really this easy, this, no. So if we look into the standouts, there's all kinds of shit. So you have basically there are and the first thing there are standards which are vendor specific and there are standard standards and you also have standards depending on the layer which you are on. So for the physical characteristics, you have your own layer, standard and then it goes on and on and on. Yep, so it's basically a total mess. So why would we need, what we want to do that? Why work with all these horrible standards and do this stuff? So what I just showed you is basically the communication between the standard communication between the card and the reader. But we don't really know what's going on there, right? We can't look into this. What we want is something like this. We want to look at the communication that happens between the card and our reader. We want to look if standards are implemented correctly, if a protocol is in there, if some encryption there and so on. So you might say, so why not just use a second reader, right? So we just use one reader to establish the RF field and to the basic communication and use a second reader for sniffing. You can also do similar stuff on Wi-Fi, right? You can just put your notebook and monitor mode and sniff everything that is on the air. No, it's not that easy on NFC. The problem here is the anti-collision loop. It is part of, in most of the cases of the firmware, and it's really hard to modify this. So what is this anti-collision loop? So if you are at your Mensa, for example, and want to buy stuff at the university for lunch or something, and you want to pay on the cashier, and you don't want to put your card every time out of your bag and lay it on the device for read-it, so you just put your whole pocket out there and lay this on the reader. So what happens is the first card says, oh, yeah, there's an RF field I answered this. The second card also says, yeah, there's an RF field I answered this, and there's more and more and more. And basically your whole pocket wants to talk with the reader. This is what the anti-collision loop tries to solve. The anti-collision loop wants to establish one connection at the time and ditch everything else. So this means for our setup which we got here, if the first connection between this reader and this card would be established and we put a second reader in there, the first connection would be simply just dropped and we can't read anything. So what you can do, what can we do? You can buy cool hardware. For example, this Proxmox 3. It supports RFID tags, NFC tags, it has all kinds of fancy hardware, and but the problem is it costs around $300, but it's really cool stuff. But we thought about, can't we do it cheaper? Can't we use something which we already have? Yes, we already saw that we can use smartphones. So this was our basic idea. Android got this cool mode where you can't, not only are you able to read in text, no, you can also emulate text. So our plan was to basically have both two smartphones which one emulates a tag and one emulates the reader. And so basically when the reader wants to talk with the card, it first talks with our first smartphone, the first smartphone talks with the second smartphone, the second smartphone talks with the card and all the way back. This enables us to read the data which is exchanged between the reader and the card because we are in control of what is sent between the two smartphones. So in theory everything is nice and dandy, but this is not really the way Android intends to use NFC for you. So we need to patch a few things. So how does NFC look like in Android? So from the top to the bottom, on the top you have your NFC hardware which is from NXP or Broadcom in most of the cases. Directly under this is your NFC driver which also depends on the hardware you have and then you have some Java libraries which are provided by Google and in the end there's your app. So we need to patch these two layers. The reasons behind this I explain the next slides but for patching we use the exposed framework and the dynamic binary instrumentation toolkit. So the first patch we needed to do is for the AID routing. So the problem is that if you want to use your smartphone to emulate an card, you have to register this AID to the Android system and we don't really want that. We want all the data which comes through and which basically comes through the NFC chip. So we need to make sure that we get everything basically. The second patch concerns the UID. So if we emulate the card, we want to do it as good as possible. So we also want to emulate the UID of the other card which we basically have on the other smartphone, right? So the problem there is if you emulate a tag with Android, the default case is that it uses a random UID. So you can't change that but we found some ways via the driver to make this possible but this also require patching, as I said. So how does the system look like which we came up with? It basically looked like this. We have a server in between our two smartphones. They are connected, for example via wifi to the server. One smartphone is connected to the NFC reader. The other smartphone is connected to the tag and we are basically able to read everything which is exchanged between two smartphones. We can do this either on, we can read the data on each smartphone or on the server itself, it doesn't matter. But we also implemented this, some kind of main and the middle feature. So if you are already in charge of all the traffic which goes between the two smartphones, why not modify it, see what happens. So now the demo. What I brought with me is basically my passport and a standard NFC reader. So this is the kind of NFC reader which you can acquire from certain public agencies. You can use them to identify yourself with an NFC enabled identity card or something but what we want to do is to read out the public available data on this passport. So without having any, so it is possible to read some basic data on your passport without having any special key or something. The only thing you need is this machine readable zone data. This is kind of used as a simple password to authenticate yourself. So what I basically do is I've already have set up the server and now I need to connect, now I need to connect our app. And I hope it works, you will see. Yes. Also our server is able to support multiple sessions. This is why I need to enter a session ID. Turns out this is really annoying if you do lots of testing. So I enter the super secret token now and it works. Okay, then what is interesting for you to see I guess is the server and I also need to start somewhere, this one. So I put the smartphone on the passport and the second smartphone on the reader and it already exchanges data. So now basically instead of using NFC which is just be capable of using five to 10 centimeters we can basically extend this range arbitrarily because we just use WiFi to communicate with the smartphones. And now would be good if we could disable the stream basically because we are about to see my personal data of my passport. If it finishes in time. So the problem is that it also loads a picture of myself from this passport and this just takes ages. Yes, so this is an ugly photo of mine but it's just should show that you can basically extend the range of your NFC enabled systems with our app and you're also capable of looking into the traffic. Nice, okay, yeah. So what can we, for what purpose can we use our app? As I already said, we can look into the exchange traffic. We can try to understand the protocols which are used. So is there proper authentication available? And we also can look at if messages are authenticated or something and we also can modify traffic. So there are also some drawbacks for now. Right now our patches only work for Broadcom NFC chips. We might have an idea to change that in the future. We need some time to implement this, I guess. We also need a rooted smartphone because we use exposed which requires a rooted smartphone and for now and also relaying data between two smartphones obviously adds latency to the exchange messages and some NFC devices measure basically how much time it takes for the response to come in and if it's too high then it just drops the connection. So what we could do here is to build into a mode which you can use to communicate directly device to device without the server in the middle. So that's basically it. You can get our source code on GitHub, use this short pass NFC WTF. You can also write us an email if you're interested or talk to me right here in the next few days. And I also want to thank Max for his research on this NFC door lock. So that's it from my side. Thank you. And I guess we have some additional time for questions. Yeah, sure. Here's an update set every time we were on set up. Okay. Ah, yeah, no it's on. We had this bit that is saying is it an emulated device or is it not, it's set in the UID and that was quite near to the hardware. So we were not able to circumvent that by software. So Qualcomm doesn't do that. We can really emulate the full UID and everything. Okay, which devices use Qualcomm chipsets? For example? No, it's the question. So I know that the Nexus 4 uses Qualcomm, Nexus 5 uses Qualcomm, Nexus 6 uses NXP, Nexus 6 P uses NXP. Yeah, so all I got was the smartphones basically use NXP and Broadcom, but this would be interesting if you find some devices which use Qualcomm, no? Sure. Okay. Another question. Yes, so did you encounter any devices that you have strict requirements for the latency and which maybe use the latency for security purposes? So when I would build a product, then I could, well, I would know how along my device takes to generate a response and when I have very strict requirements about when I accept a response, I could use that as a security method to make relay attacks at least over a certain distance impossible. Yeah, you can, as an vendor, you can just do some distance bounding basically and this prevents everything we did here except for the UID cloning, but yeah. So are you aware of any device that is out there in the real world that uses something like distance bounding by timing? There is our local Mensa system, which depending on the firmware on the NFC reader uses distance bounding. Right, thanks. You had a side note regarding the UID on the slide from the emulated mobile phone, but I missed it to read it and you skipped the slide. Okay, so you want me to go back the slides? Yeah, thank you. I don't know which one you want to see, but just say stop. Okay, oh, we need... This one? No? Yes, this one. Are you able to set a specific UID or is some bit masked inside this UID? No, we can set an arbitrary UID. Okay, and all your tested devices use an Broadcom chip set? Yes, because the function which we found to set this UID wasn't a Broadcom driver. Was it required to patch the firmware of this Broadcom device? No, just a driver. Very interesting, thank you. Okay, another question here, yeah? Hi, I have a question also regarding the latency fact. In the first demo, you showed us a stored communication between the NFC tag and the mobile phone and then you replay the stored communication to the door lock. So is the limiter in this anti-collision loop for stored communication or for live traffic? The first demo was different, so I just, I didn't record anything. I just basically listened to the tag. What UID did you got? Oh, okay, this one, then I set this by myself and then this system is really basic. It just uses the UID and looks if this matches or not. Okay, then the problems to store sessions is something in the protocol of anti-collision. No, no, so what you mean, basically your question is if I can do a replay attack by replaying the whole conversation and then replay it later. This would speed up the communication and you don't have the issue with the latency. Yeah, yeah, yeah, good idea, good idea. For example, our Mensa system had a counter measure against this, so unfortunately, we couldn't do this. But in general, this is a good idea. It really depends on the NFC system which you look into. So you first have to look, is there some counter or something which gets incremented over time or something like that. Okay, if there are no more questions, I have an additional bonus demo. So one could say that for this UID cloning, this is just a research problem. You have your custom made whatever door. No, no, no, no, no. It's not just a problem which we basically invented by ourselves. So here, this is a padlock which you can buy on Amazon. It uses NFC tags for unlocking. So if you use the right tag, you can basically unlock it. And it has basically the same vulnerability as the store system. You can just clone the UID of the tag. I can also save the UID from the tag and just emulate it later, no problem. So I read the tag, and then I can also use my smartphone to unlock it. The detection rate is really shitty on this thing. Yeah, but it worked once. Just the battery empties. Yeah, and it's open. I don't know, I would be interested if skimming is possible. So if anyone knows how to do this, come to me, we will look and do this. Okay, thank you again.