Question : Can we extract a credit card number like any EMV with this project?

[ralexy]

Hello,

I wonder if we can extract data like classical EMV credit card with this code (CC number and expiry date)? I contacted suppliers of NFC chips and they said to me : "Without a certified device we only can read bus passes or loyalty cards on iDevices".

My question is for a legit business usecase, I can explain it privately if needed!

Thanks in advance for your help!

[kormax]

Yes you can, either through magstripe compat mode as plain data, or via emv mode, both via AFL but also via SDA + DDA.

I had a private POC that allowed to use EMV cards as an access solution, including Apple Pay Express and Google Wallet transit compatability, but with Home Keys I don't find any use for it anymore.

As in regards to using this information maliciously, this is not something that digital Wallet users have to worry about, as DPAN and EXP cannot be used for online transactions. Moreover, wallet solutions force transit/express transactions to be done without CDCVM, which complicates relay attacks and limits the potential damage (as a PIN limit is enforced instead).

As for physical cards, this was and stays a concern. But one wouldn't need express mode for that.

[ralexy]

Hello kormax, thanks for your answer! I understood it but I'm curious!

I tried this today:

1) I used an EMV reader to get my DPAN via AppleWallet for a Revolut Card 2) I used this information to try a little payment on my website (DPAN + expiry date) 3) I had a “DO NOT HONOR” return.

If I understood AppleWallet uses a different CVV for every transaction. Do I have a chance to make a successful transaction with: DPAN, expiry date and dynamic CVV?

Is this dynamic CVV accessible via EMV?

Thanks in advance for your reply!

[kormax]

No, you cannot make a successful "card not present" transaction using that data. That's what I said in the first message.

Even to conduct a "card present" transaction, you would need to generate a cryptogram and post it along transaction data to the payment processor. Payment processors won't accept this data coming from randoms who acquired it using unknown hardware and methods.

Real payment terminals usually have a separate chip that's conducting the payment transaction, which then encrypts the result using the encryption keys that were injected by the payment processor. This way they are protecting data when it's sent over the network, but also verifying that transaction was done on authorized hardware (as a system won't accept unencrypted data or data that was not encrypted using known key, and you cannot get the keys on your own).

[ralexy]

Thanks for your reply,

I understand the principle about certified payment terminals and their encrypt keys.

One last question: the cryptogram with "card not present". I know this information is not stored in physical card, is it the same on a virtual one? Do you have any idea how a cryptogram is generated on "card not present" transaction (is it a random function or a mathematical one)? Can we read this cryptogram via EMV (even if we cannot use it)?

Thank you again for the time and your precious information!

[kormax]

I see that you're interested in this topic. Considering that I have no hands-on experience in the industry, and most things I told you are based on what I read or tested, for further research I'd advice you to look at information found at:

• Cardwerk;
• EMVLab;
• EMV Whitepapers PDF. (google it).

[ralexy]

Thank you for all the time given and sorry if I bother you with my questions, I appreciated having someone competent to answer me!

Have a great day and congratulations on your remarkable work!

EDIT :

I found an official answer here : https://support.apple.com/fr-fr/guide/security/secc1f57e189/web

Using a payment cryptogram for dynamic security

Payment transactions originating from the payment applets include a payment cryptogram along with a Device Account Number. This cryptogram, a one-time code, is computed using a transaction counter and a key. The transaction counter is incremented for each new transaction. The key is provisioned in the payment applet during personalization and is known by the payment network or the card issuer or both. Depending on the payment scheme, other data may also be used in the calculation, including: A Terminal Unpredictable Number, for near-field-communication (NFC) transactions An Apple Pay server nonce, for transactions within apps These security codes are provided to the payment network and to the card issuer, which allows the issuer to verify each transaction. The length of these security codes may vary based on the type of transaction.