Setting Custom AID for PN7150 in Card Emulation Mode

cancel
Showing results for 
Search instead for 
Did you mean: 

Setting Custom AID for PN7150 in Card Emulation Mode

811 Views
abalogh
Contributor II

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.

Tags (3)
0 Kudos
3 Replies

530 Views
mario_castaneda
NXP TechSupport
NXP TechSupport

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

0 Kudos

530 Views
abalogh
Contributor II

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.

0 Kudos

530 Views
mario_castaneda
NXP TechSupport
NXP TechSupport

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

0 Kudos