I'm trying to write some code that will do consumer presentment of EMV payment QR codes. That actual coding of the QR code seems pretty easy once I have the data for a particular credit card the consumer owns.
What I'm having a hard time finding is how you can scan individual credit card to get the needed data for generating the QR code.
Questions:
can you simply have the consumer type in the cc#, security code, etc. and then use that to generate a consumer qR code for presentment to a POS scanner?
if the answer to #1 is 'no', then how can you access the data on the credit card? NFC? Barcode scan? Is the data needed for QR code presentment available via NFC for example without going through some kind of EMV certified device to read it?
Related
First, I want to apologize. I am complete noob in this area and many of my thoughts are probably misleading.
I need to verify that a user of my app is on a specific place in order to be authirized to perform an action. I want to use NFC for this purpose. The user have to put his smartphone by a NFC tag in order to be authorized to perform the action. Easy but I need it to be reasonably hackerproof. It means that the NFC tag must be impossible to clone without physical damage to the plastics around the NFC chip. It also means that the NFC chip must not contain only static data. The NFC chip must contain an app, that can receive some data (cryptographic challenge) and signs them using secure built-in private key (which must be unreadable through NFC interface). When the user wants to perform the action, he will ask server for the challenge, then he lets the chip to sign it, and then he sends the signed challenge back to the server which will verify the signature using known public key. This should be achievable using NFC JavaCard. But do these NFC JavaCards actually exist? I wasn't able to find a company which would be able to produce such NFC tags for me. When I try to explain my requirements to a NFC tags producer he looks like he has never heard of NFC JavaCards. I have tried about 10 producers without luck.
Can a commonly available chip meet my requirements? I mean a chip from the Mifare familly. I suspect that Mifare DESfire might be able to meet my requirements, but I am not sure.
Feel free to respond with an advertisement, because relevant advertisement is exactly what I look for :)
I try to collect some useful facts:
NFC is a very broad term, just finding that on both sides does not ensure interoperability.
Any ISO 14443 (one of the NFC flavours) compliant smart card with crypto functionality should be usable. Note, that a card with native OS may be a viable alternative to a JavaCard, since the functionality to sign a random number is pretty standard.
Any smart phone sporting a NFC chip can address such a card in principle. Unfortunately this is strongly dependent on the OS of the smart phone, for Android the relevant class to use is IsoDep, which gives you the APDU interface. After triggering the "card enters field" event, then the app receives a handle, via which further communication can take place.
Real smart cards can't be cloned, since you are not able to dump them; especially keys can't be read.
Now some things to consider:
Your approach looks unusual, which might become a problem. (To have a portable card somehow fixed to a wall, just to get the location; so you know where somebody is, but not who? While I don't consider cloning to be an issue, you somehow must ensure destruction in case of a theft attempt, which may collide with the distance topic below.)
I don't see, where the server comes into play. If not involved in the authorized action, provision of a random number is not sufficient reason.
Asymmetric key operations have a comparatively high power consumption, and this power has to be supplied via the electric field. This severely limits the distance between card and phone and may even require direct touch. While a power supply of its own would solve the issue in principle, it is not what ISO-14443 was designed for.
Yes JavaCards do exist.
https://github.com/OpenJavaCard/openjavacard-ndef is a project makes these JavaCards to output standard NDEF messages (thought note issue 4 in that there example uses the wrong APDU but that is easily changed)
This project also give a number of cards it is fully working and tested for
ACS ACOSJ - fully working
NXP JCOP J3D040/J3D081/J2E145 etc - fully working
Both ACS and Cardlogic do cards (just google the model numbers)
e.g.
https://www.acs.com.hk/en/products/405/acosj-java-card-combi/
https://www.smartcardfocus.com/shop/ilp/id~707/j3a081-80k/p/index.shtml
The answer a was looking for is not a chip which runs a custom code. Although this might be possible it is definitely not the best way to achieve the target.
I was looking for a solution that enables strong authentication using NFC data. There might be multiple chips that offers this, but probably the most available chip is NTAG 424 DNA TT. It works like this:
The chip has a memory, which is not readable through NFC. Private key is stored there.
The chip has a read counter. It increments everytime the data are read through NFC.
The chip can generate an AES-128 signature of string UID (chip serial number) + counter using the private key in the inaccessible part of the memory.
The chip can dynamicaly inject the data above into a URL that is stored in the readable memory.
So the solution will be like (I am waiting for delivery of NFC tags right now, so I don't know for sure yet):
Read the tag UID (serial number) and the actual counter value (should be 0 on an unused tag)
Generate the key-pair
Load private key to the chip
Load some data (URL, eg: https://my.app/) to the chip
Store UID, public-key, last-counter on the server
Configure the chip to inject UID, counter, signature to the URL stored on the chip
When a client reads the data, they should contain required variables, eg: https://my.app/?counter=1&uid=ff:ff:ff:ff&signature=xyz. Then on the server:
Fetch stored info (public-key, last-counter) using uid as a primary key
verifies the signature
verifies the counter that must be > last-counter
stores counter as the last-counter
successfully authorized
Is anyone able to hack this without reading the hidden memory of the chip which would require physical tampering with the chip?
I want to display the Card type used for apple pay transaction, I know that the card details are not present in Apple pay transaction, but is it possible to figure it out from PAN? or any other alternative?
I got something, where I get to know that your PAN is used to deduce your card type , so PAN is used as card number instead of the original card number. That's related to a specification form EMV saying applicationPrimaryAccountNumber is used to hide the actual card number from getting printed on your payment receipts.
So applicationPrimaryAccountNumber can be used to deduce the card type.
Hope this helps someone
I need to implement something like NFC virtual shopping store.
But problem is I don't want to use mobile phone as NFC reader.
First thing I am learner :)
Scenario is I have five art pieces and 50 visitors
So I am thinking I will implement 5 NFC card reader and writer and 50 NFC tags
All NFC TAGS are already filled up with user data like email, email, phone
And all NFC reader and writer are setup with art pieces.
User will come to gallery and tap NFC TAG on the required art piece or somethings
PROBLEM IS HERE
"can I update NFC tag data dynamically when he tapping?"
Like adding product id into the NFC tag... and product id is fixed for that reader or writer
So at time of tapping NFC writer will write the product id (which fixed for each writer) into the NFC tag
Is that possible?
Sorry I am not good in explaining problem in short ... :)
Please let me know, it is possible or not .. and I am on right track or not
thanks in advanced
The answer is: yes you can, but it is not very practical.
You would have to connect all five card readers/writers to a controller (like PC) and implement writing logic there.
Five NFC readers/writers are also very expensive, minimum 50€ for once piece.
More common scenario would be:
Each art piece has its own NFC tag. This tag is read-only (so no one can change data) and contains information about art piece (id, price, ...).
Each visitor has his own NFC enabled phone (Android, Windows Phone) with NFC application you provided. When user scans NFC tag, art piece information is stored in application.
In case you cannot use NFC enabled phone:
Store only unique ID on visitor NFC tag and have user data stored in central database server.
When user taps NFC tag, controller adds record to database with user ID.
This way you have all the data tied to the user stored in one location and you do not have to write back to user tag.
I am writing a point of sale application for a client who has some very specific needs. The client is a retail store, so when they process credit cards, they have a physical card present and can swipe it. The way it is now, at the end of check out, it presents the cashier with a total, and the cashier keys the total into a credit card terminal (by hand--it is not connected to the computer), swipes the card at the terminal and then when the payment is processed, the cashier presses the "Paid by Credit Card" and it prints a receipt.
The problem is that hand keying in totals is time consuming and prone to errors. I'd much rather have my program transmit the amount to a credit card terminal and then get a message when the transaction has been processed. I don't want to touch any card holder information (card number, etc) because I want to stay outside of PCI. All I want to do is send an amount and get back an "accepted" or "declined". You'd think this would be common, but I seem to have failed to find information. (For example, authorize.net's card present API requires me to collect and transmit the card number. I don't want to collect and transmit the card number. I want to transmit an amount and have someone else collect and transmit the card number and notify me when the process is complete.)
Does anyone have a solution for this? Has anyone worked with Verifone or Ingenico's hardware? I don't care if I'm sending the number of a physical terminal connected via USB or to a virtual software terminal. I just don't want to be the terminal myself, so that I'm not anywhere in the chain of card data.
I'm familiar with the VeriFone line of products, both signature capture (Mx900 series) and mobile iOS devices (Vx600). Your first hurdle is that the units are pricey for the little guy (ie: small business owner) at about $500 & $900 each respectively (retail).
On the bright side these things are your friends when it comes to PCI via what VeriFone dubs Verishield Protect (VSP). Essentially VSP encrypts the card swipe on the magstripe head and your POS solution will have to send out a decryption request which your POS software can either consume for settlement or for a fee VeriFone will send it directly to the bank.
The main sticking point of the PCI requirements I believe you're running into is the fact that the clear card data can't be "stationary" at any point in your code and either of these solutions will be a good launching point.
Good luck!
You should take a look at payworks. They provide a iOS / Android SDK to integrate a credit card reader. You never touch credit card data.
Disclosure: I am a software engineer at payworks.
The Pax S300 can do it, though I haven't found a processor that supports it. TSYS is supposed to, but after 4 months of run around, I could never get a device. Helcim has great customer service and report that they are planning an Ingenico solution for pushing the total to the terminal by the end of 2015.
I've got an eCommerce system that accepts Visa, Mastercard, Discover, and Amex for recurring billing. An issue we've run into is that in some instances, people have used pre-loaded gift cards rather than real credit cards, and once the balance runs out the recurring payment fails.
I'm trying to find a way to determine if a card number is a gift card or not. Is there any sort of unique characteristics to these credit card gift cards? Is there any way to tell from part of the Issuer Identification Number? We've already got validation to check the IIN and determine the card type, but I would expect the issuers use some set of digits to identify the prepaid cards.
I don't think you have a possibility to detect it from the card data you get from the user. The number is just an ID to identify the card in the issuer's database, and that's the location where such details are defined.