It can be set via software but can be disabled by control points. There are RACF controls on the Crypto services that are needed. There are controls that can used to stop one domain setting the key for another. More serious users will have TKE workstations with card readers and multiple key holders. Leonard is correct that it is a single point of attack. But it is a very well-protected point of attack. Also note that the multiple card holders can re-create the master keys.
Lennie Dymoke-Bradshaw https: //rsclweb.com -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Leonard D Woren Sent: 15 January 2024 01:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? 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 > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
