PKI email encryption

Running Windows 2003 Domain.  Exchange 2003 and Outlook 2003.  Outlook is accessed via a Windows 2003 Terminal Server. Budget is not allowing an upgrade of our servers.  

One of our clients is requiring that our emails with them are encrypted with PKI.  We have a Barracuda appliance to filter for spam/viruses, but, per our client, the Barracuda email encryption service is not acceptable to send encrypted emails.  

I can create a user certificate from out local domain Certificate Authority and then import the cert into Outlook.  I tried sending an email to a gmail account, but Outlook balked since I didn't have the recipient's certificate.  

My questions:
To send an email, will the end user (client) have to send me a certificate and how would I import that so I can send encrypted email?
Is what I did, able to satisfy my client's request for PKI?
Is there a better way to do this? I have +/- 15 users that will have to send encrypted emails.
Who is Participating?
ParanormasticConnect With a Mentor Cryptographic EngineerCommented:
Email Encryption requires that you have the public key as that is the encryption key.  Only the recipient should have the private key that is the decryption key.  A certificate will normally include a public key with it.  Without having the key/certificate exchange occur prior to sending an encrypted email then it cannot work using public key cryptography.

There are a few ways to handle the key exchange for encryption:
1. Within the same AD you can select the checkbox on the certificate template to publish to AD.
2. Send an email and include the exported certificate as an attachment.  This exported cert should never include the private key.  You should get a .cer, .crt, or .p7c file (.p7c would have the user cert & all CA cert(s) included).  Note that many email filters will block certs cert files so you probably need to zip them first.  This method could be done admin-to-admin to send all of your company's certs to each other at one time & then you could deploy them via GPO to your users.  This isn't great if there are a lot of users, but for a couple of small companies it is usually okay.
3. Send a signed email - this will usually send the encryption keys, too, but if it doesn't then there is a checkbox in your email security settings for doing that.  This is a preferred method as it is signed also, reducing the chance of a spoofed email sending you encryption keys.  Note that if you send it to gmail there will be a .p7s file that would be used for the signature.
4. There are also "keyring" (or "keychain") providers out there where you could populate a copy of your encryption certificate & both sides could look to the keyring repository to acquire the certs as needed. I don't know of any services out there offhand, but there are a few that exist.  These normally need a client software component so it can figure out where to go look for an approved key.

You could also use another form of cryptography that uses synchronous keys, however this is generally not advisable.  Basically you could wrap a document up (e.g. zip it or Word document protection) & encrypt it using a secret password that is known to both companies.  While this would technically be valid if using something like AES for the encryption method, it would be subject to the strength of the password against an offline attack to be of any value - this would mean having a difficult to crack password over 20 characters long that needs to be entered correctly every time you send a message.  That password would either need to be shared with everyone at both companies to make it easier to use (and more vulnerable to attack) or to have a password mesh that is difficult to manage and enforce (userA to userB has one password, A to C has another, B to C a third, etc.) which obviously becomes quickly impractical to manage.  Technically, you still need to handle the secret key exchange at some point, but it could be encrypted first & relayed later but still must be done before the receiving party could read it.
Rich RumbleConnect With a Mentor Security SamuraiCommented:
For any PKI to work you have to exchange keys first, and that exchange does not need to be encrypted in any way. However, there is S/MIME email which outlook supports natively( see below), and there is PGP email. PGP will require 3rd party software, but S/MIME won't other than creating some signatures/keys. You do not have to purchase certs to use S/MIME as long as the person you're exchanging with understands that your certs are self-signed.

The two types are not compatible, you need to know if they use PGP/GPG or S/MIME.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.