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 would take less than a hundred milliseconds. 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 is writing for Wired. To me, this is yet another ID-only tag, and not very special to clone. Still, she had bothered to have one implanted, pretty much entirely for that purpose, and she was looking for someone who could do it. As we will discover, they are built with no security. It was therefore not that hard.
I went to the trouble of cloning her implanted tag, which seemed entirely unnecessary; the sample tags worked fine. She thought that it would be more impressive like that. Actually, she might have been right. The article comes out in May.
Also, before anyone else links to me using the phrase ‘claims to:’ of course I can clone it. It is really not difficult. If you are still unconvinced, and you live in or can travel to the greater Boston area, then contact me, and I will see what I can do about a demo.
* * *
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 2006, Cambridge MA