Why the Mythbusters won't do RFID (2008)
youtube.com
youtube.com
Here's the link:
http://news.cnet.com/8301-13772_3-10031601-52.html
September 3, 2008 10:59 AM PDT
'MythBusters' co-host backpedals on RFID kerfuffle
It seems odd Adam would have made up his original account, but only he knows the real story at this point.
Sure it's mildly inconvenient if your CC number gets stolen. But the CC company is the one that foots the bill. In that sense, they are the ones with the best incentive to keep the number secure. If fraudulent transactions instigated by RFID-scanning thieves ever gets to the point where it is a serious concern, I am certain that the companies will act in their own best interest to curb the behavior. In the mean time, who cares if they lose some money?
It is like it was with debit card PINs here in germany, the banks convinced the judges that the cards are absolutely secure so that any fraud was in fact to blame on the card holder who either didn't protect his PIN or was actively trying to defraud the bank.
Source: http://www.youtube.com/watch?v=J8jqea8R-bE
[edit] if you don't want to watch the whole 3 part video: http://www.youtube.com/watch?v=fFcVaFhKd_4#t=08m32s
I ended up quite dissaponited they couldn't air the show. Would have brought a lot of awareness to the issue. It is really easy to copy RFID credit cards... all you need to do is go buy a point of sale terminal from eBay, poke the little speaker that beeps when it reads a card with a needle and then plug it into a laptop and you've got a skimmer.....
That's just a few off the top of my head...
a) RFID is readable from further away than they'd like you to think.
b) You don't know when your RFID card is being read.
c) Points a and b make tracking you really easy... for anyone to do.
d) The only thing that should (ideally) be stored on any RFID chip is a unique number... not any history (recent transactions), personal data (name/phone/picture), or payment system (think public transport) where the actual info about how much money is on the card is stored on the card itself... but that's exactly the type of information which is stored on these cards.
e) Nearly all encryption mechanisms are shoddy, either because they're poorly implemented open standards, or developed in-house by the vendor (security through obscurity). Cards that make use of real encryption would be (are?) expensive to make.
Here in the Netherlands the entire public transit system is being switched to an RFID-based system, and even to a non-security expert (me) it's clear that the system is based on an insecure premise (d), and would be very vulnerable to unknown scanning by someone wishing to track you from a decent distance (a-b-c).
I was interested in the security of this system, and found this video (http://events.ccc.de/congress/2007/Fahrplan/events/2378.en.h...) of some hackers who did an amazing job tearing it to shreds. They're pretty adiment that nobody is doing adequate encryption on RFID cards. If you're interested in this at all it's an amazing hack, involving dissolving the cards layer by layer to see the code.
b) I have yet to hear of a single RFID card which has a switch on it to address this. It's a big security problem. I saw one hobbyist hook up an OLED pixel, but that's it.
e) I've heard of a couple, very expensive, challenge-response and public-key RFID systems. That is acceptable for authentication, but I've never heard of them actually being used, and one or two were only proofs-of-concept, IIRC. Many (I'd say easily most in use, from what I gather) simply transmit a unique ID, that never changes, which is used to perform X, which is ridiculously insecure.
> I'd love to take a massive dish (say, 20 foot
> diameter) & see how many can be captured from
> inside a neighboring building.
Are you talking about active or passive RFID? I was under the impression that most RFID in use is passive. In that case, you'd have to transmit something to get a response, unless you're talking about camping out in an area where lots of cards are going be activated by various things other than yourself (e.g. entrance to the transit system). But even then the transmitting power of the RFID chip is proportional (?) to the power used to activate it, so something that only expects to read it from 2 feet away isn't going to blast it with enough power to be reliably read from 100 feet away, unless I'm misunderstanding how people do those long distance RFID reading records...For active RFID, maybe you'd grab quite a bit.
You'd also grab quite a bit of noise. These are very low power signals; restricted by regulations in at least Australia, N.America, but it could still work. It did on 2005: http://blog.makezine.com/archive/2005/07/_defcon_rfid_world_...
If someone comes along with a powerful rig, say using some of the techniques astronomers have had for many years to detect far weaker signals, what sort of distance might we be talking? It's not too far-fetched if you include possible corporate / governmental espionage attempts.
I disagree. This is basically where RFID has its benefits. Transport for London has the Oyster card, which I'm pretty sure is "electronic cash", i.e. your balance is stored on the card. This allows the system to work without the huge point of failure that is a central database and the connections to it. They have millions of people passing though thousands of checkpoints, many of them on moving busses. The infrastructure needed to make sure that every single one of these checkpoints can at any given time instantly run a transaction on the central database vs. having autonomous readers that just needs to upload their log every once in a while is huge.
It's basically the difference between mainframes/dumb terminals and P2P.
The problem is that RFID implementers have been cheap with the security on those chips. It's pretty simple to make a secure setup (famous last words....) tried and true ideas from cryptography (public key infrastructure etc..) but these call for more expensive chips, and when the choice is between expensive crypto that works and cheap security-through-obscurity that works until a grad-student is bored for the summer, you're going to go with the latter, of course.
I wonder why people rolling out such systems never seem to see the obvious(?) writing on the wall:
1. Someone comes up with an "infinite balance"-hack.
2. Infinite balance cards are sold on a growing scale.
3. Transport company is forced to apply expensive bandaids to contain the problem.
Moreover I don't understand why they don't simply leverage the device that everyone already has in their pocket - the cellphone. The infrastructure would likely cost an order of magnitude less (barcode scanners like in airports, or bluetooth) and more importantly the system would be rather easy to make cryptographically secure because it's all in software.
"But what if I forgot my cellphone at home" - well, same thing if you forgot your RFID card at home.
The writing isn't at all obvious, otherwise they wouldn't have come up with it. I guess they've come to the conclusion that forging Oyster cash is similar to forging paper ticket or real cash. I don't know exactly how the Oyster card is implemented, but if it has some level of transaction log trail (however asynchronous), it's possible to detect forgeries (if you've only ever deposited £20, but since spend £100, you're cheating).
> Moreover I don't understand why they don't simply leverage the device that everyone already has in their pocket - the cellphone.
Scanning a barcode on a cellphone screen has three problems:
1: There are still loads and loads of cellphones not reliably capable of displaying a scannable barcode.
2: Barcodes are 100% copyable and include 0 cryptography - they have the same security as a barcode printed on a piece of paper, which, incidentally, is what they replace in airports.
3: A barcodes is read-only and requires online access to verify and record the transaction which is not feasible on the scale required for TfL.
Bluetooth has similar problems:
1: While most phones might be BT equipped, developing and supporting software for enough different phonemodels is very complex.
2: BT is designed for communication between specific devices, not a "class" of trusted devices. You can't trust all TfL checkpoints under one, so you'd have to navigate some sort of interaction every time you check in and out of a station/bus. Also, this interaction is different for each phone type = support hell.
3: BT is long range, compared to an RFID card. Sure, an RFID card might be skimmed from a difference, but it's easy for a reader to tell the card directly on the reader from every other card in the room. No so much for BT.
The solution including cellphones we need is NFC, which is basically RFID that can leverage the processing power of the cellphone. It just doesn't exist on very many phones yet.
That doesn't have to be case, which imho invalidates the rest of your points.
It's perfectly doable to issue tamper-proof tickets in the form of cryptographic signatures. So you could, for example, on a website order a barcode that encodes "This ticket valid between 10:00-18:00, on route section X, and belongs to Mr. John Doe". Obviously someone could copy and re-use that very barcode but you have the same problem with RFID tokens, unless there's some sort of centralized validation going on. Which is, btw, actually much easier to implement than you make it out to be, considering you'll have a hard time finding a train-station without GSM coverage nowadays.
I do agree with your concerns that not everyone has a phone capable of displaying these codes, yet, but it's a matter of years until that will be the case. During then you'll need the old paper tickets as a fallback - but that's the case with any new technology, it's not like you could flip the switch with RFID over night either.
Likewise Bluetooth may indeed be the wrong tool for the job, personally I'd favor the barcodes that seem to work out well enough on airports.
And finally, the development effort for making the software work all phone platforms is negligible. Again, the Airlines have demonstrated it can be done, and when you compare it to the effort required to rollout an RFID solution including the hardware then I'd bet the barcode approach is actually easier to do.
So. This, for once, is a problem that would be fairly straightforward to solve with technology. I can't help but assume this massive gravity towards more expensive and inferior solutions is mostly a result of lobbying. Obviously there's much more money to be made by handing out physical tokens and then enjoying the benefits of a ridiculously expensive support contract as you pile bandaid over bandaid...
I do, however, not agree that it's a superior solution to Oyster cards. First, the Oyster card was introduced in 2003 when even fewer cellphones would have been capable of displaying these barcodes - even then, the Oyster card was immediately available to everybody. That is a major feature - and it's not a small thing that even today all cellphones can't effortlessly do this. Fast mass adoption is a feature.
Also, no matter how easy the implementation, buying a barcode-ticket on your phone and then scanning it is more complicated than simply touching a card. If you have to run to catch a train, you don't want to have to stop and fiddle with your phone, for however short time, to get it to show the relevant barcode.
But that's dwelling over tiny details. My post was a counter-point to your claim that the Oyster card has grave and obvious flaws and was deployed in favour of an obviously better solution. I argue that, even considering that the Oyster card system have problems, those have not been exploited, while enabling the benefits of a pay-as-you-go system.
And just to be clear: I fully expect the Oyster system to be replaced by a system based on NFC once that is viable. That just wasn't in 2003, and it isn't today.
I admit I got a bit carried away on the barcode idea, mostly because I have used it at the airport and liked it. But I have to agree it might not scale as well to public transport use - the whole running after train thing.
Well, I guess we can meet in the middle and agree that NFC would be the near-optimal solution, when and if implemented securely (however unlikely that is.. ;-) ).
"All transactions are settled between the card and reader alone. Readers transmit the transactions to the back office in batches but there is no need for this to be done in real time." - http://en.wikipedia.org/wiki/Oyster_card
People here are saying "I think/guess/assume that oyster cards work like... ". Without even checking with Wikipedia. I'd like to hear about the Oyster card system's strengths and weaknesses from someone who really knows the system.
http://joshuamcginnis.com/2008/08/09/wow-how-to-hack-boston-...
It's really shocking that people think storing MONEY on a card that everyone has read/write access to is a GOOD idea.
E.g., http://www.schneier.com/blog/archives/2008/03/london_tube_sm...
http://web.archive.org/web/20061109232923/http://www.rfidana...
What's required to figure out how to hack these chips which are clearly readily available?
If a chip has unecrypted personal data stored on it an attacker can easily gain access to it by stealing the device. If encryption is used throughout the chip then side channel attacks can usually break the encryption. This requires something like an oscilloscope, some resistors, and a soldering iron. The danger of this attack to a consumer depends upon what's stored on the RFID chip since the consumer will notice if someone has stolen their device and will have it disabled in short order.
To clone a tag that doesn't use encryption, for instance a tag that just sends an ID, you'd need a reader to query the tags and some device to copy the responses. This is probably the easiest attack but the reader, which needs to transmit a strong radio pulse and then listen for a response, either needs to be very large or in very close proximity and you could protect a card in your wallet by surrounding it in a metal mesh (which forms a faraday cage) so it's not clear how dangerous this could be in the wild.
If the communcation channel is encrypted then an attacker could listen to the query and response from a legitimate reader and RFID tag and could then replicate the legitimate response later. However, if there is any timestamp or counter involved this won't work.