IBM Crypto Education Community

 View Only

 EMV - ARQC/ARPC on linux platform with IBM ACSP.

Rafal Kaczmarz's profile image
Rafal Kaczmarz posted Mon December 01, 2025 06:59 AM

Hi, 

I'm trying to implement EMV processing on linux platform using ACSP client - at the beginning ARQC ver/ARPC gen for CVN18.

CSNBEAC is not implemented on linux platform , so I need to do it in more steps - deriving a key in 2 steps and finally calculate MAC value to verify ARQC. 

The idea was to use following steps:

  1. prepare derivation data  to get 16 bytes value (PAN || PAN_SEQ) || (XOR[(PAN || PAN_SEQ),x'FFFFFFFFFFFFFFFF']
  2. use CSNBDKG to derive ICC/UDK from IMK (DKYGENKY DKYL1) 
  3. prepare session key derivation data based on ATC 
  4. use CSNBDKG to derive SESS key from ICC/UDK from step2 
  5. prepare data for MAC and calculate MAC value 

I've implemented steps 1-4 - all verbs end with RC=0/0 - but I don't get expected results.  

I have also access to Z platform so I was able to compare results with results obtained from more powerful verbs available on Z (CSNBDCM - Derive ICC Master Key callable service and CSNBDSK Derive Session Key callable service) - and they don't match. 

The first difference is at deriving ICC/UDK key - so I believe the way I prepare derivation data might be incorrect.

I started with 16 digits fake PAN number: 1122334455667788 and PAN seq. no = 0 

First step wat to get 10 bytes array of PAN  (left padded with 0x00) => x'00001122334455667788' and one byte of seq_no = 0x00

Then concatenated both and used last 8 bytes of result array => x'2233445566778800'.

In the next step I’ve calculated XOR value of x'2233445566778800' => x’ ddccbbaa998877ff’ and then concatenated those 2 arrays to get 16 bytes of derivation data => x’ 2233445566778800ddccbbaa998877ff’.

I used CSNBDKG to generate ICC master key with this input:

  • rule_array_count = 1
  • rule_array = TDES-ENC
  • generating_key_identifier (IMK) - 010000000000c000 ee49627dd85a161f **************** **************** 0072050003410000 0072050003210000 0000000000000000 000000000661d92a (KCV A8BDA3)
  • data_length = 16
  • data =x’2233445566778800ddccbbaa998877ff’
  • data_decrypting_key_identifier – null key token (64 bytes of 0x00)
  • generated_key_identifier - null key token (64 bytes of 0x00)

·   

Function ends with 0/0 and giving a DKYGENKY DKYL0 key on output:

010000000000c000 ee49627dd85a161f **************** **************** 0071050003410000 0071050003210000 0000000000000000 0000000046960ab4 (KCV E82AB7)

To check if it is correct I used CSNBDCM with input:

  • rule_array_count = 5
  • rule_array = "TDES....VISA....AC......APPANSEQCVN18..." (dot indicates SPACE)
  • issuer_master_key_identifier_length = 64
  • issuer_master_key_identifier : 010000000000c000 ee49627dd85a161f **************** **************** 0072050003410000 0072050003210000 0000000000000000 000000000661d92a (KCV A8BDA3)
  • icc_master_key_identifier_length = 64
  • icc_master_key_identifier – null key token (64 bytes of 0x00)
  • icc_master_key_identifier_length = 64
  • transport_key_identifier- null key token (64 bytes of 0x00)
  • pan_length = 10
  • pan = x’00001122334455667788’
  • pan_seq_number = 0x00

·   

Ends with 0/0 and gives a DKYGENKY DKYL0 key on output:

010000000000c000 ee49627dd85a161f **************** **************** 0071050003410000 0071050003210000 0000000000000000 00000000d7c77e71 (KCV D8A130)

Both verbs were executed on platform Z - to be able to use same IMK.

Everything looks ok except the key value it is different – can you help me to figure out what I’m doing wrong? I've spend a lot of time trying to change different options/data formatting but without any luck. I know I could use CSNBEAC to do the all the job - but this is not available on linux platform. 

 Best regards 

Rafał Kaczmarz

Eric Rossman's profile image
Eric Rossman posted Fri December 05, 2025 03:19 PM

Hello. I am the author of the CVN18 code in CSNBDCM/CSNBDSK/CSNBEAC. What you have looks correct.

I wonder if there might be some confusion. The part you put with asterisks would be the encrypted key value (in the IMK token, the ICCMK/UDK token, and the session). It is not a clear key value.

If you want to import clear key material, you would be best using CSNBSKM (if allowed in your environment) or CSNBKPI (to import by parts).

Rafal Kaczmarz's profile image
Rafal Kaczmarz posted Fri December 19, 2025 11:23 AM

Hi Eric - thank you for your reply. 

All the keys I put in my first post are internal key tokens and asterisks are for key value part of it. They are all encrypted under HSM master key. The IMK key which is base for all derivation is a key that was installed via EKMS ws  on our test environment and is used for real cards traffic.  In current setup we use PMV package (KMG program) provided by IBM for EMV transactions and my task is to rewrite it using pure CCA verbs.

In the meantime using pure CCA verbs I've managed to get same results I got from PMV package (including same KCV for session keys, successful MAC ver, mac GEN and script MAC). It was for real card transaction taken in test ATM. 

But I'm sill wondering why couldn't I get same KCV for ICC master key when trying to derive it using CSNBDCM and CSNBDKG (btw verification of ARQC for test transaction using CSNBEAC went ok with same IMK) . 

I'm going to have a XMAS break and after that I'll get back to it and run it once again trying to get same results using 3 different ways (PMV package,  EMV simplification verbs available on Z/OS and using pure CCA verbs).

Best regards

Rafał Kaczmarz

Eric Rossman's profile image
Eric Rossman posted Fri December 19, 2025 11:51 AM

What confused me in your original message was the statement "Everything looks ok except the key value it is different" so I incorrectly assumed that you meant the asterisks were the actual key value.

If you give me sample clear key material and inputs, I can try to reproduce what you are seeing and see where things are going sideways.

Related Content