I'm trying to encrypt and decrypt test data using Symmetric Key Decipher/Encipher calls.

I've stored two encrypted keys in the CKDS file for use in these operations.

When I run the operations, I get a 8/3067 return/reason codes. (no privileged mode of any kind)  The manual shows the following.....
The provided key_identifier refers to an encrypted CCA key token or a key label of an encrypted CCA key token, and the CSFKEYS profile covering it does not allow its use in high performance encrypted key operations.

User action: Contact your ICSF or RACF administrator if you need to use this key with an ICSF service that supports secure keys for CPACF. For more details, see 'Enabling use of encrypted keys in callable services that exploit CPACF' in z/OS Cryptographic Services ICSF Administrator's Guide.

So I've updated my RACF with the following statements....
RDEF CSFKEYS DES.CHAOS.CAT ICSF(SYMCPACFWRAP(YES))
RDEFINE CSFKEYS CSF-PROTECTED-KEY-TOKEN ICSF(SYMCPACFWRAP(YES)) UACC(READ)
SETR RACLIST(CSFKEYS) REFRESH

Normally they want to default to UACC(NONE) and add a PERMIT call for a group with READ access.  But given my test system, I thought I'd shorten the steps.

And now that I run my tests again, I'm still getting the same results.   Can anyone shed some light on what I've missed?  (not an ICSF or RACF expert by any means).

Sincerely,

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

Hi Mark -
You are missing a CSFKEYS profile for the encrypted key labels you added to the CKDS.  DES.CHAOS.CAT is a sample key label.

------------------------------
Eleanor Chan
------------------------------

Original Message:
Sent: Thu September 29, 2022 02:57 PM
From: Mark Vollmer
Subject: Encrypt/Decrypt error 8/3067

I'm trying to encrypt and decrypt test data using Symmetric Key Decipher/Encipher calls.

I've stored two encrypted keys in the CKDS file for use in these operations.

When I run the operations, I get a 8/3067 return/reason codes. (no privileged mode of any kind)  The manual shows the following.....
The provided key_identifier refers to an encrypted CCA key token or a key label of an encrypted CCA key token, and the CSFKEYS profile covering it does not allow its use in high performance encrypted key operations.

User action: Contact your ICSF or RACF administrator if you need to use this key with an ICSF service that supports secure keys for CPACF. For more details, see 'Enabling use of encrypted keys in callable services that exploit CPACF' in z/OS Cryptographic Services ICSF Administrator's Guide.

So I've updated my RACF with the following statements....
RDEF CSFKEYS DES.CHAOS.CAT ICSF(SYMCPACFWRAP(YES))
RDEFINE CSFKEYS CSF-PROTECTED-KEY-TOKEN ICSF(SYMCPACFWRAP(YES)) UACC(READ)
SETR RACLIST(CSFKEYS) REFRESH

Normally they want to default to UACC(NONE) and add a PERMIT call for a group with READ access.  But given my test system, I thought I'd shorten the steps.

And now that I run my tests again, I'm still getting the same results.   Can anyone shed some light on what I've missed?  (not an ICSF or RACF expert by any means).

Sincerely,

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

Now that the RACF changes are updated, I'm getting 8/10028.

One of the following occurred:
• Either the left half of the control vector in a key identifier (internal or external) equates to a key type that is not valid for the service you are using or the value is not that of any ICSF control vector. For example, an exporter key-encrypting key is not valid in the key import callable service.
• An attempt was made to export a non-DATA key to CPACF protected key format. The key may be a CIPHER key which does not have the XPRTCPAC bit set in the control vector.

User action: Determine which key identifier is in error and use the key identifier that is required by the service. If this is an attempt to export a key to CPACF protected key format, either use a DATA key or a CIPHER key with the XPRTCPAC bit set in the control vector

Clear key import to generate the original data key.  Save in CKDS (key num 1)
Export key num 1 to TR-31.
Import back from TR-31 to an internal CCA token saved in CKDS as separate key. (key num 2)

The encrypt operation completed fine with the key no 1.

The decrypt operation with key no 2 completed with the error shown above.

In theory, both key no 1 and key no 2 are equivalent data encryption keys.  At least that's what I'm trying to make happen and confirm with the encrypt and decrypt operation.  I figure if I can encrypt with key no 1 and decrypt with key no 2 and get the same clear text, I will have been successful.

According to my browsing of the CKDS keys, the first created by clear key import one is "DATA", the second one generated by an import of the TR-31 keyblock is "CIPHER" . (Yes, DATA and CIPHER show in clear text on the records I'm seeing in the CKDS dataset.)

Summary:  Create data key.  Export to TR31.  Import from TR31 and save as second key.  If all went well, then the original key can encrypt and the second key should decrypt.  If not, I will not have succeeded in my efforts.   The decrypt gives the 8/10028 error.

Would you think my export to TR-31 flawed?  Or my import of the TR-31 flawed?
​
Any pointer in the right direction would be greatly appreciated.

Sincerely,

Okay, I think I'm making progress.  I put the XPRTCPAC in the rule array for the TR-31 import and I'm getting zeros for the decrypt call.

I still have a bug because the first half of the test clear data looks good, but the second half does not.  

Thanks again for all the help.   I appreciate it very much.

Sincerely,

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

Original Message:
Sent: Thu September 29, 2022 05:10 PM
From: Mark Vollmer
Subject: Encrypt/Decrypt error 8/3067

Now that the RACF changes are updated, I'm getting 8/10028.

One of the following occurred:
• Either the left half of the control vector in a key identifier (internal or external) equates to a key type that is not valid for the service you are using or the value is not that of any ICSF control vector. For example, an exporter key-encrypting key is not valid in the key import callable service.
• An attempt was made to export a non-DATA key to CPACF protected key format. The key may be a CIPHER key which does not have the XPRTCPAC bit set in the control vector.

User action: Determine which key identifier is in error and use the key identifier that is required by the service. If this is an attempt to export a key to CPACF protected key format, either use a DATA key or a CIPHER key with the XPRTCPAC bit set in the control vector

Clear key import to generate the original data key.  Save in CKDS (key num 1)
Export key num 1 to TR-31.
Import back from TR-31 to an internal CCA token saved in CKDS as separate key. (key num 2)

The encrypt operation completed fine with the key no 1.

The decrypt operation with key no 2 completed with the error shown above.

In theory, both key no 1 and key no 2 are equivalent data encryption keys.  At least that's what I'm trying to make happen and confirm with the encrypt and decrypt operation.  I figure if I can encrypt with key no 1 and decrypt with key no 2 and get the same clear text, I will have been successful.

According to my browsing of the CKDS keys, the first created by clear key import one is "DATA", the second one generated by an import of the TR-31 keyblock is "CIPHER" . (Yes, DATA and CIPHER show in clear text on the records I'm seeing in the CKDS dataset.)

Summary:  Create data key.  Export to TR31.  Import from TR31 and save as second key.  If all went well, then the original key can encrypt and the second key should decrypt.  If not, I will not have succeeded in my efforts.   The decrypt gives the 8/10028 error.

Would you think my export to TR-31 flawed?  Or my import of the TR-31 flawed?
​
Any pointer in the right direction would be greatly appreciated.

Sincerely,