Hi folks,
I'm a rookie on OpenSSL and security stuff in general, and I think I can now
officially classify myself as knowing just enough to be dangerous.
Here's my situation. We're trying to do one-way authentication between a
Servlet on one machine and a C++ CGI on the other.
I have chosen DSA/SHA-1 as the signature algorithm, and I've been able to:
1. use the "openssl" tool to generate a self-signed X.509 certificate and
DER/PKCS#8 encoded private key
2. use a Java program to read in the private key and sign some data
3. use a C++ program (with OpenSSL) to load the public key from the
certificate and verify the sigature.
At the moment, I'm not encrypting my private key, but when we go to
production, of course, we'd like to have the private key stored in an
encrypted file.
The problem is the passphrase. Since the service is essentially back-end,
we don't have a way for a user to supply the passphrase interactively. So
far, these are what I see as our options.
(a) Having someone interactively provide a passphrase at system startup.
This might be OK for the Java side, since we can have a special HTTPS screen
that an Admin can use to re-load the private key. The down side is that
some one has to go into the web-server to do this.
However, this doesn't solve signing from the CGI back to the Servlet, which
we will eventually have to do. Unless there is a way to set the passphrase
in the CGI environment dynamically in a manner similar to the Java
environment (where an "Admin" type screen can be accessed to allow someone
to provide a passphrase interactively, then set the CGI environment variable
accordingly).
Also, it makes things a slightly more complicated for our Ops people, but
hopefully not much more so.
(b) Provide the passphrase as a cmdline or environment param.
Still means either being interactive, or storing a clear-text passphrase in
a command-line or other shell script. This means an intruder has to
- get the key file
- find where the passphrase is stored
(c) Perform a computation on a clear-text passphrase.
In this scenario, I would use a "secret algorithm" to compute the passphrase
from a clear-text passphrase. The problem with this is, of course, the
ability to reverse-engineer the code, esp. in the case of Java code (for
which there are any number of ridiculously easy reverse-engineering tools
for Java out there).
The additional security from (b) that they need to take the additional steps
of
- finding the code that does the passphrase mangling
- reverse-engineering the code (easy in Java, not-so-easy in C++)
(d) Store the private key unencrypted. Not desirable for obvious reasons, of
course.
So, I guess my questions for the group are:
(a) Is my thinking in the above solutions correct?
(b) Are there any other ways of doing this that are proven to be secure?
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
