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 ?
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".
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.
[...]
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.
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.
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.
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.
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.
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. It
--
Radoslaw Skorupka
Lodz, Poland
----------------------------------------------------------------------
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
