On Thursday, 09/07/2006 at 08:12 CST, "Jeffrey D. Smith" <[EMAIL PROTECTED]> wrote: > I think there is a language barrier here. My point is that there is > no point in preventing/restricting acccess to the ICSF ciphering > functions. The vast majority of encryption needs involve ciphering > data. With CPACF, there is no need to use ICSF. Thus, applying security > controls to ICSF ciphering is useless. A program can directly use CPACF > instead of ICSF.
I disagree on two points: 1. ICSF is surrounded by "Process and Privilege" (P&P) to get keys into, out of, share, etc.. If an application manages its own encryption key, then you have to create another instance of P&P. Yet another thing to be evaluated and audited in its own right. 2. If the application is using CPACF directly, then the clear key is in application memory and is vulnerable to a hacked application and is visible in address space dumps. > And ICSF now supports CLEAR keys in its own storage boundary, or within > an application storage boundary, and on the CKDS. Only a supervisor state application can extract the clear keys from ICSF for its own use with CPACF. Normal applications cannot get to the keys, encrypted or not. > With proper security controls in place, no one can *force* exposure of > the clear keys. If you have clear keys on your system, be sure to encrypt the backups of the CKDS/PKDS/or any other file that contains them! :-) Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
