Enterprise key management systems?

[Ed Reed]

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
 
 
>>><kevinkenan at mac.com> 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
majordomo at metzdowd.com 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com