Appendix N: Secure E-Mail

This topic aims to provide a simplified overview of secure e-mail.  The mix of certificates, public and private keys, passphrases, digests and ciphertexts can be confusing at first, but once you understand the basic symmetry of signing and encryption, and of private and public keys, you should find that everything falls into place.  The discussion below is structured to emphasize this symmetry.

At the end of this topic, some links for further reading are provided.

What is a signed message?

In a signed message, some arithmetical manipulation of the original plaintext of the message has been done to create a long string of numbers and letters known as a digest, which is sent along with the plaintext.  The message is visible in clear, and the recipient, or anyone else who has a suitable key, can reverse the operation to verify that the digest still matches the plaintext.  If the plaintext has been changed, it will no longer match the digest.

What is an encrypted message?

In an encrypted message, some arithmetical manipulation of the original plaintext of the message has been done to create a long string of numbers and letters known as a ciphertext, which is sent instead of the plaintext.  The message is not visible in clear, but the recipient, or anyone else who has a suitable key, can reverse the operation to recover the plaintext.

Why do we sign messages?

Signed messages need to be securely signed to make them useful.  The recipient, or anyone else who reads the message, can then be sure that a specific sender has sent the message and that it has not been modified by anyone else.  To do achieve this, the sender creates the digest by using a secret private key, which is known only to the sender, to perform the text manipulation.  So nobody else will be able to create the same digest from the same message.  But the sender makes available to everyone a second public key, which is tied uniquely to the sender, and which is capable of verifying the correctness of the digest and the plaintext.

Why do we encrypt messages?

Encrypted messages need to be securely encrypted to make them useful.  A sender can then be sure that a specific recipient is the only one who can read the message, and that nobody else has access to its contents.  To achieve this, the sender creates the ciphertext after obtaining a public key from the recipient, which is tied uniquely to the recipient, and which is used to perform the text manipulation. Anybody who has this public key will be able to create a ciphertext from a plaintext message which is to be sent to the recipient.  But the recipient also has a second private key, which is capable of reversing the operation and extracting the plaintext of the message.

What are the public and private keys?

In essence, you can think of a private key as made up of two extremely large prime numbers, and the public key as an even larger number formed by multiplying them together.  Together, the public and private keys form a key-pair. The numbers are so big that the task of finding the two unique prime numbers from the public key is computationally impractical, and would take years to complete. The arithmetic used to manipulate the text is such that the work done by a key is a one-way operation which can only be undone by the other part of the key pair. Other operations than simple multiples of two primes can also be used to form key-pairs of this type.

If you sign plaintext using your private key, the digest can only be verified, not recreated, by your public key.

If you encrypt plaintext using someone else's public key, the ciphertext can only be decrypted by the same person's private key.

Where do public and private key-pairs come from?

Anyone can create a valid key-pair. You just have to find two very big prime numbers, and multiply them together.  But a simple key-pair like this cannot be used for secure e-mail because for this purpose the key-pair has to be reliably tied to a specific e-mail address.  And it is not sufficient just to create a key-pair and announce 'this is Alice's key-pair': were this so, anyone could use this key-pair to sign e-mail with the private key and pretend to be Alice, and you could not be certain that encrypted e-mail that you send to Bob using something simply described as 'Bob's public key' is actually encrypted so that only Bob can read it.

For use in e-mail, a key-pair not only needs to be associated with a specific e-mail address, but needs a certificate which reliably confirms that it really belongs to that e-mail address.

Secure e-mail certificates and keys can be purchased from a number of organizations, including those whose links are in the Signed and Encrypted E-Mail topic.  Larger organizations may have an internal department which will issue certificates.  Certificates usually have an authentication chain which the recipients can verify, and also a validity period.  Before issuing a certificate the issuing body will make checks to ensure that the applicant and/or company is who it claims to be.

How are certificates and keys stored?

When a certificate is issued to you, it is normally received in your browser and then saved by Windows and exported to a file.  When you receive a public key from someone else, the certificate containing it is usually saved by your mail client.

Your own certificates, whether you save them in Windows certificate storage or in a separate file, are private to you and must always be protected by a passphrase which only you know. Your own certificate files used with CopiaFacts to sign outgoing e-mail or decrypt incoming encrypted e-mail should have a file extension of .PFX or .PEM and you will need to make the passphrase available to CopiaFacts in order to use them.

Other people's certificates used with CopiaFacts to encrypt outgoing mail should have a file extension of .CER and do not require a passphrase because they are not secret.  You do not need .CER files with CopiaFacts to verify incoming signed e-mail because the certificate and the public key are sent with the e-mail itself.

How is a public key actually published?

When you sign an outgoing e-mail with your private key, your addressee will need your public key in order to verify that it came from you.  Normally you need take no action in advance to publish your public key because it is automatically included with the e-mail, in the form of a certificate which certifies that the included public key belongs to you.  In the same way, you will receive the sender's public key with incoming signed mail and you can use that to verify that it came from the sender's e-mail address.

When you want other people to send you encrypted e-mail, it is usually simplest to send them in advance one signed e-mail message.  This will contain a certificate which certifies that the included public key belongs to you and that they can safely use it to send encrypted e-mail to you. The other person's e-mail client will store the certificate and they can set up their e-mail client to send encrypted mail when you are the addressee.

When you want to send encrypted mail to someone else, you should ask them to send you in advance one signed e-mail message.  This will contain a certificate which certifies that the included public key belongs to them and that you can safely use it to send encrypted e-mail to then. Your e-mail client will store the certificate and you can set up your e-mail client to send encrypted mail when the other person is the addressee.

DKIM signing is a special case.  In this case the public key is never sent with the message, but instead it is saved in the DNS records of the sending mail server.  When a DKIM-signed message is to be verified, the recipient performs a DNS look-up to the originating mail server.  DKIM key-pairs do not need to be certified to a specific e-mail address, because the verification process can only obtain the public key from a specific DNS server.  Verification thus verifies the source of the message, not the identity of the sender.  DKIM-signed messages can also be S/MIME signed and/or encrypted.

Can e-mail be both signed and encrypted?

When outgoing e-mail is encrypted, most e-mail clients will also require it to be signed.  It is of course signed with the sender's private key and encrypted with the recipient's public key. Since each key is tied to the specific e-mail address, the same key-pair is never used both in signing and encryption of the same message.

You either encrypt the signed message, or sign the encrypted message.  Both methods are used though the former is more common (and is the default for CopiaFacts outbound e-mail).

How does CopiaFacts implement secure e-mail?

CopiaFacts outbound e-mail can be signed with the originator's private key or encrypted with the recipient's public key, or both.  The key files must be specified with the FS file commands, $email_sign_keyfile or $email_encrypt_keyfile respectively, using a .PFX or .PEM file, with passphrase for the former, and a .CER file for the latter.  An $email_options command is also required in the FS file and an $email_security command in FAXFACTS.CFG.

CopiaFacts can receive inbound e-mail and verify with the originator's public key and decrypt with the recipient's private key.  The verification key file must be with the incoming message, and the decryption key file on an $email_decrypt_keyfile command in the recipient template file using a .PFX or .PEM file with a passphrase.  An $email_security command is also required in FAXFACTS.CFG, and specified only that S/MIME decoding is to be done (both verification and decryption are done as a single operation).

A summary of all the necessary commands is in the Signed and Encrypted E-Mail topic, and there are examples for outgoing e-mail.

When incoming e-mail has been received, the CopiaFacts SMTP gateway will place variables in the generated FS files to give the outcome of the verification and decryption processes.  Infobox pre-processing logic should decide how to process error conditions such as a verification or decryption failure.  Examples are in the course of development, and a future build of the SMTP Gateway Manager will facilitate the setting up of recipient templates for S/MIME decoding.

Where can more detailed information be found?

The S/MIME entry in Wikipedia is a good starting point, with links to the relevant RFCs and other sources of information.

What do I do next to SEND secure e-mail from CopiaFacts?

Get your own e-mail certificate(s), tied to the e-mail address(s) you will be receiving mail to.  Some links for providers are in the Signed and Encrypted E-Mail topic. From the browser in which it is delivered, export it in a .PFX or .P12 file.  For details see one of:

Saving your own certificate from Firefox

Saving your own certificate from Internet Explorer

Saving your own certificate from Chrome

If you already have a personal e-mail certificate in your mail client, export it in a .PFX or .P12 file.  For details see one of:

Saving your own certificate from Thunderbird

If you want to send encrypted mail as well as signed mail, ask your recipient to send you a signed e-mail message.  In your mail client, export the recipient's public key in a .CER or .DER file.  For details, see one of.

Saving other certificates from Thunderbird

Make sure your CopiaFacts license includes E-Mail Security and add an $email_security command with keyword SMIMEencrypt and/or SMIMEsign in your FAXFACTS.CFG file.

Use $email_sign_keyfile (with your PFX file and password) and optionally $email_encrypt_keyfile (with the recipient's CER file), with $email_options in the FS files for the e-mails you send.

What do I do next to RECEIVE signed e-mail with the CopiaFacts Gateway?

Make sure your CopiaFacts license includes E-Mail Security and add an $email_security command with keyword decodeSMIME in your FAXFACTS.CFG file.

When processing the FS file generated from the gateway, look at the SMIME_RESULT variable and associated error variables (using infobox logic) to find out if an e-mail signature was present and verified.

What do I do next to RECEIVE signed, encrypted e-mail with the CopiaFacts Gateway?

Get your own e-mail certificate(s), tied to the e-mail address(s) you will be receiving mail to.  Some links for providers are in the Signed and Encrypted E-Mail topic. From the browser in which it is delivered, export it in a .PFX or .P12 file.  For details see one of:

Saving your own certificate from Firefox

Saving your own certificate from Internet Explorer

Saving your own certificate from Chrome

If you already have a personal e-mail certificate in your mail client, export it in a .PFX or .P12 file.  For details see one of:

Saving your own certificate from Thunderbird

From your usual e-mail client, send one signed e-mail FROM the address you will be receiving mail to, to each person who needs to send you encrypted e-mail.  This will provide them with the public key which they can then use to send encrypted e-mail to that address.

Make sure your CopiaFacts license includes E-Mail Security and add an $email_security command with keyword decodeSMIME in your FAXFACTS.CFG file.

Use an $email_decrypt_keyfile command in a special recipient template for each address which is to receive encrypted mail.

When processing the FS file generated from the gateway, look at the SMIME_RESULT variable and associated error variables (using infobox logic) to find out if the e-mail signature was present and verified and whether the message was decrypted successfully.

Signed and Secure PDFs

CopiaFacts can also sign and secure PDF files.  See also the descriptions of the $pdf_sign_keyfile and $pdf_secure commands.