Demo: Cloning a Verichip

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