[Noisebridge-discuss] Prox Reader

[Seth David Schoen]

travis+ml-noisebridge at subspacefield.org writes:

> No specific info from me on the clipper card but...
> 
> IIUC, the primary reason why this isn't often done is cost per unit
> and power consumption on the device; RFID is powered by radio, so
> doesn't have a lot of power to compute things.

Yes, definitely.  Unfortunately the results can be really bad for users'
privacy...

> If you DON'T do this, then it's just a simple ID number, and could
> easily be replaced with a magstripe or barcode (which would be mildly
> subject to being photographed, but who really worries about that?).
> In other words, why bother with RFID?

I know from using the CharlieCard in Boston that people really enjoy
the convenience of (1) not having to worry about the card orientation
and (2) not having to take the card out of their wallet.  People getting
on transit in Boston just hold their wallet up to the faregate or fare
box and it gets authorized.  It looks like it probably saves them about
2 seconds, which is trivial in one sense and could be addictive in
another sense.

I'm in Rio de Janeiro right now and I've been using the metro system
here; they also have an RFID system but (presumably because the RFIDs
are slightly expensive per unit and they have tons of tourists who
use the metro only briefly and then leave the country) they have several
measures to try to get people to return cards that will only be used
for a single trip.  Notably, the cheapest kind of card is only accepted
for fare service if you deposit it into a slot, _even though it is an
RFID card_ and the faregate also has a separate RFID reader that's
perfectly capable of reading the cheap card.  (I know it can read it
because, on my first trip, I tried to tag the card on the reader without
dropping into the slot.  At this point a message flashed up in
Portuguese saying 'please deposit your card in the slot'.)  What's
interesting is that on every subsequent trip I felt a little tiny pang
of annoyance at having to line up the card correctly and drop it in the
slot (and then wait .8 seconds for the motor to draw it in) while this
nice RFID reader was sitting right there for local residents to use
with their multi-use refillable cards.

In the scheme of things I think this is quite a bad tradeoff for the
privacy effects, but I've now experienced the little psychological
effect a few times so I can understand the perception of greater
convenience.  I bet if Bluetooth were actually implemented properly
and could be used everywhere QR codes are used, people would positively
hate QR codes ("what!? I have to actually aim the camera? why don't
I just have the information already?")

> Nearfield effects fall off with cube of distance and systems using
> these would require the devices to be closer to gate and any target
> card.  There was talk about using these for pairing bluetooth devices
> on the cryptography mlist.

Cool!  I'm on that mailing list but I totally didn't remember that
discussion.

> Other options include:
> Switch (preferably a durable one)
> Faraday wallet
> Optical sensor (only respond to challenges if I'm getting light)

Hmmm, the optical one is new to me.  That's clever.  Although people
still don't want to have to open their wallets.  But I guess the main
point is that you can't have a UI defense against unauthorized reading
if users absolutely don't want to have to perform any action to signify
their intent to authorize transactions (and if the system designers
want to cater to that user preference).  In that case a higher-level
question is whether the authorization check is for defense against
MITM fraud or against unauthorized reading for user-tracking purposes.

> It's also worth asking yourself why the fed is threatening to withhold
> IH funds for states which don't have biometric IDs.  I was actually
> told by a DMV worker that the fingerprint scanning was "to identify
> bodies in the case of a crash" when they introduced it in my area
> years back.  I love it when government employees brazenly lie to me.

The version I've heard in California is to have an after-the-fact way
to establish whether people obtained IDs under multiple names.  But I
think there has already been some mission creep.

> HMAC causes problems here:
> 
> 1) If everyone has same secret key, then you reverse one card and get
>    the key that's used to authenticate every card.
> 
> 2) If every clipper card has different keys, then you have a key
>    management problem - every access point needs a key list.  In
>    reality, they could probably fail open, potentially letting someone
>    through, since the cost of unavailability and reliability is higher
>    than the occasional free ride.
> 
> PK requires a lot more compute power.

Yeah, these tradeoffs are certainly there.  I know Clipper fails open
in some situations as a result of what I remember from the privacy
discussions...

-- 
Seth David Schoen <schoen at loyalty.org> | Qué empresa fácil no pensar en
     http://www.loyalty.org/~schoen/   | un tigre, reflexioné.
     http://vitanuova.loyalty.org/     |            -- Borges, El Zahir