Android and Symbian NFC mobile development questions and answers (FAQ)

后端 未结 2 617
执笔经年
执笔经年 2020-12-01 05:13

Let’s share on a common place ideas about the NFC development, technology… I warmly welcome any comments you might have – either about the Android or Symbian SDK or

相关标签:
2条回答
  • 2020-12-01 05:19

    In order to be a little bit more practical, and not only theoretical, I have posted some patches on xda-developers to enable card emulation mode on the currently unique android phone supporting NFC (the Nexus S). You and others might be interested in playing around with card emulation mode by yourselves. Take into consideration that this is only for experimental purposes.

    They apply to gingerbread versión 2.3.4_r1 of the AOSP sources. They allow:

    • Enabling NFC card emulation mode on the Nexus S. This mode is always enabled.
    • Disabling reader mode, letting the card emulation being the only one working.
    • Selecting an external secure element (in UICC) instead of the embedded one (in SmartMX chip).
    • Although not related, removing time-limit to bluetooth discoverability option.

    What I have found out about NFC card emulation on Android so far:

    • Card emulation is disabled by default on stock images and require a firmware modification. Alteration of Nfc system application and libnfc-nxp system library are the places to look at.
    • Embedded SmartMX chip inside Nexus S presents itself as a dual smartcard. A programable one (allowing installing of cardlets on it) based and a 4K Mifare one.
    • The 4K Mifare card has default keys, so it can be written/read from an external reader.
    • The programable card is supposed to be GP compatible, but no one except Google can fiddle with it since access keys are not public.
    • Nexus S does support SWP and allows to operate with a secure element located inside an UICC.
    • Applications can not access directly to any contents of secure elements. On one hand the embedded SE is unaccessible because we do not know the keys. On the other hand the external element is accesible externally by means of SWP (that connects to NFC controller) but not internally because AFAIK the SIM slot is not connected by other means to the NFC controller. This leaves us with only one path, the baseband processor. However BB firmware is propietary and controlled by manufacturers. Samsung has not implemented the 3GPP TS 27.007 Technical Specification to interact with it in its BB firmware.
    • OTA access to external SE should be possible, this lies in hands of MNOs. Some of the might offer TSM services to allow 3rd party access to SE inside UICC.

    By the way the technology you mention (NFC-WI) is already used in the Nexus S to interconnect the NFC controller with the embedded secure element.

    Upate

    To summarize I answer Sten's questions:

    Since the Mifare 4K area has default keys, anybody with the external NFC reader can change the keys and securely store values there – is that correct? Did you try it? Does this come with any difficulties?

    Short answer yes, I did access Mifare 4K from an external reader. I was able to modify default keys too. The difficulties come from modifying system sources and building a custom firmware yourself.

    Is use of the external NFC reader the only way how to access the Mifare space?

    Theoretically no. The other alternative would be sending APDUs to the SIM, containing the Mifare commands to execute on the Mifare card.

    Can e.g. application installed on the Android phone read/write some data to Mifare 4K using some API (over NFC controller and NFC-WI path)? Can e.g. seek-for-android help there?

    For the time being no. Though you modify the AOSP sources with seek-for-android patches (I did it myself) your application will just crash with stock phones. The reason is that they have not implemented the 3GPP TS 27.007 Technical Specification, that allows the application processor to send APDUs directly to the SIM (UICC).

    However there could be some light ahead of the tunnel, since citizy project in France are already using secure element mode of NFC technology with Android phones, taking the UICC secure element approach. In fact there is a modified Samsung Galaxy SII model in use and the new Acer Liquid Express will also be soon available to integrate into citizy. Those phones are bound to have the required TS 27.007 specification implemented in their baseband processor firmware. When it comes to application processor I do not know if they took the SEEK-for-android from G&D path or the OpenNFC from Insecure. Being french I would bet all-in for the last one.

    0 讨论(0)
  • 2020-12-01 05:35

    So to continue the discussion I will just summary it: The NXP SmartMX microcontroller consists of two separate secure elements. The first one is programmable, runs some operating system (e.g. MULTOS or Sm@rtCafe or other) and a JavaCard VM, but it is locked and the production access keys there are in Google or TSM hands only. There is no way to install JavaCard application for testing purposes here, since it is not possible to unlock the secure element for test purposes.

    Also there is no way how to utilize the SIM card, because even if this can be technically possible, for the commercial application deal with MNO is necessary. Let’s stop for a while with the Mifare 4K, which seems to be the most promissing:

    Since the Mifare 4K area has default keys, anybody with the external NFC reader can change the keys and securely store values there – is that correct? Did you try it? Does this come with any difficulties?

    Is use of the external NFC reader the only way how to access the Mifare space? Can e.g. application installed on the Android phone read/write some data to Mifare 4K using some API (over NFC controller and NFC-WI path)? Can e.g. seek-for-android help there?

    Thanks STeN

    0 讨论(0)
提交回复
热议问题