I have just read through your thoughtful but provocative paper entitled 'Is Your Cat Infected with a Computer Virus?', which has just been presented at the Proc. 4th IEEE Intl. Conf. on Pervasive Computing and Communications. (PerCom 2006), Pisa, Italy, March 2006. http://www.rfidvirus.org/papers/percom.06.pdf I congratulate you on being nominated 'Best Paper Candidate' and appreciate that your paper raises a number of important concerns which implementers should consider, particularly when handling blocks of 'user memory' on the tags and ensuring that they are only providing clean correctly-formatted type-checked data to their applications and databases. Your paper is certainly being noticed in the news media - e.g. http://news.bbc.co.uk/1/hi/technology/4810576.stm and http://www.nytimes.com/2006/03/15/technology/15tag.html?8br However, I would like to point out a few of issues concerning your paper, especially in relation to the EPCglobal Network (which you mention in your paper): In section 2 of the paper, you write: 2. Generic Protocols and Facilities. Building on existing Internet infrastructure is a scalable, cost-effective manner to develop RFID middleware. However, adopting Internet protocols also causes RFID middleware to inherit additional baggage, like well-known security vulnerabilities. The EPCglobal network exemplifies this trend, by adopting the Domain Name System (DNS), Uniform Resource Identifiers (URIs), and Extensible Markup Language (XML). While it is perfectly correct that the EPCglobal Network does use the DNS, URIs and XML, it should be noted (perhaps by way of a footnote) that:
1) Current adopters of the EPCglobal Network are typically using low-cost passive tags with relatively limited memory capacity (much less than the 896 bits of data available in the I.Code SLI tags used in your experiments) and that the primary role of an EPC tag is to simply store and communicate a unique identifier (a serial number licence-plate typically represented in 96-256 bits), rather than commands for updating databases directly.
2) The URI representations of EPCs which are currently defined in EPCglobal Tag Data Standards [ http://www.epcglobalinc.org/standards_technology/EPC_TDS_1%201_Rev_1%2027_Ratification_final%201-2006.pdf ] consist of fields which allow the characters 0-9 A-Z and space, so there are already some impediments to the introduction of the special escape characters you note in section 3.2 of your paper, although the user memory bank and future coding schemes may permit these characters. 3) In section 3.1, you correctly note that EPCglobal's Object Name Service [ see http://www.epcglobalinc.org/standards_technology/EPCglobal_Object_Naming_Service_ONS_v112-2005.pdf ] is implemented using DNS and is therefore potentially vulnerable to DNS attacks (including denial of service attacks). However, it is not clear to me how an RFID worm could propagate via an attack on the ONS, since the ONS merely provides DNS pointers to addresses of authoritative information services for a particular EPC. I would be interested to hear further details of your thoughts on this. In section 3.1, you write that: RFID tags can exploit buffer overflows to compromise back-end RFID middleware systems. This is counterintuitive, since most RFID tags are limited to 1024 bits or less. However, commands like 'write multiple blocks' from ISO-15693 can allow a resource-poor RFID tag to repeatedly send the same data block, with the net result of filling up an application-level buffer. Meticulous formatting of the repeatedly sent data block can still manage to overwrite a return address on the stack. My understanding of 'write multiple blocks' in ISO-15693 is that it is a command sent from an application program to an RFID reader to instruct the reader to write multiple blocks of a tag's memory, rather than a command which the tag could use to send an instruction to write multiple blocks of an application-level buffer. I really do not believe that the command could be used the other way round, in the way you suggest. I have taken the liberty of blind-copying this e-mail also to three key people who are involved in the EPCglobal Network, because I am sure that they will find your paper interesting, especially as the EPCglobal Network begins its work on handling the larger blocks of user-programmable memory in RFID tags - and also in case they have additional comments or clarifications to add.
Best regards,
- Mark Harrison