Tony Shadwick wrote:
On Wed, 15 Jun 2005, Dan Nelson wrote:
In the last episode (Jun 15), Tony Shadwick said:
Are there any good documents out there on managing GnuPG in the
enterprise?
There are basic issues I need to be able to address, such as a
situation when an employee leaves a company. The admin needs to have
the rights to revoke that user's public key, and be able decrypt any
old messages to that user, and be able to decrypt messages sent to
that user that are now being redirected to someone else for handling.
Are there established mechanisms for handling centralized key
management in a company to where the Administrator has access to
everything required?
One solution is to make a copy of all keys (with known passphrases)
when they are created, and put the copy in a secure location. If an
employee leaves suddenly, you can retrieve the key to decrypt leftover
files and revoke the key. Pgp.com's Windows PGP software uses special
Revoker keys and Additional Decryption keys that get added when files
are signed, so files are always encrypted to multiple recipients and
keys are always revokable even if the original key no longer exists.
gpg doesn't recognize ADKs, though.
Just so I'm following then, let's say I have gnupg installed on my
server, and I'm creating all of my employee's secret keys there, then
installing gnupg on their workstations so that they can use local mail
clients to encrypt.
What's to prevent them from chaning their secret key passphrase or
revoking the key themselves and creating a new public key, then
publishing that to the keyservers? (Other than knowing enough about
gnupg in the first place to do any of this of course...)
Not to mention I've always wondering how gnupg plays with multiple
recipients or internal company mailing lists. For example if I send a
message to VIP1, VIP2, and VIP3, and it is an important internal
document that requires encryption, when I encrypt the message, won't it
get encrypted with VIP'1 public key, thus VIP2 and VIP3 won't be able to
open the message?
The reason for the secret password is to encrypt the actual key while
it's stored on your disk. Changing the password doesn't change the key,
just how it's stored. The un-encrypted key is what's used to
encrypt/decrypt messages, so if you create the key with one password,
give the user a copy of the key, and they change the password, your key
will still decrypt messages encrypted with their key. It would actually
be wise to have the user set their own password on their key anyway.
As for creating a new key, there's nothing you can do to prevent it,
other than perhaps run your own modified key-server, and control who can
check keys into or out of it. Using the public infrastructure, there's
nothing you can do about this.
The way to handle multiple recipients is that gpg generates a random
"session key", which it uses to encrypt the message, using symmetric
encryption like AES or DES. Then it encrypts a copy of this session key
with each of the recipients public keys using a public key algorithm
like RSA, and attaches each encrypted session key to the message. So
when VIP2 tries to read the email, gpg will look for the encrypted
session key it can decrypt, decrypt it with VIP2's private key to get
the session key, then use the session key to decrypt the message.
--
Christopher Black
Chief Security Engineer
Secure Crossing
22750 Woodward Suite 304 - Ferndale, MI 48220
Tel (800) 761-4299 | Direct (248) 658-6120
[EMAIL PROTECTED] | www.securecrossing.com
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
