Everyone,

My current environment is using CCA external keys for my general encryption needs.  I get to convert most if not all of these keys to TR-31 format as part of PCI PIN security requirements.

Part 1: I'm starting with external CCA keys stored on my own application files.  I currently pass those keys into various CCA functions to encrypt and decrypt my data.   I now get to convert all those keys to external TR-31 keyblock format for my encrypt and decrypt ICSF calls.  For a conversion process, I can export those external CCA keys into TR-31 keyblock format, but I'm fairly sure I cannot use those resulting keyblocks for encrypt and decrypt operations.

Part 2: Today, I get a partner key that I import with a KEK (CCA internal key) into a CCA external key.  This resulting key is also used to encrypt and decrypt my data.  In the future I will get a TR-31 block that I must import and save the resulting imported key into an external TR-31 keyblock format.  And use that resulting TR-31 keyblock for encrypt and decrypt ICSF calls.

My current (and limited) understanding of ICSF API suggests I can import and export TR-31 keyblocks, but I cannot use them in ICSF API calls to encrypt and decrypt data.

Can ICSF do what I want or am I forced to import all my TR-31 keys into CCA keys before calling encrypt and decrypt ICSF API operations?

Sincerely,
Mark Vollmer


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

Your understanding is correct, Mark. The current support for TR-31 key blocks is for key exchange - export and import operations. To make a key "operational" - in other words usable in CCA services - it must be imported via the CSNBT31I import service which will result in an "internal" operational key enciphered under the coprocessor's master key, which can then be used in encrypt/decrypt operations. There are a variety of services that accept a key encrypting key alongside a source key as input parameters, but the output is typically another key, not encrypted data.

------------------------------
Bob Petti
------------------------------

Bob,

Thanks very much for the clarification.   It most definitely helps me out.

Has anyone heard if IBM will update ICSF to accept TR-31 keys for encryption operations in the future or are they satisfied they're done with TR-31 support?

-Mark Vollmer

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

Original Message:
Sent: Thu September 15, 2022 06:45 AM
From: Bob Petti
Subject: TR-31 keyblock ICSF capabilities exploration questions

Your understanding is correct, Mark. The current support for TR-31 key blocks is for key exchange - export and import operations. To make a key "operational" - in other words usable in CCA services - it must be imported via the CSNBT31I import service which will result in an "internal" operational key enciphered under the coprocessor's master key, which can then be used in encrypt/decrypt operations. There are a variety of services that accept a key encrypting key alongside a source key as input parameters, but the output is typically another key, not encrypted data.

------------------------------
Bob Petti
------------------------------

We cannot comment on future plans in a public forum like this, but rest assured operational TR-31 key blocks is an item of interest within IBM.

------------------------------
Bob Petti
------------------------------

Original Message:
Sent: Thu September 15, 2022 11:19 AM
From: Mark Vollmer
Subject: TR-31 keyblock ICSF capabilities exploration questions

Bob,

Thanks very much for the clarification.   It most definitely helps me out.

Has anyone heard if IBM will update ICSF to accept TR-31 keys for encryption operations in the future or are they satisfied they're done with TR-31 support?

-Mark Vollmer

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


Original Message:
Sent: Thu September 15, 2022 06:45 AM
From: Bob Petti
Subject: TR-31 keyblock ICSF capabilities exploration questions

Your understanding is correct, Mark. The current support for TR-31 key blocks is for key exchange - export and import operations. To make a key "operational" - in other words usable in CCA services - it must be imported via the CSNBT31I import service which will result in an "internal" operational key enciphered under the coprocessor's master key, which can then be used in encrypt/decrypt operations. There are a variety of services that accept a key encrypting key alongside a source key as input parameters, but the output is typically another key, not encrypted data.

------------------------------
Bob Petti

Hello Mark,

Good to hear from someone who is already seeing how to implement the PCI Key Block TR-31 requirement.  I invite you to see this link which was written by Mr. Richard Kisley who has helped me understand these changes a little more.

https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/richard-kisley1/2021/05/21/ibm-tdes-key-token-wrapenh3-for-pci-pin

To comply with phase one of the PCI PIN Key Blocks requirement, IBM CCA introduces the IBM TDES fixed-length key block with enhanced wrapping method 3 (WRAPENH3).

Enhanced wrapping method 3 (WRAPENH3) adds several important security features to the IBM fixed-length TDES key block. 

You can use a utility for the migration of all TDES keys in a CKDS to WRAPENH3 wrapping method

I haven't done it yet, but I understand that once the CKDS is converted to the current APIs it will work without problems.

I understand that by having this covered, for phase two of the PCI requirement, it impacts the dynamic exchange of KEK keys and there if we have to use the new functions of importing the block in standard TR-31 format to be able to work with it later.

Then the pinblock received in the transactions must be verified using the Key Token generated in the previous process.

For phase three of the requirement, it is necessary to see the part of exporting keys in standard TR-31 key blocks format, but here you can find ATMs that handle RKL and it is necessary to see the TR-32 standard.

It will be quite a challenge for those of us who manage crypto using CCA/ICSF to implement these changes, however, the Crypto team has provided us with many things to get it up and running.

------------------------------
Gustavo Ramirez
------------------------------

Gustavo,

Thanks very much for this help.  I'm happy to see additions to TR-31 support.  I'll rummage around the IBM documentation to see if there is a new APG covering these updates.

I've checked and found that I have the latest release and this APAR is installed.  I like the idea of a fixed length DES keyblock format.

Sincerely,

------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
------------------------------

Original Message:
Sent: Sun September 18, 2022 07:03 AM
From: Gustavo Ramirez
Subject: TR-31 keyblock ICSF capabilities exploration questions

Hello Mark,

Good to hear from someone who is already seeing how to implement the PCI Key Block TR-31 requirement.  I invite you to see this link which was written by Mr. Richard Kisley who has helped me understand these changes a little more.

https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/richard-kisley1/2021/05/21/ibm-tdes-key-token-wrapenh3-for-pci-pin

To comply with phase one of the PCI PIN Key Blocks requirement, IBM CCA introduces the IBM TDES fixed-length key block with enhanced wrapping method 3 (WRAPENH3).

Enhanced wrapping method 3 (WRAPENH3) adds several important security features to the IBM fixed-length TDES key block. 

You can use a utility for the migration of all TDES keys in a CKDS to WRAPENH3 wrapping method

I haven't done it yet, but I understand that once the CKDS is converted to the current APIs it will work without problems.

I understand that by having this covered, for phase two of the PCI requirement, it impacts the dynamic exchange of KEK keys and there if we have to use the new functions of importing the block in standard TR-31 format to be able to work with it later.

Then the pinblock received in the transactions must be verified using the Key Token generated in the previous process.

For phase three of the requirement, it is necessary to see the part of exporting keys in standard TR-31 key blocks format, but here you can find ATMs that handle RKL and it is necessary to see the TR-32 standard.

It will be quite a challenge for those of us who manage crypto using CCA/ICSF to implement these changes, however, the Crypto team has provided us with many things to get it up and running.

------------------------------
Gustavo Ramirez
------------------------------