Hallo JMC,

I think there is a big misunderstanding out there of what card emulation
is (and what it is not!).

First of all, NFC has three different communication modes:
* Reader/writer mode,
* Peer-to-peer mode, and
* Card-emulation mode

*Reader/writer mode* is used to access NFC tag (i.e. tags that comply to
the tag formats specified by the NFC Forum and contain NDEF data).
Moreover, this modes provides compatibility to existing RFID (13.56MHz,
inductive, proximity coupling) card infrastructures (i.e. you can
interact with contactless smart (and memory) cards, like MIFARE,
ePassports, ...)
The Nexus S supports reader/writer mode for 3 (4) contactless standards:
    - ISO/IEC 14443 Type A (e.g. MIFARE) and Type B
    - JIS X 6319-4 (that's FeliCa)
    - ISO/IEC 15693 (that's vicinity coupling cards, which is not NFC
      but uses a similar communication technique also in 13.56 MHz)

*Peer-to-peer mode* is used for direct communication between two NFC
devices (e.g. two mobile phones, but an NFC device can be pretty much
anything). This mode lifts the restrictions imposed by an "active reader
-- passive card" system. Thus, in a classic RFID/smart card system there
is a reader device that starts and controls the communication with one
or multiple cards, and cards that process commands received by reader.
Whereas, in a peer-to-peer system any device can start (and control) the
communication with any other device.
Peer-to-peer mode is used to exchange any data between NFC devices. This
data can be as simple as NDEF messages, but it's even possible to tunnel
other network protocols like IP over a peer-to-peer link.
The Nexus S supports the peer-to-peer protocol (NFC-DEP, ISO/IEC 18092)
with LLCP (NFC Logical Link Control Protocol) on top. With the current
API level only a simple exchange of NDEF messages (with Android's
proprietary protocol on top of LLCP) is possible.

*Card-emulation mode* is used to emulate a contactless smart card with
an NFC device. This mode provides compatibility to existing RFID
(13.56MHz, inductive, proximity coupling) reader infrastructures. An NFC
device in card-emulation mode acts the same as any "real" contactless
smart card.
With card emulation it is important to notice the difference between a
_contactless smart card_ and an _NFC tag_:

  - An NFC tag is a contactless transponder that has a certain memory
    layout and contains standardized data elements (NDEF messages).
    Four such layouts are defined by the NFC Forum (tag types 1 to 4).
    Tag type 1 is based on Innovision's Jewel tags, tag type 2 is
    based on NXP's MIFARE Ultralight. So I would not consider these
    two "smart" cards (they are more like simple memory cards). Tag
    type 3 is based on FeliCa and tag type 4 is based on the ISO/IEC
    7816-4 smart card standard. Therefore, the latter certainly are
    smart cards. Yet, in this case an NFC tag is a smart card with a
    specific file layout (i.e. a card that contains the "NDEF
    application").
    Besides the standardized NFC tag formats, vendors like NXP have
    created guidelines for using their contactless card technologies
    (e.g. MIFARE Classic) as NFC tags.
    An NFC tag is only data storage and doesn't have (may have but
    not use) special security features like data encryption, ...

  - A smart card can be much more than an NFC tag. A smart card can
    contain, for instance, a credit/debit card application, a
    ticketing application for public transport ...
    These applications have even existed before NFC. They DO NOT use
    the NDEF format to exchange data. Instead they use their own
    protocols (e.g. EMV for payment cards). Often they use special
    security features of smart cards (high security execution
    environment, highly secure data storage, cryptographic
    processing power ...)

So the card-emulation mode allows the emulation of a contactless msart
card (and not an NFC tag, although the smart card could *possibly* be
used as NFC tag). As applications like credit cards typically have high
security requirements, card emulation is not handled by the NFC device
itself (i.e. the application processor of an NFC-enabled mobile phone).
Instead, the NFC device has a dedicated hardware component (the
so-called Secure Element) that handles all the card emulation. (*)

  (*) This is not entirely true, as some NFC controllers (like the
      PN544) would theoretically allow the emulation of ISO/IEC
      14443-4 contactelss smart cards from the application processor.
      Yet, I don't know of any NFC phone that makes this functionality
      available to the user and I rather doubt that this will become
      available on the Nexus S.

The Secure Element (SE) is typically a smart card itself. But instead of
a normal contact/contactless smart card interface it has a connection to
the NFC controller, which connects it to the NFC antenna.

The Nexus S has an integrated SE (a SmartMX combined into the same
package as the PN544 NFC controller). This SmartMX emulates a ISO/IEC
14443 (Type A) smart card and a MIFARE Classic card.
In addition to this integrated SE it is possible to use a special UICC
(also known as SIM card) that supports the Single Wire Protocol (which
is an interface designed for the communiction between the NFC controller
and a UICC) as the SE.

So the Nexus S will definitly support the emulation of contactless smart
cards (with a bit of tweaking the Android sourcesthis is already
possible to some extent). Yet, the SE is a protected environmentwhere
you can't simply install your application. Instead, you have to ask the
owner for permission to install your application. The "owner is not the
user who bought the device but instead the device's vendor. So, for the
internal SE of the Nexus S it is Samsung/Google(?) who decide who gets
access to the SE. For the UICC it is your telco who decides this.

As a consequence an "NDEF application" will most likely not make it into
the SE. So you won't be able to use your phone as *NFC tag*. But there
is not much use for this anyways as a device that understands NDEF would
most likely be an NFC device that also supports peer-to-peer mode.

To summarize this, card emulation will certainly become available for
the applications you mentioned. But it will not be used to transport
*NDEF data* between devices.

br,
Michael



On 02.04.2011 22:45 JMC114 wrote:
> Hey Michael,
> 
> Why - may I ask - do you think this possibility will not be made
> available to android phones? It seems to me it's a rather important
> part of NFC. The part where it makes phones compatible to existing
> infrastructures based on RFID (without changing those
> infrastructures), namely those in public transport, building access,
> charge points for electric driving, etc.
> 
> I - for one - believe the general public's adoption of NFC technology
> strongly depends on this.
> 
> Thoughts?
> 
> Gr,
> JMC
> 
> On Mar 23, 11:03 am, Michael Roland <mi.rol...@gmail.com> wrote:
>> Hallo,
>>
>> the current SDK does not allow you to use card emulation.
>>
>> Anyways, with card *emulation* you will not be able to simulate an
>> *NFC tag* (i.e. a tag where you store simple NDEF messages). Card
>> emulation mode allows to emulate a contactless smartcard (typically
>> used for applications with high security requirements, like credit
>> cards). While such a card (emulated or real) can be used to carry NDEF
>> messages, I really doubt that this possibility will be made available
>> for the Android phones.
>>
>> br,
>> Michael
>>
>> On Mar 23, 5:14 am, Zhihong GUO <gzhh...@gmail.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>> Hi all,
>>
>>> about NFC in Gingerbread, is it possible to simulate a tag by the SDK? I
>>> have found the support for tag read/write and P2P push message, but haven't
>>> found any support on card simulate.
>>
>>> thanks
>>
>>> James
> 

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to