Andrew,

Yes, from that same z/OS LPAR (or another in the same Sysplex), access to the 
keys via a RACF resource is also needed.

In order to access those keys one would need to use ICSF and the Crypto Express 
devices that hold the master keys for that domain/LPAR. So if another operating 
system (such as Linux) can work the interfaces to the Crypto Express and access 
the VSAM CKDS then they could gain access to the same services that ICSF uses. 

It would need to be IPLed into the exact same configuration as the z/OS system. 
It would need some work, but I guess it is possible in theory.

Access to the ICSF CKDS would not be enough, as the keys held there are 
encrypted (wrapped) using the master key. The master key is held in the Crypto 
Express domain corresponding to the LPAR in question. There is no interface to 
extract the master key from the Crypto Express device. The Crypto Express 
device is a FIPS 140-2 level 4 device so it will resist all sorts of attempts 
to get at the master keys. It will destroy those keys before you can get them 
out.

So the only thing that can be done is to use the interfaces the Crypto Express 
supplies to perform decryption of the data. 

The simplest way to achieve all this is to have another z/OS system which can 
be IPLed into that LPAR which has a rather more open set of RACF controls.

So I think physical access to the z processor would be required. 

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:              www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of 
Andrew Rowley
Sent: 06 August 2019 12:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?

On 5/08/2019 3:08 pm, Timothy Sipples wrote:
> Lennie Dymoke-Bradshaw wrote:
>> My first reason for PE for data sets is that encryption protects the 
>> data when it is accessed outside of its normal environment (i.e. not 
>> via the data's normal RACF environment).
> Some other examples, in no particular order: anything IPL'ed on the 
> system (or that could be) that isn't z/OS with its security manager 
> fully operating (e.g. ZZSA, standalone dump, Linux raw track access 
> mode, Linux zdsfs, z/VM, the Customized Offerings Driver), some of the 
> stuff Innovation Data Processing can do for backups, or a 
> misconfigured program properties table (NOPASS). RACF is excellent, 
> but you cannot assume it'll always be fully on guard.

Isn't RACF also required to protect the keys? What stops something else IPLed 
on the system from accessing the keys using the same interfaces z/OS uses?


Andrew Rowley

----------------------------------------------------------------------
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

Reply via email to