topic Re: Setting Custom AID for PN7150 in Card Emulation Mode in NFC

Setting Custom AID for PN7150 in Card Emulation Mode

abalogh — Tue, 12 Nov 2019 00:56:37 GMT

I'm Developing with the PN7150

~ OM5578/PN7150-Kit

And have been following and using the given Example (AN11990) as a baseline

~ PN7150 Example Code

So far I've gotten the board to function as expected when operating in the Reader/Writer and Card Emulation Modes,

where I've been focusing on performing Raw exchanges (Non-NDEF) of data between the PN170 and other NFC-Devices.

I'd like to know if it is possible to change the Application Identifier (AID) that the PN170 reports

when it is operating in Card-Emulation Mode?

My use case is that I want to limit the NFC-Devices that may communicate with the PN170 at all.

When the PN170 is operating in Reader/Writer against NFC-Devices operating in Card-Emulation Mode (ISODEP),

I just have the PN170 send an APDU SELECT command that specifies the Custom-AID that I want to use.

If the NFC-Device does not reconize the Custom-AID, communication is dropped.

When the PN170 is operating in Card-Emulation Mode it seems it uses

the AID of D2760000850101 (NDEF Tag Application)

when communicating with NFC-Devices operating in Reader/Writer Mode.

In the AN11990 Example I've tried to find where the D2760000850101 value(s) were defined,

and change them to instead use my Custom-AID;

NfcLibrary/NdefLibrary/src/T4T_NDEF_emu.c

- Used for/in Card-Emulation Mode

- T4T_NDEF_EMU_APP_Select (Made appropriate changes to APDU Select Command Data)

NfcLibrary/NdefLibrary/src/RW_NDEF_T4T.c

- Used for/in Reader/Writer Mode, but I still tested changing the values anyway

- RW_NDEF_T4T_APP_Select20 (Made appropriate changes to APDU Select Command Data)

- RW_NDEF_T4T_APP_Select10 (Made appropriate changes to APDU Select Command Data)

However I have not seen any noticeable effect from changing these values with respect to the AID they contain.

What I would like is that if an NFC-Device operating in in Reader/Writer Mode is brought to the PN170,

and it does not specify my Custom-AID in its APDU SELECT command,

that the communication be dropped.

Re: Setting Custom AID for PN7150 in Card Emulation Mode

mario_castaneda — Mon, 02 Dec 2019 22:16:09 GMT

Hi Andrew,

Please accept my apologies for the late reply.

I tested by my side and I am able to change the AID.

const unsigned char T4T_NDEF_EMU_APP_Select[] = {0x00, 0xA4, 0x04, 0x00, 0x07, 0xD2, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x00};
‍

I am reading out the DFname and getting the AID that I previously program.

phpalI14443p3a_ActivateCard--------ENTRY--------

Send to card: 26

Recv from card: 0100

Send to card: 9320

Recv from card: 0865ACDC1D

Send to card: 93700865ACDC1D

Recv from card: 20

phpalI14443p3a_ActivateCard--------LEAVE-------- pUidOut=0865ACDC pSak=20 pMoreCardsAvailable=00 [STATUS = SUCCESS]

phpalI14443p4a_ActivateCard--------ENTRY-------- bFsdi=08 bCid=00 bDri=00 bDsi=00

Send to card: E080

Recv from card: 0578804100

phpalI14443p4a_ActivateCard--------LEAVE-------- pAts=0578804100 [STATUS = SUCCESS]

phalMfNtag42XDna_IsoSelectFile--------ENTRY-------- bOption=00 bSelector=04 pFid=10E1 pFid=10E1 bDFnameLen=07 pDFname=D2112233445566

phpalI14443p4_Exchange--------ENTRY-------- wOption=8000 pTxBuffer=00A4040007

phpalI14443p4_Exchange--------LEAVE-------- [STATUS = SUCCESS]

phpalI14443p4_Exchange--------ENTRY-------- wOption=C000 pTxBuffer=D2112233445566

phpalI14443p4_Exchange--------LEAVE-------- [STATUS = SUCCESS]

Send to card: 00A4040007D211223344556600

phpalI14443p4_Exchange--------ENTRY-------- wOption=4000 pTxBuffer=00

phpalI14443p4_Exchange--------LEAVE-------- ppRxBuffer=9000 [STATUS = SUCCESS]

Recv from card: 9000

phalMfNtag42XDna_IsoSelectFile--------LEAVE-------- [STATUS = SUCCESS]

How are you changing the AID? Be care of the APDU frame.

Regards,

Mario

Re: Setting Custom AID for PN7150 in Card Emulation Mode

abalogh — Thu, 05 Dec 2019 15:46:47 GMT

Hello Mario,

I had mentioned that I had been focusing on performing Raw exchanges (Non-NDEF) of data between the PN170 and other NFC-Devices.

For the PN170-Example, I have the following settings changed from the default state;

- P2P_SUPPORT symbol not defined (global)

- NO_NDEF_SUPPORT defined (global)

- RW_RAW_EXCHANGE defined (/Application/nfc_task.c)
- CARDEMU_RAW_EXCHANGE defined (/Application/nfc_task.c)

That being said, I've since realized that I am not at all using the declarations in the

NfcLibrary/NdefLibrary/src/T4T_NDEF_emu.c file, or any of the files in the NfcLibrary/NdefLibrary directory for that matter.

And so changing the values in those files would have no effect for my use case, since I am not, and do want to be performing NDEF communication, which is why I have the NO_NDEF_SUPPORT symbol defined.

The NFC-Device I have operating in Reader/Writer Mode is communicating by the iso14443/iso7816 protocol,

and in that device I am able to change the AID it sends within its APDU SELECT command.

When I bring the device to the PN7150,

within /Application/nfc_task.c we have the following sequence of function calls;

task_nfc ->

PICC_ISO14443_4_scenario ->

NxpNci_CardModeReceive ->

-> case 0xA4 (Select File Command)

Using an AID of D2760000850101 on the NFC-Device, or any other AIDs of the correct Format will have communication go through

~ e.g. F00102030405060708

But this is not really the behavior I want. I would like that if the AID provided by the NFC-Device is not exactly what I have defined in the PN7150 that no communication take place.

Re: Setting Custom AID for PN7150 in Card Emulation Mode

mario_castaneda — Wed, 11 Dec 2019 20:26:53 GMT

Hi Andrew,

The issue is at some point the Android phone is being detected as another device type than expected (for instance as a remote peer device while we expect a remote card).

This could be observed by looking to the I2C traces or to the NCI trace (see NCI_DEBUG compile flag of the NXP-NCI example to see how it can be enabled in NXP-NCI code example).

Just to confirm, is your workaround working? I double-check and this fix is correct.

Regards,

Mario