|
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 break 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 as saying 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.
* * *
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
 |