Re:Decoding the MetroCard, Part 2: Research and Past Attempts
by tetrep on Monday July 18, 2016 @05:12PM
(#12118090)
> ...tamper-proof secure element...
It doesn't even need to be held in anything secure, you just need to sign the balance when writing and check the signature when it's used.
Re:Decoding the MetroCard, Part 2: Research and Past Attempts
by throwanem on Monday July 18, 2016 @06:30PM
(#12118407)
If your turnstiles can't talk to a server, they can't check key revocation lists, and I tend to imagine that in a city the size of New York somebody's going to leak a key every now and again - it's been known to happen with physical keys; why not digital ones, too?
Re:Decoding the MetroCard, Part 2: Research and Past Attempts
by dsr_ on Monday July 18, 2016 @07:24PM
(#12118576)
But they don't need to have a realtime revocation list -- it's fine if a broken card works until the end of the day, or even the end of the week, as long as it stops working faster than keys are leaked or cracked.
So a bus turnstile can do transactions when it returns to the garage, and turnstiles in locations where it's hard to run data for whatever reason can get a plug-in every so often on a regular maintenance run.
A central server can be used for things like web-based reloads and auditing, complementing the system... but it's entirely possible for a terminal to remain in offline-mode and just check-in at the end of the day to get any pending messages and upload logs. This is why it takes longer to reload/unblock a SF Clipper card using a reader in a bus (offline mode) as opposed to at a BART turnstile (online mode).