In brief: Verichip markets their product for
access control. This means that you could have a
chip implanted, and then your front door would unlock when your shoulder got
close to the reader. Let us imagine that you did this; then, I could sit
next to you on the subway, and read your chip's ID. This takes less than a second. At this point I
can let myself in to your house, by replaying that ID. So now you have to
change your ID; but as far as I know, you cannot do this without surgery.
All of this relates to an article that Annalee Newitz wrote for Wired. I would not have looked at
these parts otherwise; the Verichip is built with no attempt at security,
and is therefore not very special to clone. The designers of this product
must be aware that an attack like I outline below is possible. But, Reuters
quoted
`VeriChip spokesman' John Procter, who said that:
`We can't verify what they [Annalee and I] may or may not have done....We haven't seen any first-hand evidence other than what's been reported in the media.' (Sat Jul 22, 2006)
This is just silly. The Verichip is a repurposed dog tag; there is
no reason (counterfeit housepets?) why it would have been designed
with any security features, and in fact it was not. Their own technical
staff—or failing that, the technical staff of the company
that sells them the tags—can tell them this, with or without me.
(And while I used my proxmarkii, there's an easier way, if you want
to do it yourself.)
* * *
I will briefly describe the steps that I went through to duplicate
an ID-only RFID tag using my proxmarkii device. We will be cloning a
Verichip, which should not rationally make any of this more interesting
but does.
I have a reader and some tags. The first thing to do is to determine the
frequency of operation. I could have used the proxmarkii, but I actually
just used a coil of wire and my 'scope. I measured the voltage across
the coil, energized the reader, and used cursors to measure the frequency
of the signal received. These tags happen to work around 134 kHz.
TI's glass transponders work near that frequency, so my first thought was
that the Verichip was basically one of them. I therefore tried to read my
Verichip as a TI-type tag. That means that I excite it with a pulse a
few dozen milliseconds long, and then turn off my carrier and listen for
a response.
Clearly, this did not work. The Verichip is not a TI-type tag. That
means that it's probably the continuously-illuminated kind. I actually
could have determined this from the signal that the reader sends out,
if I had paid more attention then. The proxmarkii device could read 134 kHz
continuously-illuminated tags if I wrote the proper software for
it. Instead I will be lazy and just try it at 125 kHz; the read range
will suffer, but that isn't really critical.
So now I did a low-frequency read, and this time I got something. What is
unfortunate is that it is a mess. I just want to duplicate the tag, so
there is no particular reason to reverse-engineer the exact structure
of the bits sent over the air. Still, it would be nice to know the
fundamentals, like the period...
I do a quick autocorrelation to determine the period of the returned
signal. We could save a trace and do it in MATLAB, but I prefer to do
it in the proxmarkii software. MATLAB is nice for signal processing,
but not so good for scrolling through long traces. The graph tool that
I use is more like the user interface of a digital storage 'scope. It
is obvious that the period is 2048 samples (which, sampling every
other carrier clock, is 4096 carrier clocks).
Actually it looks like there's a little more structure to the signal,
considering all those transitions for an ID that is mostly zeros. I would
guess that it is Manchester-coded ASK, or something differential,
or something weird. If we wanted to determine the mapping between the
tag's ID and the signal sent over the air, then we would spend more time
on this. For now it is not worth the bother.
If all that I want is to clone the tag, then it is arbitrary which point in
the signal I designate as t=0. The ID just loops, so the signal over the
air is unaffected. That feature between the cursors looked sort of like
a sync pattern, though, and it occurs in both tags' traces. For want
of a better idea, I will write my demod code to correlate for that,
and use that as its reference. Then I can demodulate the received
signal to a bit string.
At this point it is only a matter of remodulating the received signal, and
we're done. Then I can download that signal to my proxmarkii, put it in
`simulate' mode, and it should be indistinguishable from the legitimate tag.
To be on the safe side,
I read my `simulated tag' using another proxmarkii device, to make sure
that my simulated ID is correct. If that looks okay, then I am ready to check my
work against the legitimate reader, and as we would hope, it reads:
(Notice that the demodulation and remodulation steps are in a sense
unnecessary; I could have just replayed the exact signal that I received
over the air, without demodulating and remodulating it. That means that
you get twice as much noise, though, because the signal received from the
tag never gets `cleaned up.' If I wanted to make this very automatic, then
I could write code for the proxmarkii that would automatically determine
the period, read the ID many times, and average those together, lining
them up at the points of maximum cross-correlation. That might be sort
of cute, because it would be fully automatic for any modulation scheme,
but it seems like a lot of trouble.)
This took me a couple of hours. I could have done it faster if I had not
constantly been interrupting myself to take a screenshot or a picture.
Of course it will take me some time if I want to build out the software
to read them properly, at 134 kHz.
The screenshots and the photograph prove nothing. I therefore save the
traces:
- verichip-raw.tr: the raw signal
from the tag, voltage versus time, one sample every other carrier clock
- verichip-remod.tr: the
remodulated (i.e., cleaned up) ID, ready for replay, one sample per carrier clock
These are for Annalee's Verichip, number 1022000000047063.
There is a curious aside: the Verichip that I read here is not
supposed to have that ID, according to medical records; but the ID that
I cloned is the ID that my legitimate reader reports. As to what this
means—malpractice? sloppy record-keeping? that I have the special
`reverse engineer's edition' of the reader?—I haven't a clue.
Oh, and lest anyone get overly worried about drive-by Verichip identity
theft: that is probably not a big deal. Their biggest security feature is
the absurdly short read range, which is restricted by the tiny antenna.
As long as the user stays at least a foot away from any unsecured person
or thing, there is very little risk.
January (and updated July) 2006, Cambridge MA
|