Novell developed NICI, Novell International Crypto Infrastructure, and has used it for much of the past decade. It's a BSAFE wrapper with several PKI-based applications, including a signed-code authenticating library loader, exportable dynamic crypto libraries with continuous authentication across the application-crypto-library interface (so the open crypto interfaces are both closed), a modular architecture similar to CDSA with key policy represented in a signed policy certificate (delivered separately from the crypto engines themselves), architected to support independent 3rd-party signed crypto modules (intended to allow national-preferred crypto algorithms to be created and authorized for use with the commodity-licensed crypto infrastructure).
Using this, we've used it to provide directory-based key management, shared-key distribution, wrapped exported keys that can be reloaded without operator intervention, directory-based, per-user secret stores for passwords and such to allow single-signon, etc, that allows operators to reset user passwords without losing their secrets (if that policy is desired - it also effectively makes secrets recoverable in the event of the loss of the assistance of the employee). The key-escrow features were designed but never implemented, that I know of. And yes, we rolled our own so we could manage the conflicting requirements for a global software company with a large number of crypto-enabled applications: 1) must be able to be FIPS 140-1/2 certified algorithms and implementations, which usually (stay tuned for the OpenSSL FIPS 140 certification success) means they MUST be dynamically linked, 2) exportable applications and crypto under commodity license (no registration or reporting requirements), which usually means they MUST be statically linked to close open crypto interface issues with export from the US 3) single global application part numbers, as we have too many part numbers already to manage through our direct and indirect sales channels - we could never double (or more) the number and manage the inventory, etc. requirements on them all That requires "something special". We solved it, as others have, with dynamic libraries linked via strong authenticating loaders that verify the crypto libraries are unchanged, and that the key-strength and algorithms allowed are authorized by the policy certificate delivered separately from the code (with license disks, if needed). Even though the export key strength issues are no longer an issue, the FIPS 140 and exportability requirements, combined with the single-partnumber requirement means we still need something like this. And we've grown VERY accustomed to being able to have NICI export an obfuscated (or hardware encrypted) key that can be reloaded without operator intervention (under control of the strong loader) for service bootstraps. We're starting to think that if we ever want to move whole sale to a non-BSAFE based crypto implementation, say, an open source one, that we will need to port our key distribution and private key management mechanisms to the new system, as we've not see their like in any generally available open source framework. For what it's worth. Ed >>><[EMAIL PROTECTED]> 10/07/04 3:58 pm >>> What are people using for enterprise key management systems? By enterprise I mean something (centralized) which supports multiple crypto-enabled applications. Specifically, are there any recommended products which support crypto hardware and database encryption? Most people I've talked to seem to roll-their-own. Is that also the consensus of this list? Thanks, -kenan --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
