The USRP from Ettus Research is an awesome tool for radio analysis. It’s a really complex tool that is capable of doing almost anything involving radio signals (see these two previous Insight posts by Corey and myself, and Raj). That doesn’t even scratch the surface, though. This post will go into the detailed hardware setup for investigating NFC over the air communication using the USRP.
For the RFnoID project, a group of us temporarily turned into nocturnal, lab-dwelling creatures to get this set up. Full credit for this post goes to my group members: Rob Lee-Own, Scott Velivis, and Vincent Lin.
Step 1: Obtain USRP. Ettus Research has several models. For the RFnoID project, we used the plain ol’ black USRP1. At Intrepidus Group, we have the USRP N210. An enormous, frustrating, caveat to the USRP will be mentioned later, but for now, keep this in mind: The USRP1 uses USB, while the N210 uses Gigabit Ethernet to communicate with the computer. Select with care!
Step 2: Select your daughter boards. The USRP requires RFID works in three frequencies: 125 KHz, 13.56 MHz, and 900 MHz. We’re going to be focusing on ISO14443-A, which operates at 13.56 MHz. For the rest of this article, NFC refers to the 13.56 MHz band. We’ll need one daughter board for receiving, and one for transmitting. The low frequency transmit and receive daughterboards (LFTX and LFRX) should fit the bill for 13.56 MHz RF communication at DC to 30 MHz.
Step 3: Select your antennae! This part took trial and error, including some home brew (courtesy of Scott and Rob):
We ended up going with two of the DLP-RFID-ANT from Digi-Key at $40.
Here’s the tl;dr so far:
- USRP @ $1700 (USRP N210) or $700 (USRP 1)
- LFTX, LFRX @ $75 each
- 2x DLP-RFID-ANT @ $40 each
At this point, you should be able to hook it all up, set up GNU radio on your computer, plug in the USRP, and capture NFC goodness right out of the air. Wahoo!
In this video, we’re issuing a read command using libnfc in the left terminal, and detecting NFC energy using the USRP in the right terminal.
Still with me? Good. Here’s where we started spending long nights in the lab banging our heads against the desk. First, a little background on the software/protocol: NFC at its most basic level follows the ISO 14443-4 “Transmission protocol” specification. You can purchase that from ISO for 136 CHF. Google tells me that’s about $150 in real money. The real gem to pull out of those endless pages is that 0×52 is the WUP (wakeup) command, and it will wake up all tags in the area. 0×26 does something similar. In short, we used some hack-y Python to convert hex numbers into a wave format the USRP could understand and transmit. Code here. Feel free to use that code, but please credit RFnoID if you do find it useful. The USRP will modulate this wave at the carrier frequency. You do not need to do that part. You can set up the USRP to use that .wav file using:
from gnuradio import gr
gr.wavfile_source(“wave52.wav”, True)
We’ll get more into the software behind this in Part 2. Back to the hardware. Here’s what we were trying to get:
Notice that wave is 5.5V peak-to-peak. The NFC tag gets its energy from the RF signal the reader (or, in this case, the USRP) transmits. That’s the energy required to wake up and power an NFC tag.
When we transmitted, the tag simply wasn’t responding. Looking at our signal using the oscilloscope, we found that our signal was roughly .5V peak-to-peak. We required an amplifier to boost the signal to the 5.5V level and, luckily, found one in the lab. The amp doesn’t have to be this fancy, but needs to be SMA-in, SMA-out. We’re still searching for a cheaper amplifier that meets our criteria. Luckily Scott understands antennas much better than I do and says: “the 13.56mhz band is so narrow that even a very non-linear amp would look linear for a ~200khz bandwidth.” We’ll keep this post updated if we find something cheap that fits our criteria.
The second major issue we encountered came when we tried to do 2 things: first, detect energy in the NFC band; and second, send a blocking signal (0×52 works well for this purpose because it re-starts the tag’s initialization and anti-collision routine). We were using a USRP1. Remember we mentioned before that the USRP1 connects to the computer using USB. We were getting a large delay (~300 microseconds) we believe was coming from the USB stack (in the Linux kernel) buffering before sending a complete frame, causing a delay in detecting the RF energy. In theory, the USRP N210, which connects via Gigabit Ethernet, would not have this issue and could send frames as soon as they were received from the USRP.
More on the software (GNU radio and the scripts we used) in Part 2!
-Max