Does anybody see the possibility to enable (by enable I mean even compile the sources, e.g. as shown by Gerald Madlmayr on the http://www.nearfieldcommunicationsworld.com/2011/02/13/35913/uncovered-the-hidden-nfc-potential-of-the-google-nexus-s-and-the-nokia-c7/) the NFC NXP 544 to work in card emulation mode not using the SWP and UICC for SE as shown in the article, but using the SE on the microSD?
For this there is dedicated protocol S2C, but I would like to stick the the traditional SD card with the SE like the Mobile Security Card from G&D ( http://www.gi-de.com/en/products_and_solutions/products/secure_microsd/product_details_4992.jsp). It contains SE, which can be accessed by the standard file I/O commands, which are APDUs 'decorated' by specific 'magic' numbers, so they are by the SD card micro controller distinguished from other file I/O and those commands are send directly to the GP enabled secure element instead of the standard flash storage...
Thanks for comments and tips.
Regards,
STeN
That seems a possibility. Supposedly the SEEK project claims it is possible to send APDU commands to SD card (even without firmware modification). However we do not know as I answered you to your other question, if the only other NFC-enabled android phone, that is SGSII in some variants, supports the required protocol. With SNS our only choice as you clearly state is using UICC, which myself haven't being able to reach yet, using SEEK patches.
Related
I'm posting this question because I couldn't find an appropriate place to ask it.
I'm developing a custom secure element using a smartcard.
I successfully got SEService connected and got a Reader instance using seservice.getReaders().
However, when I called reader.isSecureElementPresent(), it returns false.
When I tried with a normal SIM card, I could find the secure element and it returns true when I called reader.isSecureElementPresent().
So I deduced that the phone can not recognize my custom SIM card which is a native smartcard. Actually my native smartcard works properly with a normal card reader and the card supports ISO/IEC 7816-4 interface with T=0 protocol.
And when I tried with a Java Card, the phone was able to find the card, and get the ATR successfully.
Therefore, the phone can not recognize the native smartcard but the javacard.
Is there a specific requirement for a secure element to be found by isSecureElementPresent() method on Android?
I looked through Open Mobile API 3.3, but there is not enough explanation about the isSecureElementPresent() method.
And I assume that the phone can not find my native smartcard maybe because it does not implement GlobalPlatform Card Specification since the Open Mobile API 3.3 is created by GlobalPlatform organization. And actually the Java Card supports the GlobalPlatform Card Specification. That is why I suppoed so.
This is an interesting questions, although I have no answer I can point out an approach to get hold of some information which I have already used.
2 guesses:
Your SE has no SIM card file system and is not recognized as an UICC
The carrier privileges applet (GP secure element access rules) is missing and maybe it is required
If this does not help here are the links to the sources for further study:
http://aosp.opersys.com/xref/android-10.0.0_r39/xref/frameworks/base/core/java/android/se/omapi/Reader.java
http://aosp.opersys.com/xref/android-10.0.0_r39/xref/frameworks/base/core/java/android/se/omapi/ISecureElementReader.aidl
Unfortunately the AIDL is internal. What I did was in this case to use Magisk and then the edXposed framework. The latter allows to intercept system calls, e.g. for logging purposes. I have written a sample project to unmask response APDUs of the radio log. This can be used for this advise and the next one.
At a lower level level it should also be helpful to see the exchanged APDUs. This should be possible by looking into the radio log with logcat -b radio *:V
Finally also very useful is a SIM card tracer to see how the phone interacts with your SE, e.g. see the APDUs. If some commands are returning errors you have hit a candidate. This should give you the complete control to compare an accepted UICC and your solution.
I have use the previous version of SIMTrace with success, but on older phones. If this is not available search for alternatives or maybe you have an engineer who can solder something together.
I am making a Host Card Emulation app on Android, everything works fine with my PC/SC reader. I am able to send APDU commands and get the reponses. Now I want to know if it's possible to manipulate the ATR of the card emulated by Android using Android's NFC library (or not)? I have looked into the documentation but there's nothing about the ATR, does Android generate it automatically for each device?
Yes, Android generates the answer-to-select (ATS) automatically. There is no Android API to change its contents. The same applies to the anti-collision identifier (UID).
ATS vs. ATR
Note that contactless smartcards (ISO/IEC 14443-4A) do not expose an ATR (answer-to-reset) during the activation sequence. Instead, they provide an ATS (in response to the selection procedure). PC/SC readers for contactless smartcards typically map parts of that ATS into an (emulated) ATR for compatibility.
Rooted devices
Even though Android does not provide an API, you might be able to modify values such as the ATS by modifying the NFC controller configuration files. See Editing Functionality of Host Card Emulation in Android and Host-based Card Emulation with Fixed Card ID
After reading a lot of questions, i decided to post this one. I read that stock version of android does not support API's for card emulation. Also, we cannot write custom applications to secure element embedded in nfc controllers due to keys managed by google/samsung.
I need to emulate a card (mifare or desfire etc). The option i can see is doing it via software. I have a ACR122U reader and i've tested that NFC P2P mode works fine with the Nexus-S that i have.
1) I came across a site that said that nexus s's NFC controller (pn532) can emulate a mifare 4k card. If this is true, can i write/read apdu commands to this emulated card? (Probably if i use a modded rom like cyanogenmod)
2) Can i write a android application that reads apdu commands sent from the reader and generate appropriate responses (if not fully, then upto some extent only). To do so, i searched that we need to patch nexus s with cynagenmod. Has someone tried emulating card via this method?
I see that this is possible since we have products from access control companies offering mobile applications via which one can open doors e.g. http://www.assaabloy.com/en/com/Products/seos-mobile-access/
Some facts that may be of help in your quest:
The NFC controller in the Nexus S (and Galaxy Nexus, Nexus 7 and quite a few other Android devices) is the PN544
Card emulation can be done either by the secure element connected to the NFC controller or by the host device (=Android device in this case). The Nexus S has a secure element that could be used for that (used in Google Wallet). Card emulation from the host device is not a feature of the PN544 NFC controller, although some claim that they have managed to get it working.
You can turn on card emulation by the secure element by rooting your device and following the instructions at https://stackoverflow.com/a/10506299/1202968 (haven't tried this with 4.x JB, but I assume that it still works).
Emulating a MIFARE Classic card can be done by the secure element in the Nexus S, but not by the host device. Emulating a DESFire card is not supported by the secure element in the Nexus S.
I have investigated a similar doorlock product that used card emulation itself to communicate to an NFC mobile device, while using card reader/writer mode to communicate to access control cards.
IMO, the 2 simplest options are: use P2P communication (Android Beam) or use card emulation in a reader device (if it supports it). All the other options require things like rooted devices and custom ROMs, which are not future-proof and have no possibility to be translated to a real product.
Card emulation via software is now available with Android 4.4. http://developer.android.com/guide/topics/connectivity/nfc/hce.html
2) Card emulation by software should definitely be possible, but not exposed in current Android APIs. You will have to dig deeper into the libnfc-nxp (and possibly below). This might be a difficult one though. This feature is offered on Inside Secure's chips, as shown in their OpenNFC reference implementation. The only question is whether it requires a CLF firmware change. If not, then you can hack it into a software image.
The caveats are, however, that you will lack the following features :
- security (an Android app is not as secure as a smartcard)
- fast and predictable response times (well, depends how you code it probably)
- card emulation running when phone is off
I believe SEOS is based on ISO14443-4 and not Mifare. This means you would need a secure element to run it.
1) Not too sure about this one, my guess is that this will still be hardware-based (e.g. depend on an embedded secure element such as NXP's SmartMX.
The other alternative is to start developing on a secure element. The most straightforward way would be to get some sample test SIMs with SWP/HCI support. There is a free dev kit called IzyNFC which you can use for the javacard, and GSMA and AFSCM technical documents for the Android application side.
I know NFC functionality is implemented in libnfc-nxp library in Android. So, does it mean that card emulation functionality is defined and implemented there, too? To be more specific, I have a phone in card emulation mode, my CPR 40.30 reader, however, cannot read nor write to the card emulated in it, as it doesn't even recognize the type of transponder.Although it can read the UID when touching the phone to it. When I asked someone for help, he asked me if I wanted to work with libnfc-nxp library.This is why I'm curious about this library and to know if I can modify it so that I can access card emulated in secure element. Any help will be very grateful
The actual card emulation is done by the embedded Secure Element in the NFC chip in Android NFC devices that use libnfc-nxp as the driver library. The library itself is only used to turn card emulation on or off.
Can you post the UID your reader is receiving from the phone? I do have the doubt that your reader is detecting an NFC target (and not the emulated card). If the ID starts with 0x80 (or ends -- depending on the byte order), it is the anticollision ID of an NFC Target.
I'm searching for a way to send specific commands from my phone to a reader.
I have already read that card emulation is not supported on android due to securtiy reasons, but it is possible via a firmware patch for android 2.3.4 on the Nexus S.
My main question is, do I really need card emulation to send defined APDUs to the reader and to recieve the answer APDUs or is there any other posibility maybe by misusing android Beam?
If I need to use card emulation are there any new insights?
The last posts, few posts I found are nearly one year old...
As adiditional information in the end I will not have any control over the reader.
Thanks for answering and on any new insights on card emulation.
It's possible in Android KitKat 4.4.
Check out this link, more information will be added soon I belive.
http://developer.android.com/guide/topics/connectivity/nfc/hce.html
What you are trying to achieve is somewhat candid. The reason smart cards are being used in NFC is because the NFC protocol is built in such a way that it is not possible to know the correct response in advance. There is always a secret involved, and you can't just guess it. Otherwise there would be a major security flaw in all the systems using contactless smartcards (building access control,
You can't just spy on the protocol, save the exchanges, and replicate them in some software, on most applications this will fail. There will be some random value at some stage, and some crypto computation to perform.
In order to emulate a card with the phone, you need a secure element (smartcard chip on the phone or the SIM card in your phone), and you need the NFC chip in your phone to route card emulation APDUs to this secure element (this is probably what the patch you are referring to is doing).
There are ways to do card emulation in an Android application, but I suspect this will require substantial patching, and you will not have predictible response time, so your reader might not like it. Also this will prevent card emulation from working when your phone is off (battery delpleted for instance).