GnuPG in the enterprise

[Christopher Black]

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
cblack at securecrossing.com | www.securecrossing.com