Libnfc:nfc-anticol

From NFC Tools
Revision as of 08:37, 21 January 2016 by Dereklau (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Anti-collision demonstration tool for ISO14443A tags, performed by custom constructed frames.

Warning: this is only a demonstration tool, it only supports ISO14443A tags and only one tag at once.
This may be in contradiction with the fact that it does anticollision but real anticollision can only be achieved by firmware in the reader chip to be able to detect bit collisions.

The first frame must be a short frame which is only 7 bits long. Commercial SDK's often don't support a feature to send frames that are not a multple of 8 bits (1 byte) long. This makes it impossible to do the anti-collision yourself. The developer has to rely on closed proprietary software and should hope it does not contain vulnerabilities during the anti-collision phase. Performing the anti-collision using custom frames could protect against a malicious tag that for example violates the standard by sending frames with unsupported lengths.

Background

Iso.14443-3.select.sequence.flowchart.png

To avoid multiple tags to respond at the same time there is a way to sort out and select only one tag. The reader tries to detect if there are more tags in the field. This is done by looking for collisions in the modulations from the available tag. There will be collisions with multiple tags because they will answer all at the same time, this time is specified by the ISO14443-A standard.

The anti-collision procedure is always performed as start-up communication between a reader and the tag. The anti-collision is required to detect which nearby tags are available. Every tag has a different unique identifier (UID). To avoid any collisions in the communication, the ISO14443-A standard defines the anti-collision protocol. The figure to the right presents the schematic overview of the anti-collision sequence.

The first action comes from the reader (initiator). It probes for any tag (target) that is within reading distance. The probing can be done in two ways, by sending a REQA(0x26) or a WUPA(0x52) frame. Both commands have a frame-length of 7-bits. To distinguish these commands from other communication frames it is 1 bit smaller than a byte and have no CRC bytes, other frames consist of more than one byte. The REQA (request) command invites all tags that are new in the field to respond (new means here that they have not responded before and are not previously disabled). The WUPA (wakeup) command wakes up all tags that are in the field, even those that were active or disabled earlier. Notice that when a tag does not leave the field (and the field stays on) it stays powered and active. This means that a WUPA command can be used without dropping the field while the REQA command requires to drop the field before invoking again any tag response.

When no tag responds, the REQA command is send over and over again. The delay between commands is proposed in the standard, in practice it is implemented a different way by every manufacturer. Experiments show that some readers wait a complete second while others use just a few milliseconds. As expected, the smaller the interval, the faster a tag can enter and leave the field again. This interval is not the only aspect that influence the speed, but it seems to be a rather large factor. Apart from this the speed also depends on the length, number and intelligence of the frames transferred between reader and tag.

A tag in the field will respond on a REQA or WUPA command with the ATQA block (answer to request). This will initiate the anti-collision procedure in the reader. The reader now tries to find all the tags in the field. Every tag contains a UID (unique identifier) that offers a distinction between tags. The length of the UID could be 4, 7 and 10 bytes. Some flags of ATQA block contain the bit-length of the UID. The anti-collision process is performed by doing a binary search to sort out single tags.

Binairy-tree-search-uid.png

After the reader has received the ATQA block, it sends a SELECT (select) command with the valid UID starting bit(s) responding to the current request of the binary search. When a UID of the tag matches on the prefix of these bits it will respond with its complete UID. If multiple tags are responding simultaneously on the SELECT command, a stricter prefix with more specified starting bits is send by the reader. As search area gets smaller ultimately an individual transponder can be identified. This process is visually displayed in the figure to the left.

If the mask singles out only one tag, the reader sends a new SELECT command with the specified UID of this tag. The tag responds with a SAK (select acknowledge) command. After the SAK command this cascade level is completed, but there could be multiple levels. For 7 UID bytes, the SELECT command will be invoked two times and for 10 bytes three times. When the SAK annotates that no more UID bytes are available, the anti-collision ends and the tag gets activated. In this state the tag processes all frames until a HALT (disable) command is received from the reader.

The anti-collision as defined in the ISO is always using non-encrypted data. This is vulnerable to several attacks like replay, relay and forgery. The next trace is observed from the communication between the reader and the tag during the anti-collision. For this example a tag is used with an UID length of 7 bytes. This means that two cascade levels are performed during the anti-collision. The communication is observed from the reader side.

R: 26                                    => Welcome (REQA) (or use WUPA = 0x52)
T: 44  03                                => Respond (ATQA)
R: 93  20                                => Select cascade 1 (SEL)
T: 88  04  34  74  cc                    => CT, UID(byte 1,2,3), BCC
R: 93  70  88  04  34  74  cc  0e  05    => Select available tag (SEL)
T: 24  d8  36                            => Select Acknowledge (SAK)
R: 95  20                                => Select cascade 2 (SEL)    
T: e1  e3  1c  80  9e                    => UID(byte 4,5,6,7), BCC
R: 95  70  e1  e3  1c  80  9e  b9  e1    => Finish select (SEL)
T: 20  fc  70                            => SAK without cascade bit set
R: e0  50  bc  a5                        => Request Answer to Select (RATS)
T: 06  75  77  81  02  80                => ATS (DESFire EV1)
R: 50  00  57  cd                        => Disable (HALT)

Found tag with UID: 043474e1e31c80

CT  => [Cascade Tag] byte (88), signals that the UID is not complete yet
BCC => [Bit Count Check] byte, calculated as exclusive-or over the four previous bytes

Screenshots

Example-anticol-screenshot.png

Personal tools
Namespaces

Variants
Actions
Navigation
Documentation
Misc
Toolbox
Partners