Thank you .
Yes there are master keys inside the HSM that is in the TKE workstation. They are randomly generated inside the HSM when the HSM is initialized. The initialization is done in administrative mode using the "TKE Crypto Adapter Initialization" applications on the TKE. This application can also be run from the "TKE Workstation Setup" application of the TKE. During the initialization, either for use with passpharse or smart card profiles, you will see these messages:
DES/PKA master keys set.AES master key set.APKA master key set.DES Key Storage initialized using desstore.datPKA Key Storage initialized using pkastore.datAES Key Storage initialized using aesstore.dat
During the initialization, random keys are generated, and the TKE's key stores are initialized. The stores are used for TKE functions. There is no data that needs to be preserved if new keys are generated. It is possible for a client to manage the TKE's master keys, but it is not necessary and clients are not encouraged to do it.
At the end of the day what are the purpose of those specific master keys inside the HSM that is in the TKE workstation at the initialization ? For what functions are they used (what kind of keys they wrap if they do) ?
Just only at the initialization a kind of "starting point" -no data user- from scratch to be able to load further the "real" users Master Keys that will always be loaded in the crypto cards (CryptoExpressxS) and stored in MK dedicated smart cards ?
Key parts are stored on smart cards. Session and transport keys are generated to protect key parts in flight. For CCA key loads, the key part goes from the Smart card to the HSM in the TKE. This happens AFTER an ECDH handshake to derive a session key. The part is unwrapped in the TKE's HSM and then rewrapped with the transport key for the target IBM Z or LinuxONE HSM (An ECDH handshake is involved).
The command is built with the blob ready for the Target HSM. The command is sent to the smart card to be signed. The command is shipped to the target HSM. The Target HSM validated the signature (user authentication) and verifies the role of the person who signed it is authorized to run the command being processed (User authorization.) Now the key part is unwrapped and added to the appropriate master key register.
As you can see, we don't need or use the TKE's master key or any key store in this process.
What are the stores used for... not much. If you generate RSA keys on the TKE to import to a key store on an IBM z or LinuxONE, the store is used in that process. But the content is only there a short time. If lost, you have to recreated the wrapping key used to protect the RSA key in flight.
Thanks for your reply.
Only for understanding the last and second side of your post (regarding TKE's master keys and stores) .
"If you generate RSA keys on the TKE to import to a key store on an IBM z or LinuxONE, the store is used in that process. " means if the TKE workstation menus are used to generate in clear RSA Master key which is briefly stored in the TKE stores to then finally loaded in IBM z (or LinuxONE) crypto cards : is it the right meaning ?
"If lost..." means if the inserted in the TKE in clear Master key (is lost) : is it the right meaning ?
For sure using MKs smart cards to store key parts is the more appropriate/secure way !
Hello Garry,Thanks for your reply.
I wanted to come back just 1 min to your last reply if you may .
Only for understanding perspective the last and second side of your post (regarding TKE's master keys and stores) .
------------------------------Nordine MosbahOriginal Message:Sent: Tue March 07, 2023 02:54 PMFrom: Garry SullivanSubject: Master key parts stored inside the TKE crypto adapter workstation
So there is no confusion, if you use the TKE to generate an RSA key, that has noting to do with any master key management. Very few clients us the TKE to create RSA keys. If (in the extremely rare case) you do use the TKE to create an RSA key, the TKE's key store is used to hold the wrapping key used to protect the RSA key in flight. The wrapping key is an "operational key" not a "master key". The wrapping key is made from parts that are stored on a smart card. You have to create the wrapping key before you can create the RSA key. The wrapping key is encrypted with the TKE's HSM master key and then placed in the key store on the TKE. If the TKE key store is lost, you must rebuild the RSA wrapping key if you still need it. Next you generate an RSA key. It is protecting it with the wrapping key you created. The same wrapping key must be installed in the key store on the target HSM. The RSA key is unwrapped in the target HSM, then re-wrapped with the Target HSM's master key before it is stored in the key store on the IBM z or LinuxONE. The wrapping key and the RSA key are never outside the HSM in the clear.
Thank you for your patience. There are two kinds of hardware on a TKE (the crypto adapter and the smartcards), as you noticed.
As Garry pointed out, the master keys on the crypto card are usually randomly generated and have no relation to the MKs that the TKE is used to load/set on z/OS and Linux adapters. From my understanding, all of the master key parts are stored within the smartcards and never in the clear.
By saying " the MKs that the TKE is used to load/set on z/OS and Linux adapters" do you mean that those are master keys inside the HSM that is in the TKE workstation
generated at the initialization of the TKE crypto adapter ? And those TKE crypto adapter's master keys are only used by workstation itself to load/set the users "real" Master keys (stored in dedicated MKs smart cards) inside the crypto cards plugged in z server ?