Comments

yet another bruce December 14, 2022 10:50 AM

I can understand why a large-scale, long-lived system like the MTBA fare system might not have bulletproof security. It is pretty hard for me to see why they don’t log every transaction and run a script periodically to reconcile card values over time against transactions. Even equipment with no network connection could still log transactions to an SD card.

Norio December 14, 2022 1:53 PM

Deck us all with Boston’s CharlieCard,
Walla Walla, Wash., an’ Kalamazoo!
Nora’s freezin’ on the boulevard,
Swaller dollar cauliflower alley-garoo!

Don’t we know archaic barrel
Lullaby Lilla Boy, Louisville Lou?
Trolley Molly don’t love Harold,
Boola boola Pensacoola hullabaloo!

[For more verses and background, see:
https://www.straightdope.com/21341623/what-are-the-lyrics-to-walt-kelly-s-classic-carol-deck-us-all-with-boston-charlie
https://groovyhistory.com/deck-us-all-with-boston-charlie-pogo/6%5D

Ted December 14, 2022 2:55 PM

How do you deal with exposed encryption keys available in a public repository?

It seems like MBTA would want to prevent tools like Flipper Zero and the Mifare Android app from drawing on these. Wait, are all the MBTA keys (same across all the cards) already preloaded into these programs. Ruh-roh.

The MBTA says they detect and deactivate about 10 counterfeit cards a month. However, it’s not clear to me if their detection methods are responsive to new developments, like the new and improved Chinese Mifare clone cards.

Clive Robinson December 14, 2022 3:26 PM

@ yet another bruce,

Re : Pace of change v. Cost

“It is pretty hard for me to see why they don’t log every transaction and run a script periodically to reconcile card values over time against transactions.”

The simple answer is it creates a “time window”. One of the attacks outlined is “near real time” so as long as the attacker stays inside the time window then “they are golden”.

The more complex problem is the shorter you make that time window the faster you run into reconcile issues. As described the system uses “stored value cards” not “identity tokens to an online account”.

The way a ‘stored value’ system works is “Off-Line” mode, the way ‘account’ systems work is “On-Line” mode and they are radically different in the way they work. So much so they are in effect mostly “incompatible” so running the two systems on one backbone system is going to be problematic in all sorts of little ways, that can all become security vulnerabilities.

The reason for going “Off-Line” is historic and to do with the pace of technology. Back when Philips in Einedhoven split off their semiconductor business into NXP, communications at any level was very far from ubiquitous and eye-wateringly expensive.

A travel card system has to work very reliably 24×365.25 unlike credit cards or ATM cards, so flaky communications is out. So the use of an Off-Line system back then was not just for customer safety and confidence, but the money side would be way more secure (a lesson from the credit card industry that used an “On-Line” model that “fell back” to an “Off-Line” model and got hit financially).

Now communications is nearly ubiquitous in metropolitan areas and often for rail operators actually a “profit center” not a “cost” due to rail-side leasing of fiber etc.

Eventually most Wide Area charging systems will move to the “On-Line” account method, because it lacks anonymity for users, and their “travel data” is seen as worth more than the cost of running it.

The joke of it is so valuable is that travel data seen, some metropolitan network opetators are doing all but the “account transaction side” already.

It’s just another reason we need very strong user privacy protection at all levels.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.