[Noisebridge-discuss] Prox Reader

Seth David Schoen schoen at loyalty.org
Fri Aug 13 22:20:44 UTC 2010


Glen Jarvis writes:

> This reminds me of something that I was thinking of this morning.
> 
> Do you know the new clipper cards?
> 
> What keeps someone from getting close enough to someone to read the card
> contents and puke the same response back at a BART gate, and thus "steal"
> someone's BART ride (i.e., someone else paid for one's BART ride). As I have
> no interest in stealing, my query is more "What keeps someone from doing
> that to me?" and How do I learn more.
> 
> I know some of the basics of smart cards and a password is sometimes needed
> to read.  But, as there are so many different entry/exit points, these must
> be syncronized. I have no idea if clipper cards are RFID, smart cards, or
> whatever...
> 
> What has been discovered?

I don't know any of the Clipper implementation details (I may have known
some after a meeting about privacy years ago, but, if so, I don't remember
them).

There are designs for smart cards that resist replay attacks so that you
can't just play an old response back to the service and get the same
authentication result.  In fact, all smart cards probably _should_ be
using such designs in order to protect their users, but it's true that not
all of them do.  Even some recently-deployed systems seem to make their
users vulnerable to skimming and cloning attacks, notably in passports
and credit cards.

One basic idea is that you could issue a challenge to the card in the
form of a number that the card has to transform in some way using
information known only to the card.  For example, the card might have
to perform a cryptographic operation like encrypting, signing, hashing
(with a secret) or HMACing (with a secret) the challenge.  If the
verifier also knows the secret (or the necessary verification
information in a public-key system), they should be able to confirm
that the card possessed the secret information and used it properly to
respond to the challenge.  But since each challenge is different, you
can't just take a previous response an use it again -- it will no longer
match the current challenge.

Now, someone can still do a man-in-the-middle attack (Ross Anderson's
Security Engineering referred to this scenario as a MiG-in-the-middle
because of precedents in identify-friend-or-foe systems in military
aviation) where they have one device that receives the challenge and
then another device that repeats the challenge and receives the
response.  These two devices will probably have to be in different
physical locations and will need to have a communication channel
between them.  For instance, you might have a radio next to a BART
faregate and a different radio next to the pocket of a stranger on
the street or elsewhere in the BART station.  If these radios also
have a way to pass data back and forth, you could imagine recording
a challenge and then issuing it to a card (at a different location)
and then recording the corresponding response and issuing it to the
faregate.

The fare collection system could try to defend against this attack by
associating timestamps with the challenge, ideally with a pretty low
timeout, so that challenges become "stale" if they don't get answered
promptly, and then answers to those challenges are no longer accepted.
(The faregate doesn't actually have to tell the timestamp to the card
as long as the faregate is able to reliably remember what it was.)
There's a plausible argument that a lot of MiG-in-the-middle attacks
against a system like Clipper would add some latency compared to using
a real card in person at the faregate, and thus might be distinguishable
from the proxied version.  By the time the reply came back, it might no
longer be valid.

I guess there are other properties of radio signals that are somewhat
hard to copy (like polarization) and other ideas for how the card could
determine its own location to figure out if it's actually right near a
faregate (or to figure out whether the user intended to use it to make
a payment right at this moment), but in a lot of designs where the RF
circuitry in the card is not very complex, where the card doesn't have a
lot of computing power, and where it may not have any user interface, it
seems like latency is the main information available to try to defend
against this kind of attack.

It's also true that in this scenario the verification information needs
to be pretty widely distributed.  Each faregate can certainly make up
its own challenges (if it has a good random number generator), but the
faregate has to be in possession of whatever's needed to authenticate
the responses.

-- 
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



More information about the Noisebridge-discuss mailing list