Today is Samstag, 23rd März 2019

Posts Tagged ‘P2P’

Development with Android Beam and NFC Peer-2-Peer

NFC offers three different operating modes:

  • Card Emulation Mode
  • Reader Writer Mode
  • Peer-2-Peer Mode

Reader Writer Mode is already available in Android since the first Gingerbread release in December 2010. Card Emulation Mode, which is actually required for Google Wallet, is not yet available for public. Peer-2-Peer Mode as defined in ISO 18092 is now finding its way into Android devices, also known as „Android Beam“.

NFC: Touch is the new click.

The idea behind NFC was to invent a new killer application of a mobile device – but what is it? It’s not payment, not ticketing and not BT pairing. It is every day life. So what can you help during every day life? You have a bunch of keys in our pockets, so what about making access easier? There are several cards and coins in your wallet, and for sure you don’t have the change when you need it. So let’s put a technology into mobile devices that allows us exactly to do this with our most personal device: the mobile phone. And in 2004 Sony, Philips and Nokia agreed on starting to work on this technology, and they called it NFC.

NFC Starter

NFC is a wireless communication technology to cover distances up to 10 cm, possible data rates are 106, 212 or 424 kBit/sec. A “classic” NFC transaction doesn’t take too long, about 200- 500 ms in order to keep the user experience good. User experience is actually the “key” behind NFC. The technology provides an easy and intuitive interaction, like a simple touch. You probably know this kind of contactless transaction already from one of your contactless smartcards you use for payment, access or ticketing and as you may have experienced, the time for the transaction is quite short – and that’s good. Or would you like to wait 10 seconds until the door opens? (Also think of the people queuing behind you!)

Smartcards & RFID

Depending on the standard use, these cards are either proximity cards (according to ISO 14443) or vicinity cards (according to ISO 15693). Both standards use the so popular RFID Technology, so I’ll talk about that first. RFID standard for Radio Frequency Identification. The technology bases in the inductive coupling of two coils/antennas. Depending on the antennas and the power used to generate the electro mangentic field, distances starting from some centimeters up to several meters can be briged by using RFID Technology. There are several different frequencies used in the RFID Industry, popular ones are: 125 kHz, 13,56 Mhz (used by ISO14443, ISO15693, ISO18092) or 900 Mhz. In an RFID System there is usually an active reader, that generates the electro mangentic field and a passive transponder (tag, smartcard) that is powered by this field (and thus needs no battery). After the passive part is powered, the communication is established and both parties can exchange data. The active part (reader) emitting the field is also called initiator where as the passive one (waiting for the initiator) is called target. So far for the electro magenetic stuff (from a very basic, theoretical side) and back to the smartcards.

13,56 MHz

As already mentioned both proximity and vinicity card use 13,56 Mhz and therefore are compatible on the very low (physical) layer of communcation. ISO 15693 actually is not considered by the NFC Forum – the standardization body for NFC – thus, I will not give further details on this standard. During the standardization of ISO 14443 the two major players (Infineon, Philips; now NXP) could not agree on a modulation schema, thus there are two different one: ISO 14443-A (Philips, now NXP & Co.) and ISO 14443-B (Infineon & Co. ). There are several popular products using ISO 14443, like the RFID Passport. One of the most widely used RFID Card is Mifare. Mifare is not compliant to ISO 14443 on all levels (only 1 – 3) as it implements a proprietary cipher. Several public transport Systems, like London (Oyster) or Hongkong (Octopus) use Mifare. The cipher actually was broken in 2008. In Japan Sony has introduced its one contactless Smartcard: Felcia; there it is used for Payment & Public Transport (Suica). Felcia is neither ISO14443-A nor –B. NFC Devices in the further should be able to overcome all this different smartcard standards and should be able to talk to any of these contactless smartcards or reader.

NFC (= ISO18092) vs. NFC Device

When talking about NFC, I’d first like to clarivy two terms: when talking about „pure“ NFC, I’m talking about ISO18092, which specifies the NFC peer-2-peer mode. (see Operating Modes). When talking about an NFC device, I’m talking about an NFC device like a handset, that features also other operating modes, like reading smartcards or acting as a passive tags.

Operating Modes

This brings me now to the different operating Modes of an NFC Device:

  • Reader/Writer Mode: This mode is also called PCD (Proximity Coupling Device), as in this case the NFC device emits an electro magnetic field, that powers a passive transponder. Operating in this mode, the NFC device can read and alter data stored in NFC compliant passive (without battery) transponders. Such tags can be found on SmartPoster e. g., allowing the user to retrieve additional information by reading the tag with the NFC device. Depending on the data stored on the tag, the NFC device takes an appropriate action without any user interaction. If a URI was found on the tag, the handset would open a web browser for example. An NFC device can read the data format of the Tag, which is call NDEF (NFC Data Exchange Format). NFC Devices must be capable of reading different ISO14443 tags and Felica.
  • Card Emulation: An NFC device can also act as smart card (ISO 14443) after being switched into card emulation mode. In this case an external reader cannot distinguish between a smart card and an NFC device. This mode is useful for contactless payment and ticketing applications for example. Actually, an NFC enable handset is capable of storing different contactless smartcard applications in one device.
  • Peer-to-Peer: The NFC peer-to-peer mode (ISO 18092) allows two NFC enabled devices to establish a bidirectional connection to exchange contacts, Bluetooth pairing information or any other kind of data. Cumbersome pairing processes are a thing of the past thanks to NFC technology. To establish a connection a client (NFC peer-to-peer initiator) is searching for a host (NFC peer-to-peer target) to setup a connection. Then the NDEF (NFC Data Exchange Format) is used to transmit the data.

Great new world

The great thing about NFC devices now is that you don’t only have passive transponder or an RFID reader, but also a display and a keyboard to interact. Secondly, there is no air time that will be billed by the operator when using NFC (but if you open URL, of course, a GRPS connection is opened billed). And: the transaction is only made by intention, as the range is very short. It’s not like Bluetooth that can send data over several meters. NFC only works within some centimetres. This also helps to provide a better user interaction. Let’s say: I want to pay now. So I touch this reader. Payment done. (without pressing _one_ single button!) Or: You take a picture, you touch a printer and it is printed. You don’t have to care about anything like pairing devices. NFC can do that for you. NFC will make life and interaction more simple, as world already is too complicated.

Device Integration

NFC technology integrated in a mobile device typically consists of two integrated circuits. The NFC controller is required for the analog digital conversion of the signals transferred over the proximity connection. An HCI (host controller interface) allows the host controller to set the operating modes of the NFC controller and process data sent and received. The second IC, a secure smartcard chip also referred to as the secure element, is used for the tag emulation mode. The secure element is connected to the NFC controller for proximity transactions (external mode e. g. for payment at point of sale ) through the Single-Wire Protocol (SWP). The host-controller as well is able to exchange data with the secure element (internal mode e. g. for top up of money into the secure element over the air ). In order to access the functionallity with an Application, there a two APIs:

  • Contactless Communications API (JSR257): This JSR was released in 2006 and describes the necessary interfaces in order to allow contactless transactions with a J2ME application running on the handset. Thus this API makes use of the reader/writer mode as well as the NFC peer-to-peer mode. The JSR257 already implements the NDEF format and the basic RTDs published so far by the NFC-Forum.
  • Secure and Trust Service API (SATSA, JSR177): The JCP released the SATSA in 2004. The intended goal of this API was to provide cryptographic functionality of a smartcard chip to J2ME applications. Also, the use of a secure storage for DRM certificates and digital signatures was a use case during the definition. With the introduction of NFC and the use of a smartcard chip for tag emulation, this API received a boost in importance. Recently in 2007 a maintenance release was published.

Both APIs allow an application developer to use the functionality of an NFC device. By providing a J2ME API for using NFC technology, the barrier to application developers is lowered in comparison to using proprietary Symbian OS or Windows mobile APIs.

Nokia at the moment offers three different NFC Devices: The Nokia 3220, Nokia 6131 and the Nokia 6212. The Noia 5140 with the RF Shell is not considered as an NFC device, as it only supports Reader/Writer Mode. All three Nokia Models come with an NXP NFC Chips inside (PN511/512 or PN531/532) and SmartMX Secure Memory Chip with a Java Card OS from G&D. The Chip is the same as in a G&D SmartCafe Javacard. The integration of the NXP solution is called smart connect.

The solution allows you to switch between internal access of the secure element (eg: a Midlet is reading/write data of the smartcard chip), Active/Initiator Mode (in this case the device activly emits a field) and Passiv/Target/Card Emulation Mode (in this case the device is found by an external reader or other Initiator). This switing of the operating modes is also called „Mode-Switch“ Actually, there is only one mode at a time possible, which causes the following problem: Imaging, you are reading an external tag and would like to use a key, to authenicate, that is stored in the secure element. In this case the midlet requires to read on the one hand site the tag and on the other handset to access the secure element. But you can’t do that and you need to implement some kind of work around for that.

Welcome at