can we read union pay and JCB cards using the specifications described in EMV standards for contact and contact less technologies
Sure you can do it in the lab for development purposes. For production Contactless and Contact EMV Kernels implementations must be certified.
EMV Contact terminal flow is the same for both schemes. The differences from the card profiles not visible from terminal contact interface.
In regards Contactless:
JCB uses EMV Contactless Book C-5 Kernel 5 Specification,
CUP uses EMV Contactless Book C-7 Kernel 7 Specification.
See EMVCo site for details.
Related
There is an access control system in my university. It uses MIFARE 1k cards.
As I bought Apple Watch with NFC inside, I'm wondering if I can emulate 1k card using NFC.
There is a possibility to send 64KB by NFC using Apple Wallet. But how to order the data from card properly, to send it? The question came because I know that RFID cards has some blocks of data, and unfortunately I don't know how to send them as one unit.
If I understand correctly: Apple Pay, Android Pay and NFC-enabled credit cards can all be accessed using APDU commands via NFC according to the EMV standard.
I want to use information from this data exchange to associate the device/card with some persistent server-side information, typically a check-in/check-out scenario.
The NFC Tag ID is randomized on most devices, making this obvious approach unusable.
I am NOT trying to take payment, only use an unique identifier that does not change over time. It is also important that the identifier is unique per device, so that the same credit card registered on two phones does not appear to be identical.
Reading about the use of temporary tokens makes we wonder if this is at all possible on the phones due to the one-time tokenization employed. Apple creates a Device Account Number that is unique for a device, but this is supposedly not shared with the Point Of Sale. But still, travellers can use EMV Cards as well as Apple Pay to check in/out on the London underground, this is not possible without reading the same identifier twice.
So my question is what information can I use to read a persistent unique token that works across all EMV mediums?
Extra bonus points for some information on the APDU commands used for reading this information or thoughts on the security aspects of using this token as an non-cloneable identifier (can offline PIN verification be used?).
The following threads could not provide an answer:
Serials on NFC Tags - truly unique? cloneable?
Create Token With Apple Pay Without Payment
I think you might be getting a bit confused around how Apple Pay works - it's just a regular EMV contactless card payment with a device specific card number/token instead of the actual token. The uniqueness comes from the EMV cryptogram. The public Apple Security Whitepaper details this: https://www.apple.com/business/docs/iOS_Security_Guide.pdf
Apple Pay Contactless payment scenario is a sub-part of Visa PayWave specification. During the card(or Apple Pay device)-to-terminal interaction Card(or Apple Pay device) generate ARQC cryptogram which, together with other transaction details, needs to be validated by Acquirer host.
Nothing actually new invented here. Apple Pay is just method to provide Card data and Transaction Cryptogram (TC) via Apple devices. The same or at least similar scenario as for usual PayWave Contactless-EMV card.
The Apple Pay UK and US profiles and test scenarios now covered by Visa PayWave Test Procedures (VpTP).
I'm wondering if it is possible to create mobile app running on phone with nfc support to behave transparently like contactless payment card.
User launch this app and put the phone to contactless terminal and then will be accomplished some communication between terminal and phone.
The goal is to provide payments between our users and merchants with contactless terminal. Our users are users of our application which is some sort of e-wallet. They have some credit in the wallet and we want them to spend the money for example in supermarket.
We assume that we will have agreement with merchants, but I want to know, if merchant can use contanctless terminals they have, without any HW or FW modifications. Or the terminals are hard-wired to VISA or EC/MC and accept only theirs cards?
Your Merchant terminal works under their Acquirer Bank (or Payment Service Provider) Environment. It is a property of Acquirer or Bank. Ask them dirrectly about your loyalty cards acceptance, but not the merchant. In other case Merchant will take all risks and questions resolution for your cards.
The acceptance of payment cards (or local loyalty cards like in you case) by the terminal itself depends from the terminal functionality.
Usually, without additional agreements between Merchant and Acquirer, only well known payment cards are accepted by the terminal - some card brands which are in the Acquiring agreement, especially contactless cards acceptance.
For sure you may try to reuse terminal readers and other HW. It is possible in some cases. But, due to security reasons, it is prohibited by the terminal owners (Acquirers, Terminal SW developers, Terminal vendors) without additional deal.
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.