I'm checking on the key pair now to see if everything is in order or not. Thanks for the suggestion.
Developer, but does everything.
Original Message:
Sent: Wed July 31, 2024 04:16 PM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
Mark -
I'm glad to hear that you resolved your issue.
When exporting/importing a key, if a NOCV EXPORTER is used on the export, a NOCV IMPORTER must be used on the import. Using a NOCV key-encrypting key on one operation but not the other would definitely cause the key value to be different.
If the NOCV bit is on in the EXPORTER or IMPORTER transport key, the transport key, not the transport key variant, is used to encipher the source key.
------------------------------
Eleanor Chan
Original Message:
Sent: Wed July 31, 2024 11:33 AM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
I can't thank you enough for all your help. Your note about matching KCV values 4 days ago, was the trigger that helped. I put in KCV checks at all the places I could and I found that when working with KEY1, it was not always the same when I created it, flavored it, and then used it later.
It seems that a utility key export/import pair was causing my problem. I put a different pair of utility keys in place, and the KCV values started to match everywhere.
I've no idea why the original utility key pair did not work. The only difference I could find was the one that did not work did not have the NOCV value, whereas the one that did work had the NOCV attribute.
When it comes to exporting an internal key to an external form, and then importing that external key back into internal form, I can't really see how NOCV would affect that. It is basically all ICSF. The partner is no where in this effort, until I use that key later.
And even more odd, the KCV values for KEY1 on the IBM side and the partner side were identical. This suggested to me that we both had the same key. And it never occurred to me we had any problem with that key. I'm now thinking that when I went to use KEY1 to encrypt KEY2, I did not get the KEY1 value that both partner ends agreed they had. I can't prove it, but that's what I'm thinking at this time.
Again, thanks very much for all your help. I would still be trying to figure all this out if you hadn't taken the time to help me.
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Tue July 30, 2024 06:50 PM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
Mark -
When using KGN to generate a key pair, both keys will have the same
clear key value.
Here is some sample code:
key_form = 'OPEX'
key_length = 'KEYLN16 '
key_type1 = 'OPINENC '
key_type2 = 'IPINENC '
kek_id2 = ''
kek_id2 = left('TEMP.NOCV.EXPORTER',64)
gen_key1 = copies('00'x,64)
gen_key2 = copies('00'x,64)
KGN returns the following keys:
gen_key1 is an operational OPINENC
010000000000C000CA6B408A02371B1D85D8AF85684CF9D4843E2BD8ACB1CCC5
00247700034100000024770003210000000000000000000000000000F363AB9D
gen_key2 is an external IPINENC encrypted with TEMP.NOCV.EXPORTER
020000000000C0000000000000000000C14520689D80F7C3F0988F34C46DD3AE
0000000000000000000000000000000000000000000000000000000015CD3B0D
gen_key2 has a zero control vector so it already looks like a DATA key.
It can be sent to your partner as is.
------------------------------
Eleanor Chan
Original Message:
Sent: Tue July 30, 2024 01:42 PM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
It does match. So far, each partner has agreed with the KCV for KEY1.
KEY2 KCV values do not reliably match.
I can get the KEY2 KCV values to match if instead of using KEYGEN I use RNGL and multiple clear key import (CKM). (KEY2-D)
I generate random ODD 16 bytes and pass that into CKM which yields a DATA key type.
I then export that with a utility key as a DATA key, then reimport that key back in as a IPINENC key. (KEY2-I)
I then use KEY1 (nocv) to export either the KEY2-D or KEY2-I and I get the same resulting cryptogram.
My parter and the IBM side do agree on the KCV values.
However, the desired approach is to use KGN.
KGN to create a operational internal IPINENC double length key.
I then export that using the utility key to an external IPINENC. Then I reimport that back into an internal DATA key type. the KCV for both internal key types match.
I then use the KEY1 (NOCV) to export the internal DATA key and send it to my partner. We can never get a matching KCV.
If I export the internal IPINENC key with the KEY1 (NOCV) and send that one down, partner can't get a matching KCV either.
For the life of me I can't figure out why generating a random key works, but using keygen does not.
I'm missing something important I'm sure.
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Fri July 26, 2024 03:16 PM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
Mark -
Calculate the KCV of the DATA key (after you "flavor" it) and before passing it to SYX. Make sure it matches the original KEY1 EXPORTER KCV.
------------------------------
Eleanor Chan
Original Message:
Sent: Fri July 26, 2024 12:03 PM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
I flavor the KEY1 exporter as a DATA key type using an export & import utility key (KEX & KIM). It is that DATA key type version of the key that I pass to SYX. I have to rules DES & PKCS-1.2.
KCV values are calculated on internal versions of all my keys prior to exporting them. Maybe I should attempt to create a KCV on the actual exported key.
I'm looking to shore up what I'm doing on the IBM side so that I can unequivocally say I'm delivering the proper cryptogram. As of now, I'm only 90% sure.
I can can say that the non IBM partner in this work does not have ICSF. They keep telling me that all they need is a DES encrypted key using ECB wrap.
It would be very nice to have the capability of getting clear keys out of ICSF in my test system and running them through another DES encryptor to validate the results.
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Fri July 26, 2024 11:46 AM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
Hi Mark -
What rule_array did you use in SYX to wrap the EXPORTER KEY1 with an RSA key? Looking at the APG, I do not see a rule that supports exporting a DES key that's not a DATA key.
Things to consider:
- Make sure you used the correct partner RSA public key in SYX to export KEY1.
- KEY2 is an external OPINENC wrapped with the NOCV EXPORTER KEY1. When calculating the KCV on an external token, the KEK must be specified in the parameter list.
- KEY2 must be imported with a NOCV IMPORTER to retrieve the correct key value. I do not know how this is done on a non-IBM system.
------------------------------
Eleanor Chan
Original Message:
Sent: Thu July 25, 2024 03:44 PM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
I'm back with my original problem, but slightly altered code to accomplish my goal.
I'm generating two DES double length keys. I have two pair of pub/priv RSA keys, one for each end of my exchange partner. IBM on one side, non IBM on the other.
I create an EXPORTER/IMPORTER key pair (KEY1), passing in a token with NO-CV settings. This returns a double length EXPORTER key, no-cv, ecb-wrapped as confirmed through the ICSF screens.
I then use SYX and the RSA keys to export the KEY1 to send to the non-IBM partner.
Both the IBM and non-IBM partner agree with the KCV values we calculate.
I now generate (KGN) an IPINENC/OPINENC pair of keys (named KEY2) (OPEX) where the IPINENC is an internal token, and the OPINENC is an external token exported with KEY1. Based on the settings we know of KEY1 and our discussion above about KGN, I can rest assured that my resulting OPINENC of KEY2 is exported with KEY1 and using ECB wrap.
When I send the encrypted KEY2 to my partner, we cannot agree on the KCV values.
I can't explain why the non-IBM partner gets a different KCV than the IBM partner.
My non-IBM partner assures me that the KEY2 value encrypted with KEY1 value using ECB settings is the proper method of creating that cryptogram to send to them.
I'm now sitting in the bad position that IBM documentation says I am creating the cryptogram correctly, but the non-IBM partner disagrees.
Would you have any ideas on where I should look in order to diagnose my problem? An extra set of fresh eyes would be appreciated very much.
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Fri June 21, 2024 09:58 AM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
Thanks very much. Using a label instead of the token worked just fine. And I'm finally where I need to be. I can't thank you enough for all your help.
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Fri June 21, 2024 09:19 AM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
Hi Mark -
I'm glad you resolved your earlier issues.
Are you using a NOCV kek token vs a key label? You need to be in supervisor state or system key to pass a NOCV key token. Add the token to the CKDS and pass the key label instead.
------------------------------
Eleanor Chan
Original Message:
Sent: Thu June 20, 2024 07:02 PM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
I've run into another road block.
If I import a clear key (key1) as a DATA type and flavor it to an EXPORTER key, using the KIM to accept a KTB skeleton token with nokek-cv set in it, I successfully create an exporter key with nocv setting.
If I key gen a new key (key2) as EXPORTER using a KTB skeleton token with nokek-cv set it it, I successfully create an exporter key with nocv setting.
When I use the key2 to export an IPINENC key I get success.
When I use the key1 to export the same IPINENC key I get the error 8/2068 - I'm not in supervisor state.
Why would one succeed where the other would fail? Aren't these equivalent in ICSF usage?
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Thu June 20, 2024 03:43 PM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
It would appear that the size of the key for my importer/exporter pair used during my flavoring operation makes a difference. Once I moved to use double length keys for my efforts, I get the results I believe I'm looking for.
The first 8 bytes of my encipher CBC, non CBC, Export IPINENC & Export DATA keys all match.
The entire cryptogram matches for both encipher results. I guess there isn't an option for ECB.
The entire cryptogram matches for both Export calls. It does not matter whether I use the IPINENC or the DATA token of the B key I'm testing with. I get the same result when exporting with the same A key I generate.
Unless there is some additional magic to get all this working with ENC, I might have good enough results to implement a solution for my problem.
Thanks very much for all your help. It most certainly got me to this point.
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Thu June 20, 2024 02:24 PM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
I had been using KYT rather than KYT2 as per the REXX example.
I've updated the calls to use KYT2 instead. still get different results though.
Does it matter if the working importer & exporter keys are triple length? Would a double length pair of importer/exporter keys work differently/better?
The keys I'm creating or importing are specified as DOUBLE.
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Thu June 20, 2024 11:11 AM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
I added the KTY calls to my flavoring routine. I can confirm that I get different results between the source token and the target token.
The rexx example you shared...
Here's a sample of how to change the key type of a key using KEX/KIM and NOCV KEKs.
https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/eysha-shirrine-powers2/2020/03/25/using-nocv-key-encrypting-keys-to-create-a-different-key-type-with-the-same-clear-key-value?communityKey=6593e27b-caf6-4f6c-a8a8-10b62a02509c
Shows the import function using a full copy of the exported target token.
source_key_identifier = target_key_identifier ; /* from KEX */
My code, using double length keys, clears the src key identifier to low values and then copies in just the double length key data from the exported token result. This starts at relative 1 offset of 17 and runs for 16 bytes.
The import completes without errors, but I can't get the kcv to match on the source and resulting tokens.
I have confirmed that the exporting and importing tokens have the same KCV when I look them up in the ICSF panels.
Using the full key as shown in the rexx example returns 8/39 a CV violation.
I also found that using DES, GENERATE & ENC-ZERO rule array returns a 8/2016
| The rule_array parameter contents are incorrect. One or more of the rules specified are not valid for this service OR some of the rules specified together may not be combined.User action: Refer to the rule_array parameter described in this publication under the appropriate callable service for the correct value.REASONCODES: TSS 021 (033) |
I have been using KEY-ENC, GENERATE, NOADJUST & ENC-ZERO for my rule array list for KYT calls. These calls complete successfully.
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Thu June 20, 2024 09:45 AM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
My B key was imported using multiple clear key import function creating a data key.
By flavor, I mean that I export the key using a working exporter key. Then reimport that exported key with the corresponding importer key back to an internal token but with a different key type. In this case, it was IPINENC.
My encipher operation is performed using the clear B key and the A key DATA key type internal token. Once with CBC as a rule array parameter. The second time, without the CBC as the rule array pointer. The two results are identical. I find that odd.
KGN is used to create a new A key for each of my tests (Feeding it a NOCV token template created by KTB). Asking for: OPEX (Exporter, Importer). I've no current need for the Importer part of this call. I then flavor the OP/Exporter key by the method mentioned above into a second OP/Data key for use in ENC calls. The OP/Exporter is used in my KEX calls.
Not using SYE at this time.
The exporter and importer work keys are NOCV double len keys.
I'll call KYT on both B key values to confirm they are identical and report back.
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Wed June 19, 2024 11:08 AM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
Mark -
I question whether your B keys (DATA and IPINENC) have the same key values. KGN generates random key values when generating keys. So, how did you retrieve the key value of the EXPORTER to "flavor" into a DATA key. BTW, I don't know what you mean by "flavor". You can confirm that the key values are the same by calling KYT2 to calculate a key check value.
If you are using SYE for the encryption, CBC is the default processing rule so it did not matter whether you specified it in the rule_array.
------------------------------
Eleanor Chan
Original Message:
Sent: Tue June 18, 2024 05:11 PM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
Thanks very much for the helpful URLs. I was not as successful using that information as I would have liked.
I use KGN to create an Eporter/Importer pair. When the help of the KTB build of an internal nocv-kek skeleton I was able to create an exporter key with a NO-CV flag and WRAP-ECB. I confirmed this through the ICSF panel lookup of the CKDS token I saved.
I then flavored that key into another DATA key type token. I now have two versions of the key. Exporter & Data.
I then use multiple clear key import to create a B key from known double length data. This gives me an internal Data key type.
I then flavor that key into a IPINENC key tpe. The B key now has three forms: clear key data, internal data token & internal ipinenc token.
I then perform an encipher with CBC in the rule array using the A key data token on the bkey clear data.
I then perform an encipher without the CBC in the rule array using the A key data token and the bkey clear data.
Both encipher results are identical.
I then export the bkey data token using the akey exporter token.
I then export the bkey ipinenc token using the akey exporter token.
Neither of these two export results match in any way shape or form, despite having the same clear key data for the export key and the same clear data for the data to be exported.
And niether of the export results match in any way, the encipher results created above.
I had expected them all to match on the first 8 bytes.
I am still missing something important. Any help to figure out what I've missed would be very much appreciated.
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Mon June 17, 2024 04:38 PM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
Here is a sample testcase to generate/create NOCV KEKs:
https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/eysha-shirrine-powers2/2020/03/25/rexx-sample-generatecreate-nocv-importerexporter-key-encrypting-key-pair?communityKey=6593e27b-caf6-4f6c-a8a8-10b62a02509c
------------------------------
Eleanor Chan
Original Message:
Sent: Mon June 17, 2024 04:23 PM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
I just found this document. It explains a lot.
https://www.ibm.com/support/pages/system/files/inline-files/keymgmt.pdf
In order to create a NOCV exporter key, I'd need....
- KGUP
- TKE Workstation
- Authorized program.
Is there another option from a problem program?
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Mon June 17, 2024 09:04 AM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
Mark -
The 8/81F failure is due to the encrypted DATA keys created by CKM. In the APG for callable service CSNBSYE under description for parameter key_identifier, it states
"For the KEYIDENT keyword, this specifies an internal clear token, or the label name of a clear key or
an encrypted key in the CKDS. Normal CKDS label name syntax is required."
Since you know the clear key values of the DATA keys, you can create CLRDES keys using KTB.
key_type = 'CLRDES '
rule_count = '00000003'x
rule_array = 'DES INTERNALKEYLN16 '
key_value = '2C2C2C2C2C2C2C2C1616161616161616'x
Call KTB
------------------------------
Eleanor Chan
Original Message:
Sent: Fri June 14, 2024 04:37 PM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
Thanks very much for the example. I figure out that I let the KEY-CLR rule default when I provided a CKDS label for the encryption key. Once I changed it to KEYIDENT, it worked better, but still not perfect. Now I get the error....
| 81F (2079) | An encrypted symmetric key token was passed to the service. Either an encrypted key token is not supported for this service (CSNDPKE) or the required hardware is not present (CSNBSYD and CSNBSYE). |
I probably don't have any additional hardware that does not come on a basic z/OS box by default. I confess that I have no idea how to see if I have any adapters. I'm fairly sure I do not.
Any ideas on how to proceed or am I and a dead end with the SYE calls?
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
------------------------------
Edit: I think I have a coprocessor that is not activated. I'm in touch with tech support asking how to get that done.
Original Message:
Sent: Fri June 14, 2024 01:59 PM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
Here is my sample testcase:
rule_array_count = '00000002'x ;
rule_array = 'DES ECB ' ;
key_identifier_length = '00000010'x ; /* 16-byte key */
key_identifier = '2C2C2C2C2C2C2C2C1616161616161616'x ; /* this is data key A */
key_parms_length = '00000000'x ; /* ignored for ECB */
key_parms = '' ; /* ignored for ECB */
block_size = '00000008'x ;
init_vector_length = '00000000'x ; /* ignored for ECB */
init_vector = '00000000000000000000000000000000'x ;
chain_data_length = '00000010'x ;
chain_data = '00000000000000000000000000000000'x ;
clear_text_length = '00000010'x ;
clear_text = '6229524610E3C81076CE3DE323E6B9CD'x ; /* this is data key B */
cipher_Text_Length = '00000010'x ;
cipher_Text = '00000000000000000000000000000000'x ;
optional_data_Length = '00000000'x ; /* ignored */
optional_data = '' ; /* ignored */
------------------------------
Eleanor Chan
Original Message:
Sent: Fri June 14, 2024 01:20 PM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
CSNBSYE supports ECB encryption. If I understand correctly, data key A is the wrapping key and data key B is the clear text. Using CSNBSYE, key_identifier is data key A and the clear text is clear data key B.
------------------------------
Eleanor Chan
Original Message:
Sent: Fri June 14, 2024 10:30 AM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Eleanor,
My test clear keys are double length.
In my case, I'm using some clear test keys in my testing to validate my code.
I use multiple clear key import and get a data key A.
I use multiple clear key import to get a second data key B.
I then encipher that clear second key b using the first data key A. I'm trying to get a known result where encipher uses ECB. I'm not finding a way to accomplish that.
Whether I encipher with CBC or without that rule array parameter, I get the same results, that do not appear to be ECB results.
(The export discussion will follow a little later, or I can open a new topic after I get this part sorted out).
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Fri June 14, 2024 09:46 AM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
Actually, CSNBKEX will use the same wrapping method as the source_key_identifier. If the source_key_identifier is WRAP-ECB, the target_key_identifier will also use WRAP-ECB.
DEFAULTWRAP is not used in this case. It is used in those services that have no other way of changing the wrapping method. Sorry for the confusion.
------------------------------
Eleanor Chan
Original Message:
Sent: Thu June 13, 2024 04:51 PM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
If the DEFAULTWRAP is set to ORIGINAL, then we can rely upon the exported DES (single or double len) keys in the KEX calls to be ECB wrapped?
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
Original Message:
Sent: Thu June 13, 2024 03:09 PM
From: Eleanor Chan
Subject: Export using EBC rather than CBC
Hello Mark -
The original wrapping method is WRAP-ECB, unless this is changed by the DEFAULTWRAP parameter in the ICSF installation options data set. Also, when using CSNBKEX, the output target_key_identifier will be wrapped in the same manner as the source_key_identifier.
------------------------------
Eleanor Chan
Original Message:
Sent: Thu June 13, 2024 12:35 PM
From: Mark Vollmer
Subject: Export using EBC rather than CBC
Everyone,
I have an interface that requires me to DES encrypt a key using EBC rather than CBC. Apparently the other side (receiver) can't decrypt a key I send using CBC.
It appears to me that when I export a key (CSNBKEX), or when I encrypt a data key, I get a CBC result by default.
I can't find a DES EXPORT function that will take WRAP-ECB. If someone knows otherwise, please give me a heads up.
I would appreciate any help pointing me in the right direction.
Sincerely,
------------------------------
Mark Vollmer
Developer, but does everything.
CV Systems, LLC
------------------------------