For decoding the symbol streams into bytestreams we must take into account the symbols generated by the encoding. The ISO/IEC-14443-2 standard also defines these symbols in sections “8.1.3 Bit representation and coding” for PCD and “8.2.5 Bit representation and coding” for PICC. The procedure for extracting the symbols and the exchanged bytes is very simple and does not require advanced programming skills, as shown below.
One thing to note from ISO/IEC-14443-2 is that the air interface supports several bitrates and bit encodings. For correct bitrates and encodings handling we must follow the specifications given in the ISO/IEC-14443-3&4 standards. The rest of the air interface interception procedure for extracting the command-response pairs exchanged by the reader and the tag is dependent on tag type.
The procedure described here is not new and has applications that go beyond debugging the NFC air interface. It is possible to combine tools like SciLab and MatLab with many different data acquisition front ends to create our own customized hardware debugging tool.
At this point we can arrive to another obvious conclusion: The NFC air interface is not only observable and analyzable with generally available tools. With relative ease an attacker can sniff into the air interface and extract the information that was exchanged between reader and tag. This corroborates our first conclusion from previous part: The NFC air interface must always be considered part of the unsecure region.
Is the previous statement conclusive enough to drive the decision of not integrating NFC technologies for wireless communications?
Do you find SciLab or MatLab useful for testing your data processing algorithms before going into hardware and software implementations?
What other uses you see for the possibility of downloading the digitized signal from the DSO?