You've gotten some good feedback on RACF-L, however I'll comment here, because I think this is more appropriate for IBM-MAIN.
(I do disagree with Russ's suggestion to write down the key material though. There is no point in paying big bucks for the secure key technology and then storing the key material on a piece of paper, outside of the technology. One of the strengths of the IBM crypto infrastructure is that your operational keys can be safely managed within the infrastructure and it do not need to exist outside.) As you described, when you create the key material, that is done inside of the tamper-respoinding boundary of the card. And when you need to store the key material in a repository, it will be encrypted under the master key. The ICSF key repositories are simply vanilla VSAM data sets, and there is nothing special about them. So they can be handled with your normal utilities (DFSMSdss or FDR or whatever) for backup and recovery purposes. As Lennie described on RACF-L those keystores should be protected just like your RACF database. You can simply dump them along with the RACF database and the rest of the operating system and carry those to your DR environment. The master keys are what 'unlock' those keystores, so you will need a way to physically restore the master keys. That is, when the operational keys are stored in the keystore, they are first encrypted under the appropriate master keys. So your master key material will need to be 'written down' so they can be transported. The TKE provides the most secure way to do that (via smart cards), however you can also do it securely when using the ICSF ISPF panels. The beauty of the system is that you can have potentially thousands or even tens of thousands of operational keys stored in the repository and it only takes the master keys to unlock those. On the current hardware, there are a maximum of five master keys that need to have special handling to unlock all the other keys. There is an IBM ATS TechDoc, WP101629 which are the key management operational procedures as provided by two crypto customers. You might want to review that document on how to capture the master key material so you can recover at a DR site. The title is 'Sample Procedure(s) for Crypto Management' and it's available at http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101629. I should also caution you that using IDCAMS REPRO to move a single key is not a good solution. While you can probably move a key from one keystore to an identical keystore, you cannot simply move a key from one keystore to another. There are a number of checks that ICSF performs internally on key material that will fail when trying to do this. That is, there are some hashes that are stored with the key that will no longer be valid if you move it to other than an identical keystore. In general, your DR process will manage the keystores in their entirety. However, you also have the potential issue of an error within the key management process. That is, a key officer could accidentally (or maliciously) delete or change a key in the key repository. That is one reason why key management is such a hot topic right now (along with the fact that the number of keys that need to be managed is growing by leaps and bounds). This means that you need to have a crisp set of procedures for managing the key definition process. There are a number of key management solutions available (including several from IBM: EKMF, SKLM, TKE). A tool like EKMF will provide a way to recover a single key in the keystore. My general comment would be that your recovery procedures will depend on your key management process, and no matter what tools you use, you'll need to test your DR plan. Otherwise you don't have a plan, you have a prayer (that it will work). Greg Boyd IBM Advanced Technical Support Supporting Crypto on System z (and soon to be Greg Boyd at MainframeCrypto, www.mainframecrypto.com) On Fri, 14 Mar 2014 14:43:02 -0500, Ann Mackey <[email protected]> wrote: >I'm reviewing some of our set-up for the ICSF encryption processing. We do >not have a TKE or the "use at your own risk" ISPF panels that IBM supplies. >We currently create data keys via KGUP and let the ICSF generate the key, so >no human has knowledge of the key parts. > >Should something catastrophic occur, what's the best way to recover - must we >move to entering key parts? > >I tested recovering a single key from the CKDS dataset using IDCAMS REPRO - >and it seems to have worked. > >Any known concerns or suggestions? >Thanks! > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
