0

In the EMV protocol the IMK(ac) is used to generate the session key, which is used to generate an ARQC. The IMK(ac) is exclusive to the chip and the card issuer host

As far as I understand, the card issuers do not share those keys with the card brand (i.e. Visa cannot validate your ARQC, only "The Bank of Peoria" who issued the card can).

When an EMV Apple Pay transaction occurs in which the phone generates the ARQC, which IMK(ac) key is it using? Presumably it can't be the IMK(ac) from the original card, and thus the card issuer cannot validate the ARQC.

If it's an Apple IMK(ac) being used, then does this mean that it is Apple validating that ARQC?

If this is the case, what's the transaction flow that gives Apple the opportunity to validate the ARQC?

[Edited for clarity]

Tom West
  • 1,759
  • 2
  • 13
  • 20

2 Answers2

1

Encryption will always use Session keys derived from an IMKac for Cryptogram generation. However the IMK need not be the same as what your physical card uses( you can manage this using a different CVN as host). The same key will be available with the payment schemes(Visa, MasterCard etc.) who will validate the cryptogram during the transaction and send you the results of verification.

Wallet CVNs are different. If you as a card issuer host wants to verify the cryptogram, then you should have the IMKac for the CVN and your HSM should support the CVN. Ideally you can rely on the verification results code (in 44 for Visa and 48 SE71 for MC) to decide whether it can be approved or no.

In case if you have more documentations from Apple you can share, I would love to go through those :-) .

Adarsh Nanu
  • 2,133
  • 1
  • 13
  • 18
  • Many thanks - I've modified the question for clarity based on your answer. Sadly, no, I have no documentation from Apple detailing the EMV version of Apple Pay. – Tom West Mar 28 '18 at 14:59
1

Mobile wallets like Apple/Google Pay don't use the card's PAN, so they don't need to provide the same ARQC that the card would have generated.

Instead, they use network tokens which are then mapped back to the PAN by the scheme.

Before the transaction

  • the Token Requestor (e.g. Apple) sends its IMKac to the Token Service Provider (e.g. Visa) as part of the onboarding
  • the Device (i.e. individual phone) is provisioned with a Token that can be mapped back to the PAN by the Token Service Provider as part of adding the card to Apple Pay

During the transaction

  • the Device:
    • generates an ARQC, which it includes in the transaction
    • sends its Token in the place that the PAN would go
  • the Token Requestor:
    • swaps out the Token for the PAN, which the issuer can recognise
    • validates the ARQC using the Token Requestor's IMKac, and forwards the result of this validation to the issuer
linuxpirates
  • 101
  • 1
  • 7