I'm trying to get a better understanding of how the Secure Element on an android phone interacts with a reader in card emulation mode. Any insight to the following questions would be useful.
Theoretically (based on hardware design), is it absolutely necessary to go through the SE when communicating with a reader? If I'm not interested in sending private data, is it possible to "transceive" directly to a reader? If yes, how would that work?
If you do have to go through the SE, conceptually, how does that work? For example, say a reader sends a SELECT AID command...presumably, the android host queries the SE to get the SELECT AID command. If the host wants to respond to the SELECT AID command (assume dynamic responses), does the host send the response back THROUGH the SE? I've read a lot about querying the SE to get info (e.g. ISO 7816-4), but haven't yet understood this final point. How do you send responses to a reader?
This is for current generation NFC chips, the next generation are a bit more flexible:
From the NFC chips point of view, the chip has two different hosts, the Secure Element and the Android host.
The NFC chip also knows which host has opened which operation mode on the NFC chip (e.g. peer-to-peer, reader-modes, card emulation modes etc).
Requests and events that belong to one operation mode will only be send to the host that has opened the operation mode.
For secure elements the most usual 'mobile payment' configuration is that the SE opens card emulation in the NFC chip, and the android hosts opens reader-modes and peer-to-peer.
If an external reader gets detected by the NFC chip all communication will get sent to the SE only. The Android host will not see any of the data exchanged between the SE and the external reader. The android host may however see that an external RF field has been detected at the antenna, so android knows that something is happening.
The software running on the SE usually consists of a small OS that manages multiple applications, parses the SELECT AID command and forwards the requests to whatever application matches with the AID.
The applications running on the SE may decide later to send data to the android host. These events are called transaction events and are a one way communication. The android host is not able to reply to the transaction events sent from the SE.
The android host will also not be able to send data to the SE via the NFC chip. If it wants to communicate with the SE directly, e.g. to install a new application, it has to use another physical connection, usually the sim-card pins or the micro-sd pins.
For completes sake: There are also embedded secure elements that are built into the NFC chip. These don't have any physical connection and the NFC chip allows bidirectional communication between the android host and the SE host.
Theoretically it is not necessary to "go through the SE" when communicating with a reader. If the NFC chip has the capability to generate a card's RF signal (some NFC chips do), the phone can send responses directly to the reader. Of course, you need an API for that to be able to access this functionality from your app. Android ICS does not have such an API (in contrast, BlackBerry OS does have one).
Related
Can an Android device pretend and connect as a Bluetooth controller?
Can Android devices connect as a device to, say, a PC and act as a gamepad or similar device?
Is it allowed and doable in code without root access?
I tried this code: Connect Bluetooth devices. But it can not get it to pair.
Short answer, yes.
I recommend looking at Google's example project on Bluetooth communication BlueToothChat initially. Based on what you've written, I think you're missing several important steps.
You need all of the following components / steps:
General Overview
Set up Bluetooth
Set Permissions
Scan for other Bluetooth devices
Query the local Bluetooth adapter for paired Bluetooth devices
Connect to a remote device as client or server
Transfer data over Bluetooth
If you have access to the device your attempting work with as a controller, then you can create your own communication setup. Define a set of parameters to write and read on both sides that emulate the functionality you're looking for.
If you do not have access to creating your own read/write setup, or you want to use standard interaction methods for the industry, then the best bet is the Bluetooth HID Device profile mentioned by #Morrison Chang.
The HID profile basically establish an industry standard of required device features, read/write formats, combinations of features equaling a controller type (ie: "this is a keyboard"), and data mappings for what read/write numbers mean on either side of the client / server connection.
From the linked comment thread, the Kontroller project on Github has source available for your peruse.
There's also a reasonable Intro to Bluetooth HID that covers some of the topics on what Bluetooth HID is actually doing.
Finally, also recommend looking at Google's own BluetoothHidDevice page.
I am looking for a way to establish p2p communication between an Android phone (lets call it A) and a PN532+microcontroller (lets call them B).
By p2p I mean a scenario in which:
1. A sends some application specific data to B
2. B receives data and sends a response containing application specific data to A.
I have seen similar questions but most of them date back to 2011, stating that such functionality is not yet supported by the API. Looking at the latest API I can still only see a solution in which B is treated as a TAG.
Am I missing something or is the kind of communication I am looking for is still not supported?
When you want to specifically use NFC peer-to-peer mode, then the same answers are valid today: Android only supports Android Beam for P2P communication. Hence, you can, in general, only transmit one message into one direction and you need to tap the Beam UI each time you want to send data. However, if your interaction is exactly 1 message from Android to PN532 and then 1 message from PN532 to Android, and you are okay with tapping the Beam UI when sending from Android, you could use some tricks to first receive the message from Android, then disconnect and reconnect to send the response to Android.
When you are open to support other modes, then you have some options:
If the Android device has Android 4.4 or later and supports host card emulation (HCE): Use the PN532 in reader/writer mode and implement a HCE service on the Android side.
Otherwise, use the PN532 in host card emulation mode and access it from the Android side using the standard NFC reader/writer API (e.g. IsoDep / NfcA or NfcF).
I want to create an application to exchange information between 2 devices via NFC.
I know how to make one mobile send information to the other using Android Beam. What I don't know is how two phones could send data to each other with just one touch.
Is this possible? If yes, how?
That depends on what you are trying to achieve and what Android version(s) you are using:
Both devices with Android < 4.0
Both devices can send one NDEF message each with no user interaction required. The messages cannot depend on each other (i.e. it's not possible that one device sends a message and the other one sends an answer to this). You would use a combination of enableForegroundNdefPush() and enableForegroundDispatch() to achieve this.
At least one device with Android < 4.4
Both devices can (theoretically) send one NDEF message per touch, but user interaction is required on both devices (i.e. the user needs to touch the Beam UI). Moreover the Beam UI on both devices needs to be touched pretty much at the same time. Otherwise, the Beam UI on the other device will get interrupted due to the received NDEF message. Thus, this "solution" is not really usable. You would use a combination of setNdefPushMessage*() and enableForegroundDispatch() to achieve this.
Both devices with Android 4.4+
Starting with version 4.4, Android has two new features:
NFC reader mode and
Host-based Card Emulation (HCE).
When you combine those feature (i.e. you have a HCE on-host card emulation service on one device and put the second device into reader mode), both devices can communicate with each other (real bi-directional communication) using ISO 7816-4 APDUs.
This is possible, as explained online here. There is also an API demo in the API demos provided with the SDK that discusses this.
However, keep in mind that NFC has a very small payload size, and you're unlikely to be able to transfer any sizable data using it. NFC should instead be used to quickly setup bluetooth connections, or another form of wireless transfer like WiFi direct, which can then be used to transfer larger amounts of data.
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.
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.