-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hmmm... Interesting question. We've put a bit of thought into this
one here at Inprise, and Bryan Olson and I thought about it a great
deal when we were both at Uptronics.
At Uptronics, we felt that the best thing to do was simply to use a
crypto coprocessor such as the the IBM 4758, or nCipher nFast/KM,
(and for the sake of completeness I should mention that Certicom,
Eracom, Atalla, and Chrysalis make crypto coprocessors as well,
thought I have no direct experience with them.) Assuming that you
have a Cryptoki interface for the coprocessor, you should be able to
convince Netscape or Apache web servers to interact with it.
Using this solution, the key pair is generated on the coprocessor,
and the private key never leaves it's protected environment. The
application program on the host (the web server in this case) is
given an opaque key object that represents the private key on the
coprocessor. When it comes time to actually use the private key, the
function calls that are supposed to perform the operation pass the
parameters (message hash or symmetric key, opaque key object) to the
coprocessor which uses the key object to perform a lookup on a table
of private keys that it knows about and then generates the signature
or message envelope. The private key never leaves the coprocessor,
and theoretically never will, so you can avoid the problem of having
the private key's encryption password lying around on the server.
There are a couple of drawbacks, including: 1) you have to buy a
coprocessor. These things typically 'aint cheap. If you're dealing
with a large corporation, however, you can probably get them to
spring for the $1500 - $3000 that they typically cost. 2) Configuring
your web server to use the coprocessor rather than a private key in
memory might be difficult. I don't really know how difficult this is
since I've never tried it (Nico? Are you on this list?) 3) the
management and development tools for some of these coprocessors are
still a little immature. I should point out that my personal
experience with this last point deals exclusively with the 4758, not
with the nFast, which I havn't worked all that much with.
Theoretically however, applications build with later versions of
BSAFE-C and BSAFE-J should allow you to 'seamlessly' use the
coprocessor. But, if you're in an enterprise environment and can
afford it, I think it's definitly the way to go.
A much more interesting problem is key management on the coprocessor.
You'll probably not want to trust that your private key to a device
that can potentially fail, and is designed to not allow attackers to
read the private key should they have physical posession of the
coprocessor. In using a coprocessor, you'll have to do a lot more
work up-front coming up with a plan and policies for backing up the
private key (remember, there are no locksmiths in the digital world.)
If you use a coprocessor, you'll probably want to pick 3-5 'trusted'
individuals to posess key shares, and come up with a business policy
that disallows all of them from being in the same room with the
coprocessor without an officer of the company present as well (or
something like that...)
Also in the realm of more interesting problems is how to share a
private key across multiple coprocessors. In my opinion, no one has
really done this right, though I havn't really been looking at the
state of the art for the last six months. What would be great is if
the coprocessor vendors would have a system by which coprocessors
could be clustered in a 'domain', where a domain is defined as the
set of coprocessors who share the same administrative secret key. For
backup purposes, this key could be split or shared using a m-of-n
scheme, with shares going to certain 'trusted' individuals. Ideally,
this share would be protected on a smart card, encrypted using the
share's owner's password. The coprocessors could then use a
Nyberg-Reuppel (sp?) or Kerberos or EKE or whatever to exchange
private keys.
This has the benefit that if you have an array of web servers that
all serve html on what appears to be the same IP address or the same
machine name, they could share a private key. When one of your
coprocessors fails (and despite what thier manufacturers tell you,
they will eventually fail or need to be upgraded,) you get m out of
the n trusted key share holders together to personalize it. It's then
put into production, starts up, realizes that it doesn't have a
required private key and attempts to contact another coprocessor in
the same domain. Assuming everything goes well, an encrypted key
exchange occurs, the private key is then encrypted with the key from
the EKE, and you're ready to fly. All the operator had to do was
press the power button.
So, let me pose a follow-up question, is anybody working on such a
system? IBM has something similiar to this in thier 4758, but to get
it to work you'de have to do a fair amount of coding yourself. Also,
the web server manufacturers would have to provide some way to
interface with the coprocessor. I'm guessing that Netscape has a leg
up in this regard with thier existing Cryptoki support (or do they?)
I've been pretty lazy about figuring out what the latest updates to
Apache are, so I don't know if such a system exists already. I
wouldn't trust IIS to handle this sort of thing, and while I love
Macs, I don't know that the market share is there to support the work
on that platform.
Secondly, if it's not being done, anyone want to spend some cycles to
try to get it done? At least for the Apache web server? Any
Coprocessor manufacturers out there willing to donate an old system
for this work?
- ----- Original Message -----
From: "Jeffrey M. Smith" <[EMAIL PROTECTED]>
To: "Crypto Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, January 04, 2000 1:40 PM
Subject: starting up servers that need access to secrets
> Is there a good solution to the problem of starting up a network
> server that needs access to an encrypted database? For instance, a
> server that has its own RSA key pair encrypted on disk, and needs
> to decrypt it during operation so the private key is available in
> memory?
>
> The only examples I've seen so far (e.g., Netscape servers set up
> to use SSL) require you to type in a pass phrase during server
> start-up. (They also give you the option of having the server store
> the pass phrase on disk, although they warn you that this is
> completely insecure.)
>
> These seem like the only options to me. If the database the server
> needs access to is encrypted, then either a person must type in the
> pass phrase when the server starts, or the pass phrase must be
> stored on disk for the server to read. The first is inconvenient,
> and the second insecure.
>
> I follow the crypto mailing list, but I'm not anywhere close to
> being a cryptography expert. I'd appreciate any insights the list
> may have to offer. Thanks in advance. -- Jeff Smith Purdue
> University phone: 765-496-8285 West Lafayette IN 47907-1408 fax:
> 765-494-0566
>
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
iQA/AwUBOHKX9qpYCXEJSE/yEQJX9ACg6ulvXskTzPtvZioDcJ0s6XSFsBcAoJBh
HBC50oGf6eHA/8d9Ole+8Yy/
=Ahei
-----END PGP SIGNATURE-----
