Convergent Software has ceased trading.

The site will be available until 14 August 2019.

What have Meltdown and Spectre got to do with RFID Privacy?

Anyone involved with running a computer system will be aware of the newly discovered vulnerabilities at the heart of nearly every modern computer. Given their rather cute names (and graphics), Spectre and Meltdown hide a serious issue.

This type of computer vulnerability is discovered by academic researcher and white hat hackers working for security firms, then reported to the organisation that should fix the vulnerability and eventually made public. They are all known as Common Vulnerabilities and Exposures (CVEs). Details of over 95,000 CVEs[1] have been published. Some CVEs can be embarrassing for the companies behind the hardware or firmware, as in this case. But generally the system works reasonably well with the overall objective of identifying and trying to fix the vulnerability. These fixes eventually appear as patches and updates to systems.

The Spectre and Meltdown vulnerabilities have been put down to problems in the original chip design. RFID technology is also based on chip design. While the RFID chips are not as complex as computer CPU chips, they still pack a lot of bang for your buck on a pro rata basis. And the high-end contactless chips cost a lot more than a few cents and can even be a few Euros or dollars.

But there are some more significant differences. RFID depends on wireless technology. And the laws of physics mean that there are potential inherent vulnerabilities that are difficult to design out.

Also there is no equivalent to the CVE for RFID-related technologies. As such most RFID operators are unaware of any potential vulnerability in RFID products and the design of applications. This is despite the fact that in 2014 a European Standards Committee published two Technical Reports: CEN/TR 16670[2] and CEN /TR 16672[3] that identified RFID vulnerabilities and how privacy might be implemented. A matrix of 27 features and 16 standards identified these four conditions, with many (241) in the first category:

  • not supported by the standard - and by implication not in compliant products
  • supported by the standard, but it is only optional in the product - how does the user know what product supports what features?
  • supported by the standard; can be used by application - but only if the application designer uses them
  • application-dependent - this is a non-hardware feature that needs to be built into the RFID application design

Bear in mind that vulnerabilities and the privacy-enhancing techniques apply to the entire RFID application. Having a privacy or security feature in an RFID tag requires support by a relevant command from an RFID reader (interrogator). Not all RFID reading devices might support such a command, and as such the latest tag gizmo feature in a tag might not have much material value. It is important to understand the privacy implications of the wireless interface between the reader and the tag.

The same applies throughout the RFID application. There is also an interface between the reading device and the application. Here is a real example at the application layer. Contactless payment transactions depend on the reading device interfacing with the bank or credit card provider to validate the payment. Some transactions are done offline, i.e. not in real time. For smaller retailers, a batch of transactions might only be dealt with daily or at even longer intervals. Therefore if a card is stolen or lost and that fact reported to the card issuer, transactions can still take place and the fact that the card has been cancelled is not flagged up. There are reports of such transactions taken place months after the card should have been stopped. A UK consumer organisation raised the issue in 2016. According to its recent report[4] some progress has been made to require more on-line transactions, but the “security flaw [is] still not fully fixed 18 months on”.

Those European Technical Reports were vital inputs to the development and publication of EN 16571, Information technology - RFID privacy impact assessment process. This is the only objective way to identify and assess RFID risks AND identify countermeasures that can be applied. Using the PIA process defined in EN 16571, it is possible to use a technology-based risk assessment to overcome the fact that there are no CVE type reports for RFID. Furthermore, that PIA process can be used to define a Privacy-by-Design approach to any RFID application.



2 CEN/TR 16670, Information technology - RFID threat and vulnerability analysis

3 CEN/TR 16672, Information technology - Privacy capability features of current RFID technologies


Multi Domain SSL
Multi Domain SSL