IBM Crypto Education Community

I'm reading through Chapter 10 in the ICSF APG about using TR-34.  After reading through the chapter a few times, I'm not seeing anywhere a discussion regarding using TR-34 without using TR-31 for the key block.

The hardware vendor I'm working with has a TR-34 document that discusses using K0 to indicate it is not a TR-31 formatted key block.  Whereas using K1 indicates that we are using TR-31 formatted key block.

Does the ICSF implementation of TR-34 allow for the "optional use" of TR-31 ?  If yes, might you point to the page(s) I'd need to reread, as often as necessary, for me to understand how to use TR-34 without TR-31?

Thanks,
Mark

------------------------------
Mark Vollmer
------------------------------

Hi,
TR-34 is a technical report that describes transport of a symmetric key (DES or AES-128) using an asymmetric RSA-2048 (or RSA 3072) wrapping key.  The payload in the TR-34 key 'token' - the key transport package that has the key you are sending and all the data bound to that keys - includes a TR-31 key block header according to the design of TR-34. Both the '1 Pass Key Token' and the '2 Pass Key Token' include this.  Refer to Section 6.1 of ASC X9 TR-34-2019 which shows the TR-31 key block header. 

Technically you can use Crypto Message Syntax (CMS, in IETF RFC 5652) to carry just about any payload, however X9 has defined TR-34 for the purpose of carrying keys and so they re-use the TR-31 Key Block Header to bind the key attributes to the key.

You may be asking if you can carry a K0 key in the TR-34 'key token' instead of a K1 key - in other words, does CCA allow you to export a key encrypting key with Key Usage of K0 using TR-34?  The answer is 'yes' to this question, just use the 'KEK' keyword to CSNDT34D instead of the 'KEK-WRAP' keyword.  When using the 'KEK' keyword, the CSNDT34D service will put the K0 Key Usage in the key block header carried in the TR-34 payload.

Please let me know if this helps or I misinterpreted the question.

------------------------------
Richard Kisley
------------------------------

Original Message:
Sent: Wed April 06, 2022 04:13 PM
From: Mark Vollmer
Subject: TR-34 without TR-31 possible?


I'm reading through Chapter 10 in the ICSF APG about using TR-34.  After reading through the chapter a few times, I'm not seeing anywhere a discussion regarding using TR-34 without using TR-31 for the key block.

The hardware vendor I'm working with has a TR-34 document that discusses using K0 to indicate it is not a TR-31 formatted key block.  Whereas using K1 indicates that we are using TR-31 formatted key block.

Does the ICSF implementation of TR-34 allow for the "optional use" of TR-31 ?  If yes, might you point to the page(s) I'd need to reread, as often as necessary, for me to understand how to use TR-34 without TR-31?

Thanks,
Mark

------------------------------
Mark Vollmer
------------------------------

Thanks for your response.  I think we have a slight disconnect on our understanding which I hope we can close. 

My other vendor had indicated that using KEK would result in a non TR-31 payload.  And that using KEK-WRAP would result in a TR-31 payload.  

My reading of the chapter and your response would suggest that regardless of whether I use "KEK" or "KEK-WRAP" I would still get some version of a formatted TR-31 payload when using the ICSF api transport call (2PASSCRE/1PASSCRE).  Please let me know if this is what you meant.

It would seem that the information from my vendor and the information from apg chapter 10 are not the same or even equivalent.

Thanks very much for helping me clarify what I'm reading.


------------------------------
Mark Vollmer
------------------------------

Original Message:
Sent: Fri April 08, 2022 05:26 PM
From: Richard Kisley
Subject: TR-34 without TR-31 possible?

Hi,
TR-34 is a technical report that describes transport of a symmetric key (DES or AES-128) using an asymmetric RSA-2048 (or RSA 3072) wrapping key.  The payload in the TR-34 key 'token' - the key transport package that has the key you are sending and all the data bound to that keys - includes a TR-31 key block header according to the design of TR-34. Both the '1 Pass Key Token' and the '2 Pass Key Token' include this.  Refer to Section 6.1 of ASC X9 TR-34-2019 which shows the TR-31 key block header. 

Technically you can use Crypto Message Syntax (CMS, in IETF RFC 5652) to carry just about any payload, however X9 has defined TR-34 for the purpose of carrying keys and so they re-use the TR-31 Key Block Header to bind the key attributes to the key.

You may be asking if you can carry a K0 key in the TR-34 'key token' instead of a K1 key - in other words, does CCA allow you to export a key encrypting key with Key Usage of K0 using TR-34?  The answer is 'yes' to this question, just use the 'KEK' keyword to CSNDT34D instead of the 'KEK-WRAP' keyword.  When using the 'KEK' keyword, the CSNDT34D service will put the K0 Key Usage in the key block header carried in the TR-34 payload.

Please let me know if this helps or I misinterpreted the question.

------------------------------
Richard Kisley

Original Message:
Sent: Wed April 06, 2022 04:13 PM
From: Mark Vollmer
Subject: TR-34 without TR-31 possible?


I'm reading through Chapter 10 in the ICSF APG about using TR-34.  After reading through the chapter a few times, I'm not seeing anywhere a discussion regarding using TR-34 without using TR-31 for the key block.

The hardware vendor I'm working with has a TR-34 document that discusses using K0 to indicate it is not a TR-31 formatted key block.  Whereas using K1 indicates that we are using TR-31 formatted key block.

Does the ICSF implementation of TR-34 allow for the "optional use" of TR-31 ?  If yes, might you point to the page(s) I'd need to reread, as often as necessary, for me to understand how to use TR-34 without TR-31?

Thanks,
Mark

------------------------------
Mark Vollmer
------------------------------

Hi,
You are correct.  A correctly prepared and **interoperable** TR-34 payload will always have a TR-31 key block header to describe the key being transported using TR-34.  Note that since TR-34 and TR-31 are 'technical reports', not standards, implementors can and have coded support that does not map well to the documents.  Like I said before - vendors can put whatever they want in the CMS payload and claim they are implementing TR-34.  It just won't work with any other vendors.

Let's get practical.  Say I am a bank.  I buy some new ATMs from one of the major ATM vendors, who all now support TR-34.  Now I want to send initial keys to those ATMs.  I need to implement on my mainframe or key management system a TR-34 version that is interoperable.  The ATM vendors have implemented to the TR-34 document quite closely - and expect a TR-31 key block header in the payload. 

Looking at the TR-34 document, interoperable implementations will have the below data structure, without detailing the ASN.1 Crypto Message Syntax:

------------------------------
Richard Kisley
------------------------------

Original Message:
Sent: Fri April 08, 2022 05:41 PM
From: Mark Vollmer
Subject: TR-34 without TR-31 possible?


Thanks for your response.  I think we have a slight disconnect on our understanding which I hope we can close. 

My other vendor had indicated that using KEK would result in a non TR-31 payload.  And that using KEK-WRAP would result in a TR-31 payload.  

My reading of the chapter and your response would suggest that regardless of whether I use "KEK" or "KEK-WRAP" I would still get some version of a formatted TR-31 payload when using the ICSF api transport call (2PASSCRE/1PASSCRE).  Please let me know if this is what you meant.

It would seem that the information from my vendor and the information from apg chapter 10 are not the same or even equivalent.

Thanks very much for helping me clarify what I'm reading.


------------------------------
Mark Vollmer

Original Message:
Sent: Fri April 08, 2022 05:26 PM
From: Richard Kisley
Subject: TR-34 without TR-31 possible?

Hi,
TR-34 is a technical report that describes transport of a symmetric key (DES or AES-128) using an asymmetric RSA-2048 (or RSA 3072) wrapping key.  The payload in the TR-34 key 'token' - the key transport package that has the key you are sending and all the data bound to that keys - includes a TR-31 key block header according to the design of TR-34. Both the '1 Pass Key Token' and the '2 Pass Key Token' include this.  Refer to Section 6.1 of ASC X9 TR-34-2019 which shows the TR-31 key block header. 

Technically you can use Crypto Message Syntax (CMS, in IETF RFC 5652) to carry just about any payload, however X9 has defined TR-34 for the purpose of carrying keys and so they re-use the TR-31 Key Block Header to bind the key attributes to the key.

You may be asking if you can carry a K0 key in the TR-34 'key token' instead of a K1 key - in other words, does CCA allow you to export a key encrypting key with Key Usage of K0 using TR-34?  The answer is 'yes' to this question, just use the 'KEK' keyword to CSNDT34D instead of the 'KEK-WRAP' keyword.  When using the 'KEK' keyword, the CSNDT34D service will put the K0 Key Usage in the key block header carried in the TR-34 payload.

Please let me know if this helps or I misinterpreted the question.

------------------------------
Richard Kisley

Original Message:
Sent: Wed April 06, 2022 04:13 PM
From: Mark Vollmer
Subject: TR-34 without TR-31 possible?


I'm reading through Chapter 10 in the ICSF APG about using TR-34.  After reading through the chapter a few times, I'm not seeing anywhere a discussion regarding using TR-34 without using TR-31 for the key block.

The hardware vendor I'm working with has a TR-34 document that discusses using K0 to indicate it is not a TR-31 formatted key block.  Whereas using K1 indicates that we are using TR-31 formatted key block.

Does the ICSF implementation of TR-34 allow for the "optional use" of TR-31 ?  If yes, might you point to the page(s) I'd need to reread, as often as necessary, for me to understand how to use TR-34 without TR-31?

Thanks,
Mark

------------------------------
Mark Vollmer
------------------------------

Hi,

Thanks so very much.  This is absolutely the information I needed to get up to speed.

If I have followup questions, and I most likely will in the coming weeks, I will be most happy to contact you again.

------------------------------
Mark Vollmer
------------------------------

Original Message:
Sent: Sun April 10, 2022 10:38 AM
From: Richard Kisley
Subject: TR-34 without TR-31 possible?

Hi,
You are correct.  A correctly prepared and **interoperable** TR-34 payload will always have a TR-31 key block header to describe the key being transported using TR-34.  Note that since TR-34 and TR-31 are 'technical reports', not standards, implementors can and have coded support that does not map well to the documents.  Like I said before - vendors can put whatever they want in the CMS payload and claim they are implementing TR-34.  It just won't work with any other vendors.

Let's get practical.  Say I am a bank.  I buy some new ATMs from one of the major ATM vendors, who all now support TR-34.  Now I want to send initial keys to those ATMs.  I need to implement on my mainframe or key management system a TR-34 version that is interoperable.  The ATM vendors have implemented to the TR-34 document quite closely - and expect a TR-31 key block header in the payload. 

Looking at the TR-34 document, interoperable implementations will have the below data structure, without detailing the ASN.1 Crypto Message Syntax:

KT-kdh =
{   {  R-krd || KBH || EncryptedKey || BE }, Signature, CRL }

The KBH is defined to be the TR-31 key block header for the key being carried, binding it to the key attributes.
The KBH has 16 bytes:
0 : key block version - not useful in TR-34
1-4 : length - not useful in TR-34
5-6 : Key Usage
7 : Algorithm
8 : Mode of Use
9-10 : Key Version Number
11 : Exportability
12-13 : number of optional blocks
14-15 : reserved bytes, must be 0x00 (in all TR-31 versions, but not X9.143)

The interesting fields - that control how the TR-34 token receiver uses the key - are:
5-6 : Key Usage
7 : Algorithm
8 : Mode of Use
11 : Exportability

As you know, you are asking about the value at 5-6: the Key Usage attribute.  The CSNDT34D keywords "KEK" and "KEK-WRAP" keywords only change the value at bytes 5-6, they change nothing else about the resulting TR-34 envelopedData package.  The "KEK" keyword causes a 'K0' to be put here, the "KEK-WRAP" causes a 'K1' to be put here.   Which one do you choose?  It depends on where you are sending the key.  How will the target use a 'K0' versus a 'K1'?

TR-31 defines what a 'K0' and 'K1' should be used for:

--'K0': this is a Key encrypting key.  The target should use this only for wrapping or un-wrapping other keys.  The mechanism for how the target uses the 'K0' key to do this wrapping is not specified.  The 'K0' key can be used for wrapping or un-wrapping TR-31 key blocks, although 'K1' is the preferred Key Usage for this case (see 'K1').
--'K1': this is a Key encrypting key that should only be used for wrapping or un-wrapping TR-31 key blocks.  The receiver of the TR-34 envelopedData should only use the key that they pull out of the package for wrapping or un-wrapping of TR-31 key blocks, as allowed by the 'Mode of Use' attribute.  This key should not be used by the target for wrapping or un-wrapping of other types of key blocks.

Please note: as the technical editor for TR-31-2018 and X9.143, and the designer of the IBM support for TR-31 and TR-34, I have a unique perspective that I am happy to share.  If a phone call/webex with all the parties would be better we can set that to clear up any remaining items.

------------------------------
Richard Kisley

Original Message:
Sent: Fri April 08, 2022 05:41 PM
From: Mark Vollmer
Subject: TR-34 without TR-31 possible?


Thanks for your response.  I think we have a slight disconnect on our understanding which I hope we can close. 

My other vendor had indicated that using KEK would result in a non TR-31 payload.  And that using KEK-WRAP would result in a TR-31 payload.  

My reading of the chapter and your response would suggest that regardless of whether I use "KEK" or "KEK-WRAP" I would still get some version of a formatted TR-31 payload when using the ICSF api transport call (2PASSCRE/1PASSCRE).  Please let me know if this is what you meant.

It would seem that the information from my vendor and the information from apg chapter 10 are not the same or even equivalent.

Thanks very much for helping me clarify what I'm reading.


------------------------------
Mark Vollmer

Original Message:
Sent: Fri April 08, 2022 05:26 PM
From: Richard Kisley
Subject: TR-34 without TR-31 possible?

Hi,
TR-34 is a technical report that describes transport of a symmetric key (DES or AES-128) using an asymmetric RSA-2048 (or RSA 3072) wrapping key.  The payload in the TR-34 key 'token' - the key transport package that has the key you are sending and all the data bound to that keys - includes a TR-31 key block header according to the design of TR-34. Both the '1 Pass Key Token' and the '2 Pass Key Token' include this.  Refer to Section 6.1 of ASC X9 TR-34-2019 which shows the TR-31 key block header. 

Technically you can use Crypto Message Syntax (CMS, in IETF RFC 5652) to carry just about any payload, however X9 has defined TR-34 for the purpose of carrying keys and so they re-use the TR-31 Key Block Header to bind the key attributes to the key.

You may be asking if you can carry a K0 key in the TR-34 'key token' instead of a K1 key - in other words, does CCA allow you to export a key encrypting key with Key Usage of K0 using TR-34?  The answer is 'yes' to this question, just use the 'KEK' keyword to CSNDT34D instead of the 'KEK-WRAP' keyword.  When using the 'KEK' keyword, the CSNDT34D service will put the K0 Key Usage in the key block header carried in the TR-34 payload.

Please let me know if this helps or I misinterpreted the question.

------------------------------
Richard Kisley

Original Message:
Sent: Wed April 06, 2022 04:13 PM
From: Mark Vollmer
Subject: TR-34 without TR-31 possible?


I'm reading through Chapter 10 in the ICSF APG about using TR-34.  After reading through the chapter a few times, I'm not seeing anywhere a discussion regarding using TR-34 without using TR-31 for the key block.

The hardware vendor I'm working with has a TR-34 document that discusses using K0 to indicate it is not a TR-31 formatted key block.  Whereas using K1 indicates that we are using TR-31 formatted key block.

Does the ICSF implementation of TR-34 allow for the "optional use" of TR-31 ?  If yes, might you point to the page(s) I'd need to reread, as often as necessary, for me to understand how to use TR-34 without TR-31?

Thanks,
Mark

------------------------------
Mark Vollmer
------------------------------