Develop Reference

Is it possible to capture Android phone SIM card APDUs?

I want to know are there any methods to log/trace APDUs which is communicated between SIM and Android Phone (ME)?
I want to log APDUs which transferred during the mobile network handshake process.

I am not aware of any software method to do this.
There is a Simtrace 2 under Osmocom project which provides a hardware based logger:
Osmocom SIMtrace 2 is a software, firmware and hardware system for passively tracing SIM-ME communication between the SIM card and the mobile phone, and remote SIM operation.
While it was designed for SIM-ME communication, it supports all ISO 7816 smart-cards using the T=0 protocol (the most common case).
Good luck with your project!

NFC card emulation

I would like to write an application where I can store NFC tag on my phone so that NFC readers can access it. For example storing a boarding card on phone so that it can be accessed by NFC reader at the airport. I guess it can be implemented beaming NDEF messages, however in order to do that the phone needs to be on.
My problem is, I need to get it working when phone is off. As per my understanding, the only way is to store the NFC TAG in Secure Element (SE) so that it can be emulated as card. NFC reader's power can be used to access information stored in SE.
Is there anyway I can store my TAG to Secure Element? As per my search so far, there is no way to access SE directly. Following post talks about it, not sure if things are changed since the time it was posted.
NFC card emulation Android
If storing in SE is not possible, is there any other way to store TAGs on the device so that it can be read by NFC reader when phone is off.
Thanks
B

When it is a strict requirement that your emulated card ("NFC tag" is not necessarily the best terminology to use in that context) is accessible while the phone is powered off, then your only option is to use a technology that bypasses the phone's main application processor. Consequently, your only option is to use a secure element.
Accessing the SE: This requires cooperation with either the device manufacturer (for embedded SEs) or the mobile network operator (UICC/SIM card). If you have that cooperation, they will likely be able to give you further advice on how to access their SE. If you don't have that cooperation, then there is pretty much no way to get access to an SE on a production device. (I did not mention the µSD scenario, as this is completely idependent of a device's NFC chipset.)
Other options: All other communication through the NFC interface is performed by the mobile phone's main application processor. Thus, in order to have such capabilities (peer-to-peer data exchange, host card emulation, inverse reader mode) the device needs to be powered on and have its operating system loaded.

How to store data within Secure Element of Android? Ref : Host Card Emulation

Since the launch of Kitkat, Android claims that Secure Element is not required for Host Card emulation. If its not required then, how does anyone can store any card details in Android ?
There is OffHostApdu Service also which developer.android.com says to refer to incase if our android app has access to Secure Element - Can anyone explain
Also, is there any limit on memory of Secure Element data ?

Since the launch of Kitkat, Android claims that Secure Element is not
required for Host Card emulation. If its not required then, how does
anyone can store any card details in Android ?
With Android Kitkat you have two possible ways to do card emulation:
Host based card emulation. In this emulation you write an Android service that emulates a card that responds to ISO7816-4 APDU commands. The service is able to store data just like any other Android service or intent.
Off host card emulation. Here the card emulation code resides within the secure element. In general these card emulations can not be implemented by users but are implemented by your phone manufacturer, telephone provider or bank. Access for ordinary users is not possible because the keys to install applets on the secure element are secret.
The secure element has no access to the host to store data, but it can use the non volatile memory provided by the secure element itself.
Each card emulation must be registered with an AID (application identifier). These AIDs can either be registered for a host based card emulation or for an off host card emulation.
If a NFC reader starts talking to your phone it will send out a SELECT APPLICATION command containing the AID that it want to talk to. Once the NFC chip receives such a command it will check it's internal registry of registered card emulations and route everything that is registered for the secure element to the secure element. All other communication is routed to the host. The host will check it's own registry of available off-host card emulations and start/activate off-host card emulations services if it finds a matching AID.
Also, is there any limit on memory of Secure Element data?
Yes, sure there is a limit. If there wouldn't be a limit we could just forget about hard-disks and expensive storage, buy one secure element and store all the data of the world on it :-)
The exact amount of free memory on a secure element depend on what kind of secure element is built in your phone. Different brands and models come with different memory sizes. Also the memory is limited if there are applets pre installed on the secure element. You usually don't have to worry about this because it is highly unlikely that you'll ever get the keys to install an applet on the secure element anyways.
In general anything from 64kb of storage up to several gigabytes is possible.

Android application to mimic a physical RFID card

Is it possible for an Android application to send a previously stored RFID card ID to a NFC reader? The aim would be to use an Android device to enable access to a room instead of a physical RFID card.
Having read a lot of other threads about NFC/RFID & card-emulation, I came to the conclusion it was not available for now in Android but I'm still kinda confused if it apply to this particular case. Can't the application simply send the card ID within a NDEF message or an APDU command or I'm just completely dreaming?

Well, strictly speaking. For what you want to do you don't need card emulation. You just need to send a token to the door lock that can be validated.
You could do this with Android beam by pushing an NDEF message to a device that is compatible, SNEP is the protocol you'll be looking for.
A solution I would prefer would be to get the door lock device to emulate a tag. Then you could have your Android app register a listener for that tag (Doesn't even need to be running). When the tag is detected that app will fire up and send your secure token to the lock by using the tag write NFC functions in the Android SDK.
Securing your token is another matter.

The android view:
Long story short: It's not possible.
Long story long:
It would be possible from a hardware and software point of view to do this. The NFC chips are perfectly capable to emulate most (not all) standard tags. The functionality to do this is even built in the lower level software but not exposed to applications.
Why: Emulating tags is what the entire mobile payment infrastructure is built upon. Allowing two card emulations of the same type at once is for most NFC chips not possible and will also shut off mobile payment as mobile payment readers only accept a single tag at once (for security reasons).
Things are a bit different for RIM based Blackberry phones, they allow card emulations (even have this feature out of the box) but they don't do any mobile payment at the moment as far as I know.

During an NFC payment is the phone active or passive?

When somebody purchases something and pays with google's NFC payment system (google wallet) , is the phone sending information to the register (if yes, what?) or is it just receiving the cashier's ID code, and then completing the transaction online (like dwolla)?
-gk

during the payment the phone behaves exactly in a the same way as a contact-less payment plastic card (it is based on same ISO/IEC standards). Phone works in so called 'card-emulation' mode. The card is emulated in the secure element, which is highly protected chip. This chip can be so-far programmed only by Google or Samsung. Only those two manufacturers or possibly highly trusted 3rd party (currently I am not aware of any) companies have the possibility to use the build-in NXP SmartMX secure element. It means that nobody else can develop similar application like Google Wallet.
You can of course use other NFC HW for payment - the SIM card, but then you must deal with MNOs (Android SDK does not support the SWI officially), bluetooth NFC sticker or NFC SD card or SD card connected with NFC antenna via NFC-WI (S2C). Note that the last option is the best one, but is not supported by any phone.
You can also invent some proprietary payment system, which is less secure or which uses different schema like e.g. NFC PayPal application, which does not use the secure element, but the peer-to-peer mode for communication between phones. In this application the NFC is just the bearer to transport information - they can do the same over bluetooth or WiFi.
BR
STeN