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.
Related
I don't know much about nfc and the nfc tags, I just wondering can I send the nfc tag's data to another phone through network, then that phone can read that data and create a copy of it on its own,finally it could open the door that protected by the keycard.
pic
reading NFC data (payload) isn't a problem, sending this in any way also, the real question is that receiving data-copy Android device can act as and emulate same NFC type. check out HERE for more options, but in short: that may depend on source tag type
your scenario looks very similar to card data stealing, NFC-based security systems are oftenly using some prevention, e.g. are reading some hard-coded and whitelisted card uid, which can't be emulated easily
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.
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.
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).
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