Sunday, August 10, 2008

Stupid Card Security - The Case of the MBTA and CharlieCards/CharlieTickets

In a story initially written up [very completely] on Wired's Blog, a Federal Judge has essentially halted (via a temporary restraining order) a bunch of MIT students from giving their presentation on the MBTA [Massachusetts Bay Transit Authority] fare cards and the vulnerabilities associated with them. The article in Wired already writes the case up nicely, and even includes a link to the (now-public-domain) vulnerability report.

Given all the number of magnetic swipe cards out there for various things and the recent cases rash of "hack the card" incidents [Oyster card case, many others] there are several lessons-learned here that I think apply to every one of these cases.
  1. Centralize card-management: For the love of all things good and pure, a centralized card-management system stops a vast majority of these "hack the fare card" issues. Dave and Buster's started doing this when someone figured out that you could simply pick up a game card, load $10 on it, take it home, and magically program another $100 into it (don't ask how I know...) - why hasn't this lesson been learned industry-wide?
  2. Use strong encryption: This is important - because in order to "dismantle" these cards one first must generally crack the encryption key on them... right? So it would follow that a strong crypto-algorithm (and likely not one that's custom-made... why do people insist on reinventing the wheel?)
  3. Checksum bits: Like in this CharlieTicket/Card case where the checksum was only 6 bits (2^6 = 64 total combinations) weak checksums are silly. If you only have 6 check bits then one in every 64 tries will be a winner. Like the PDF above-referened suggests... all one has to do is implement 16-bits for checksum (2^16 = 65,536) which will make only 1 in 65,536 cards a winner.
What it all really boils down to is lazy implementations. Corporations, governments and organizations simply don't think intelligently. Much like in today's business world (take software for example) we test the positive assumption hundreds or millions of times - but in the end we rarely try and test the negative... why is that? Sure, if you do the same [good] thing a million times it'll likely never break - but what about that one person who will stand there and try the negative [bad] thing a few times... how does the system behave then?

Lesson-learned here, although I suspect we'll still keep seeing this stupidity in the future, is think things through and don't try and take the simple implementation - because you'll be very upset when it gets hacked and it'll be all your own damn fault. As a side note, NXP is at fault for more than one of these gaffs in security... think that through... shouldn't the MBTA be suing NXP?

BTW: *great* editorial piece on this topic here [BorePatch].

No comments:

Google+