The ABCs of NFC chip security

tl;dr

NFC tags are becoming increasingly more common in everyday use cases such as: 

• Public spaces like museums, art galleries or even retail stores in order to provide additional information about an item or product. 
• Inventory management sites use NFC tags on product packaging to update information on its contents. 
• Industrial facilities can use NFC for sharing initial secrets needed for device or service provisioning scenarios and also to deploy configuration data in operational mode (e.g. Amazon Monitron). 
• Numerous other use cases such as factory and home automation, industrial and street lighting, security systems, metering, healthcare, and wellness. Some real-life examples are the IRISS E Sentry Connect used to track electrical equipment inspection and maintenance history, McLear RingPay used for contactless payments, or the Oura ring used for healthcare and wellness tracking. 

When looking into guidance on securely configuring NFC tags, a well-documented resource detailing how to securely configure a specific NFC tag chip was not readily available. The only available solution was to search every manufacturer’s datasheet and documentation in order to identify the security-related information. NCC Group aims to solve this documentation deficiency in this blog post by presenting an overview of security features that are available in the most common NFC tag models on the market, and to provide a side-by-side comparison. 

NFC Tag Standards and Specifications

The NFC technology stack is rather complex, as there are several available standards and specifications that define NFC tag feature support. Generally, security features in NFC chips will correlate to commands that are supported by each chip.  

The following table maps the features provided by each standard to the NFC protocol stack, which illustrates the complexity of the NFC ecosystem.  

The complexity of the NFC ecosystem is illustrated by the previous chart. Perhaps the most surprising thing about the diagram above is not even that different standards exist at different layers of the NFC stack, but that even at a given layer of the stack, there are multiple competing standards which often fail to align. This complex ecosystem has resulted in inconsistencies in users’ security expectations – and security engineering methodologies – when deploying NFC.  
 
For example, above, the ISO International standards are mainly involved in defining the specifications at the physical and RF layers, but as we go up in the protocol stack, we encounter the different manufacturer contributions. For example, the ST25TA64K chip supports three command families:  

• The NFC Forum Type 4 Tag command set 
• The ISO/IEC 7816-4 command set 
• The ST proprietary command set 

Further illustrating the degree of complexity, in order to enable the Read Only permanent state for an NDEF file in this same ST chip, commands from all three supported families are required. The following RF commands need to be used, in this precise order: 

1. NDEF Tag Application Select (NFC Forum Type 4 Tag command set) 

2. NDEF select File: Selects the NDEF file (NFC Forum Type 4 Tag command set) 

3. Verify command: Checks the right access of a NDEF file or sends a password (ISO/IEC 7816-4 command set) 

4. NDEF select File: Selects the NDEF file (NFC Forum Type 4 Tag command set) 

5. EnablePermanentState command: Enables the Read Only or Write Only security state(ST proprietary command set) 

From this we can see that it is clear that there are several standards defining the NFC protocol stack, and so any tool looking to provide support for configuring NFC tag security features will need to support more than one standard. This is one of the primary reasons why tooling support and security best practice documentation in the NFC ecosystem is woefully lacking. 

Available Security Options

To illustrate an important concept within NFC security – namely, that of “user” and “system” specific memory protections, we share an example in the following image which describes the block architecture of the ST25TA64K tag from NXP. Note below the presence of both User and System memory areas, which exist within different regions of a 64-Kbit EEPROM internal to the NFC chip. 

The NFC specification defines important security features for these two memory areas. For each chip surveyed, two main types of security features were observed:  

• User memory protection: User memory is where customer data, such as NDEF records (https://w3c.github.io/web-nfc/#dfn-ndef-record), would be stored. The NFC Data Exchange Format (NDEF) is a data format that can be used to exchange information (NDEF records) between any compatible NFC device and another NFC device or tag.  
• System configuration protection: This is where system configuration data would be stored, such as the passwords used for user memory area protection.  

User memory and system configuration are generally stored in different memory areas within the NFC chip, and are accessed via different commands. For both user memory and system configuration protection, the following configuration parameters are available: 

• Read Protection (RDP): Protection via a password for read operations. 
• Write Protection (WDP): Protection via a password for write operations. 
• Permanent Lock: Prevent the contents from modifications (Write operations). 

The implementation of these protections, as well as additional protections some chips might offer are compiled in the following section. 

Comparison

The tags used for this comparison were chosen by public availability and features offered and are listed hereafter. The astute reader will notice some duplication below, and that is due to the fact that some vendors sell NFC tags that use another vendor’s NFC chip. 

• STMicroelectronics ST25TA02K 
• STMicroelectronics ST25TA64K 
• STMicroelectronics ST25DV Series 
• Adafruit 4032 (NXP NTAG213) 
• Adafruit 4033 (NXP NTAG213) 
• Adafruit 4034 (NXP NTAG213) 
• DFRobot FIT0313 (NXP NXPS50) 
• Murata Electronics LXMS33HCNG-134 (NXP ICODE SLIX) 
• Avery Dennison RFID 600560 (NXP UCODE 7) 
• Avery Dennison RFID 600600 (Impinj Monza R6) 
• SparkFun Electronics WRL-14151 (EPCglobal Gen2) 
• Abracon LLC ART915X250903AM-IC (Alien H3 RFID) 

Understanding the security impact of NFC chips’ range frequency

NFC solutions have evolved with time to support higher RF frequencies, and as a consequence they can be interacted with from longer distances, including by attackers. The advertised ranges for UHF chips are close to early Bluetooth ranges and would no longer even require an attacker to physically tap the tag. Additionally, the advertised applications have been expanding more and more and entering safety critical areas, such as within the , oil and gas industry, as well as military devices and vehicles. It is thus important to know how to choose the appropriate chips for a given use case, and how to configure them securely. 

Understanding the security impact of NFC chips’ memory protections

For a strong security posture, it is important for the chosen chip to support as many protections as possible. Having these protections enabled by default even with easily guessable passwords may protect the contents of the chip from some opportunistic threat actors, improving the security stance. However, this will not provide any protection against any sort of more persistent or even mildly sophisticated attack. It is thus important to include enabling the security protections and configuring secure passwords in the NFC chip configuration process before they are deployed in the wild. Depending on the chip and management needs, it can be permanently locked to prevent write actions from RF, if there is a secondary channel to perform this action, such as I2C (e.g. ST25DV) or if the contents are never expected to change. 

In the following table we enumerate all of the surveyed NFC chips and whether read (RDP) and write (WDP) user memory protections are available, as well as the default chip configuration was to enable or disable RDP and WDP, and whether the chips support Permanent Lock functionality. Although some chips had detailed publicly available documentation, for other chips the data sheets and reference manuals were only available under NDA. All chips have public documentation of their security features, except for Alien H3, which required an NDA and the NXPS50 and Sparkfun EPCglobal, which list the security features but don’t document their default configuration. For those chips whose documentation was locked behind an NDA, we have filled in their corresponding values as “Unknown”. Only publicly available information has been used in this post, no information requiring an NDA. 

Chip	RDP/ Default	WDP/ Default	RDP Default PWD	WDP Default PWD	Perm. Lock/ Default
ST25TA02K	Y / N	Y / N	0x00 (128-bit)	0x00 (128-bit)	Y / N
ST25TA64K	Y / N	Y / N	0x00 (128-bit)	0x00 (128-bit)	Y / N
ST25DV Series	Y / N	Y / N	0x00 (64-bit)	0x00 (64-bit)	Y / N1
NXP NTAG213	Y / N	Y / N	PWD: 0xFF (32-bit)	PWD: 0xFF (32-bit)	Y / N 2 3
NXPS50	Y / Unknown	Y /  Unknown	Unknown	Unknown	Unknown
NXP ICODE SLIX	N	Y / N	N	0x00 (32-bit)	Y / N
NXP UCODE 74	Y / Y	Y / Y	0x00 (32-bit) 5	0x00 (32-bit) 5	Y / N
Impinj Monza R64 6	N	N	0x00 (32-bit)	0x00 (32-bit)	Y / N
EPCglobal Gen2	Y /  Unknown	Y /  Unknown	Unknown	Unknown	Unknown
Alien H3 RFID	Y / Unknown	Y / Unknown	Unknown	Unknown	Y / Unknown

The following table documents whether read (RDP) and write (WDP) system configuration protection is available for each of the reviewed chips, as well as the default configuration and whether they support Permanent Lock capabilities. 

Chip	RDP/ Default	WDP/ Default	RDP Default PWD	WDP Default PWD	Perm. Lock/ Default
ST25TA02K	N / N	N / N	Not Applicable	Not Applicable	Partial/N 11
ST25TA64K	N / N	N / N	Not Applicable	Not Applicable	Partial/N 11
ST25DV Series	Y / N	Y / N	0x00 (64-bit)	0x00 (64-bit)	Y / N1
NXP NTAG213	Y / N	Y / N	PWD: 0xFF (32-bit)	PWD: 0xFF (32-bit)	Partial / N 2 3 7
NXPS50	Y / Unknown	Y / Unknown	Unknown	Unknown	Unknown
NXP ICODE SLIX	N	Y / N8	N	0x00 (32-bit)	Partial / N9
NXP UCODE 710	Y / N	Y / N	0x00 (32-bit) 5	0x00 (32-bit) 5	Y / N
Impinj Monza R66	N	N	0x00 (32-bit)	0x00 (32-bit)	Y / N
EPCglobal Gen2	Y / Unknown	Y / Unknown	Unknown	Unknown	Unknown
Alien H3 RFID10	Y / Unknown	Y / Unknown	Unknown	Unknown	Y / Unknown

Conclusion

Despite the many standards available defining NFC, in reality the support, definition and implementation of security features for NFC tags can vary quite a lot depending on the chip manufacturer as well as the tag vendor. Additionally, some tags don’t support read/write protections, and most tags are delivered to end users with an insecure default configuration, such as including default protection passwords that are easily guessable (all 0s). Moreover, many tags have no available information in their public documentation on the default configuration. 

Thus, depending on the application intended for the NFC tags, it is important to ensure that  the chip can fulfill the security expectations of the product threat model. For example, if the tags are to be installed in public areas such as libraries or supermarkets, then a manufacturing or provisioning process should be defined in order to lock down the memory contents. 

The average user will tend to trust the businesses that deploy NFC tags and will scan them in order to view content, which could expose their own mobile devices to further attacks If these tags are deployed in the default insecure configuration, a malicious actor could re-write the tag with malicious content, such as a link to a phishing website, or an NDEF record that redirects the user to install a malicious application on their phone. Some examples of attacks are: malware installation via Android Beam, or redirecting the user to install a Play Store application by writing on the tag an Android Application Record (AAR) NDEF record with a malicious application. The latter will instruct the mobile device that the malicious Android Application should be used to handle the NFC tag and open the application’s Play Store page, guiding the user to install it. Attackers could go as far as locking down the tag memory, so that the company could not restore them and would have to re-deploy new tags. This type of attack does not target a user’s mobile device security, but instead impacts the trust the user has when scanning the tag provided by the business or organization. 

Therefore the consequences of insecure deployment of NFC is not limited just to the affected users and their devices – it can also affect businesses in terms of both their reputation as perceived by their customers and suppliers, as well as their ability to reliably use NFC deployments in their ongoing operations. 

Endnotes

¹ The system configuration can be permanently locked for write access from RF, but an I2C host will still be able to edit and unlock: “user cannot unlock system configuration if LOCK_CFG=01h, even after opening RF configuration security session (only I2C host can unlock system configuration).” (https://www.st.com/resource/en/datasheet/st25dv04k.pdf) 

² The documentation mentions : “CFGLCK: user configuration permanently locked against write access, except PWD […]” and “The PWD  [… is] writable even if the CFGLCK bit is set to 1b.“, which means the two passwords can still be modified, despite the memory being permanently locked. (https://www.nxp.com/docs/en/data-sheet/NTAG213_215_216.pdf) 

³ Additional protection in the case of too many unsuccessful authentication attempts : “As soon as this internal counter reaches the number specified in AUTHLIM, any further negative password verification leads to a permanent locking of the protected part of the memory for the specified access modes.” (https://www.nxp.com/docs/en/data-sheet/NTAG213_215_216.pdf) 

⁴ The tag does not have user memory per-se, the inventory data is stored in the EPC memory section, for this comparison we consider this area as “user memory” as this would be the data returned to a user when reading the tag. 

⁵ “If a Tag does not implement the kill and/or access password(s), the Tag shall logically operate as though it has zero-valued password(s) that are permanently read/write locked” (https://www.gs1.org/sites/default/files/docs/epc/uhfc1g2_1_2_0-standard-20080511.pdf) 

⁶ “Monza R6 does not have any user programmable passwords. As per the Gen2 specifications the passwords are PermaReadLocked and set to zero. It follows that Monza R6 is not killable and does not utilize the Access command.” (https://support.impinj.com/hc/article_attachments/1500019253582/Impinj_Monza_R6_Tag_Chip_Datasheet_V7_20210521.pdf) 

⁷ The documentation suggests that only the first two configuration pages can be permanently locked: “Remark: The CFGLCK bit activates the permanent write protection of the first two configuration pages. The write lock is only activated after a power cycle of NTAG21x. If write protection is enabled, each write attempt leads to a NAK response.” (https://www.nxp.com/docs/en/data-sheet/NTAG213_215_216.pdf) 

⁸ Only for EAS and AFI functionality: “Password (32-bit) protected EAS and AFI functionality” (https://www.nxp.com/docs/en/data-sheet/SL2S2002_SL2S2102.pdf) 

⁹ Only available for specific configuration areas: “Lock mechanism for DSFID, AFI, EAS” (https://www.nxp.com/docs/en/data-sheet/SL2S2002_SL2S2102.pdf) 

¹⁰ An additional security feature from the EPC standard, a tag can be “killed” : “The kill password is a 32-bit value stored in Reserved memory 00h to 1Fh, MSB first. The default (unprogrammed) value shall be zero. An Interrogator may use the kill password to (1) recommission a Tag, and/or (2) kill a Tag and render it nonresponsive thereafter. A Tag shall not execute a recommissioning or kill operation if its kill password is zero. A Tag that does not implement a kill password operates as if it has a zero-valued kill password that is permanently read/write locked.” (https://www.gs1.org/sites/default/files/docs/epc/uhfc1g2_1_2_0-standard-20080511.pdf) 

¹¹ Only for the GPO Config and Event Counter Config bytes (https://www.st.com/resource/en/datasheet/st25ta02k-p.pdf)