MasterCard PIN change issuer script fails, Thales HSM used for MAC generation. EMV

Question

I use Thales Payshield 9000 HSM. So far, all commands has worked and everything has been achieved what i wanted.

Now the problem is when trying to change pin in ATM. Pin change script is generated and format looks like is OK when checking MasterCard docs.

Our pin change script looks like this: 86158424000210PPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMM where 16 P letters are PIN block sent in DE125 and 16 M letters represents MAC. (I masked them, but below will be used data from example)

With this script all looks ok here from my side. Now i suspect the problem is MAC generation.

To generate MAC we use following HSM commands:

• HA (generate TAK (its a random key, every time (every PIN change operation) i call this command, key is different)) - the input is: key = PVK key (U+32Hex symbols under LMK), delimiter = ';', keySchemeTmk = 'U', keySchemeLmk = 'U'; Then the TAK key is received
• M6 (generate MAC) - input is: modeFlag = 0, inputFormatFlag = 2, macSize = 1, macAlgorithm = 3, paddingMethod = 0, keyType = '003', key = 'Tak key from HA command', messagelength = '0030', message = '8424000210345755BFDC4F2903A392B3E1229A502C892680' (message is concatenated like in the screenshot above: command header + ApplicationtransactionCounter + ARQC + PIN Block) (message data here is from example in screenshot)

So, when those two commands are executed, i receive 16HEX symbols MAC which exatcly i need. So the script is prepared like this: 8424000210 B3E1229A502C8926 422A8FF11056ACD4: header => 8424000210, pinBlock => B3E1229A502C8926 and MAC => 422A8FF11056ACD4

When i go to ATM and do Pin change, my pin never get changed and i receive reversal message.

Also can anyone explain what are those flags, i'm not sure which ones i should use (command M6):

So the questions are:

• Is HSM command M6 correct command to generate MAC for PIN change/unblock script? It requires TAK key while MasterCard docs clearly states that it should be done with SMI key.
• Is my config for M6 command is not correct when trying to retrieve MAC hash?

---

Updated

I managed to get KU command working and it brings me response but the PIN change itself is not successfully completed. Below i will show you what request i generate to the KU command:

{ "mode_flag": "3", "scheme_id": "1", "mk_smi": "U25A22A6553A7F68ABACBD1E04BBD8889", "pan": "7891234567891200", "integrity_session_data": "55BFDC4F2903A392", "plaintext_message_data_length": "0018", "plaintext_message": "8424000210345755BFDC4F2903A392B3E1229A502C892680", "delimiter": ";", "confidentiality_session_data": "55BFDC4F2903A392", "offset": "000F", "cipher_text_message_data_length": "0008", "cipher_text_message_data": "B3E1229A502C8926", "delimiter2": ";", "source_pin_encryption_key_type": "0", "source_pin_encryption_key": "UBAAAA3488AA6AA564AAC8AA3AAC1AAA2", "source_pin_block_format_code": "01", "destination_pin_block_format_code": "35", "pan2": "891234567891" }

Keys and sensitive data is masked so the PAN is used here: 5678912345678912 and sequence number 000. For the first pan parameter 14 last PAN digits used + two last digits from sequence number. For pan2 parameter, only 12 last PAN digits used, with check digit excluded.

Am i using correct Offset flag for replacing PIN block in plaintext data with the new encrypted pin block ?

Confection

Answer 1

I am fighting the same issue. I may be wrong but speaking to other folks I was told that KU is the one to use for CVN10. Now, I was also told to only use KU command as it does everything that is needed. This means it will translate the new pinblock that is coming in from the ATM using the pin key that is stored on the chip. The only thing I see is that the destination pinblock you use is 35 which is Europay > MC Pay now, but I think you have to use 34 which is the default for offline clear pin.

Sahaptin

You are right. I resolved this situation and discovered that i used incorrect PIN block format, i found it by investigting MChip Advanced Issuer Guide and tried to generate PIN block on my own. So i saw that i must actually use 34 format instead 35. Another issue was, that i was passing pinblock in plainTextData, which is not correct. The correct scripData should be 8424000210{ATC}{ARQC} the by parameter offset you let reencrypted pin block to be placed ant the end of that scripData and all the things started to go in the right direction with Pin Change and HSM – Confection

This is great to know. Since it is already working for you maybe you can help me. So tu summarize the data that goes into the HSM as plaintext data is the 8424000210 plus ATC plus ARQC. But the actual script that goes to the card is only 8424000210+newPinBlock+MAC..is this a correct assumption? – Sahaptin

Yes, you are correct to the card goes, 8424000210+newPinBlock+MAC . NewPinBlock is taken from HSM response, and MAC is also from response. Also you may check if padding of 80 is required for you when creating plaintextdata. If no padding added, offset should be the same as plaintextdata length – Confection

Thank you for the response. One last question. How do you know if you need padding? Would the HSM decline the KU request if the data is not complete? The card I am working with is MC but I do not see padding needed. Not sure if I a m missing something. – Sahaptin

My card had M chip advanced version. So i checked the documentation for that version and it was written that padding is required. But i dont remember now if padding is added automatically by HSM or not. I will check how i create plainTextData and will let you know – Confection

OK, HSM should add padding of 80 itself. so the plain text data should be like you say: {header}{atc}{arqc} and this is it. Hsm will add newEncryptedPinBlock here {header}{atc}{arqc}{newEncryptedPinBlock} and then will add padding and MAC will be calculated – Confection

Again, thanks for all the help. I was able to test it today with a little program that I wrote – Sahaptin

One last question. I was able to generate the data according to what we have spoken about but the card still rejects the message. We are placing the script under tag 86 and tag 81 is placed under 71. Am I correct? – Sahaptin

I did it under 72 tag, it means that script is going to be executed after second generate AC. 71 is before second generate AC. I think both are valid for mChip advanced. I just not sure why you add 81 tag? It is fine to go with: {DE55}{71}{lenght}{86}{length}{842400....}. 81 tag may be required for EMV standard, which is used by Visa i think. – Confection

I apologize..the 81 was a typo..it was supposed to be 86..Not sure it will make a difference but so far we have not been lucky running it under tag 71. The card keeps rejecting the pin change. So we will try with tag 72 – Sahaptin

One more question. What Responsecode are you sending after Tag91? We are sending 91+ARPC+0010 – Sahaptin

Also, would you mind sharing the name of the Mastercard Manual you were using as a reference so that I can ask for it internally? – Sahaptin

If i won't forget, tomorrow i will check what is the exact document as i dont have it at home. About 91 tag, i think you are doing ok, it should be ARPC + Responsecode, if i remember well i send 0012, but in some cases i send 0010. – Confection

About unsucessfull pin script, are you sure that your PIN block/MAC and the whole pin script is correct, the place which starts with tag 86 and all the following part of the script? If you are not sure and dont have the manual, you can try to get the working PIN unblock script it is much easier to do and does not require any PIN block. If you succeed there, it will mean that you are going into right direction. If you fall into a deep depresion, i suggest you to simulate step by step pin script generation by Mastercard manual. then with your keys you can validate what HSM translates to you – Confection

And by the way, for pin change is used KU command, mode_flag=4 and HSM Thales p9000 version 3.3 – Confection

Manual used: M/Chip Advance – Issuer Guide - Version 2.2.1 – Confection

Thanks..It finally Worked..for some reason it will not work if sent under Tag 71. It only works under Tag 72. Maybe M/Chip Advance is set to do the script after the second AC – Sahaptin

Nice to hear that it worked for you. It should be no difference with 71 or 72 but well, until its fine with 72 then its ok :) – Confection

Answer 2

Answering your question, M6 is not what you should call for script generation. It's purely for message integrity when communicating with acceptance devices or other hosts. That's why there is even no option for derivation of keys required for cards.

For EMV cards there are seperate sets of commands for verification of ARQC, generation of ARPC as well as generation of issuer scripts.

For Issuer scripts generation purpose, please have a look at KY command where you shall supply master keys for integrity and confidentiality as well as other parameters (including PAN, PSN, ATC, etc) that are required for session key derivation. There is a particular mode for PIN change command where PINblock is supplied under ZPK or TPK.

You should check precisely security parameters you have set for your cards as there are different algorithms that may be used for session keys derivation (verify what are your card application settings). Cards may also support different MAC length and you should take care of it as well.

Hak

Thanks for the answer. On monday i will definately check this. I just know that CVN version for my MasterCard cards is 10, so i think i should use KU command. Is that correct? Based on MC documentation, my MAC from HSM should be 8 bytes long – Confection

KY for mChip 4.x, KU for 3.x if i remember it correct. ARQC validation is done with KQ command and that went successfully. I actualy tried KU and KY commands just for Intergrity, with KY i have successfully got a MAC, but it never matched with the one i calculated in my code (which must be good, because i generated the same MAC as it is shown in the screenshot in my post). – Confection

Yeah, KU will do if you have MC proprietary session key derivation. The MAC length may be a matter of card application configuration and may depend on card vendor. You may have 8 bytes in your case, but be aware that there are configurations where it is 4 bytes just not to be surprised and sometimes it it simply different in different card products you may be issuing. When it comes to MAC calculation, the example you have shows a SESSION key (already derived). For KU/KQ/KY you supply MASTER keys so the HSM derives them on the fly with the parameters you supply. In real life you'll use Master – Hak

thanks for your insights, i now trying to use KU, but i struggle with documents.Host Command Reference v3.3 and v3.4 is somehow very different from each other.Older doc is missing some fields which are in new doc, but when creating request from new doc the request data becomes very different from the older version. I susprect the 3.4 doc is faulty for KU command. Anyways, im trying to build request, but so far no success: "error_code": "15", "error_message": "Invalid input data (invalid format, invalid characters, or not enough data provided)" – Confection

Which means i pass incorrect data somewhere. May it be for what i pass into Plaintext Message data ? because there i pass 8424000210345755BFDC4F2903A392B3E1229A502C892680 which is constructed of script header, ATC, ARQC and New Pin Block padded with 80 at the end to make string dividable by 8 bytes – Confection

Hi, Sorry to respond after a while, but I wasn't at the computer. The command is used for building Issuer Scripts, not just MACing. You probably shouldn't add neither MAC nor padding yourself. Also, the Encrypted PIN Block will be the result of calculation. Neither of them should be supplied as input. Please remember that you need to pass random numbers as described by MC (there is a chapter about random numbers for secure messaging in the card application specification). As Host Command Reference version, I cannot help as I'm using older one, but it will be associated with your firmware ver – Hak

Hey, np. So there was an issue in my KU command preparation, where data was concatenated. Now i fixed it and KU command gives me response. The response is 8 bytes MAC, then the 2 bytes length '0008', which indicates length of pin block which is also in response right after that length. – Confection

But the problem is that i still couldn't successfully chane pin. The random number for integrity parameter is arqc for the first script, just not sure if arqc for confidenciality should be passed the same as for integrity. RANDi vs RANDc , what is the diff between them? Im using modeFlag 3 and using 3.3 documentation. There is one parameter which is also not 100% clear for me, it is Offset, what length should i put there? Is is the place where the pin block is appearing in the plain text data for MAC? – Confection

Lets say plain text message is this: 8424000210345755BFDC4F2903A392B3E1229A502C892680 header: 8424000210, atc: 3457, arqc: 55BFDC4F2903A392, newPinBlock: B3E1229A502C8926, padding: 80. Am i correct to say that the offset is 000F = 15th byte? So the pin block will be taken from 16th byte. docs say: If Offset = n, Ciphertext is inserted AFTER the nth byte of the Plaintext. Am i right? – Confection

@MichalGluchowski hi, where do i find the card network API's to integrate with my backend? Can these be found online or do i need to contact an acquiring bank first and they will provide me with the necessary API's? – Idolist