Phil, Thanks very much for the detailed explanation. Impressive.
My interest is based on my involvement, not too long ago, with a commercial z/OS crypto product where I had been looking at creating a key server to be stored on z/OS (for all the usual and (I feel) proper reasons... RAS, etc.), providing the kind of unique and value-add management features such that you have described with your product; but also wanted to stay inside the lines with our crayon when it came to compatibility with existing key management methodologies (ICSF); and use those for all that is the best of the breed (no need to re-invent the wheel, right?). This, for both symmetric and asymmetric keys, as well. Not a simple project and mine never got off the ground (won't go into it); but I admire someone (an entire team, I'm sure) that was able to take this on and have some level of success. All the best, Scott T. harder Mainframe Services, Inc. Naples, FL > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Phil Smith III > Sent: Tuesday, March 23, 2010 11:50 PM > To: [email protected] > Subject: Re: Encryption software? > > Scott T. Harder wrote: > >I'm not trying to be a jerk here, but does this mean that all someone > needs > >is your product and knowledge of the id used, in order to generate the > >key(s) to decrypt data encrypted with that id??? > > >I am probably missing something here, but it sounds like there is > something > >intrinsically wrong with that premise. > > You aren't being a jerk, you're asking a great question, because I failed > to explain how key access is controlled. Any key server has some sort of > authentication: ours ships with several (password-based, user/password, > LDAP, Active Directory, etc.), and is built so it's trivial to add more -- > based on phase of the moon or stock prices or whatever you can program. So > no, knowing the identity used doesn't help a cracker break into Voltage > SecureData, any more than knowing the key name helps with any other key > management system. > > Knowing the identity and even the key generation algorithm wouldn't help > you create keys on your own, either. Remember, there's root key material > configured in the key server (as is something similar in all key servers, > whether it's explicit or just entropy). This root key material is what > needs to be backed up with Voltage SecureData: when you instantiate a key > server, you create a one-time backup (or hopefully several copies of it!) > and put THAT in your safe. Then you can ALWAYS recreate a key server and > your keys, by firing up a hot/warm/cold spare and restoring that > configuration. Hey presto, it can serve the keys you need. > > With most key servers you have to back up keys constantly -- which means > those key backups are now a target. They also generate the key names with > the keys, so the data flow is all from the key server to the application. > And now there are TWO critical, dynamic pieces of data to back up: the key > AND the key name. If you lose either, your data is gone. Most key servers > pre-generate groups of keys, so they can do a backup before the keys are > needed -- but the key name must still be matched to the data (and they > better generate ENOUGH keys for a day's requirements, eh?). If the data > store is DB2 or equivalent, that's not too bad: you add a column > containing the key name used to encrypt a given row, and in a DR scenario, > you restore your encrypted database and your key database and life goes > on. It's a bit harder with most other datastores, as you have to store the > key name somewhere. (Oh, and you DID take as much care backing up the key > database as you do the data, right? And yo! > u protected the key database somehow, presumably NOT storing it with the > data backups? So you have two sets of daily data that must be kept > separate: key and data backups. Hmm.) > > With Voltage SecureData, your daily backups are just as they were before > encryption: data. Your key server-related backups (the configuration) are > infrequent, and are thus easy to manage. These configurations (we call > them "districts") are small and easy to back up, and the key server can > support an essentially unlimited number of them (presumably limited only > by disk space). > > To (perhaps) anticipate your follow-on question, the next nightmare of > encryption is rolling keys. Rolling keys means changing keys periodically > as required by many regulations (PCI et al). You can roll keys within a > district, so most customers do not tend to have many separate districts, > just generations of keys within a district. > > With Voltage SecureData, an identity can be "fully qualified", specifying > more than just an email address, but it's all human-readable and thus easy > to specify in an application. There are thus several ways to roll keys, > depending on how your applications want to work. You can roll the identity > -- [email protected] rolled to [email protected]; > [email protected]#1255619218 rolled to [email protected]#13921939133 > (that's a "serial number" in the district); varying the timestamp in the > key ([email protected]:090720000000Z rolled to > [email protected]:100720000001Z; or even changing the root key material. > And of course combinations of these also work. Various of our customers > have chosen different schemes based on their needs. > > We also offer what we called Embedded Format-Preserving Encryption, or > EFPE. This violates the basic tenet of FPE by producing output that isn't > quite the same format, but is the same length, by using a larger output > alphabet than input. So a 9-digit SSN might encrypt as 13A4498B2 instead > of all numeric. Now, in some cases, that's impossible due to storage > schemes (SSN as 5-byte packed decimal, for example), but a surprising > number of customers have embraced it because it makes key rollover > trivial: the extra addressability offered by the extended alphabet allows > storing a "key number" in the data. So if today your social encrypts to > 13A4498B2, tomorrow it might encrypt to something different, if the key > has been rolled in the meantime. On decryption, there is no requirement > for your application to worry about the key version: it just specifies the > minimal identity ([email protected]) and the product figures out what > the key number is, then asks the key server for THAT ver! > sion of the [email protected] key. So it Just Works. > > Now, you're saying, "But that means when we do a lookup for my social [by > encrypting it first], we won't find it if it was encrypted using > yesterday's key". This is true -- and is an issue with any key rollover > mechanism. The usual approaches are to encrypt the plaintext using all > known versions of the key and search for those, and/or to roll the data as > well -- re-encrypting it all with the new key after rollover (painful, but > sometimes necessary). > > OK, I've blathered on enough. Hope this helps! > > ...phsiii > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
