Frank, I would strongly recommend a checklist style with places for initials for each of the MK holders.
Naming conventions - Your naming convention takes care of the test v.s. prod.. which is good. But how do you handle migrating from one key to another. Example. KEY1 is in use, KEY2 is the one that you have to switch to... Depending on what you are using the key for ... you may need both or need to replace the contents of KEY1 with KEY2 (think session keys... not data base encryption) The whole key management thing can make things difficult. Personally, I agree with separating test and production. However, you may find that there are some keys (think PKDS) that have to be the same in test and production. As previously discussed the ability to move keys from one PKDS to another using the KEYXFER tool is dependent on the MK being the same. Not to say that I think having the same MK for test and production is a good idea.... I would not recommend it.... it is just a reminder that you may need to consider other options if the key needs to be the same in both places. The security for keys will be made much easier if you keep them separated "name-wise". You will regret choosing the same name for test and production (only seems like a good idea... but your security folks will stage a revolt ... tar and feathering may be involved.) I am making an assumption that the security rules / security data base being the same between test and production. I am personally a fan of doing things "one way". Centralizing databases and rules means that even if you make a mistake.. and production ends up in test for example ... then the same rules are always in effect. Additionally, I would suggest implementing some of the newer controls for CSFKEYS which allow for a bit more granularity that the old method of "READ" or "NONE". Also, I would consider using the Protected key if performance is a consideration. This topic has been discussed at some length on this list. Are you running more than one production LPAR that is going to share keys? I have personally been thru a conversion from using Thales security modules to using the Crypto Express cards. It is awesome. Rob Schramm Senior Systems Consultant Imperium Group On Thu, Sep 13, 2012 at 8:39 PM, Frank Swarbrick <frank.swarbr...@yahoo.com> wrote: > All of our TN3270 traffic is SSL encrypted. > > I will definitely be documenting everything! > > We have a naming convention as suggested by our vendor, but if you have any > particular good practices I'd love to hear them. > > Your point about DR is also well taken. We'll have to discuss that. > > Another question, since I've got your attention. Our vendor mentions that at > all of their other customers the CKDS/PKDS are shared between production and > non-production. It wasn't clear to me if this was because they run prod and > non-prod in the same LPAR or for some other reason (such as perhaps they > didn't know any better). Because of this they had keys with names like > KEKKIM.TEST.ABCD and KEKKIM.PROD.ABCD. We, on the other hand, will have > production in one crypto region with it's own CKDS/PKDS, totally separate > from non-production. This seems the obvious, best way to go, but I'm curious > what others have to say. Because of this we could have both a production and > a non-production key with the same label name, but they would not refer to > the same actual key value. (One could not access the production keys from a > non-prod LPAR.) > > Thanks! > Frank > > > >>________________________________ >> From: Rob Schramm <rob.schr...@gmail.com> >>To: IBM-MAIN@LISTSERV.UA.EDU >>Sent: Thursday, September 13, 2012 5:54 PM >>Subject: Re: loading cryptographic coprocessor key part registers >> >>I am hoping that you have already considered the need for encrypting the >>TSO session. >> >>Additionally, having the procedure actually documented before entering >>your production MK is a really good idea. Also, secured key part storage >>onsite as well as offsite for disaster recovery. >> >>Also, naming convention for the operational keys is critical!!! >> >>Rob Schramm >>On Sep 13, 2012 5:50 PM, "Frank Swarbrick" <frank.swarbr...@yahoo.com> >>wrote: >> >>> Looks like we found a solution: >>> http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS189. >>> Frank >>> >>> >>> >>> >>> >________________________________ >>> > From: Frank Swarbrick <frank.swarbr...@yahoo.com> >>> >To: IBM-MAIN@LISTSERV.UA.EDU >>> >Sent: Thursday, September 13, 2012 12:43 PM >>> >Subject: loading cryptographic coprocessor key part registers >>> > >>> >We are migrating our PIN/card security process to use ICSF and a Crypto3 >>> card. All of our vendor's other customers have used the TKE Workstation to >>> load their operational keys (in multiple key part/component format). We >>> were not planning on purchasing the TKE feature. But I cannot see any way >>> outside of TKE to enter operational key components in to the "cryptographic >>> >coprocessor's keypartregisters" outside of using TKE. Help! >>> > >>> >Frank >>> > >>> >---------------------------------------------------------------------- >>> >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 >>> >> >>---------------------------------------------------------------------- >>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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
