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!
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.
For android phone which supports volte, they can directly place call with jio sim without data require, but the phones without volte needs to use Jio4GVoice app or a custom rom which supports volte to make phone calls.
IS there any way , we can implement it for offline use?
4th Generation network, which we also know as LTE, was developed forecasting the growing data needs of the future. It was intended to replace wired broadband with wireless devices, a platform for which had already been set with 3G networks.
Hence this time, their focus in the development phase was not Voice, but only Data. To simplify network designs, all communication in & out was to be handled on fully-IP networks, much like the present Internet. This would enable faster, simpler communication than 3G, since all communication is now referred with their node's IP addresses. It was only in the final phases of development that they practically realised, for 4G to completely replace legacy systems, they must find a way to transmit Voice over the network, which they succeeded in, with VoLTE.
Basically, VoLTE speaks for itself, i.e. Voice over LTE.
VoLTE transmits Voice in Data form, much similar to VoIP internet calls we make on WhatsApp or Skype or Google Voice.
This means, you always need to establish a Data network with your respective 4G operator. This is unlike the system established in 2G/3G networks, where it would establish data networks only when you needed to surf the internet. Those were based on two way systems, different for Voice & Data.
4G transmits both Voice & Data simultaneously over the same Data pipeline, so you have the right to only be charged in Data you consume & not Minutes you talk. Which is the reason why Jio does not charge you separately for calls. The bandwidth required to transmit Voice is very small, (most calls usually fall in the range of KBs, in standard plan you get 1GB per day) & so Jio deducts the data used for Voice from your Data balance.
Since everything is data, you need to establish the data connection on your 4G smartphone or JioFi router to make calls. Hence Jio4GVoice app cannot function without a data connection.
I've seen in various VoLTE enabled smartphones, they still give you a Data Toggle/Switch to turn on/off data so that you can conserve some when not in use. It does not physically terminate data communication with the network, since it is the only connection. Rather, it just isolates all apps on your system from accessing the internet, and only the Dialer is given access to continue to make & receive 4G VoLTE calls.
Hope I've managed to solve all your curiosities.
I am trying to understand the technology behind NFC. I have a basic understanding of the protocol, the physics behind the technology and the immense power it brings to the wide range of applications that could be there.
Now I am trying to understand the the different modes in which an NFC enabled device (may be a smart phone) can operate.
I understand that the device may take up the role of a reader/writer or a card (card emulator). However, what I do not understand is what is the need for having the initiator and the target modes of operation ?
My understanding is :-
In a passive communication mode between 2 NFC enabled devices, one device takes up the active role (thus acting as the reader/writer) and the other device takes up the passive role (and thus acting as the card emulator).
And we know that the active device (in a passive mode of communication between 2 NFC devices) is the one that creates an RF field and constantly polls to find out nearby NFC enabled devices that are ready to act as a card emulator.
So is it not just obvious that the the device acting as an active device (taking up the reader/writer role) is the one that would be the initiator of the communication ? Why is a separate initiator and target ** mode required when it can be inferred easily from the **reader/writer or card role ?
You got it right:
The distinction between target and initiator is only of significance in the peer-to-peer communication mode (aka Android Beam). In this mode one device powers the field and acts like a card reader/writer. This is the initiator. The other device takes over the target role and technically acts like a card emulation.
The difference between target and initiator is significant in the LLCP protocol which implements the peer-to-peer functionality. Reason for that is, that the target cannot send data on it's own. It first has to be asked from the initiator if it wants to send something.
The LLCP protocol (among other things) abstracts this difference and lets the initiator poll the target at regular intervals. If you write communication code on top of this protocol (or anywhere higher in the protocol stack) you don't have to worry about the target/initiator mode at all anymore.
For completes sake here is also a operation mode within peer-to-peer where the two devices are powering the field (called active mode), but this is rarely used because support for it is not that great.
To answer your question:
Why is a separate initiator and target ** mode required when it can be
inferred easily from the **reader/writer or card role
The naming is there to avoid confusion. Take peer-to-peer initiator mode for example: Also it is technically 95% identical to reader/writer mode there are still some minor differences. You don't want your peer-to-peer initiator to connect to a real card but only to peer-to-peer targets for example.
Naming this mode initiator instead of reader/writer avoids confusion.
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