Straw men of RFID

Do you know what a "straw man argument" is? It's when you carefully construct your opponent's arguments so that they have a hole - e.g. "well, this straw man here represents you. I can easily push you over with my hand, so therefore I can push over you with my hand, too." It's a pretty standard technique in heated arguments over empty pints of beer. But you should not use it in scientific debate.

Recently, Melanie Rieback et al published a paper detailing RFID viruses and worms, where they show that particular RFID system backends are vulnerable to SQL injection attacks, built an entire web site about it, and are - in a pretty alarmistic tone, I might add - shouting how RFID is dangerous, and RFID worms and viruses are just around the corner.

Unfortunately, if you read the paper through carefully, you see that they have constructer their own backend, which just happens to be vulnerable to SQL injection attacks. So, they carefully built a system which is vulnerable to these attacks, and wrote a big article about how RFID systems in general are vulnerable. It has no analysis of any of existing middleware products, nor does it attempt to analyze whether they are susceptible to this kind of a problem. It might well be that none of the existing products in the world are vulnerable to these attacks. This is bad, bad, bad science. All the article does is that it sets up a big straw man, and shoots it down; essential proving the existence of SQL injection attacks against any system that uses them. There are plenty of OSS products that have had the same bug; this is well known science, and has nothing to do with RFID systems.

The beginning of the article makes a bunch of good points on how the RFID world should pay more attention to security and how, once the RFID systems become more commonplace, you can no longer get away with thinking that nobody else is ever going to read and write your tags. Very good, and lots to think about to those who are building RFID middleware, especially chapter 7, which provides practical instructions on writing good middleware.

But... I wouldn't mind the paper so much if it wasn't touted as the Most Important Thing Since Pamela Anderson Got Fake Boobs. Come on - getting your own "rfidvirus.org" web site (with headlines like "How to write a RFID virus") for a single paper, which just says that any badly designed computer system has security holes? That's just alarmist and scaremongering, and riding on the general "RFID is evil" -wave.

(Disclaimer: I work for Nokia, which produces RFID products; and I also am involved with the NFC Forum work (so I claim some expertise on the matter), but everything I say is, of course, my personal views and not corporate opinions.)

(Link via Digitoday.)

Update: Some commentary from Ed Felten.

Update2: Slashdot commentators, for once, get it right. This is a backend issue, nothing to do with RFID.

Update3: BoingBoing has good commentary. "this is all a bunch of hooey"




Comments

I don't know anything about rfid, so I wonder if the rfid-certification process includes a test for "invalid" data. To test for buffer overflows etc. Maybe, if there is no forced test system, the unlikely possibility of a faulty system is too propable for comfort. And maybe this study will help create certification tests...

--Oliver, 15-Mar-2006


The thing is that RFID application space is dominated by completely proprietary solutions. There are no "RFID certifications" for data layers - however, there are several storage and radio standards, but they don't say anything about how the data should be handled; only how it is stored.

There are some proprietary application standards, yes, such as the ~SuiCa and Edy cards in Japan, and they do have a certification process. How much of that deals with invalid data, I don't know.

But buffer overflows are quite a known factor. So I'm hard pressed to see that this study would contribute to anything but the general fear against RFID.

--JanneJalkanen, 15-Mar-2006


More info...     Comments?   Back to weblog
"Main_blogentry_150306_1" last changed on 17-Mar-2006 11:37:06 EET by JanneJalkanen.