It is being done everytime you buy new machine and use ICSF.
TKE can be used for that, but even without it is feasible and secure.
...and secure. :-)
1. Master key is divided into parts. How many? 2 or more.
2. Each part is know to only one security officer. Note, the officers
need not to know each other. That's information security - no single
person can disclose the key. No one knows the key.
3. Every officer is "duplicated" by another person. That's data security
- lost key part is not a problem, because we have another copy of the part.
So, let's assuming 2 key parts and three copies we have 6 persons and 6
safes to keep the parts.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 15.01.2024 o 02:52, Leonard D Woren pisze:
There has to be a way to set it via software. What happens when you
replace the machine including the hardware where the master key is
stored?
How is the key set into the disaster recovery machine?
/Leonard
Jousma, David wrote on 1/14/2024 4:50 PM:
Pretty hard to mess up the master key, since it only lives in the
crypto hardware.
That's the other thing though. Sounds like the OP wants to encrypt
everything with the same HLQ, with the same key.... that's a big
exposure if the key gets accidentally deleted. Not sure what the
rule of thumb is either, as one key per dataset turns into a key
management nightmare.
Dave Jousma
Vice President | Director, Technology Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand
Rapids, MI 49546
616.653.8429
________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on
behalf of Leonard D Woren <ibm-main...@ldworen.net>
Sent: Sunday, January 14, 2024 7:05:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: Technical Reason? - Why you can't encrypt load libraries
(PDSE format)?
(I read the whole thread before starting this reply. ) Steve Estle
wrote on 1/13/2024 8: 28 AM: > [. . . ] > My true reason for
composing this is that we've discovered the inability to encrypt load
libraries - even in PDSE format. [. . . ] >
(I read the whole thread before starting this reply.)
Steve Estle wrote on 1/13/2024 8:28 AM:
[...]
My true reason for composing this is that we've discovered the
inability to encrypt load libraries - even in PDSE format.
[...]
I know this seems innocuous, but we'd like to encrypt as much as
possible in our environment and due to Top Secret deficiencies we
have to encrypt at high level qualifier level (HLQ) (all or nothing
under each HLQ unfortunately). Given we have load module libraries
under many differ HLQ's this is posing difficulties in moving
forward with our rollout when an HLQ does have one or more load
module libraries as part of that HLQ. You can only imagine the pain
of renaming a load library given all the JCL, etc that is
referencing that library name.
So, you have poor naming conventions and a poor security system, and
you want IBM to make difficult changes which will potentially affect
all customers negatively?
2. If I were to submit an IBM idea, can I count on this community
for some backing here to help in upvoting such an idea submission?
I'd vote the highest value of "no".
An aside, since I didn't keep track of which comment mentioned this
(maybe it was on an old item cross-posted from RACF-L?). For those
concerned about ransomware, z/OS encryption of all data at rest means
that a ransomware hacker need only mess up the master key so that no
data sets can be decrypted. No need to waste time encrypting all
data, since it's already encrypted.
/Leonard
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
