 to attack NFC platforms using quite basic components. So what is NFC? Mainly it's to do with opening doors or paying for things or accessing the underground train system. And it's basically one card being spoken to by a reader that illuminates it with a field using induction and communicates with it. Why would we attack NFC? Well, as I said before, it's used in payment systems, door access control systems, and metro lines. And it can be found anywhere. And it's a type of protocol that is quite insecure, with most of the security relying on very weak encryption, or the fact that there is a very, very low range for the tags and the readers. So as I said before, we're going to talk about the protocols involved and how you build tools to work with them. And from there, we're going to talk about the main standard which is used, which is ISO14443. Now, this is the 13.56 megahertz protocol, which is for my fair classic cards and ultralight cards, which are generally used for hotel room keys or door controls. It defines characteristics as ISO14443A, which is the most common, and 4443B, which is slightly less used. From there, we're going to build a tool that will analyse and emulate a my fair classic tag using these protocols. So low-level communication wise, tags are powered by an electromagnetic inductor from the reader, which basically powers it through the inductors so that the card can communicate back and forth using that power to communicate via drawing load from the reader. The reader uses a modified miller encoding. This is a kind of encoding which basically has a large amount of space between bits so that there's not too much power loss or glitching due to communication being involved. And responses are sent by Manchester Coding, which is a radio encoding scheme which is basically for keeping track of data quite simply and with a high level of timing issues. So modified miller, as I said before, it's basically disabling the field at certain intervals, making sure that the tag has enough power to still run, but to also receive data. So it's defined as 0 bit being a low transition flowed by high for the rest of the transmission, a 0 bit after 1 being high for the entire transmission, and a 1 bit just being high for the first half of the transmission, a small dip, and then back up again. And this is completely designed so that there is never a really small gap between power losses and that the communication works well. Manchester Coding is performed by modifying the phase of a signal using a subcarrier. This is done by basically drawing load from the reader so that it can analyze that to see what the tag is saying. And this is done so that there doesn't need to be some kind of proper two-way communication. So how basic enumeration works is the reader always starts off the transaction and the tag always responds. So it usually starts off with the reader, giving a request or a wake up command, which the tag then responds with a response defining the basics of what the tag does. The reader then tries to select a tag by requesting any tags in the field to send a unique identifying number. Now this can be four bytes, seven bytes, or nine bytes. And then the reader can then select using that ID. And the end of that transaction is the tag sending the SAK response, which is the very specific definition of what kind of tag it is. From there, the reader can then try and authenticate or communicate with the tag in a way that it's meant to. There is an extra section, which is called anti-collision. This is performed when there's more than one tag on a reader at the same time, and they haven't yet enumerated properly. It involves the requesting responses based on partial UIDs. So when the reader sends a request for all the UIDs in the field, it will often get garbled communication back because the communication being sent is from two tags at the same time. So what it does is it tries to differentiate between the two using small amounts of the unique identifiers that are used. Increasing number of bits as it goes along will mean it eventually finds a set of unique identifier bits that do not match on both tags. And then it can select that unique identifier and then go through to the next one. So we're going to talk about a few different kinds of tags there are. So the first one is my for all flight, which is the most simple errors. So that uses an authentication key, which just sends the tag in the plane. Usually there are other ways it can be done, but this is the most basic way. If the key is accurate, the reader has authenticated and then send communication, which isn't encrypted, and all the communication can be performed. If it's wrong, then usually the tag will log the field communication and lock after a while so that that tag can never be used again. It can also be set up to use no authentication, which is quite insecure. It has support for a few different other authentication techniques, especially in newer versions, such as my for all flight C, but usually these aren't used and more complex and secure methods are used at that point. There's my fair classic, which is probably the most common you'll see anywhere in the world. So this is used everywhere, and it is one of the most insecure protocols there are, and yet it's still used everywhere. So it utilises the crypto one algorithm, which is known to be broken in a huge number of ways. Basically the reader requests authentication for a sector of the tag. The tag responds to the unique four byte value. The reader responds with a random value followed by a value generated by the original random value sent by the tag, which is then encrypted. And the tag responds with an encrypted number generated from that value. All for the communication is then encrypted using this algorithm from that authentication. Each sector of the tag can have two keys, and they can be completely unique to that section of the tag. Then finally, there's my fair defyre, which is interesting because it is not broken yet in any reasonable manner. So it's based on different application IDs, and it can authenticate based on DES, triple DES, and AES, depending on how it's set up. Multiple keys can be used for authentication, and it can be authenticated. The authentication works similarly to my fair classic. The reason it's not been broken in the same way is due to the fact that my fair classic's weaknesses lie in encryption used. And as my fair defyre is using slightly more complex encryption, it's more secure against these attacks. So first we're going to talk about creating analysis tools for hacking NFC. So usually when you think of these things, you think of like the Proxmark, or maybe more complex tools like the USRP. And I decide to try and make tools out of the most basic components I could find. So anything that I could get as raw components or as a very small tool. So this is a list of some of the existing tools. So you have the Proxmark and the Comedian Mini, which are the most well-known and the most commonly used for actual engagements and tests. The Proxmark 3 being able to be a reader, a tag, or just passively significant communication. There is HydroNFC, SimpleNFC, and EMU tag, which are more hobbyist level projects and are very interesting in their own way because they can perform communication with small tools, especially the same as some of the tools I've created today are. So firstly, how do you detect an NFC field when you can detect it with just an LED in a coil of wire? If you put that circuit as small as it is into an NFC field, that LED will light up and tell you when communication is occurring. It's very useful for detecting whether the field is active. But apart from that, it's just interesting to see how simply it can work. The first thing I wanted to do, though, was create a passive sniffing tool. So basically, so I could see the communication between a reader and a tag and view how the communication goes on and see where the attacks can lie. So I use an RTL-SDR, which is the most basic and most cheap SDR tool you can buy. It can tune between 25 MHz and 1700 MHz. It's got quite a strong sample rate that can be configured quite well. And there's a huge number of libraries that can work with it. There are a few problems for what we were doing, though, as it couldn't tune all the way down to 13.56 MHz without some hardware modifications. And the low sample rates are used by the communication between a tag and a reader. It was just too high for, so I'd have to find a way around that. It's also bundled with some weak hardware, including the weak antenna. And it's not really built for a specific purpose, which is the main problem with software-defined radios. So I managed to get past most of these limitations by using little tricks with no hardware modifications necessary. So firstly, in order to read the communication from a reader, I tuned up to 27.12 MHz, which is the harmonic frequency of 13.56 MHz. Due to the fact that there's a huge amount of raw power going through a reader to communicate with a tag, it's possible to pick up all the harmonic frequencies and all the noise coming and use that to get the signal and the definition as it's going through. I could synchronize with the sample rate twice what it needs to be. So I sent it to 1.695 MHz, which is double the 847.5 kHz required for communication. Antenna modifications were required as I took that first circuit, the LED in the coil, and put it around the antenna that came with it. And due to the fact that when a reader detects any tags in the field, it ramps up the power being used, I managed to pick up the signal from that. As there was a constant signal, I could also use automatic gain control, which meant it could be very easy to analyze as things were going on. I managed to get real-time analysis of communication from a reader to a tag, but not the other way round. Due to the fact that I was using a harmonic frequency, it wasn't possible to get it the other way round. So here's a dump of the output as it came from the reader. So firstly, start with the wake-up command to basically say any tags that haven't been spoken to yet. Yeah, please talk to me. A selection because it already knew the tag that was in place and a hold command saying it doesn't want to communicate anymore. And then another request in order to see if that any other tags on the reader and a wake-up to speak to the tag it had already spoken to again. From here, I wanted to build a myfair classic tag from scratch in a way where I could do completely raw communication with it and modify any parts of the protocol I needed to. So I wanted to do it without any abstract hardware whatsoever. No NFC chipsets, I just wanted to use a microcontroller and any hardware I could make. I wanted to use minimal components and cheap components so that I can make it really reproducible. And also because if I take that concept and make it really simple, I can then add complex features to it later. It would require me to implant the crypto one authentication in a way which is usable and add complexity to the project when it's going on. By fully implementing this protocol, though, I'll be able to find weaknesses in it and also create tools to attack them. So I needed the inductive coupling, exactly the same as the LED in the coil or anything else. This signal would need to be demodulated by amplitude. This would not be possible on the microcontroller, so it would need to be done in hardware. And I would need a microcontroller which was fast enough and powerful enough to run at 13.56 megahertz accurately. This would also require complex encryption calculations which would need to be done sufficiently quickly and it would need enough memory to do them as well. So let's start with the circuit. So I started with an LC circuit. This is just an inductor and a capacitor together which is used to tune to the reader's inductive coupling. I could just test with a big coil of wire and multiple different capacitors until in a logic analyzer I got a frequency that matched digitally. Due to the amount of power being put through, it's possible just to check if the logic analyzer rather than a scope or anything more complex. I then added an envelope detector which can be made from a diode resistering capacitor. Now this is used commonly for decoding AM radio signals, especially when they're using binary and amplitude shift keying. And it literally works by rectifying the signal and then smoothing it until you get the exact signal that was actually being modulated rather than the original version. The values can be guessed by trial and error and I got it to a 1k resister and a 220u picoferic capacitor. All I need to do was create this circuit and again run it through a logic analyzer and if I got the modified miller communication which I did see as shown there, I would be able to work with it. This is the final circuit that was required and all that needed to happen was one of those pins would go to ground and the other would go to an input pin which could then allow me to receive on a microcontroller. I decided to go for the 80-84 microcontroller because it's extremely simple, extremely cheap and it's quite easy to work with from a programming perspective. It has 8k of RAM and 512 bytes of RAM, 8k of flash. It can be programmed using an Arduino or a dedicated programmer and it can use external crystals really well to do tuning to a correct frequency. So I've put a 13.56 MHz crystal there. The dip package means it'd be really easy to build from a hobbyist perspective and it'd be done on a breadboard or anything and it would be nice to, it's very easy to work with the GPIOs on it. It does have good support for interrupts and timers which came to be very important later but very bad support for the debugging. Also the 8-bit architecture on it meant that it was very bad for doing encryption calculations. I added the 13.56 MHz crystal which meant it ran in sync with the reader. I added the receiving circuit just to one pin which received the data and then tied another pin to it to send data back using pulse with modulation, basically creating load on that pin as it's receiving in order to get the data back. Due to UART on it, which is the usual thing you'd use for debugging on this particular platform, not being feasible as the clock was non-standard, I basically dumped out debug strings to debug data via a software-based SPI just to another dev board so that I could analyse the data. I added an LED which was attached to confirm the device is working and I basically set up the state machine as you would see it on an appropriate My Fair Classic tag, so sending responses for selection, authentication when it is meant to be done. There are a few timing issues that came across. The first thing I did when I was running this was basically trying to receive data at a rate of 847.5 kHz. Now, this should have allowed me to receive the modified miller data that's going along at predefined intervals, but due to the fact that it had a huge amount of clock drift due to heat, time and power issues, it meant that the thing would get out of sync very quickly and I'd only receive about 50% of the transmission. Instead, what I did was basically check the difference in time between each drop in the signal and use that to receive the data and that gave me a very high accuracy enough to make the tag behave appropriately. I then had to implement Crypto1 and this is a very well-documented library, despite the fact that people don't want you to know about it. The main library that's used is called Crypto1, which is a great way of saying that it's a terrible encryption library and there's a huge amount of papers about how it works. It's found to be based on 48-bit keys that are basically split into 24-bit keys and just a swap between during authentication and due to the amount of bit shifts and calculations involved, the 8-bit microcontroller will just have a few problems with it. A main one being that the bit shifts on the AVR microcontrolls, the 80 tinies, are how to be done one at a time, meaning if you want to do a 16-bit shift, that's 16 operations or sometimes if it's optimized a lot quicker. The main culprit for this issue was the filter function, which is used to generate the encrypted bits as it went along. This is the main filter function and as you can see, there's a lot of bit shifts, a lot of large numbers that are larger than 8-bit and a lot of other calculations. So we had these bit shifts, which would need to be converted into much more efficient bit shifts. We had these 20-bit values, which are being calculated in C as 32-bit values, but could be calculated as 20-bit if we did it in assembly. And we had one 32-bit value which had a few complications. What I ended up doing was taking all the crypto-1 codes and converting it to AVR assembly in order to optimize it. So I wrote from scratch all these filter functions and calculations in order to find the efficiency where I could. I used the CIM AVR emulator because it's much easier to debug and put it right against the main crypto-1 authentication and basically the unit test to check that they were putting out the same data. All the calculations could be sped up, the most complex of which being the bit shifts, which I could do by basically modifying how it performed though. So if a 16-bit shifts dropping the data down, eight-bit shifts dropping it down slightly less, four-bit shifts swapping the upper and lower nibbles of the data and then just doing standard bit shifts when it was necessary. This made the thing about 10 times faster, meaning that it could now behave as a proper MyFair Classic tag with any reader. This is the horrendous assembly that was used. It's very quick, but not very well-written. And this is the final product. Now, as you can see, it's a very, very simple circuit. The lower one is everything you need to emulate a MyFair Classic tag on this platform and do it in raw in a way which will allow you to perform attacks on it or modify the authentication. If we could play demo one now, that would be excellent, please. I found that that reader that I was using after I bought it from Taobao was also used in Beijing Airport, which was very exciting to take through customs. But it was... It did get through. As said before, there were hardware limitations due to the fact that it was 8K of flash and 512 bytes of RAM. There wasn't enough room left to do anything more complex with the authentication encryption or assessment. I couldn't add extra tooling to it, and just due to the fact that the hardware was not up to scratch, I decided to make something a bit more complex in order to make a proper analysis tool. Due to the fact that it had really slow responses, there were some readers which weren't compatible, but I found that these readers often weren't compatible with their Proxmarks or Comedian menus either. So I decided to build a bigger and better device using an STM32 microcontroller. Now, these can be bought very cheaply in development boards, have great support for debugging and huge amounts of memory to work with. The one I used was the STM32L496, which has one megabyte of flash and 320 kilobytes of RAM, which is 640 times more than the 80 tiny. The clock speed could go up to 80 MHz, but it could also change to 72 MHz, which became very important later. Also, the fact that it was using a 32-bit architecture and it was ARM meant that encryption calculations were much, much easier to work with. It also has a large number of useful peripherals, including USB and UART, meaning it was easier to basically dump data out of it as it was going on. I set it up using the STM32Q, which is a very useful tool that basically gets you use hardware extraction to set things up, and then I could just copy a lot of the core code from the 80 tiny version into it, apart from the data for sending responses and receiving data from the reader. There were going to be synchronization issues, though, because it couldn't tune to the specific clock rate that it needed to, the 13.56 MHz. The internal clock of the chip is quite configurable and can go from a huge number of frequencies due to the fact that the STM32Q will take a value you give it and work out exactly what it needs to do to get the clock that fast. This could have caused problems with transmitting data, but not receiving it, because the spaces in time between each signal would still be fairly slow and allow you to pick up the differences between them. I didn't want to use an external crystal because it would add complexity to the board, and on a development board, this can also cause a few problems. Without an accurate clock, though, we could do much work with it, so I had to find a way to get in sync with it. What I ended up doing was finding every frequency that was within about 10% accuracy against 13.56 MHz in order to find one which could then be within range for the Manchester Coding to still work. And I basically processed through these frequencies and found that 72 MHz was the fastest and most efficient frequency that could be used for this. This is the same circuit as before, just built onto the development board, so it's got a big coil of wire, the tuned LC circuit, and the envelope detector just attached to two pins on the ground, and that's all you need to emulate a my fair classic tag in hardware. Because it was so efficient so fast and it had so much flash and RAM available, I could implement a huge number of new features. So the first one I did was implement support for multiple tags. So this would mean if you had a reader that could support multiple tags, you could make it pretend to be one, two, three, or more different kinds of tags. These multiple requests can be used to cause exploits or just for making things more efficient when you're working with them. All I need to do is set up the same state machines over and over again and make it process through them as data is going through. I could add dynamic key generation so I could make the UIDs which are completely randomized on my device, generate correct keys for the different readers. So if you can generate a huge number of different UIDs, you can get all the different keys that can be made using crypto attacks and then work with those to try and reverse engineer how those keys are generated. I started implementing Desfire. Now Desfire, the only place that I've seen it used is back in England where it's used for Easter cards in London. It's an incredibly powerful protocol with very strong encryption but it's also not been implemented very often in other devices just because it is highly complex. So what I ended up doing was taking my phone which has a tool for doing my fair Desfire, taped it to the tag that I've made and then went through the different communications sending responses appropriately as he went along and from there I could build up to the point of doing authentication which works similarly to how it works in my fair classic but with much more robust and strong encryption. There it is just attached to the tag and that's all I needed to communicate with it. So let's talk about some security weaknesses in NFC now now that we've built the appropriate tools for it. So crypto one, as I've said before, is very, very weak. The most common attacks were shown in dismantling my fair classic, a very old paper which basically went through every single weakness possible from the tag side, reader side, et cetera. These included the fact that it uses a 48 bits key split into two which can then be processed separately. Authentication is vulnerable to replay attacks because of the weak random number generated on the tag. The nonces can be used to recover a key stream which can then be used on brute force attacks and it can be rolled back to the start of the authentication in order to get the original keys. So in order to do this, what you need to do is start authentication with my tag or any other one or a Proxmark until the point where the reader has sent back the eight bit response from the original nonce. This response contains the random values and the ones generated from the tag and this can be used to be exored with the original nonce because it's a deterministic value in order to generate 32 bits of key stream. Basically then you can separate those 232 bits of key stream into 16 bits of key stream which can then be handled separately. So what you would do is take one of the keys and process through 16 of those bits and find every single value out of the 24 bits that matches that key stream and then do it for the other 16 bits as well. In one way, so going from the first bit of the key stream to the end, this would create 200,000 values from the original 16 million. If you did it backwards, you'd get 30,000 different keys for both the 24 bits of encryption which can then be used to work together. These matching key pairs then can be processed together just via brute force very quickly and you can end up cracking the keys in about 10 minutes with this process. So that's the authentication request. That's the nonce response from the tag. That's the random value and that is the encrypted value generated from that original value. This can be used to perform offline cracking. You just need two reads from a tag and nothing else and it can be used much more efficiently than reader-based attacks when it comes to a tag. So rather than trying to pickpocket someone to do attacks on the tag, you could just walk up to the reader and do it and because it's using offline cracking, you just go home and wait for the keys to be cracked. This functionality is available on other devices but it's never used because it's very, very inefficient to work with. It's just not very practical. So I decided to implement this attack taking a Japanese video game which has a USB reader NFC reader on it and basically has no research whatsoever so far so I wouldn't be able to just guess the keys in order to perform this attack. I'd have to use this process in order to authenticate with them. So I worked out the USB protocol just by using a Beaglebone Black and the USB proxy tool to man in the middle of the communication and then made it just dump the tag UIDs and request data which would then create authentication. The reader was found to be compatible with the Proxmark, wasn't found to be compatible with the Proxmark just because the speed of the response is expecting from the reader to the tag and the amount that's going on on that device. So there's the tag. Just attach the reader and if we could do demo number two now please. So it just placed it on the reader and it just generates these authentication tokens. And that's the UID and it's just sending authentication data which can then be processed later. I basically dumped these out so via UART on the device and then put it through a program on my laptop which just ran through the keys and generated the keys from them. And as you can see it was done in 10 minutes and this was very consistent as I processed through different types of keys and different UIDs. Some improvements that could have been made to crypto one is first to increase the key size to something much larger. This would have some problems with obviously efficiency when it came to the tags because there's not a lot of complex circuitry in there for doing encryption but would have made it more secure. Even up to 64 bits would have made it a huge amount more secure. Users of a single large key that was processed through would be much better than just having two keys that are processed together because there wouldn't be that separation that could be used for the attack and an improved random number generator would be just so much better for this. And as this weakness was because of known plain text attacks it was just much better. So let's talk about some raw protocol weaknesses. Now this is very important because most other attack tools aside from the more complex ones and more expensive ones like the Proxima, the Communion Mini et cetera require complex NFC based chipsets which means it can't go down to the raw communication level in order to perform attacks. This means that these attacks usually you feed it a UID and it handles all the communication for you apart from some of the authentication. As I could change any part of the communication by doing this raw communication I could do anything I wanted to it. The greatest weakness I found was denial of service using the anti-collision procedures which happened at the initial enumeration. So here's a quote from the Texas Instruments documentation on this. So, due to the recursive nature of the anti-collision algorithm there is a risk of a stack overflow. I found this to be very true and on a huge number of readers and what people generally do is just never implement this anti-collision feature because of it. But when do they do if they often get it wrong? So every time the reader sent a request to my tag I would send completely messy responses back that looked like there were two tags on the reader sending a response. I constantly did this despite it trying to request more and more bits and the tag did never limit it how much data was being sent back. So the reader would then basically constantly try and find the unique UID. Even past the maximum size a UID can be on the reader. This weakness is known about but it's really not found anywhere because no one really implemented this feature but it can be used to crash readers when you use it. There's a few high-level protocol weaknesses for instance each tag type uses things called endef data or block data or et cetera which has different sizes and different methods for communicating and each of these have weaknesses in the buffers and size just from how they work. The authenticator mechanisms often have weaknesses as demonstrated before in the My Fair Classic tag but it's extremely easy to identify them in other things as well. Weaknesses in things like the My Fair Ultralight where it just sends a plain text key is obviously very simple to sniff. The reason that Dezfire et cetera is much more secure is because it's using authentication which just doesn't have these weaknesses in it. I decided to compile all this research up into one tool for proper testing purposes and I decided to take everything that I learned everything I'd built and put it inside a toy sonic screwdriver and basically take all the tools and exploits and put them one by one in a device so I can click through them at will in order to do different attacks. The first one would be fuzzing. Second, it transmits the authentication data via RF. Yeah, can we play demonstration in the video three please? So what that was doing is basically randomising its unique identifiers and as it was processing through them, essentially sending that data via RF to my computer via an RTL-SDR. So what it basically has is an ASK transmitter as shown in the pictures which is what you generally use for opening a garage door but it's very useful for communicating small amounts of data in a project and I could then use that to crack that data offline remotely. Can we play demonstration four just to demonstrate that please? So yeah, literally just sending data to my computer via the RTL-SDR again which was very simple. This tool came to be very useful and I'm still adding features to it but I think after a while it'll be quite useful. I think I'm going to put it in a different case but I definitely think it's got some merit. So what I'm going to be doing now is basically releasing all the source code, all the designs and everything so you can look through them and see what you want to about them. The most important of these would be the SDM30 tool tools which have the most credibility for future work as it's very powerful and can be used for a lot of different things. I'm going to set up the boards to be a bit more complex and a little bit more tolerant of errors and that sort of thing and I'm going to start implementing DESFIRE properly. So if we can implement this entire protocol and feature then the weaknesses can be identified in it much better and we'll be able to find exploits and weaknesses in the encryption which can then be further used in order to perform a tax on it. There's my GitHub if you want to go look for the code and thank you very much.