bytebasket.com

...applied technology

Home
Welcome to bytebasket.com!

RFID and NFC

My wallet is full of plastic cards. Access cards, credit cards, loyalty cards, ID card, health insurance, stored value tickets and more.

I like to have things done easily, no filling of forms, not having a lot of cash "just in case". Getting things done with just presenting one of theses neat "smart" cards looks like a great solution. Being owner of the Nokia N9 smartphone with build-in NFC capability since a couple of month triggered my interest for NFC and RFID. There is recently also a of talk about mobile payment, which increased my interest. What standards are there? Would it be possible to transfer a part of my plastic load onto the phone and wave the phone instead of the single cards?
I try to summarize and give an overview about RFID (Radio-Frequency Identification) and NFC (Near Field Communication).

RFID vs. NFC

In short, RFID is the technology below NFC. The NFC forum has been founded by Nokia, Phillips and Sony to standardize and promote RFID applications on smartphones. It has now about 150 members. NFC standards describe the communication protocols (basically re-using existing RFID specifications) and data formats. E.g. a smartphone user could touch a smartposter with an embedded NFC tag, reading the tag using one of the standard RFID specs, and interpret the NFC standardized data record. This can be a URI, opening the phone's browser and direct him to a specific web page with more information.

Physical Layer

As a "radio man", operating an amateur radio station for some time, I was firstly interested in frequency bands and the lower layers.

LF (Low Frequency) Band

120-150 kHz. This has been used for first deployments, access cards and animal IDs. Not widely used for new deployments anymore. Range about 10cm.

HF (High Frequency) Band

13.56 MHz. Most proximity card applications deployed today are using this band. Proximity in this context means the user has to narrow card or tag and reader intentionally, usually to not further than a couple of centimeters. One widespread standard in this band is considered a vicinity standard, allowing a maximum reading distance of 1-1.5m. In practice this distance depends on reader and card and is often less.
There are a couple of different modulations and protocol standards in use. I will focus on this band in this article.

UHF (Ultra High Frequency)

868-870 MHz (Europe) and 902-928 MHz (North America). This used for vicinity applications, e.g. reading is not limited to having objects to read very closely to the reader. The main use is article tracking in warehouses and shops, using EPCs (Electronic Product Codes). A reader can read all single EPC RFID tags of a pallet full of EPC tagged articles without getting close to each single item. This would allow a speedy check-out at the supermarket cashier, without unloading the shopping carts.

Other Bands

Other bands are in use for military applications, toll gates and other applications. Partly active tags are used here. Possible bands are, but not limited to: 433 MHz, 2.4 GHz, 5.8 GHz, 3.1 GHz, 10 GHz.

Basic Operation

RFID readers generate a magnetic field which is inductively coupled to the passive RFID tag. The RFID tag can draw it's own power supply from this field, e.g. it works basically like a transformer. The reader can modulate this RFID field which will be read by the tag. The tag in turn does not transmit on it's own, but modulates the reader's field by changing the load. The communication is half-duplex, e.g only one side sends data at a time.

13.56 MHz

There are 4 main standards used on this band:

ISO 14443 A and B (counted as two standards as readers and cards often support only one variant)
The differences between A and B are the modulation, coding scheme and initialization procedure, which are described in part 2 and 3 of this ISO specification. The transmission protocol specified in part 4 is identical for both.
The reason of having two variants for 14443 is that two implementations had to be merged into this ISO standard: The A version originated from NXP/Phillips, while the B version came from Infineon.
It seems that 14443A applications are having the bigger market share. The Mifare RFID tags and cards from NXP use naturally the A version and have a big market share. Mifare tags are used as stored value tickets as well as as access cards. The ePassport as specified by the ICAO must be compatible to 14443 and depending on the chip manufacturer is using A or B.

ISO 18092 (FeliCa)
This RFID variant was designed by Sony and proposed as a third version (C) for ISO 14443. It did not make it into 14443 and was later standardized as ISO 19092. Main application seems to be electronic purse applications and in Japan and ticket systems in some other countries.

ISO 15693
This is the vicinity standard among the 13.56 MHz standards. This specification allows card reads in up to 1.5 meter distance.
Contrary to payment and ticket system, were it is desired that the card is intentionally placed at a defined location to show consent to a specific transaction, this vicinity standard is suitable for access systems in which waving the card approximately into reader direction, or even keeping it in the pocket, is more convenient or desired.
The widespread iClass access cards from HID use this standard.

Security

All the above mentioned applications require authentication / authorization of the reader. This can happen on various levels. Usually cards are divided into several application areas or segments / blocks. Each area requires a different key. There can be separate keys for just read access, read/write access or to increment or decrement an integer value like the monetary value. Early implementations like the Mifare Classic card have been already hacked and can be read / copied. iClass access systems use often the same master key in various deployments. In spite of those weaknesses, many of those vulnerable RFID systems are still in use.

Another threat are relay attacks, in which a man-in-middle provides a long distance communication path between the RFID tag and the reader, emulating a reader at the victim's location, and a card at the targeted reader. With this construction no keys needs to be hacked, only the low level communication needs to be implemented. It is enough to be close to the card owner and have an RFID antenna close to his card, e.g. in a crowded subway. On the remote end an assistant can operate like the real card was present, e.g. get access somewhere or do financial transactions. The feasibility of this attack has been proven already.

There is also a concern about location privacy. Without accessing secured tag data, the easily readable tag ID could be used to track the location of a person. Although this attack is difficult to do given the needed frequent proximity to the targeted person, especially for most 13.56 MHz standards, the risk is potentially there. As UHF EAN labels are emerging, e.g for clothing, there is a real risk here. UHF EAN labels can be tracked from a distance and would allow to get movement profiles of persons wearing clothes with such labels, mostly without their knowledge.

NFC

The goal of the NFC forum is to promote the usage of RFID applications on smartphones.  To allow easy migration of existing applications and to allow smartphones to communicate with a wide area of tags and readers (in passive or card emulation mode), NFC compliant phones must support ISO 14443 A and B, as well as ISO 18092 as the RFID base for smartphone NFC applications. I found one source stating that 15693 was considered for NFC as well, but I could not get confirmation for this.

Nokia N9

The N9 comes with a PN544 NFC controller from NXP. It supports all of the above mentioned 13.56 MHz RFID standards, including the 14443A Mifare variant . In "Card Operation Mode", the PN544 can appear like a passive tag / card to a reader and send data using load modulation. This seems to be NOT supported for ISO 15693.
NFC smartposters can already be read and the browser opens with the URI read on NFC compatible tags.

Conclusion

RFID and smartphones seem to have an interesting common future. I will follow the development and do some experiments using the N9's RFID capabilities, if my time allows.

 

What Makes Us Motivated?

Here is something not technical that I want to share. Actually it is related. What makes open source work? Why dedicate thousands and maybe millions of people their unpaid time to technical projects? How could Linux succeed?

Watch the rather surprising truth here:

http://www.youtube.com/watch?v=u6XAPnuFjJc

Are HR departments aware of this? Are they ready to learn? I am afraid not.

 

Getting ready for IPv6

The alarm bells are ringing everywhere: we are are out of IPv4 addresses! What does this mean for the end user? In most cases nothing! There are enough IPv4 addresses for the backbone infrastructure and servers. The bottleneck is on end user side, especially in some booming regions which have not large enough IPv4 pools available. But the shortage is not only based on a growing number of individuals using the internet. Its based on the increasing amount of devices used per individual and the probably exploding amount of non-human IP users, e.g. machine-to-machine (m2m) applications.

Is there any need for action for the end user? I would say no. As long as the ISPs can assign IPv4 addresses, everything is fine. So let's wait until the last v4s are gone.... As soon as ISPs are forced to assign IPv6 addresses, the mess begins.

The problem lies not on the network side. An increasing amount of websites are already reachable on IPv6. Sometimes the IPv6 address is only visible on special names servers. E.g. besides the test url http://ipv6.google.com, which has ONLY an IPv6 AAAA record, e.g. needs IPv6 to be reached, most other Google servers have already IPv6 addresses besides their IPv4 addresses. But those are not returned to the average user; name servers return only the IPv4 address. This should avoid problems with incorrect working dual stack clients. There is an agreement between the network operator and Google necessary to return AAAA records. This shows that shows that simply trying to ping6 an arbitrary domain to see who is IPv6 ready, does not give us a correct picture about the IPv6 readiness. The IPv6 readiness on server / information provider side if bigger, but in some cases hidden.

Ideally most servers will be reachable from IPv6 only clients when the end user IPv6 mass rollout begins. It should be easy for the hosters to get IPv6 ready. We can expect that only a view servers will be IPv4 only when the mass rollout begins. For those destinations there are special solutions possible, like NAT64.

On the user side the situation is different. Many consumer devices and applications do not support IPv6. What about ADSL routers, WLAN access points, IPTV boxes, IP telephones, VPN clients for home offices, network printers, mobile phones, digital photo frames, etc.? SIP is a challenge as well.
The ISP would probably provide a new ADSL modem/router, but everything on the private LAN is left up to the users. Not all of those devices need Internet connectivity. But for sure there has to be a co-existence of v4 and v6 for some time. And this mix will probably cause a lot of confusion.

Should I get IPv6 now?

There is actually no benefit to get IPv6 now, if you have IPv4. I see only one reason to get IPv6 in parallel to the existing IPv4 connectivity: For point to point protocols like file sharing, and direct peer-to-peer applications like VoIP and video conferencing, it might be a benefit to have IPv6 as well as soon as a critical mass of IPv6 only hosts exists. In the web 2.0 age, and with ever increasing IP connection speeds, more and more information consumers become information providers. And in the near future, those new private providers might be not in the position to get an IPv4 address, unlike the big players. This makes proxies and translation services necessary. It's unclear what limitations this imposes and how reliable this would work.

Besides this, the professional user might want to test today what impact IPv6 has on his home network, how the existing nodes behave and how to protect the network without the usual NAT protection. Some headaches about incoming traffic can certainly be solved with global reachable IPv6 addresses and such scenarios could be tested as well today already.

IPv6 tunnels

A couple of protocols make it possible to establish an IPv6 tunnel over an IPv4 network. The IPv4 network will be used as link layer for a point to point connection to a tunnel service provider and into the parallel world of IPv6 routing.

There are a couple of ISPs offering IPv6 tunnels free of charge. A very popular one is Hurricane Electric. They offer free IPv6 addresses using the 6in4 tunnel protocol. Their offering can be used to get IPv6 on a single host, or by implementing the tunnel endpoint on a router and make IPv6 available on the whole LAN.

Benefits:
- all hosts can use IPv6
- permanent IP addresses
- all hosts are reachable without special NAT traversal measures and can act as servers
- IPv4 remains available

I have set up a configuration with a separate IPv6 tunnel router, primarily for testing. This provides both, IPv4 and IPv6 in my LAN. Especially it is also interesting to test how I can continue to use my IPv4 only devices in a simulated IPv6 only environment, e.g. my Grandstream VoIP desktop phone and apps like Skype.

The steps are described here:

IPv6 using Hurricane Electric's 6in4 tunnel

 

Virtual Machines

I maintained a dual boot installation on my main desktop PC for some time now. Ubuntu is my default OS, providing all productivity tools like email client, OpenOffice for text documents and spread sheets, web browser, photo editing, network analysis and much more. But there are still applications requiring Windows. In my case it's the missing Linux support for my Canon 9000F scanner and my preference to use Paint Shop Pro over Gimp for some things. Therefore the XP on the second HD partition. But it's time consuming to reboot the PC to switch OS's.

Until today I did not want to invest time to set up a Virtual Machine environment on my PC. I also had doubts about the stability. I can not yet answer the question how reliable my setup is, but for sure Oracle's VirtualBox is super easy to setup fulfills all my requirement! I can only recommend to try it and for many it might be the preferable solution over a dual boot configuration.

There are two versions available: The Open Source Edition (OSE), which is part of many distribution's repositories, and the professional edition, to be downloaded from Oracle's web site. Both are Open Source,  the professional version is freely available for private use.

Highlights of the VirtualBox are USB support and ability to map folders from the host OS to the guest OS. Unfortunately there is no drag- and drop between host OS and VM windows possible.
For me it is possible to use the original Canon scanner SW (which is only for Windows available), scan my stuff and save it to a Linux folder for further processing or storage. This is a major improvement over rebooting the PC!

Besides this, it is very easy to create multiple VMs, install SW for testing, preserve the VM in any state and transport the whole VM elsewhere.

There are many instructions on the net how to install and use Oracle's VirtualBox. As a quick reference I put a short guide together here:

HowTo short guide

 

Browsing Privacy

How easy is it for someone to track our movements in the world wide web? Dynamic IP addresses? NAT? Disabling cookies?
This all seems to be of not much help!  Interestingly our individual PC and browser configurations are so diverse that there are rarely two of the same kind! And this information is available for the server. Means two corporations using a common database could identify you as being one and the same person accessing their web pages.
You can put this to the test here:
https://panopticlick.eff.org/
At least my configuration proofed to be unique out of 1,379,358 tested so far!

IPv6 Privacy Implications

The 128 IPv6 address space is divided into a 64 bit prefix and a 64 bit interface identifier. Especially the interface identifier is of interest here. The Interface Identifier was planned to have the MAC address embedded. The MAC address can identify the used HW uniquely. Furthermore it will tell us the manufacturer plus potentially the type of equipment if there are different MAC blocks used for different products.

This privacy design flaw can be corrected by using the Privacy Extensions. Those do not embed the MAC address and change the Interface Identifier regularly, while listening additionally on the previously assigned Identifiers for some time.
IPv6 privacy extensions are available on many OS, but for example not on iOS (4) and Android (>=2.1). As especially those devices are personal devices, the users are easily re-identifiable if IPv6 is used!