Feel free to hack this up as you see fit. Copyright assigned to the
OpenSSL Project 2006, Kyle Hamilton.
<DRAFT!>
HOWTO: Key Management (best practice information)
(written by Kyle A Hamilton, [EMAIL PROTECTED])
1. Introduction
Keys are the heart and soul of how cryptography work -- the algorithms
are publicly-known, so the security of any cryptography lies in the
secrecy of the keys and just how well they're protected.
UNIX file modes provide some level of security; Windows NT and Trusted
UNIX ACLs provide a much higher level of security, but note that in
every case there is a group of users -- the 'superusers' or
'administrators' -- who can bypass any protection scheme that you put
on your keys. In some circumstances ("I just want people to have a
reasonable expectation that they're communicating with my webserver
and not with someone else's") this might be sufficient, depending on
what you mean by 'reasonable expectation'. In other cases, this is
not sufficient (PGP/GPG keys residing on a remote system, for example,
that are being used to sign software tarballs).
2. Background (or, "Why Key Management Is Important")
Every time you generate a 'key', you're creating one of two things: a
public/private (i.e., asymmetric) key pair, or a secret (i.e.,
symmetric) key. These have different properties, and different things
that they are useful for.
For OpenSSL, the one we're most usually concerned with with the
public/private (asymmetric) key pair, though (because of some of the
properties of asymmetric keypairs) we do also have to worry about the
other kind as well.
Public keys are sent off to registration authorities, certifying
authorities, clients of our webservices/email servers/IMAP
servers/POP3 servers, and so on. The way this model works, everyone
knows our public key. Anyone who has our private key can 'prove'
(cryptographically) that they are us. [In a world where cryptographic
signatures are increasingly being viewed as legal signatures, it makes
a lot of sense to ensure that our signatures can't be
cryptographically forged.]
What we get back from the CAs that we send our public keys to are
statements of who we are, what our public key is, and a signature from
the CA that it has verified that this information is correct (i.e., a
'certificate'). Unfortunately, CAs make mistakes, and sometimes CAs
don't do what they say they're going to do. (If you remember the
brouhaha from 1999 or so, someone managed to convince Verisign that he
represented Microsoft, and obtained two certificates from Verisign
stating that they belonged to Microsoft Corporation. This caused
Microsoft to issue an emergency patch including a "Certificate
Revocation List" from Verisign to explicitly tell MS's software that
those two certificates were invalid.) (Thawte Consulting Pty, Ltd has
recently begun issuing certificates in direct violation of their
'certification practice statement' -- i.e., their publicly-vowed
statement of the ONLY situations they will create a certificate in.)
This means that CAs, too, need to keep their private keys private, and
appropriately limit their usage.
3. Essential Key Management Issues
There are several levels of 'key management' you can take, not all of
which can be directly compared. These are, "key and certificate in
the same file", "encrypted key and unencrypted certificate in the same
file", "unencrypted key in one file, certificate in another file",
"encrypted key in one file, certificate in another file", "encrypted
key not directly accessible by the system, certificate in file."
In addition, the longer a private key stays in memory, the more
insecure it becomes. (Webservers that read the private key on
startup, for example, and then leave it in memory to access again and
again -- it's a performance gain, but a security loss.) However,
there is no way to avoid the need for a long-running process to be
hardened against security issues, especially one that listens to
network requests -- this is something to be kept in mind when building
an application, or adding cryptographic functionality to an
application that already exists.
So, here are some general guidelines for each of the preceding scenarios:
a. unencrypted key and certificate in a single file
This is possibly the most insecure scenario you can get. At a
minimum, the only person who should be allowed to update the file is
the person who owns the keypair and certificate, and the only entity
that should be allowed read-only access to the file is the software
that needs the information to properly function. This is difficult to
do on UNIX and variant systems, and only slightly easier on
ACL-implementing systems.
On UNIX-and-variant systems, any process that must listen to a port
numbered below 1024 has to run as root (or be delegated that privilege
from root, in the case of Linux). However, because root has unlimited
power on UNIX-and-variant systems, it is a very bad idea to keep root
privileges after it does what it needs to as root (which, in most
cases, is viewed as the bind() call to the port below 1024). So, it
binds to the port, changes its user ID to (usually) www:www or
nobody:nogroup, and then starts to read in all the files it needs to.
Since most users aren't part of the 'www' or 'nogroup' groups, this
means that they cannot limit the reading of their certificate and key
to just the webserver, but instead must keep them in a file readable
by every user on the system. (On personal systems, this doesn't
matter so much, but for shared systems this would be unacceptable, in
this author's point of view.)
b. encrypted key and unencrypted certificate in the same file
This is a bit better than the previous scenario, even though it
requires a bit more hassle when the system or webserver restarts.
Basically, the private key is kept on disk in an encrypted form. This
means, though, that the server needs to know the key with which to
decrypt it before it can use it. This can be obfuscated through some
means, but there has to be a point where the server obtains the key,
and that point can be focused on in an analysis.
In addition, if you change the key under which the private key is
encrypted, you must securely wipe all previous copies of the file that
contained the key. Otherwise, an attacker can keep the old copy and
continue to attempt to break its password -- and once he figures out
the encryption key, he's got the private key that it protected, and
doesn't need to break the encryption key on the new file.
c. unencrypted private key and certificate in different files
This allows for a separation of where the files are that contain the
different parts that are needed for a server to function. This may
make it more difficult for an attacker to find the file that contains
the private key, but not necessarily. Otherwise, all the caveats of
(a) apply.
d. encrypted private key and unencrypted certificate in different files
Again, as (c), it may make it more difficult to locate the file where
the private key is located on disk. Otherwise, all caveats of (b)
apply.
e. private key not directly accessible to system, certificate in file
This is the realm of smart cards and other encryption devices.
Usually, these must be unlocked with a PIN or some such, then accessed
by the server whenever it needs to perform a private-key operation.
The security of this relies on an attacker being unable to access the
device after it has been unlocked and request a private-key operation
on arbitrary data -- such as for the creation of a "proxy certificate"
(see RFC 3820 for more information), or for hijacking or sniffing an
encrypted connection.
4. Essential Key Management Best Practices
The best practice for private key management involves minimizing the
number of people who have access to the private key, the files that
contain the private key, or the system that the private key is on.
The fewer people who have access to it, the better. The more you
trust the people who have access to it, the better. (Though 'trust'
is an entirely separate concept, and one that is far beyond the scope
of this document.) Limiting its access to only you is the best
possible practice, but is very difficult to implement. (Among other
things, do you trust the person who makes your backups?)
On Windows NT/2000/2003 and such, an administrator needs to directly
read the private key from a file that contains it, providing the
secret key that encrypts it if there is one, into the machine so that
IIS can read it. On UNIX, an administrator needs to point to a file
that contains the key for the webserver to read it, and needs to set
up some means for the webserver to obtain the secret key if there is
one to decrypt the private key. Either way, the administrator needs
to have the secret key, and needs to be able to have access to the
private key file.
5. Conclusions
There is no 'perfect security' for cryptographic keys, at least not at
this point in time (and perhaps never). This coincides with the fact
that there is no 'perfect security' for anything (except putting your
computer in a safe, creating a random and unrecorded combination for
the safe, locking it, wrapping chains around it, welding the chains to
the safe and the safe door shut, and then dropping the safe over the
side of a ship over the deep trough in the Pacific Ocean). All you
can do is reduce the attack surface of the things that have access to
the private key.
6. Acknowledgements
UNIX is a registered trademark of The Open Group (http://www.opengroup.org/).
Windows NT, Windows 2000, Windows 2003, and IIS are trademarks or
registered trademarks of Microsoft.
Verisign is a registered trademark of Verisign, Inc.
Thawte Consulting Pty Ltd is a corporation in South Africa owned by Verisign.
This document was written to be part of the documentation package for
OpenSSL, which requires the following credit information: This product
includes cryptographic software written by Eric A. Young
([EMAIL PROTECTED]). This product includes software written by Tim J.
Hudson ([EMAIL PROTECTED]).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
