Using the sample utility in the TechDoc would be one solution and I know of customers that are using it, however that implies a couple of things: 1) You have to install and maintain the sample code from the TechDoc (i.e. it is provided 'as is', and for some customers that may not be acceptable) 2) Your key material will exist, at least briefly, in memory when using those ISPF panels, so someone who can view memory could capture your key material 3) And probably most importantly, you need to make sure that the hardcopy of those key parts that are loaded via the panels are stored securely somewhere. An attacker will hit the weakest link, which is probably the file cabinet or drawer where those key parts are stored. You are paying lots of money for the secure key technology, probably not so much for the file cabinet.
Another solution might be to simply export your secure keys. That is, you could use a key-export-key (KEK) to encrypt a copy of your operational key and store that encrypted copy in a file somewhere. Or you could use a public pair to encrypt a copy of your operational key and again, store that encrypted copy in a file. If you accidentally delete the operational key from the keystore you would decrypt the backup copy from the file using the KEK or the private key. With this solution, you could still 'shoot yourself in the foot', but you'd have to delete both the original key plus the KEK or the public/private key before you'd be in a bind. Bottom line, is that while the System z crypto technology provides an incredible amount of protection for your key material, your operational procedures are just as important in protecting the crypto infrastructure. If you don't have key integrity (knowing that you have the right keys when you need them) your crypto infrastructure will break down. I'll also agree that if you only have a small number of keys, and they don't change very often, then you don't need a comprehensive key management solution like EKMF or the TKE, however I would suggest that you need some robust local procedures to manage those operational keys. Greg Boyd IBM Advanced Technical Support Supporting Crypto on System z (and soon to be Greg Boyd at MainframeCrypto, www.mainframecrypto.com) On Tue, 18 Mar 2014 10:04:12 -0500, Ann Mackey <thearch...@live.com> wrote: >Greg – > >Thanks for your reply, it’s a great overview. > >My concern is not with master keys, only with the data keys (we have tested & >documented master key recovery procedures). The last half of your answer is a >big help. We currently encrypt/decrypt data using one ‘data’ key for all prod >data, one key for test, and so on – so we don’t have a high level of change >to our key stores. Based on what you pointed out, we could use repro in our >current environment, since we use only the CKDS, and the same CKDS on each >LPAR (and I do understand that repro is not an ideal recovery choice, and >certainly not 100%). > >My concern would be the deletion of a data key in error and how to recover >that key when the key parts are unknown since we use KGUP to automatically >generate the key. For example: > >-KGUP is used to create data key “X”. Data key “X” exists in ICSF memory & the >CKDS vsam dataset. >-Admin mistakenly deletes “X”. We still have data encrypted with “X” - we >need to recover “X”. >-Without knowing the key parts, we can easily restore the CKDS in its entirety >from a backup when “X” existed, but what if additional key changes were made >to the CKDS after “X” was deleted, but before the CKDS was restored? Without >knowing the parts, at the current time, our only option would be to use REPRO >on the missing record(s). > >So I think I have my answer – Since we shouldn’t rely on IDCAMS REPRO, and to >ensure PCI compliancy, we need to create our data keys with ‘known’ key parts >and at least install the ISPF panels & Rexx that allow dual key entry (not the >ICSF ISPF panels used for master keys). >(http://www-01.ibm.com/support/docview.wss?uid=tss1prs189) > >Thanks to everyone for your input. > >---------------------------------------------------------------------- >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
