TR-31 key block

[Kapilashantha Rajapaksha]

Hi,

I'm implementing dynamic key exchange for (PIN key and an Mac key ) with TR-31 key block.

And I'm using a java application to perform this. I have noticed the KB length issue with receiving messages from the host.  And the length of MAC too.

Receiving from  host as below format 

 

Sample TR-31 PIN KEY BREAKUP
B0096P0TB00E00005450948FD298FE32E418C3F0574CEE4FE3388FDFD722863C43CC24414025440C807AF25ABB07AAF3
Header
	Key Block Version	B
	Key Block Length	0096
	Key Usage	P0
	Algorithm	T
	Mode of Use	B
	Key Version Number	00
	Exportability	E
	Number of Optional Blocks	00
	Reserved	00
ENCRYPTED DATA		5450948FD298FE32E418C3F0574CEE4FE3388FDFD722863C43CC24414025440C807AF25A
MAC		BB07AAF3

But my program 

B0080P0TE00E0000 81C6985A61E12F2502C9F07C78290DA6D4DFCC36EC09713ACC07EA56FFC59A36 0EDB20C54B582CCD

Host Length = 0096 but My program = 0080

Host MAC = 4 bytes but my program = 8 bytes

Appreciate your support on this

Thanks 

[Mark Salter]

On 17/04/2023 02:29, Kapilashantha Rajapaksha wrote:

I'm implementing dynamic key exchange for (PIN key and an Mac key ) with TR-31 key block.

And I'm using a java application to perform this. I have noticed the KB length issue with receiving messages from the host.  And the length of MAC too.

Code you wrote?

What is the issue?  You just noticed a difference in some of the payload or is something not working?

Are you producing a key or receiving one?

Receiving from  host as below format 

 

But my program

Perhaps you need to check the specification of this Host and match *your* code to it?

B0080P0TE00E0000 81C6985A61E12F2502C9F07C78290DA6D4DFCC36EC09713ACC07EA56FFC59A36 0EDB20C54B582CCD

Host Length = 0096 but My program = 0080

Their key component is longer - why is that, what does their key exchange specification say about it?

Host MAC = 4 bytes but my program = 8 bytes

Appreciate your support on this

It is unclear what you need or why you are asking here;  can I suggest you read all the available documentation for this 'Host' and consult with it's owner's or administrators first.

Then please ask a smart question here.

--

Mark

[murtuza chhil]

Not much can be done when we don't have access to the KBPK , the clear key or the program you are using for generating the keyblock.

If you want you can try by plugging in your values in the test code at 

https://github.com/chhil/TR31Keyblock/blob/main/src/main/java/org/keyblock/tr31/Main.java 

-chhil

[Kapilashantha Rajapaksha]

Hi Chhil and Mark,

Sorry about my bad typing. 

I'm using same project - https://github.com/chhil/TR31Keyblock/blob/main/src/main/java/org/keyblock/tr31/Main.java 

KBPK - Triple Length Key (24 bytes ) and ZPK also Triple Length key (24 bytes)

================================================================================================================

I'm using below test case -  

test3TDEAKeyBlockTypeB();

public static void test3TDEAKeyBlockTypeB() throws Exception {

Header header = new Header(KeyblockType._B_TDEA_KEY_DERIVATION_BINDING, KeyUsage._P0_PIN_ENCRYPTION,

Export.E_EXPORTABLE_UNDER_TRUSTED_KEY, Algorithm._T_TRIPLE_DES,

KeyUseFor.E_ENCRYPT_ONLY, "00");

TR31KeyBlock kb = new TR31KeyBlock(header);

kb.setClearKey(Bytes.parseHex("F039121BEC83D26B169BDCD5B22AAF8FF039121BEC83D26B"));

kb.setKBPK("260892192061C8760BDF235E1619B057B334FED0EFA74F32");// triple length

kb.generate();

System.out.println(kb.toString());

}

Output as below

6C8AC1B7AE4E546239F16C051841F058E6AABBE85AF7FE1A5F918B3567C2343AB6ACC3F41B02C9654C2B73665A96D327

KBPK 260892192061C876 0BDF235E1619B057 B334FED0EFA74F32

KBPK[K1_CMAC]=92FF93B268C67876, KBPK[K2_CMAK]=25FF2764D18CF0F7

KBEK[kbek1]=C663C8FBDC5E1061 KBEK[kbek2]=12F7A014BDFC561D

KBEK[kbek3]=913C9F522283ADE6

KBEK=C663C8FBDC5E1061 12F7A014BDFC561D 913C9F522283ADE6

KBMK[kbmk1]=E157450719CC9B51 KBMK[kbmk2]=72C77B811B76DD0C

KBMK[kbmk2]=E95657F280A17E98

KBMK=E157450719CC9B51 72C77B811B76DD0C E95657F280A17E98

KBMK[KM1_CMAC]=99DD2D20F25D2ADD KBMK[KM2_CMAC]=33BA5A41E4BA55A1

KBMK MAC Key=99DD2D20F25D2ADD 33BA5A41E4BA55A1 99DD2D20F25D2ADD

ClearKey=F039121BEC83D26B169BDCD5B22AAF8FF039121BEC83D26B

Length Encoded ClearKey=00C0F039121BEC83D26B169BDCD5B22AAF8FF039121BEC83D26B

LengthEncode Padded Clear Key=00C0F039121BEC83D26B169BDCD5B22AAF8FF039121BEC83D26B000000000000

Encrypted Key=3A9EA40DC754C375E9418ABDEC39882F8B52E96352EB1CF66AEF61567F165850

Mac :4C2B73665A96D327

Header + encrypted key + mac

B0080P0TE00E0000 3A9EA40DC754C375E9418ABDEC39882F8B52E96352EB1CF66AEF61567F165850 4C2B73665A96D327

================================================================================================================

And above table content shared by the host vendor (no more any documents from the host vendor.

I have below 2 issues

• As per vendor spec total length of Key block - 0096 but above program it will be 0080, what is the correct length for TDES?
• As per vendor spec MAC bytes only 4 but above it's 8 bytes, what is the correct one ?

Further I have used BP tool with triple DES same keys, I have got the 0096 Key block but again MAC value is 8 bytes.

Thanks

--
--
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/50ea1415-f6c2-4262-92ba-6198d54f3151n%40googlegroups.com.

[Kapilashantha Rajapaksha]

And I have attached the BP too testing as well 

===============================================================================================================

 [2023-04-19 14:49:29]

 TR-31 Key Block: Key block encrypt operation finished

 ****************************************

 KBPK: F039121BEC83D26B169BDCD5B22AAF8FF039121BEC83D26B

 Header: B0096P0TB00E0000

 Plain Key: 260892192061C8760BDF235E1619B057B334FED0EFA74F32

 ----------------------------------------

 TR-31 Key Block: B0096P0TB00E00008426C3111A69083C2D5638F50D1376EB85EF09E4DFEA6240F2D32A76341664C1E3E2C6764E5C9820

 

 

 

 

  [2023-04-19 14:50:48]

 TR-31 Key Block: Key block decode operation finished

 ****************************************

 KBPK: F039121BEC83D26B169BDCD5B22AAF8FF039121BEC83D26B

 TR-31 Key block: B0096P0TB00E00008426C3111A69083C2D5638F50D1376EB85EF09E4DFEA6240F2D32A76341664C1E3E2C6764E5C9820

 ----------------------------------------

 TR-31 Header: B0096P0TB00E0000

 ----------------------------------------

   Version Id: B

   Block Length: 0096

   Key Usage: P0

   Algorithm: T

   Mode of Use: B

   Key Version No.: 00

   Exportability: E

   Num. of Opt. blocks: 00

   Reserved: 00

   Optional Blocks:

 TR-31 Encrypted key: 8426C3111A69083C2D5638F50D1376EB85EF09E4DFEA6240F2D32A76341664C1

 TR-31 MAC: E3E2C6764E5C9820

 ----------------------------------------

 Plain Key: 260892192061C8760BDF235E1619B057B334FED0EFA74F32

===============================================================================================================

It's 0096 length but 8 bytes MAC.  In addition, I have seen some definitions of TR-31 MAC. (EFTlab - Breakthrough Payment Technologies (eftlabs.com))

• When using a DES Key Block LMK, the Key Block Authenticator is calculated using a 3DES CBC-MAC, with a zero IV. (No padding is required, as the data to be authenticated is always a multiple of 8 bytes in length.) The left-most 4 bytes of the result will be used as the Authenticator. The authentication key will be a variant of the LMK.
• When using an AES Key Block LMK, the Key Block Authenticator is calculated using an AES CMAC over the clear Key Block. The left-most 8 bytes of the result will be used as the Authenticator. The authentication key will be cryptographically derived from the LMK.

I'm waiting for you expertise for this 

[Mark Salter]

As already indicated, you need to read the Host specification to know what they are doing so you can match their needs.

-- 

Mark

Sent from Proton Mail mobile



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

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV0j-fMDjmxHzZoJpR1xjiRwFZws8udX8j-o0w-4ce-pxQ%40mail.gmail.com.

[DUMP VN]

Both of them are wrong:

1. Your host spec is wrong in that encrypted data and MAC breakup. MAC length should be 8 bytes (16 hex), encrypted data should be 32 bytes (64 hex) only.

2. The library you are using is wrong in that Length encoding (and so the MAC), the length should be 0096 (16 header + 64 encrypted data + 16 mac = 0096)

so,

1. correct length is 0096

2. MAC is 8 bytes

[Kapilashantha Rajapaksha]

Dear Dumpvn,

I have found with code (they have set length wrongly ) And I have compared below test cases with BP tool 

• Using KBPK - > 16 bytes and clear key 16 bytes - Result Tally (can decode from PB tool)
• Using KBPK - > 24 bytes and clear key 16 bytes - Result Tally (can decode from PB tool)
• Using KBPK - > 16 bytes and clear key 16 bytes - Result Failed (can't decode from PB tool)
• Using KBPK - > 24 bytes and clear key 24 bytes - Result Failed  (can't decode from PB tool)

My requirement is (Using KBPK - > 24 bytes and clear key 24 bytes) -  Can you help me where I should change the code ? 

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/cb42d51d-3e7e-45cf-b51e-319e1e152a2an%40googlegroups.com.

[Mark Salter]

If the Host sample regurgitated directly and has not been munged, then I would hope it is right - *for them*.

Still best to check with the Host and documentation for their details and assistance than here.

-- 

Mark

Sent from Proton Mail mobile



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

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/cb42d51d-3e7e-45cf-b51e-319e1e152a2an%40googlegroups.com.

[chhil]

Depending on the version id the MAC length varies. The library is written by me and verified with against a standard EFT simulator.

Could you elaborate on stating things are wrong and the following are right?

1. correct length is 0096

2. MAC is 8 bytes

You received this message because you are subscribed to a topic in the Google Groups "jPOS Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jpos-users/fJGCmEdRSUo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/cb42d51d-3e7e-45cf-b51e-319e1e152a2an%40googlegroups.com.

[chhil]

Kapilashantha,

I currently don't have the time to investigate the problem and match it with the TR31 ansi spec. You could open github issue which I may get to sometime in the future. If you have the Tr31 spec feel free to debug the code and provide a patch.

This was something I created just to understand TR31 and play with some crypto. I personally don't use it. At work we use thales hsms for our TR31 needs.

• Using KBPK - > 16 bytes and clear key 16 bytes - Result Tally (can decode from PB tool)
• Using KBPK - > 24 bytes and clear key 16 bytes - Result Tally (can decode from PB tool)
• Using KBPK - > 16 bytes and clear key 16 bytes - Result Failed (can't decode from PB tool)
• Using KBPK - > 24 bytes and clear key 24 bytes - Result Failed  (can't decode from PB tool)

My requirement is (Using KBPK - > 24 bytes and clear key 24 bytes) -  Can you help me where I should change the code ? 

[chhil]

A temporary hack for it to work for you (Using KBPK - > 24 bytes and clear key 24 bytes) is to change
https://github.com/chhil/TR31Keyblock/blob/main/src/main/java/org/keyblock/tr31/Header.java#L119

In there add another 16. (Its specific to your current use case, it will break other combinations)

blocklength = 16 + optionalblocks + 48 + 16 +16;// #header, optional blocks,key len in ascii, mac

[2023-04-19 05:11:27 PM]
 TR-31 Key Block: Key block decode operation finished
 ****************************************
 KBPK:            F039121BEC83D26B169BDCD5B22AAF8FF039121BEC83D26B
 TR-31 Key block:    B0096P0TB00E0000362D6B7B5D73969D3560CB6EE142206A34C9A0D5736619868843D35054F36B11C1BFFAA30E1EFB5D
 ----------------------------------------
 TR-31 Header:        B0096P0TB00E0000
 ----------------------------------------
   Version Id:        B - TDEA Key Derivation Binding Method
   Block Length:    0096
   Key Usage:        P0 - PIN Encryption Key
   Algorithm:        T - Triple DES
   Mode of Use:        B - Both Encrypt & Decrypt / Wrap & Unwrap
   Key Version No.:    00
   Exportability:    E - Exportable u. a KEK (meeting req. of X9.24 Pt. 1 or 2)
   Num. of Opt. blocks:    00
   Reserved:        00
   Optional Blocks:    
 TR-31 Encrypted key:    362D6B7B5D73969D3560CB6EE142206A34C9A0D5736619868843D35054F36B11
 TR-31 MAC:        C1BFFAA30E1EFB5D
 ----------------------------------------
 Plain Key:        260892192061C8760BDF235E1619B057B334FED0EFA74F32

Java test

        Header header = new Header(KeyblockType._B_TDEA_KEY_DERIVATION_BINDING, KeyUsage._P0_PIN_ENCRYPTION,



                                   Export.E_EXPORTABLE_UNDER_TRUSTED_KEY, Algorithm._T_TRIPLE_DES,



                                   KeyUseFor.B_BOTH_ENCRYPT_AND_DECRYPT, "00");





        TR31KeyBlock kb = new TR31KeyBlock(header);





        kb.setClearKey(Bytes.parseHex("260892192061C8760BDF235E1619B057B334FED0EFA74F32"));



        kb.setKBPK("F039121BEC83D26B169BDCD5B22AAF8FF039121BEC83D26B");



        kb.generate();



        System.out.println(kb);

You can see the plain key matching in EFT Sim and the TR31 code.

-chhil

[DUMP VN]

>  Depending on the version id the MAC length varies.

 let's talk about the definition of length, it's the total length of keyblock in decimal. let me know if you don't agree.

and here is the last 2 lines of output of your library:

Header + encrypted key + mac

B0080P0TE00E0000 3A9EA40DC754C375E9418ABDEC39882F8B52E96352EB1CF66AEF61567F165850 4C2B73665A96D327

Do you see what's wrong here ? the Header length + encrypted key length already 80, not counting any bytes of MAC. if you add 8 bytes MAC (16 hex), it must be 96, not 80.

[Kapilashantha Rajapaksha]

Hi Chhil,

Thank you very much - https://github.com/chhil/TR31Keyblock/blob/main/src/main/java/org/keyblock/tr31/Header.java#L119

It's working and tally with the PB tool as well. 

 [2023-04-20 08:49:38]

 TR-31 Key Block: Key block decode operation finished

 ****************************************

 KBPK: 260892192061C8760BDF235E1619B057B334FED0EFA74F32

 TR-31 Key block: B0096P0TE00E000087468EC5A87BB394D5A1A0BD92CE4275477108CCE6BA8446346D0ECDBAAB72C6A9D62F8F685A50F5

 ----------------------------------------

 TR-31 Header: B0096P0TE00E0000

 ----------------------------------------

   Version Id: B

   Block Length: 0096

   Key Usage: P0

   Algorithm: T

   Mode of Use: E

   Key Version No.: 00

   Exportability: E

   Num. of Opt. blocks: 00

   Reserved: 00

   Optional Blocks:

 TR-31 Encrypted key: 87468EC5A87BB394D5A1A0BD92CE4275477108CCE6BA8446346D0ECDBAAB72C6

 TR-31 MAC: A9D62F8F685A50F5

 ----------------------------------------

 Plain Key: F039121BEC83D26B169BDCD5B22AAF8FF039121BEC83D26B

But as per the vendor spec it's 4 bytes MAC, so how can I address this one ? 

Host spec -  In fact, the above table is the host specification.  further they are telling it's TR-31 ANSI standard

Regards 

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/d6b9103d-fd06-4144-a924-c3c71b022279n%40googlegroups.com.

[chhil]

> Do you see what's wrong here ? the Header length + encrypted key length already 80, not counting any bytes of MAC. if you add 8 bytes MAC (16 hex), it must be 96, not 80.

The MAC length varies , its not 8 fixed. I agree the length being hardcoded to 0080 is incorrect and varies with input clear key length that needs to be wrapped. A temporary hack has been provided. Thank you for taking the time to respond.

> But as per the vendor spec it's 4 bytes MAC, so how can I address this one ? 

TR31 spec does not say anything about truncating MAC's.  Usually, the MAC remains the same and substrings are done to extract the correct amount based on regular encryption that I have dealt with.

The only thing you could try is strip the excess characters and change the length in the header appropriately.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV3bT21GD7kqj6gXSUYL8JHZvRNoXaOFD%2BwcmBEP%3D_kB3Q%40mail.gmail.com.

[chhil]

Github has been updated with a proper fix.

This group being a JPOS group, TR31 is off-topic and generates a lot of noise, it would serve everyone well to report problems with an opensource third party library at the appropriate place (in this case github issues for that repo).

-chhil

[Kapilashantha Rajapaksha]

Thanks Chhil, 

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAPazefDt0Dfq3NHB1YGRUJM8OUsK%2BneCLAcZ%3DwyiwF6N8GiNDg%40mail.gmail.com.

[Mark Salter]

Ask the *host* how they calculate the mac (perhaps they only want the first or second half).

-- 

Mark

Sent from Proton Mail mobile



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

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV3bT21GD7kqj6gXSUYL8JHZvRNoXaOFD%2BwcmBEP%3D_kB3Q%40mail.gmail.com.

[Kapilashantha Rajapaksha]

Hi Chhil,

I'm using your latest repo for TR-31 key block implementation.  And I'm facing an issue to validate the receiving keyblock from the host.  It seems like that it is not implemented in code.  

public static void decryptAndValidate() throws Exception {

TR31KeyBlock kb = new TR31KeyBlock();

String keyBlock = "B0096M1TC00E0000339021DE38A48262A8A78EE5B8F938A3E7321C940CCF1E6676DEB20CB4331C713AED12CA92F43F05";

String kbpkString = "260892192061C8760BDF235E1619B057B334FED0EFA74F32";

if (kb.decryptAndValidateEncryptedKeyblock(keyBlock, kbpkString)) {

System.out.println("VALID");

}

else {

System.out.println("INVALID");

}

}

OutPut

>>>>>>>>> MAC _B_TDEA_KEY_DERIVATION_BINDING

INVALID

Let me know how to extract clear key from KB?

thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/MzBBYidx0lLka0-1U7PfrhhIgzX0tWgDzgvw8DLFh11hT9gLVr_ua4EzIj-hOVAAKLozsIRNX7UvciB7aFhhPcxg6rsGjzX12k_67zge-ok%3D%40pm.me.

[chhil]

You can try the following. Currently, if the mac mismatches, an exception is thrown (you can change the 5 at the end of the string in your keyblock to anything else and try it)

        TR31KeyBlock kb = new TR31KeyBlock();



        String keyBlock = "B0096M1TC00E0000339021DE38A48262A8A78EE5B8F938A3E7321C940CCF1E6676DEB20CB4331C713AED12CA92F43F05";



        String kbpkString = "260892192061C8760BDF235E1619B057B334FED0EFA74F32";



        kb.decryptKeyBlock(keyBlock, kbpkString);



        System.out.println("C L E A R K E Y = " +kb.getClearKey().encodeHex(true));


        System.out.println(kb);

-chhil

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV2sTRBO-wsGLAidfPdAkb0NBcsmBf342uQZ2zytmBjifA%40mail.gmail.com.

[Kapilashantha Rajapaksha]

Hi Chhil,

I can't find below method 

kb.decryptKeyBlock(keyBlock, kbpkString);

regards

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAPazefD81yryAuqnZq2q5phSBTJtb1XChVHSpzO4BDCOwat7-w%40mail.gmail.com.

[chhil]

https://github.com/chhil/TR31Keyblock/blob/main/src/main/java/org/keyblock/tr31/TR31KeyBlock.java#L324-L376

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV1rhx0pCdB%3DYGvekvWUM6E17yAFbandsPAdFrY4Jg1XHg%40mail.gmail.com.

[Kapilashantha Rajapaksha]

Thanks it's working now

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAPazefDje73sUQYPn%3Dk-_0kgAhJ_2u-WC9Y2FPwDWyRGe60PBA%40mail.gmail.com.

[Kapilashantha Rajapaksha]

Dear Chhil,

I'm facing issue to generate mac using mac key.

I'm receiving right mac key (key check value is correct in both side)

mac key = 85323286bc3d2910c12a49bfdad9ad85b67c62237301518a

Mac data = 3030303030303031303030303231363831303338383734353137313558595A414243313134343030383839

I cant get HSM generate MAC in my program level - 

Host side - HSM request and response 

       RSM5M600111FFFS00088M1TC00E000286B7CC40320693D98B22A116802E3D8F461B89FE16

       5E92825270C580F85CCE8082C922510058303030303030303130303030323136383130333

       8383734353137313558595A414243313134343030383839??

 RSM5M700 55C53169BEF16CBB  (HSM return mac)

Regards 

[chhil]

Sorry I don't understand how this is TR31 keyblock related. 

The host side hsm request response messages, I have no clue what they mean or are related. 

The TR31 sim is just a poc for handling TR31 wrapped keys. What those keys do, encrypt/Mac etc are not the intent of the sim. 

-chhil

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV37L1hbE%3DN%3DwU-9T6dMN5uKtOqe5z7Q90DbyMZDK0WLrA%40mail.gmail.com.

[Kapilashantha Rajapaksha]

Chhil,

ThelseHSM they are using host command M6/M7  

Initially , I'm receiving key exchange (TR-31 MAC key block) and I have successfully extracted the key and check kvc it's tally in both side. 

But  generating mac at my program level is not matching with receiving. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAPazefDoAnF1gvN485kMjj0hgUf0dy1TP7qRtrGx%2BqSr5sERqw%40mail.gmail.com.

[chhil]

You may want to try the eft sim to generate the Mac using the thales command and use Java crypto with different MACing algorithms to see what matches. 

-chhil

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV0Hvgy9%2BbYmV7hHuwxchLSzM7-f11KQoY%2Bj1AQN2V4u6w%40mail.gmail.com.

[Kapilashantha Rajapaksha]

 [2023-05-16 17:49:55] BP-Tools - Cryptographic Calculator is ready

 ********************

 [2023-05-16 17:51:04]

 Retail MAC operation finished

 ****************************************

 Key:       85323286bc3d2910c12a49bfdad9ad85b67c62237301518a

 Algorithm: 3DES

 Finalize:  None

 Data:      3030303030303031303030303231363831303338383734353137313558595A414243313134343030383839

 ----------------------------------------

 MAC:       DB55D91CB639C888

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAPazefCygN9j4sjCVdJ6rgU3Mp%2BH7GPvRJ72j5rC88YOWxSBVg%40mail.gmail.com.

[chhil]

You should probably look at the jpos crypto code that does MACing. 

Sorry I cannot be of more help here. 

-chhil

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV3DBNH3i_gdJt9S3JN9z5bpQQQZNdaxeLANkJwAMcy6fw%40mail.gmail.com.

[chhil]

You need to find the ISO 9797 MAC algorithm 1  implementation and use it in java.

https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/security/jceadapter/JCESecurityModule.java#L169

jpos jsecurotymodule has calculateMACISO9797Alg3, you will need to find an implementation fpr alg1 padding 1 or write it yourself if you can find the specification. Or have the have use 3 which has an implementation in jpos.

'3': ISO 9797 MAC algorithm 3 (= ANSI X9.19 when used with a double-length key) (DES only)

And have them use padding method 2 which is available in jpos.

'2': ISO 9797 Padding method 2

https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/security/jceadapter/JCESecurityModule.java#L544-L594

   RSM5
   M6
   0 : Only block of a single-block message
   0 : Binary
   1 : MAC size of 16 hex digits
   1 : ISO 9797 MAC algorithm 1 (= ANSI X9.9 when used with a single-length key) (DES only)
   1 : ISO 9797 Padding method 1
   FFF : Ignored keytype
   S00088M1TC00E000286B7CC40320693D98B22A116802E3D8F461B89FE165E92825270C580F85CCE8082C9225100583030303030303031303030303231363831303338383734353137313558595A414243313134343030383839??

[Mark Salter]

That mac data looks like it might well be hex, but in your hsm m6 command you are saying it is binary. I would check that first and also with the supplier (as previously suggested) of thus request and values for their details.

-- 

Mark

Sent from Proton Mail mobile



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

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV37L1hbE%3DN%3DwU-9T6dMN5uKtOqe5z7Q90DbyMZDK0WLrA%40mail.gmail.com.

[Kapilashantha Rajapaksha]

Is this supported only double length key (128 bits) ? my case I'm using triple des KEY 

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/Km96LM7R-slCe8HeNgjdee-hvaIjKsIZzZAyEsON59mQkosSp00Gvrd7ME3-H7AzldxbP25k501oSbvENNSW0VlwNyiRVwKqQUWz7HZMOao%3D%40pm.me.

[chhil]

You will probably need to talk to the host side and determine if the hsm request command they are creating has the correct field values.

-chhil

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV2gMwfuWPgaVmtfabe9dv%3D-GY221Ft%3DccX4Og8%2B7dVcFA%40mail.gmail.com.

[Kapilashantha Rajapaksha]

Chhil,

It's already live system and  it's working with other clients.  try  google but cannot find out any code to generate MAC X9.9 using triple des key.  

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAPazefA24oOjE4gwgzADGE6Lt-AEmdh6yWcEhmUfPfjrditaOA%40mail.gmail.com.

[Mark Salter]

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

On 17 May 2023, 06:12, Kapilashantha Rajapaksha < kapila...@gmail.com> wrote:

>> It's already live system and  it's
>> working with other clients. 

The system suppling your input is live?
Just your code is not able to reproduce the same?
Are you unable to ask them for an example of a worked through MAC calculation?
Do they not document the process (as they implement it) and so what data and keys lengths are used?

Who is the supplier of this message that you are not yet able to process - that small detail will help us know if we have existing function that also works with them.

Otherwise we need to guess based on what you are sharing; which is not currently not really enough.

--
Mark

[chhil]

Options

1. Buy the iso spec if it's important and implement it.

2. Use a true HSM.

3. Make a separate new post in jpos group pointing to ISO 9797 alg3 implemented in JSEcurityModule and if any one has ideas or a shareable implementation of ISO9797 Alg 1 padding 1

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV1DxSBj_UY%3DsZmizXX8UAXE4MfPnFAd59qt-MjRMStztA%40mail.gmail.com.

[Kapilashantha Rajapaksha]

I could able to create correct mac from BP tool 

And using Iso9797Alg3 - Retail MAC Calculation in Java · GitHub 

But it will return the wrong mac value , any changes need to be done ? 

--
--
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/nqrPrrWyrhlgOKZ8VJBGUADmQPp_1ZULQX7TW2SFpcQgvZ7U9WQuK962RQnWUL8n9Y8FKGarlGfp-mjXz4EZ6TE9Io6eNw56PH-KIYUuzRw%3D%40pm.me.

[chhil]

Mark, 

The MAC is coming from a real Thales HSM, so its implementation wont be documented anywhere.

The OP is using a software hsm to talk to the "live" system and he cannot validate the MAC in software because the algorithm and padding used to generate the MAC is not implemented in the software hsm.

-chhil

--
--
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 a topic in the Google Groups "jPOS Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jpos-users/fJGCmEdRSUo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jpos-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/nqrPrrWyrhlgOKZ8VJBGUADmQPp_1ZULQX7TW2SFpcQgvZ7U9WQuK962RQnWUL8n9Y8FKGarlGfp-mjXz4EZ6TE9Io6eNw56PH-KIYUuzRw%3D%40pm.me.

[chhil]

You did not provide the correct data when you shared the key and data as compared to what is in your BP tools , your image shows 172 you provided 86.

Ended up wasting my time on it.

-chhil

You received this message because you are subscribed to a topic in the Google Groups "jPOS Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jpos-users/fJGCmEdRSUo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV1L3GUP8LSQAqqS2iJXQM_DX_urFL1fDDWTq0%3DF5dy-XQ%40mail.gmail.com.

[Mark Salter]

OK, I had not even risked surmising this from the OPs posts.

So your earlier posting is the way they should go and I can safely ignore this rather wasteful thread:-)

-- 

Mark

Sent from Proton Mail mobile

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

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/CAPazefDOsmLmfbek5T93AhWxr60M7vD23b%2B6QuPHj5VE8TAzMw%40mail.gmail.com.

[chhil]

If you had provided the correct data it would have just worked.

          public static void main(String[] args) throws 

            NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, IllegalBlockSizeException,

            BadPaddingException, InvalidAlgorithmParameterException {


//Data padded with 0's at the end to make it a multiple of 8

        String hexData = "33303330333033303330333033303331333033303330333033323331333633383331333033333338333833373334333533313337333133353538353935413431343234333331333133343334333033303338333833390000";



        String                 key = "85323286bc3d2910c12a49bfdad9ad85b67c62237301518a";

        Key                    k   = new SecretKeySpec(ISOUtil.hex2byte(key), "DESede");

        Cipher                 c   = Cipher.getInstance("DESede/CBC/NoPadding");

        AlgorithmParameterSpec aps = new IvParameterSpec(new byte[8]);

        c.init(Cipher.ENCRYPT_MODE, k, aps);

        byte[] out = c.doFinal(ISOUtil.hex2byte(hexData));



        System.out.println(ISOUtil.hexdump(out));



    }

Output

      0000  CD 09 2D 77 0E E1 3B 0C  E1 12 20 14 71 3A E5 A3  ..-w..;... .q:..

0010  FD A4 B9 AD 4C 67 35 E9  11 BF CB 36 F6 14 84 DD  ....Lg5....6....

0020  9F 48 16 AE C1 32 5B E3  A3 F7 37 0E A0 27 BE 73  .H...2[...7..'.s

0030  81 C6 CE DF 8B 6E 5F 76  AC 68 72 90 47 02 CF B7  .....n_v.hr.G...

0040  84 C2 F6 44 6E 8F 3D 80  4B 39 60 08 17 03 8E 81  ...Dn.=.K9`.....

0050  55 C5 31 69 BE F1 6C BB                           U.1i..l.            <--- MAC

-chhil

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/DMxLjXZXzSp_wBsxNRdJTewTeW4dFoWXiFLkTL4s4sXG5YmN3cu8cAVNrfeWbQwqFknb_yBBa5Vjj255vIQGRFdjwmhUQOrdhVEDFQ82Ny4%3D%40pm.me.

[Kapilashantha Rajapaksha]

Thanks Chhil, it's working now I covered all things. 

Actually I have shared the hsm request (that is correct data) and so I just double ascii and check then i found that is the correct way  we have input mac data 

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/DMxLjXZXzSp_wBsxNRdJTewTeW4dFoWXiFLkTL4s4sXG5YmN3cu8cAVNrfeWbQwqFknb_yBBa5Vjj255vIQGRFdjwmhUQOrdhVEDFQ82Ny4%3D%40pm.me.

[chhil]

Good for you and all of us :)

I saw the following and used it as data and manually created the data from the bp-calc sim image where you said it worked.

Mac data = 3030303030303031303030303231363831303338383734353137313558595A414243313134343030383839

-chhil

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAKV%2BfV1wrcXB7mBMBsgrE1ew6%3DY1A9e7O7pS1ZDtEWcoVVr1FA%40mail.gmail.com.