×

Discussion Board

Results 1 to 5 of 5
  1. #1
    Registered User
    Join Date
    Mar 2011
    Posts
    4

    NFC - Card Emulation - wallet sccenario

    Hi there,
    I am new to this, so please excuse me for any misunderstanding while at the same time I will appreciate if one can correct it.
    I have been reading docs and working on samples esp for card-emulation mode. [simulator I am using is Nokia 6212 and 6131).
    I am trying to get the E2E picture clear here for the communication that happens between the mobile device and the POS terminal [contactless reader] in card emulation mode.

    If we have a requirement to build a mobile wallet which can hold multiple cards [credit/debit] issued by one party(bank) and allow the customer to use any of those card at the point of sale.
    There are quite a number of things evident that we will need :
    1. as many cardlets for each card hosted on secure element [ we might use the SIM secure element instead of internal secure element]
    2. one midlet for the UI purpose to retrieve the balances of each card [interacting with the specific cardlet wrt to the card] hosted on the device memory.
    3. one midlet that controls the card in terms of setting the priority of the card to be used hosted on the device memory.
    4. one CRS application [cardlet using globalplatform api] that helps to control the registry of apps as SECM.

    Now what is not clear, is the exact flow that happens and which components participate here.

    say, the user launches the midlet (or it can be launched automatically using Push Registry) before the POS terminal and select the card (from the list of cards in his/her mobile wallet), this involves the calling the SECM cardlet using the JSR177, which will change the priority of the card.
    Once the user has selected the card, user taps it on the POS reader and this should succeed in completing the transaction using the card selected.

    As I understand the POS reader in the contactless mode will send the WUKA/WUKB commands along with RATS command and resulting in ATS response command followed by SELECT PSE command and then using the AID from the CFI received from the response.

    But the missing links are the interaction between the NFC controller and the SIM [card emulation mode]. How does NFC controller passes the command to the exact AID when there are multiple secure element available such as SE on SIM and Internal SE.
    Where do NFC controller route the command SELECT PSE and to which applet/application?
    is the 1PAY.SYS.DDF01 file name fixed as I have seen at some places reference to 2PAY.SYS.DDF01... not sure what should be used? - I believe this should be standard.

    NFC controller is more likely to be just a communication medium where it receive the tags/message from the POS reader (or another device) and passes to the appropriate device, which unit does that intelligent work? What is that unit that parses the NDEF message extract the APDU command and pass it appropriately?
    How does the card-session is being maintained for the entire transaction?

    is there any contactless applet/application also needs to be written as part of this? as the cardlet using the Javacard Framework are more likely to be just processing the APDU commands..

    thanks,
    archit

  2. #2
    Registered User
    Join Date
    Feb 2009
    Location
    Hagenberg, Austria
    Posts
    121

    Re: NFC - Card Emulation - wallet sccenario

    Hallo,

    Quote Originally Posted by archit_agarwal View Post
    But the missing links are the interaction between the NFC controller and the SIM [card emulation mode]. How does NFC controller passes the command to the exact AID when there are multiple secure element available such as SE on SIM and Internal SE.
    The NFC controller does not process any APDUs. Instead the NFC controller only handles the low level processing. For a secure element connected through NFC-WI (wired interface), this means that the NFC controller only translates the analog signals to some digital signal and the processing of the ISO 14443 protocol is then done completely in the secure element. For the UICC there is some higher anstraction layers, where the processing of parts of ISO 14443 is already done on the NFC controller (check the SWP and HCI specifications from ETSI for further information).

    So, the NFC controller will NOT choose the secure element based on the commands/APDUs received, but requires one secure element to be explicitly selected befor any transaction. (Typically done by the user.)

    Quote Originally Posted by archit_agarwal View Post
    Where do NFC controller route the command SELECT PSE and to which applet/application?
    Any commands are routed to the currently selected secure element.

    Quote Originally Posted by archit_agarwal View Post
    What is that unit that parses the NDEF message extract the APDU command and pass it appropriately?
    Don't mix NDEF and card emulation. NDEF (NFC Data Exchage Format) is a data format for storing and exchanging data with NFC tags/across peer-to-peer links. They are used to enable the "It's all in a touch" experience (i.e. touch something to trigger some action). While NDEF messages can be transfered on top of APDU commands (cf. NFC Forum Type 4 Tags), this is not a requirement (see tag types 1 to 3 and the proprietary tag types from NXP: Mifare Classic [cf. AN 1305] and ICODE [cf. AN 2023]).

    Card emulation on the other hand is most likely to be used only for applications with high security requirements (like credit card payment). The cardlets communicate using APDUs. No NDEF messages are used here.

    Quote Originally Posted by archit_agarwal View Post
    How does the card-session is being maintained for the entire transaction?
    Just like with any other "normal" smartcard.

    br
    Michael

  3. #3
    Registered User
    Join Date
    Mar 2011
    Posts
    4

    Re: NFC - Card Emulation - wallet sccenario

    Thanks Michael for explanatory response.
    However, I have still some questions as I went through ETSI guidelines.

    For a secure element connected through NFC-WI (wired interface), this means that the NFC controller only translates the analog signals to some digital signal and the processing of the ISO 14443 protocol is then done completely in the secure element.
    Does this mean the applet deployed in the secure element should be able to parse the NDEF (Type-4 tags)?

    For the UICC there is some higher abstraction layers, where the processing of parts of ISO 14443 is already done on the NFC controller (check the SWP and HCI specifications from ETSI for further information).
    Are you referring to ETIS 102-613 and ETSI-622 or some other spec, [IMG]file://C:\Users\122891\Pictures\SWP-HCP-CLF.jpg[/IMG]

    So, the NFC controller will NOT choose the secure element based on the commands/APDUs received, but requires one secure element to be explicitly selected befor any transaction. (Typically done by the user.)
    How does the user selects the secure element? Isn't it the user selects the application deployed on the secure element? Does it mean by selecting the app, user implicitly selects the secure element as well? which component does understands this implicit behaviour?
    While referring to GlobalPlatform there is a concept of CRS application and CREL application does these come into the play?


    Don't mix NDEF and card emulation. NDEF (NFC Data Exchage Format) is a data format for storing and exchanging data with NFC tags/across peer-to-peer links. They are used to enable the "It's all in a touch" experience (i.e. touch something to trigger some action). While NDEF messages can be transfered on top of APDU commands (cf. NFC Forum Type 4 Tags), this is not a requirement (see tag types 1 to 3 and the proprietary tag types from NXP: Mifare Classic [cf. AN 1305] and ICODE [cf. AN 2023]).
    So, do you mean that in Card Emulation mode one should not use the NDEF-Type4 tags? if not then, does the POS reader sends the APDU commands directly to the active app on the secure element through NFC controller?

  4. #4
    Registered User
    Join Date
    Feb 2009
    Location
    Hagenberg, Austria
    Posts
    121

    Re: NFC - Card Emulation - wallet sccenario

    Quote Originally Posted by archit_agarwal View Post
    Does this mean the applet deployed in the secure element should be able to parse the NDEF (Type-4 tags)?
    No, as I wrote before, your cardlet will most likely not handle any NDEF messages. Unless you want to create an NDEF tag application (and even then you simply need to provide the file structure and your off-card applications will handle the NDEF parsing).

    Quote Originally Posted by archit_agarwal View Post
    Are you referring to ETIS 102-613 and ETSI-622 or some other spec
    Right, that's SWP and HCI.

    Quote Originally Posted by archit_agarwal View Post
    How does the user selects the secure element?
    That's not defined. Usually I would expect the user to be able to select the secure element from the phones' settings menus.

    Quote Originally Posted by archit_agarwal View Post
    Isn't it the user selects the application deployed on the secure element?
    Right, the user would also need to select the prefered *payment* application (only if multiple applications would fit the use-case).

    Quote Originally Posted by archit_agarwal View Post
    Does it mean by selecting the app, user implicitly selects the secure element as well?
    Most likely not. I would expect this to be the other way round: by selecting a specific secure element, the user limits the range of payment applications that are available to use.

    Quote Originally Posted by archit_agarwal View Post
    So, do you mean that in Card Emulation mode one should not use the NDEF-Type4 tags?
    I'm not sure what you are suggesting here... The NFC device will be either in reader/writer mode (to be able to read NFC tags) or in card emulation mode, but not both at the same time. (Although, from the user point of view, the mode will be automatically selected based on what item is touched (either another reader or a tag)).

    Quote Originally Posted by archit_agarwal View Post
    if not then, does the POS reader sends the APDU commands directly to the active app on the secure element through NFC controller?
    The NFC controller routes the "reader to emulated card" communication between the antenna and the secure element (with whatever level of abstraction/processing that is needed in between). So yes, the POS exchanges APDUs with cardlet.

    br,
    Michael

  5. #5
    Nokia Developer Champion
    Join Date
    Mar 2003
    Posts
    4,105

    Re: NFC - Card Emulation - wallet sccenario

    Quote Originally Posted by archit_agarwal View Post
    is the 1PAY.SYS.DDF01 file name fixed as I have seen at some places reference to 2PAY.SYS.DDF01.
    You have to go for the latter, because this is the wireless (proximity) Payment System Environment (PPSE). The last two bytes (‘01’) are a version number. The first byte is a variant: 1 = stationary; 2 = wireless. ‘1PAY.SYS.DDF01’ does not work for MasterCard PayPass for example. Did your project worked out?

Similar Threads

  1. NFC-Card Emulation
    By archit_agarwal in forum Mobile Java General
    Replies: 1
    Last Post: 2011-03-22, 15:26
  2. writing information to an internal card for card emulation
    By joery_vn in forum Near Field Communication
    Replies: 4
    Last Post: 2010-05-18, 15:16
  3. Card Emulation - Nokia 6131 NFC
    By sharmashashi17 in forum Near Field Communication
    Replies: 2
    Last Post: 2009-10-23, 13:10
  4. NFC Newbie (6131 card emulation)
    By saviodomnic in forum Near Field Communication
    Replies: 25
    Last Post: 2008-09-24, 17:05
  5. Nokia 6131 NFC card emulation
    By lfarady in forum Near Field Communication
    Replies: 3
    Last Post: 2008-04-08, 14:18

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •