NFC technology is now just a part of everyday life. One day, you can meet it as a developer building new firmware for an NFC device that serves as a digital wallet. Get prepared for the security challenges when using NFC.
Tap-and-go operations are used so widely and the assembly of an NFC intercepting device is so simple and inexpensive, that NFC exploits are common “in the wild”.
Crypto wallets, unmanned vehicles, access control devices, FIDO2 tokens, NFC tags, or contactless payments—NFC devices are everywhere and are often used for critical actions! And in each case, there must be proper security measures based on a threat model, as the risks may vary. But as a security-aware developer, you can reduce the chances of exploits.
We’ve seen many security problems in NFC key vaults, some of them literally migrate from project to project.
⚠️ For example, developers tend to use “encrypt-then-CRC” (Cyclic Redundancy Check) or “CRC-then-encrypt”, but both those options are unsuitable because the CRC is not designed for cryptographic integrity. The CRC is computed without secret and can be easily changed.
# CRC-then-encrypt example
# NEVER USE IT
def encrypt(key, message):
iv = b'\x00' * 16
tag = crc16(message)
plaintext = tag + message
ciphertext = aes_cbc_encrypt(key, plaintext, iv)
return ciphertext
⚠️ Instead of crafting your own integrity checks, prefer AEAD encryption (like AES-GCM), and use a proper MAC, like HMAC, GMAC, or Poly1305.
And this is not a rare thing. Just check other problems NFC devices can bring: replay, passive MITM, timing attacks, encryption flaws, buffer overflow, etc.
💡 Well, so how to mitigate the NFC security risks? First, consider proper threat modelling and suitable secure architecture. Then implement proper security controls. Talk to cryptographers if your system involves encryption (as it should!). And, for sure, do not ignore testing, auditing, and reacting on incident stages.
Click on the image to read in-depth:
Follow us on Twitter for more.
Top comments (0)