> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of R.S. > Sent: Thursday, September 07, 2006 1:22 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: ICSF with CPACF (was RE: Encrypting tape drives... anyone > considering field encryption?) > > Jeffrey D. Smith wrote: > [...] > > >>I dare to disagree. ICSF's CKDS is ready to use key container. The keys > >>are encrypted using master key. > > > > > > Wrong. The CPACF services offered by ICSF require CLEAR KEYS. They are > > not encrypted by the master key. There are new key form keywords for > > clear keys, "CLRDES" for clear DES key and "CLRAES" for clear AES key. > > These are the only key forms usable by the CPACF interface in ICSF, and > > they are not encrypted anywhere, either in storage or on the CKDS. > > How about key IMPORT ? Could I keep the key in encrypted form and import > it from CKDS ? Of course, but you can't use CPACF in that case.
> Second thought: CKDS is (should be) well protected. No user, especially > production support should have read access to it. Keys are read by ICSF > STC user. Even that is better than nothing. Remember: we're talking here > about *clear key functions* - such cryptography means your staff is able > to read the key. It is not "secure too much". That's a given. Any key repository must be protected by a security product, like IBM RACF. ICSF CKDS is no different in that respect. > >>This is the advantage - you don't have > >>to worry about it. You can control and audit key usage using RACF. The > >>person who use key may be unable to read the key from storage (different > >>set of authorities). > > > > The RACF support in ICSF restricts access to the services, but not the > > resource being ciphered. That is a HUGE difference. > > RACF restrict acces to both services and keys as well. ICSF issues security calls for services and keys. That's not my point. ICSF does nothing to protect the ciphered resource. *Both* the ciphered resource and the key that ciphers it must be protected through a single point of access. > > [...] > >>>A key management *system* is much more complex than what ICSF offers. > >> > >>Please enlight us: > >>1. What is key management system? > > > > A key management system controls access to keys, rather than access to > > ciphering services. > As I mentioned ICSF calls RACF for the keys usage as well. But ICSF does not call the security product to determine whether the key may applied to the resource. > > > With CPACF, any problem program can perform ciphering. > > Restricting access to ciphering is missing the entire point of security. > Nonsense! Why to limit access to ciphering functions ??? It is as > pointless as restricting access to functions like ADD, DIVIDE etc. Using > such commands I can implement encryption alghorithms in the software. > Again, I see no reason to restrict the functions. Maybe except > performance penalty. 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. > > > Controlling and auditing access to keys that are bound to specific > resources > > is the point of a secure key management system. > > RACF CL(CSFKEYS) again. Again, that does nothing to protect/ensure that the ciphered resource is being accessed properly. It does not to ensure that key is being applied to the correct resource. > > >>2. Why do we need KMS, especially for clear key operations? > > > > The KMS prevents exposure of the keys to the application. The KMS can > use > > the CPACF with clear keys in *protected* storage so that the end-user > cannot > > exposure the clear keys. Thus, the benefits of performance and > scalability > > of CPACF are complemented with secure key management. You don't get any > of > > that with ICSF. > > Anaything in central storage is considered as susceptible to being read > by a human. Such a person should have specific knowledge and system > authorities. End user is absolutely unable to read the key from storage > or read storage at all. System programmer can make a dump. CPACF does > not offer protected storage - because it is central storage of CPC. And ICSF now supports CLEAR keys in its own storage boundary, or within an application storage boundary, and on the CKDS. With proper security controls in place, no one can *force* exposure of the clear keys. > If you really want secure keys, you need to use crypto cards, CEX2C, or > older PCIXCC, PCICC. This is in fact specialized computer, with PowerPC > onboard and *it's own storage*. The storage is protected against > tampering. Opening enclosure clears all the memory & registers making > card clear and unusable. Yes, we know all of that. This topic is focused on the CPACF and its clear key usage, and how to manage keys. There are plenty of sites that can operate satisfactorily without the hardware protection of the master key. Even then, what happens when the master key register is cleared? The master key or the pass phrase must be kept somewhere in the clear. A software-only solution would have the same requirement. A software implementation that correctly exploits the built-in security and integrity features of z/OS can be just as operationally secure as the physical tamper-resistant crypto box. Violating security procedures and protocols can happen both with the hardware implementation and with the software implementation. In the end, it all comes down to obeying proper security procedures and protocols. > > So, if you are forced to use a 3rd party key management system, you have > > no need for ICSF. > > Wrong assumption - maybe people are not forced to use 3rd party KMS. > Sometimes people use ICSF with TKE workstation. TKE is not a key management *system*. It is a trusted key entry device. That has nothing to do with managing the use of keys. > Radoslaw Skorupka Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ comments are invited on my encryption project ---------------------------------------------------------------------- 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
