NFC Relay Attacks

How big of a security issue are they really?

Dec 5, 2016 - 5 minute read

In any secure application design, there are lots of things that must be considered. For lots of NFC-based application, one of these concerns is vulnerabilities to a type of man-in-the-middle attack called a relay attack. In post, we’ll look at what a relay attack is, why they’re dangerous even with encrypted communication, and how you can reduce the odds of one impacting your system.

What is a relay attack

In the common man-in-the-middle attack, the attacker inserts themselves in between two communicating parties. When a message is sent from one party ostensibly to the other, the attacker instead receives the message, modifies it as desired, and passes it on. Mitigating the effects of this sort of attack can be quite complicated, but most advanced NFC tags support mutual-authentication schemes with fully enciphered communications, which drastically reduces the amount of information that the attacker can glean from a man-in-the-middle attack, as well as preventing modification of the messages by the attacker.

In the relay variant of man-in-the-middle attacks, the attacker does not attempt to modify the messages at all and merely passes them between the two devices. With plaintext communication, this can be very effective for extracting private information without anybody noticing, but when communication is enciphered, the attacker is very limited in what kind of data they can extract.

Why are relay attacks a problem

At first glance, relay attacks on enciphered communication might seem useless. Assuming the enciphering process is secure, the only information you can really gather is the length and timing of messages, which, in the context of NFC, are often not particularly useful for an attacker. That said, there is a class of NFC solutions for which relay attacks are a major concern - cashless payments.

In a cashless payment system, if an attacker can build a pair of devices that relay the communications between a payment terminal and a card over the air, they now have the capability to perform payments against a card that is not in their physical possession. As an example, with such a system, an attacker could have an accomplice surruptitiously hold one of the relay devices in range of somebody else’s payment card, perhaps merely by holding it near their wallet if they haven’t bought or built an RFID blocking wallet. Once this is done, the attacker could then use their relay device to purchase an item - bus fare, a beer at a festival, groceries, etc - with the charge going against the victim’s card.

How do I prevent them

Unfortunately, there’s no way to completely prevent relay attacks from happening, but there a few ways you can make successfully mounting a relay attack much harder.

Limit maximum latency

Relaying the data from one device to another will always take non-zero time, so if you are able to determine how long it should take for a tag to return a response to a command, you can then code your application reader-side to refuse to communicate with any tag that appears to be taking significantly longer than expected. This is the most common way to reduce the liklihood of relay attacks in NFC applications and, while it isn’t perfect, it can quite easily prevent long range relay attacks over high-latency mobile internet networks. Whether or not it will work to prevent relay attacks for other techniques depends entirely on how aggressively you limit latency and how fast the attacker’s devices communicate.

Limit latency variation

By introducing another communication step and two more devices into the system, the relayed data is going to be more likely to experience significant latency variation as a result of compounded small latency fluctuations at each step. If you characterize the kind of latency variation your reader experiences when communicating with the card, you can then program the reader to detect communications that exceed these levels of fluctuation and reject them.

Pay attention to the terminal

If your system is purely based on NFC cards, just paying attention as people use it should catch any attacker who hasn’t developed a miniaturized relay device, further raising the bar to successfully attack your system. Unfortunately, if your system also must support interacting with phones, this is of limited use given that a modern smartphone contains all the hardware necessary to mount a relay attack already.


As you can see, completely preventing NFC relay attacks isn’t really possible, but you can make it such that the attacker would have to have very small devices with very high performance relay connection, which will certainly make it harder for them to attack your system. Additionally, latency and latency variation will generally increase as the distance between relay devices increases, so the tighter your tolerances, the closer you force the attacker to be to the victim and the terminal, which increases the ease with which your staff can spot them - two guys on opposite sides of a large outdoor event behaving oddly are very hard to spot, but two guys behaving oddly three feet from each other in a line at a beer tent are comparatively quite easy to notice.

One thing you also may have noticed is that these anti-relay provisions should be implemented at the reader level. If your reader has to relay communications to a host device in order to proceed, it will be much harder to detect malicious relay attacks given that, in a sense, you’re relay attacking yourself. Therefore, in order to do the best possible job of preventing relay attacks, you will need a reader platform that supports application-specific firmware development, such as the TapTack Tappy line of NFC readers.

Luke Van Oort

Chief Developer, fan of immutable data structures and functional reactive programming. Guitar noodler and cycling enthusiast.

Share on: LinkedIn, Twitter, Google+