Mastercard ARPC

[Raman Verma]

I am trying to validate Mastercard ARQC/ARPC for CVN10. I have a Mastercard simulator that is being used to generate the ARQC and validate the ARPC. 

What is happening is that the ARQC is getting validated by the HSM properly and an ARPC is being generated upon successful ARQC validation. The catch is that the ARPC that HSM generates is 8 Bytes but in the simulator, it is expecting 10 Bytes. 

As far as I understood 10 bytes goes as 8 Bytes ARPC+ 2 Bytes ARC. But if that is the case then the HSM is generating only 6 Bytes of ARPC if we consider the last 2 bytes as ARC because the last 2 bytes are always getting matched every time with the expected ARPC by the Mastercard Simulator and I am assuming the last 2 bytes as ARC only. 

Mastercard expecting - D5473925DD870F63CD0B
HSM Generated         -             AB15BE4758DFCD0B

If anyone have an idea and who has worked on Mastercard Cryptogram validation and generation pls do share your leanings and inputs. 

[Mark Salter]

Perhaps try

https://paymentcardtools.com/arqc-calculators/cvn10

Unused it recently for some independent validation.

Given the value your hsm command returned it not close or similar to what the simulator is expecting, perhaps check the keys and data in play in the flow.

What simulator are you using if you can share?  Is it configured correctly?

This is really off topic and it would be nice if the subject indicated it as so.on your opening post - now added.

-- 
Mark

Sent from Proton Mail Android

-------- Original Message --------

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/1069acb8-4773-4182-945d-e4b604d0a684n%40googlegroups.com.

[Raman Verma]

I have tried these tools but no help. They are also generating 8 Bytes of ARPC.

keys are configured correctly and ARQC validation by HSM confirms that. ARQC generated from the Simulator is getting validated in HSM but ARPC is something that is causing issues. 

What simulator are you using if you can share?  Is it configured correctly? - > I am using the Mastercard professional simulator (given by MasterCard) which is configured as per the MasterCard documentation.

[Mark Salter]

And the MK-SMI key check value matches on both ends?  It sounds like your MK-AC could be right but perhaps not MK-SMI.

Is the card set as CVN10 in simulator?

-- 
Mark

Sent from Proton Mail Android

-------- Original Message --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/f5c7bcfe-a59c-4a61-a24d-1331efc4beben%40googlegroups.com.

[Raman Verma]

Sorry for the delayed reply. I am not getting the MK-SMI part here. I have only configured the MK-AC keys and in Thales command, only MK-AC is required for ARQC validation and ARPC generation. Frankly, my understanding is that the MK-SMI is only used for issuer scripts like pin change etc. Not sure how it's going to be used in ARPC. 

Can you let me know what is the exact process of ARPC generation to send back to the network? I am trying to get this info from Mastercard itself but no luck till now.  

[Mark Salter]

Yeah, mk-smi was on my mind (and yes scripting).

I don't understand why you arpc is so different to that which the simulatornis expecting, it suggests keys.

ARPCs are 8 bytes, so the sim is expecting other data, perhaps CSU, but that is 3 bytes, so it dont understand why it is expecting 10.

Mastercard tools I am afraid are ropey at best, but do confirm that the simulator is handling the card as if it is CVN10.

You are doing a validate ARQC and generate ARPC in one command?  Is the response code into that command the same as on the response de39?

-- 
Mark

Sent from Proton Mail Android

-------- Original Message --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/f5120325-39d8-432d-a055-b8b4b60d2df5n%40googlegroups.com.

[Raman Verma]

I don't understand why you arpc is so different to that which the simulatornis expecting, it suggests keys. -> could be the case. last two bytes always getting matched.

ARPCs are 8 bytes, so the sim is expecting other data, perhaps CSU, but that is 3 bytes, so it dont understand why it is expecting 10. -> I am trying to understand the same for last 3 days :-) . Thales saying ask mastercard and mastercard is too slow to respond.

Mastercard tools I am afraid are ropey at best, but do confirm that the simulator is handling the card as if it is CVN10 -> its CVN10 as I can also confirm from IAD data that is getting generated from simulator. 

You are doing a validate ARQC and generating ARPC in one command? -> Yes, KQ command is there. 

Is the response code into that command the same as on the response de39? -> Yes

[Mark Salter]

You said you had checked the keys, but now you say...

"
could be the case.
"

What hexdump values donyou have for :-

"last two bytes always getting matched."

Are the bytes changing but matching the sim or static?

-- 
Mark

Sent from Proton Mail Android

-------- Original Message --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/18cd7448-e61b-44bc-a3f8-7d52673880fdn%40googlegroups.com.

[Raman Verma]

could be the case -> It's in the context of the MK-SMI key coming into the picture. 

Are the bytes changing but matching the sim or static? -> Yes they are changing every time and getting matched with the Simulator. 

[Mark Salter]

No MK-SMI, that was my mistake.

Can you share a sample of the bytes that are managing to match and  which dield/tag for context?

-- 
Mark

Sent from Proton Mail Android

-------- Original Message --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/4fd788c6-af2b-449c-910e-0f1249724dedn%40googlegroups.com.

[Raman Verma]

they are the last two bytes that are getting matched every time. There is no specific field for this to my knowledge. It's just part of ARPC that is getting generated from HSM.

[Mark Salter]

It travels in a field and tag, can you share that and also a sample of the data

-- 
Mark

Sent from Proton Mail Android

-------- Original Message --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/6629a756-16e3-43e1-a2c0-d33ecad87334n%40googlegroups.com.

[Raman Verma]

field 55 tag 91 len 8 value 06A2AF576DA80C01

sent to sim = isoRes.set(55,ISOUtil.hex2byte("910806A2AF576DA80C01"));

      command: 'KQ'
      mode: '1'
      scheme-id: '1'
      key-scheme: 'U'
      mk-ac: '4FDB4XXXXXXXXXXXXXXXXAFBCE711E'
      pan: '343500XXXX432501'
      atc: '021f'
      un: '40100268'
      txn-data-length: '28'
      txn-data: '00000010000000000000000008400000000000084024042200401002685c00021f02000004400080'
      delimiter-txn: ';'
      arc: '0000'
      arqc: '931ea79de8e9127b'
      delimiter: '%'
      lmk-identifier: '00'

[Mark Salter]

You are using Thales payshield?

That output being a representation of the bytes Sent, not the actual bytes (lowercase would be invalid)?

KR response looks like?  Hex dump ideally.

ARC is incorrect and won't match your de39.

What is your de39?

-- 
Mark

Sent from Proton Mail Android

-------- Original Message --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/aa60dbd0-82ab-4a78-a555-84467b5ff7ddn%40googlegroups.com.

[Raman Verma]

You are using Thales payshield? - Yes

That output being a representation of the bytes Sent, not the actual bytes (lowercase would be invalid)?

KR response looks like?  Hex dump ideally. -> It says ARQC valid and returns ARPC

ARC is incorrect and won't match your de39. -> It ask for 2 bytes of ARC. Changing it to 00 not making any difference. Getting same ARPC.

What is your de39? -> 00

below is the complete hex dump. Just replaced key values with X.

    request:
0000  30 30 30 31 4B 51 31 31  55 34 46 44 42 34 35 36  0001KQ11U4FDB456
0010  37 30 4X 3X 3X 3X 3X 3X  3X 3X 32 33 32 36 43 33  70XXXXXX572326C3
0020  41 46 42 43 45 37 31 31  45 34 35 00 26 30 43 25  AFBCE711E45.&0C%
0030  01 02 1E 55 10 73 05 32  38 00 00 00 10 00 00 00  ...U.s.28.......
0040  00 00 00 00 00 08 40 00  00 00 00 00 08 40 24 04  ......@......@$.
0050  22 00 55 10 73 05 5C 00  02 1E 02 00 00 04 40 00  ".U.s.\.......@.
0060  80 3B A0 E8 DE B3 26 C3  8D 80 00 00 25 30 30     .;....&.....%00

    response:
0000  4B 52 30 30 EF BF BD EF  BF BD 71 EF BF BD EF BF  KR00......q.....
0010  BD 5E EF BF BD 3A                                 .^...:

[Mark Salter]

If de39=00, then arc into KQ is 3030 - check the manual.

-- 
Mark

Sent from Proton Mail Android

-------- Original Message --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/53c6dbde-04eb-4497-8c22-7c0cf54e30efn%40googlegroups.com.

[Raman Verma]

if changed to 3030 then the last 2 bytes also not getting matched.
ARC will be 0000. I have seen other examples too. 

[Mark Salter]

It is an ascii value.

Unless you have something translating the bytes hotting the hsm- significantly - that you do not show.

0000 is wrong.

Good luck, I am done trying to help.

:-)

-- 
Mark

Sent from Proton Mail Android

-------- Original Message --------

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/1274007b-d13b-4911-80a5-5c5542866aean%40googlegroups.com.

[Raman Verma]

Thanks for the help and more importantly putting in the valuable time. Appreciate it. :-)

I Had a call with the Thales team today. They again do not have any idea of a 10-byte ARPC and asked me to share the doc from MasterCard as to which algo they have put in for generating a 10-byte ARPC (:D) so that they will also add the same in the later version.

Still not able to connect with Mastercard on this. Once I get an update will let everyone know here.