Re: is this a sound key management approach?

I for one cannot discern the key-management approach described
on that page.

aplogies. i should have been clearer.

it looks like the google project i pointed to is using some kind of
passphrase-based encryption (pbe) to store and protect a symmetric key on
the filesytem.

to clarify my questions: i'm not asking whether or not - in and of itself -
password based encryption to protect a symmetric key on the filesystem is
secure. since that approach is used by more than one market-leading
middleware product (bea weblogic server, oracle db, to name only 2), i'm
already convinced that - in general - a pbe/filesystem approach is a viable
key management solution.

the key management used in the google project i referred to is _analogous_
to (i repeat: "_analogous_ to" NOT "_exactly_ like") the key management used
by systems like this one:

http://oraclegeek.net/joomla/content/view/22/38/

if the oracle specific elements in the 4th paragraph on that page are
replaced with generic analogies (replace "oracle wallet" with "keystore",
for example), then that same description would apply to the google project's
key management approach:

"...[a] master key is stored in a [keystore], which is protected by a
password. So to gain the access to the [protected data] one would need
access to the [keystore] and one would also need to know the password to
access the [keystore]..."

the difference is in how the password is passed in to gain access to the
keystore|wallet. and that is reason i posted my original questions.
typically in a pbe approach, the password is passed in interactively. for
example, application code would have to explicitly pass in the
keystore's|wallet's password programmatically whenever encryption/decryption
needed to be done. but for a web application that needed some
encryption|decryption service, if the application server that the web app is
deployed on crashed, say, and needed to be rebooted, then it couldn't be
automatically rebooted if it was necessary to pass in the pbe password
interactively.

this bullet point on the google project page suggests that is one problem
their approach is trying to solve :

"The keystore password is specified in a file (as opposed to
interactively). This has two advantages:

* It does not preclude automated startup of the application (say after a
reboot)."

that bullet point is exactly what my questions are about. namely: whether or
not having the keystore password specified in a file is a sound approach?
please, allow me to repeat my questions so there is no further confusion.

my questions are:

1) how sound is the approach of storing the keystore password in a file?

2) what implicit assumptions does the approach make?

3) how could it be improved?

thanks again for your replies.

----- Original Message -----
From: "Peter Pearson" <ppearson@xxxxxxxxxxxxxxx>
Newsgroups: sci.crypt
Sent: Monday, August 11, 2008 4:28 PM
Subject: Re: is this a sound key management approach?


On Sun, 10 Aug 2008 20:34:17 +0100, beboposaurus <bebop@xxxxxxx> wrote:

what do folks here make of the key management approach taken by this
google
project?


http://code.google.com/p/google-enterprise-connector-manager/wiki/PasswordEncryption

I for one cannot discern the key-management approach described
on that page. There appears to be something called a "connector"
that crawls a "CMS" and uses JCE with sane defaults. Swell.

If the security was designed by someone who thinks this is a
description of a security design, then No, it's not secure.

--
To email me, substitute nowhere->spamcop, invalid->net.


.

Quantcast