I am gonna write a Payment Application based on Host-Based Card Emulation(HCE) of Android 4.4 (Kitkat) but I don't understand a process between AID (Application ID) and HCE service of Android 4.4 after I read this article Host-based Card Emulation. After we register an Application ID of both "Payment" and "Other" Category in the manifest file, Where else is the AID used? or It is used for Our written HCE service to recognize and then do whatever that define in our written HCE Service?
or It is used for Our written HCE service to recognize and then do whatever that define in our written HCE Service?
This is the case. You register your AID in the manifest file. If a reader selects your AID the NfcService then knows which HCE-service to start and to dispatch APDU transfers to.
All further communication will then get routed to your HCE Service until the reader selects a different AID or the reader stops providing the RF field.
Related
I want to Convert my existing app code which interact with Kernel mode driver(WDM driver). For IOCTL i’m using DeviceIoControl APIs.
For porting my app to UWP i’m using this link : https://learn.microsoft.com/en-us/cpp/porting/how-to-use-existing-cpp-code-in-a-universal-windows-platform-app?view=vs-2017 .
After applying changes in project properties as mentioned in link, i’m getting error as DeviceIoControl identifier not found. That’s issue i’m facing. Is there any sample app/API available instead of DeviceIoControl?
Actually, we added DeviceIoControl to the allow list in RS5. You need to get a HANDLE to the device first, and that will require two changes
Call CreateFileFromApp instead of CreateFile
The device being opened needs to grant access to app container. If
you own the driver and it is a custom device interface, you can use
a custom cap.
If you are accessing an in box defined device interface, you can’t get a direct HANDLE to the device. If your MSR access driver is a pnp driver you can use the guidance above.
You can't use DeviceIOControl from UWP apps. You can see the list of supported Win32 and COM APIs and this is not one of them. UWP apps have a more restricted security model to make it harder to use as a malware vector, so you can't interact with arbitrary kernel mode drivers.
There is a specific scenario where you can enable a custom capability and use Windows.Devices.Custom APIs. See CustomCapability sample. This is intended for hardware support aps generally. See Hardware Support App (HSA): Steps for Driver Developers.
As mentioned by #Xavier Xie, CreateFileFromApp and CreateFile2FromApp are available in later Win10 releases to get brokered device handles from app container. This is probably the easiest approach if you already have a lot of Win32 code that you want to port.
Device access also has UWP version in Windows.Devices.Custom. This also brokers the device handle but encapsulates it into a CustomDevice object which you can use to do IO control to your device.
Note: in both cases, the device handle gets brokered (ie. created in the runtime broker in medium IL, and marshaled into the app container) if the app its self doesn't have permissions to directly open the device. What this means is that the device interface will still need to be ACL'ed or otherwise granted access such that the app can open it.
The most current best way to grant access to an app to access your device is through a custom capability. The Device Access Broker will check the interface's DEVPKEY_DeviceInterface_UnrestrictedAppCapabilities key for the app's PFN. In the legacy flow, Device Access will check DEVPKEY_DeviceContainer_PrivilegedPackageFamilyNames.
I am completely new to the NFC scene and pardon me if this question is quite obvious. I have an Identive Cloud 4700f card reader and I want to use my android phone to beam data to this card reader via android beam.I do not intend to use HCE since I want a to&fro(P2P) communication.Is this possible through the PCSC protocol using c-APDU and r-APDU. If so is there any knowledge base where I can get a list of all APDUs to communicate to&fro (P2P) between the card reader and the phone.
Here is the link to Identive 4700f Data sheet
I am told that there is a fax modem that operates as a printer, and that I can use that as a standard printer in Windows to accomplish printing to fax destinations. Is that true? If so, what would be the best fax modem to use?
I see that there is a fax device in Windows 7 called Microsoft Shared Fax Driver. Is it possible to print to that, purely in code, without user interaction or popups, to achieve printing to fax?
This is for an application that I work on that can generate reports directly to printer. But we are talking with a client that wants to the reports to go directly to fax. Our application is a reporting library, so there's no user interaction, although there can be configuration to set the fax number, for example. We use J2D+JPS on the Java side, and System.Drawing.Printing on the .NET side. I know that the client could implement this with third party libraries, but I want to address the possibility of simply using our existing direct-to-printer feature.
You can use the built-in Fax Service Extended COM API to send a fax programmatically, and without any user interaction.
The API allows you to check if there are any fax devices installed on the machine (via the FaxService.FaxDevices collection) and attach files to a FaxDocument via the Body property.
A caveat: the Body property is actually a string containing the path to the file that should be sent as a fax. From the documentation: the body has to be associated with an application that is installed on that computer, and the application has to support the PrintTo verb. This means that you can't fax the report directly from an in-memory object; you'd have to generate the report to some temporary printable file (an image, a PDF, or XPS) in some location, and set its' path to the Body property of the FaxDocument.
We have a mifare card system and are looking into the possibility of using NFC chips in phones as mifare cards.
I have done a bit of research into NFC but the question that I cannot answer is do NFC chips in mobile phoned have a unique identifier that I can read like a mifare card has ?
Also if the NFC chip dies have a unique code can I just read it using the NFC reader or do I need an application on the phone to put it into card-emulation mode ?
I work for a large agency and this same question was proposed. In summary, I was able to successfully emulate a mifare classic chip (our id card) and gain access to all facilities as if I was using my id card (lenel access control). However, in the end the solution was a hack and a half. Only devices with NXP NFC controllers could this be possible on. Further, I had to modify the nfc_access.xml (remount the file system to rw) system file and include the signature of the application. Then using reflection, enable mifare emulation. Then using a mifare reader/writer (hid 6055b), I encode the data (sectors and blocks, in my case sector 1) onto the phone. In essence, I treat the phone as a mifare ID card. That is, i copied my id card to the phone. You can't programmatically set this.
NXP owns mifare. Mifare sits above the iso14443 part 3 specs and implements a proprietary communications protocol. This protocol is only implemented in the secure element which is also owned by NXP. This is why devices equipped with broadcomm chipsets can't read mifare (e.g. nexus 5).
Although I proved it possible, it is not feasible for production.
The phone can emulate certain chip cards in secure element, but it is a bit difficult procedure and is not available through the normal SDK (See e.g. here or here).
Note that the main problem there is not missing Android support, but the security procedure behind accessing the secure element.
Since the phone cannot emulate chip card you are left with the option of the peer-to-peer communication between the phone and the reader. The unique identifier can be saved in the phone memory - to be sure it is your identifier it must be digitally signed.
If you need to protect it from cloning (i.e. someone cannot copy it to other phone), then it becomes more difficult and it will be never as secure as Mifare.
BR
STeN
I understand how NFC is supposed to work on a high level, and a bit about the protocols used. Now, I need to understand, with your help, if there are any standards related to mobile payments.
From a trusted service manager perpective, I believe there are no standards at all and that both the machine on the point of sale and the app on the mobile device would have to be custom made correct?
If no such standards exist yet, can I assume it can be as "simple" as:
On contact the machine creates a checkout receipt and sends it to the device (this would have to be done with customized hardware)
The device receives the receipt and uses the UICC to authenticate itself with the bank/TSM
The bank, upon validation, signs the receipt which is forwarded to the machine by the device
Am I getting this right? If there are any technical bits I'm missing, please refer them so I can research.
Thanks
sure there are standards - see EMV (Europay, Mastercard, Visa). It is necessary for world wide interoperability of the payments systems, which uses the chip (aka secure element), no matter they are contact or contactless (i.e. NFC).
EMV specifies used hardware, protocols, file structures and used commands, data authentication, PIN ciphering, key management. It is pretty complicated.
I think you can start here: http://en.wikipedia.org/wiki/EMV
Regards,
STeN
www.mautilus.com
As said before, EMVCo standards will cover some of your need, but so will also GlobalPlatform underlying technology, as well as some further refinements of AEPM.
I'll also add once you obtain the information you need from the payment card, you have to send it to a payment gateway which then transfers the information to the payment network (Visa, MasterCard, etc.) where the data will then be routed to the issuer of the card for authorization. The response is then sent all the way back through the chain to the initiator of the transaction. Triangle has a free API that captures the card information for you. You can then use the captured information and route it to your gateway.
Disclaimer: I'm the co-founder of Triangle.