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 -- payroll2...@company.com rolled to payroll2...@company.com; payr...@company.com#1255619218 rolled to payr...@company.com#13921939133 (that's a "serial number" in the district); varying the timestamp in the key (payr...@company.com:090720000000Z rolled to payr...@company.com: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 (payr...@company.com) and the product figures out what the key number is, then asks the key server for THAT ver! sion of the payr...@company.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
