Halt! Who goes there? What's you're UID?
Last week Chip Monkey & I gave a talk at OSHUG, the Open Source Hardware User Group, where we discussed and demonstrated the (soon to be released!) RFIDler prototype...
One of the interesting things that came out in the discussions afterwards was the concept of the UID. To me, having been immersed in low level RFID for the best part of 6 months (and on and off for the last several years), this seemed intuitively obvious, but it was clear that it meant several different things to different people. Accordingly, I think it's worth some discussion!
First off, I have to say that however I 'define' a UID it will be wrong in some contexts, and I will just have to live with that. RFIDler is designed to attempt to work with any and all tag types, and so a common vocabulary must be created for dealing with overlapping concepts and methods. In the early days, when I started writing RFIDIOt, I used the terminology that the the first RFID reader implementation dictated, and stuck to that from then on. This meant that the command to get a UID from a tag was 'SELECT', as that's what the ACG reader I was using called it. However, this turns out to be a bad choice as 'SELECT' has a specific meaning for some tags, and is meaningless for others. 'READ' was also suggested, but, again, this is not a good choice as 'READ' tends to refer to reading any block of data, not just the UID...
But we're getting ahead of ourselves - let's get back to the concept of the UID itself, and then it should become clear why the language used to refer to it is also important.
In the simplest terms, a UID is what the the letters stand for: a Unique IDentification number. In the context of RFID, however, it is not quite that simple. I have yet to come across a tag type that does not have something that could be considered a UID, but not every tag specifically refers to it as such, and some tags can provide multiple 'UID'-like data sets, depending on the circumstances. Accordingly, we will have to set our own rules for how to determine what is a UID and try to make them work for all tag types.
Broadly speaking, there are two ways a tag might present a UID:
Firstly, by emitting a repeating bit pattern as soon as it is energised by a reader field. These tags have no intelligence, additional storage, or options to do anything other than emit those bits. This is probably the simplest to understand, but not necessarily the simplest to deal with, as we'll see in the next section!
Secondly, by emitting a bit pattern (which may or may not repeat) when commanded to do so. This command is effectively a 'WAKE UP' signal, telling the tag to stop being dormant and tell us who it is. These tags will still be energised as soon as they enter the reader field, but will do nothing until instructed to do so. The command may be a simple 'GET UID', or something more complex, but the end result is the same - the reader needs to know the correct command sequence in order to elicit a response from the tag.
Examples of the first type of tag would be:
EM4X02, FDXB, Unique, HID, Indala, Q5, T55X7
and the second:
Hitag1/2/S, Q5, T55X7
So, I told you it wasn't that simple! Note that Q5 and T55X7 fall into both camps, and, strictly speaking, so could a Hitag2, depending what 'mode' it was in. I haven't included it because in it's default factory issued state it doesn't - it will only respond to a 'wake-up' command in the form of a 'START AUTH', but a Q5 and a T55X7 will do both - by default they will spit out a 'UID', but by command they will also provide another one, known as 'TRACEABILITY DATA'.
OK, as you can see, it's easy to get sidetracked, so to let's try to get back to the original question: what is a UID?
If we assume we've done whatever's necessary to get some data bits from the tag, and those bits are the UID, what do they mean? Well, as usual, the answer is 'it depends'.
If we take our first tag type, that just starts emitting bits as soon as it enters the reader field, we have an immediate problem: how do we know where the data starts and where it ends? We don't know for sure that the first bit we read was the first bit that the tag sent, as if it's repeating the data, it will be an endless stream of bits and we could be anywhere in the sequence. We must, therefore, have some means of latching on to the start of the data, and this is normally done by providing a specific 'SYNC' pattern - a set of bits that only exists once within the repeating pattern.
Let's take an EM4x02 as an example:
From the datasheet we know that it is an ASK/OOK modulated tag running at 64 Frame Clocks per bit, and it is Manchester encoded. The UID is a 40 bit number, but what's transmitted 'over the air' is actually 64 bits. So we already have two different interpretations of a 'UID' - the one that the reader will 'see', which is 64 bits, and the one the user is expecting, which is 40 bits.
To solve this conundrum, RFIDler deals with both. Internally, it works with the original over-the-air data, but contextually it will provide the 'interpreted' one according to it's config and what we are trying to do at the time. Again, looking at the EM4x02, the raw data transmitted over the air could be interpreted in at least two different ways, to give two different 40 bit values: as a 'native' EM tag, or as a 'Unique' standard. This is because Unique follows the same rules for extracting the 40 bits, but then adds another layer of interpretation before final output.
The base rules are: the first 9 bits are '111111111', followed by the 40 bit data broken into 4 bit chunks with a parity bit on the end, i.e. 10 x 5 bits, followed by 4 further bits of parity, and a single 'stop bit' (a '0'), giving a total of 64 bits. In the case of a native format EM tag you simple extract the 40 bits and convert it to HEX and that is your UID. For Unique, you still extract the 40 bits but do some further manipulation such as swapping nibbles (pairs of 4 bits) and changing MSB/LSB:
And the same applies to most tags of this type - FDXB, HID etc. follow a similar set of rules for manipulating the over-the-air data into the actual one for the end-user device to work with. Indala probably does too, but since it's encrypted and we don't know what the algorithm is, the only thing we're able to latch onto is the sync pattern, which is always zeros, so in that case we treat the 'raw' and the 'interpreted' UID as the same thing, but for most tags we'll either convert to the published standard, or to a human readable format that makes some kind of sense.
Specifically, for example, with HID tags, the 'UID' is normally interpreted as a Site Code and an ID, so the 'HEX' value is effectively broken down into two, and is presented in Decimal, with a 3 digit Site Code and a 5 digit ID - e.g. for a Site code of 123 and an ID of, say, 42, it would look look like '12300042'.
Similarly, the FDXB contains a Country or Manufacturer code, plus a Unique ID within that locality, as well as a couple of flag bits to show whether it's an Animal application and if further Data is available. My sheep tag, with country code 124 and animal ID of 270601654 is presented as 'A00124000270601654', which breaks down as 'A' (animal application), '0' (0 = no data, D = data), '0124' (4 digit manufacturer/country code), '000270601654' (local ID).
On the other hand, for the second tag type, like Hitag2 and Q5, when sending their UIDs on command they don't need to bother with such complex schemes as they know that the reader started listening only when the command was issued, and so the raw data need only be sent once, and may not even include any checksums or other synchronisation bits. Just grab the bitstream, turn it into HEX and you're done.
The whole issue is further complicated by tags that have multiple personalities, such as the Q5, Hitag2, T55X7 etc., and are capable of emulating other tags, so depending which data blocks you read and how you read them, you may get a different UID. A Hitag2 programmed to be in FDXB mode, will give you a valid FDXB UID if you simply read it in ASKRAW mode with the right data rate etc., but if you issue a 'START AUTH' command, it will also give you it's 'real' UID.
At the end of the day, it will be largely down to you as the end user to figure out what you're really dealing with through experimentation, but RFIDler (hopefully) gives you some useful tools to help with the process. The main one is probably the VTAG - a Virtual TAG. This can be used to store a copy of the original tag, which can then be used to create additional 'clones', convert the raw data to the appropriate format for emulation by another tag type, or simply to examine the underlying data... But that's a subject big enough to deserve it's own post, so I'll save it for next time...