WebMail: Secure Mail (S/MIME)

The Public Key technology implements a so-called asymmetric cryptography. Using a regular, symmetric cryptography, both parties need to know some "key" or "password" (called "shared secret"). Before the parties can exchange data securely, they need to exchange that "shared secret", and this is the main security problem with symmetric cryptography: the "shared secret" can be stolen during the exchange process.

Imagine a spy who needs to exchange information with his center securely, using some secret key. That key must change frequently to ensure that the time needed to "break the key" is much larger than the "lifespan" of the information encrypted with that key. The center has to send those new keys to the spy (or vice versa), but those keys can be intercepted, and anyone who succeeds in intercepting the key will be able to decrypt all messages they send.

The Public Key technology uses pairs of specially generated keys. Both keys are very large numbers: they have 512 bits in length (approximately 60 decimal digits) or more. The special method used to generate those key pairs and the method used to encrypt information with those keys ensures that the message encrypted with one key can be decrypted with the other key. One key is called the "Private Key", the other key is called the "Public Key".

The PKI algorithms ensure that any data encrypted with the Public Key can be decrypted with the Private Key, any data encrypted with the Private key can be decrypted with the Public Key, and that it is extremely difficult to calculate the Private Key if the Public Key is known. Please note that messages encrypted with the Public Key cannot be decrypted with the same Public Key - they can be decrypted only with the Private Key.

Now we can see how this technology can be used by a spy, or any other party that needs to exchange information securely:

• The spy generates a pair of Public/Private Key using the key generation algorithm.
• The Private Key is stored securely at the spy's location.
• The Public Key is sent to the center using any type of communication - even a very "open" one. For example, the Public Key can be posted on the Web.
• When the center receives the Public Key, it uses it to encrypt the information it wants to send to the spy. It then sends it to the spy using any type of communication - again, it can just post the encrypted message on the Web.
• Since only the spy posses the Private Key, only the spy can decrypt the information the center has sent. All other parties only have the Public Key and the encrypted data, but the Public Key cannot be used to decrypt the information, and it cannot be used to calculate the Private Key.
• The Center can also generate a pair of Private/Public Keys and send its Public Key to all its spies - so all of them can send message to the Center that only Center can decrypt, using its Private Key.

In real applications, PKI is not used to encrypt actual information. Instead, a random "regular key" ("shared secret","password") is generated, actual information is encrypted using that shared secret, and PKI is used to encrypt that "shared secret" key. The encrypted "shared secret" key is appended to the actual information. The recipient uses its Private Key to decrypt the "shared secret", and then uses that "shared secret" to decrypt the actual data, using regular, "symmetric cryptography".

This method is used to decrease the amount of PKI computations (shared key is usually much smaller than the actual information), since PKI algorithm are much more complex than symmetric-key algorithms.

When it is said that the information is encrypted using 40 bit, or 56 bit, or 128 bit keys, it means that the random "shared secret" key used had this length - the PKI keys have much higher length. It is much easier to break a 40-bit "shared secret" key used to encrypt data, than to break a PKI key used to encrypt that "shared secret". But "shared secret" keys are generated at random for each transaction, so if someone breaks the "shared secret key" used for any transaction, only that transaction will be compromised (decrypted), because other transactions with the same PKI keys will use different "shared secret" keys.

The method with 2 keys (PKI and "shared secret") allows a sender to send an encrypted message to several recipients at once. A message is encrypted using a random "shared secret" key, and then PKI is used to encrypt that "shared secret" several times, with Public Keys of all recipients. All encrypted "shared keys" are appended to the message, and each recipient can find the "shared secret" encrypted with its own Public Key, decrypt it with its Private Key, and use the decrypted "shared secret" to decrypt the actual information.

Encryption alone does not solve all security problems. If we return to our spy/center example, anyone who got the spy's Public Key can send an encrypted message to the spy. The spy needs to verify that the sender is really the center. The "digesting algorithms" and the Public Key algorithms are used to implement digital signatures.

Digest is a relatively short (16-40 bytes) number with a "checksum" of the message. The algorithms used for "digesting" ensure that it is very difficult to compose 2 different messages that would have the same digest values.

To sign a message, the sending software:

• calculates a "digest" for the message;
• encrypts the calculated digest using its own Private Key;
• appends the encrypted digest to the message.

The receiving party uses the sender's Public key (it is known to the receiving party) to decrypt the message digest, calculate the message digest itself, and compare the decrypted and calculated digests. If they match, the message has not been altered, and it was really sent by the party that has the proper Private Key.

In our spy example, a third party won't be able to send a message pretending to be the Center, because it does not know the Center Private Key. And if the third party encrypts the digest with some other Private Key, the signature verification will fail, because the spy will try to decrypt the digest with the Center's Public Key, and the resulting garbage will not match the calculated message digest.

The encryption and signing methods assume that parties can freely exchange the Public Key information. The PKI eliminates the risk of "key stealing": the Public Key can be known to anybody (can be "publicly known").
But there is another risk - when a party receives the Public Key, it should verify that that it really belongs to the proper entity. Otherwise a third party can generate its own Private/Public Key and send the Public Key to the center, pretending that it is the Public Key of the spy. If the center does not detect that this is a fake, it will use that key to encrypt the information it sends to the spy. The spy will not be able to read it (it is encrypted with the wrong Public Key), but the third party that has issued the key pair will be able to decrypt it, as it posses the matching Private Key.

To solve this problem, the Public Keys are not distributed in the "raw form". Instead, they are distributed embedded into Certificates. A Certificate contains the following data:

• "Subject" - the name of the party the Certificate belongs to.
• Public Key - the Public Key of the "Subject".
• "Issuer" - the name of the party that has issued this Certificate.
• Signature - the digest of the data above, encrypted with the Issuer's Private Key.

Certificates are issued by a Certificate Authority - some party that all parties choose to trust. All parties should know the Public Key of the Certificate Authority. Modern Internet applications (browsers, mailers, etc.) have a built-in list of Trusted Authorities (including VeriSign and other similar companies), and have the Public Keys of those Trusted Authorities built-in.

When a certificate is received, the receiving party can verify if it has been issued by a "trusted authority": it checks if the "issuer" name in the Certificate is one of the "Trusted Authorities", and uses the already known Public Key of that Authority to verify the Certificate signature. If the signature is verified, the party can trust that the Public Key in the Certificate really belongs to the party specified in the Certificate Subject.

Very often an intermediate Certificate Authority is used. For example, a corporation can get a Certificate issued by a Trusted Authority, and then it can act as a Certificate Authority itself, issuing certificates for its employees. To enable verification of such a certificate by any third party, the Certificates issued by an Intermediate Certificate Authority are sent together with the Intermediate Certificate Authority own Certificate. The receiving party first checks that the Certificate is really issued by that intermediate Authority (by using the Public Key from its Certificate to verify the signature in the sender Certificate), and then it checks that the intermediate Authority is what it claims to be (by verifying its Certificate using the known Trusted Authority Public keys).

In order to use PKI for Secure Mail, an Account should have its own Private Key and a Certificate with its Public Key. The Private Key should be protected as much as possible, while the Certificate should be easily accessible by anyone.

CommuniGate Pro stores the Certificate in the Account Settings (as the "userCertificate" element), and also it copies the Certificate into the Directory - if the Directory Integration is enabled.

CommuniGate Pro stores the Private Key in the Account Settings, but it encrypts the Private Key with a "Secure Mail Password". To use any of the Secure Mail functions, you should enter the "Secure Mail Password" to let the server read and decrypt your Private Key.

Note: The server does not store your Secure Mail Password anywhere. If you forget the password, you will need to obtain a new Private Key and Certificate. This means that your will not be able to decrypt any message encrypted with your old Public Key.
Neither your System Administrator nor CommuniGate Systems will be able to help you get those messages back.

Note: While it is very important to remember your Secure Mail Password, it is not too difficult to do: the Secure Mail Password can be a word or a phrase (up to 100 symbols), in any language.

You can use your regular E-mail client (such as Microsoft® Outlook or Netscape® Messenger) to obtain a personal Private Key and Certificate (also called "Digital ID"). You can then export that "Digital ID" to a .pfx or .p12 file - a so-called PKCS#12-formatted file. In order to protect your data, the E-mail client will ask you for a password, and will encrypt the exported information with that password.
Note: while the file format supports non-ASCII symbols in a file password, you should use ASCII symbols only, as many E-mail clients (including Outlook) do not process national symbols correctly.

Connect to the Server using the WebUser Interface, and open the Settings section. Click the Secure Mail link to open the page that contains the following fields:

Note: If you do not see the Secure Mail link on your Settings pages, it means that your Account or Domain has the S/MIME service disabled.

Enter the name of the saved .pfx or .p12 file or use the Browse button to select the file on your workstation disks. Enter the File Password you used when you created that file.

Enter the password that will become your Secure Mail Password - this password will protect your Private Key on the CommuniGate Pro server. Enter this password twice, into two fields, and click the Import File Data button. If you have entered the correct File Password, the Certificate and Private Key information will be stored in your CommuniGate Pro Account settings.

Alternatively, you can ask the CommuniGate Pro server to generate a Private Key and a Certificate for you. Use the Generate Key And Certificate button:

As when importing Key and Certificate from a file, you need to specify the password (twice) that will will become your Secure Mail Password.

The generated Certificate will be issued for the E-mail address you have specified as your From address in the WebUser Interface Settings, but only if that address points to your CommuniGate Pro account. Otherwise, the Certificate is issued for your CommuniGate Pro Account address.

The generated Certificate is signed with the CommuniGate Pro server certificate.

The Secure Mail page now shows your Certificate data and the size of the Private Key.

To change your Secure Mail Password, enter the new password twice into the Modify Secure Mail Password panel fields and click the Modify Password button.

To store your Key and Certificate information in a file on your workstation disks, click the Export Key and Certificate link. A panel will open in a new window:

Enter the password to be used to encrypt your Key and Certificate information in the file (you need to enter it twice), and click the Export button. Your browser should ask you where to save the CertAndKey.pfx file (you can rename it).

IF you decide to remove your Private Key and Certificate, you need to have their copy in a file. This is done to ensure that you can restore this info if you removed the Key by mistake. Remember that if you remove the Private Key completely and do not have a file to restore it from, all encrypted messages sent to you will become completely unreadable.

To remove the Key and Certificate, enter the name of the file that has the your Key and Certificate and the file password, and click the Compare with File and Delete button. CommuniGate Pro will decrypt the file using the supplied password and it will compare it to your current Private Key. If the Keys match, the Private Key and Certificate are removed from your Account Settings.

When the Private Key is placed into the Account Settings, it is activated. The WebUser Interface automatically decrypts all messages encrypted with your Certificate/Public Key, and you can send encrypted and signed messages. In order to protect your sensitive information, your Private Key is automatically deactivated ("Locked") every 3 minutes. If you log out of the WebUser Interface session, and then log in again, your Private Key will not be automatically activated.

To activate your Private Key again, you need to enter the Secure Mail Password on any of the CommuniGate Pro WebUser Interface pages that displays the S/MIME Key Activation panel:

A message stored in your Mailbox or a message part can be digitally signed. When you open such a message, the WebUser Interface component automatically checks the integrity of the signed part. It retrieves the Signers data from the signature data and tries to verify the signature of all signers. It then shows the list of all signers whose signatures match the message content:

Dear Sir,

Thank you for your offer. I'm accepting it.

Sincerely yours,
Sample Sender

If the information cannot be verified with any signature, an error message is displayed.

A Signed message contains the Certificate of the signer. The Take Certificate button that appears on the Message page when a Signed message is displayed. By clicking that button you include the E-mail address and the name of the signer (as specified in the Certificate, not in the message headers), and the signer certificate into your currently selected Address Book.

When an Address Book is displayed, the [@] marker indicates the entries that have known (stored) certificates. You can send encrypted messages to those addresses.

To Send a signed message, make sure that your Private Key is unlocked. If it is unlocked, you will see the Send Signed checkbox on your Compose page. Select this checkbox to sign your message. If you send a message with attachments, the entire content of your message, including all attachments, will be signed with your Private Key and your Certificate will added to the message signature.

Recipients of your Signed message will be able to verify that the content has not been altered, and they will be able to store your Certificate and later send you encrypted messages.

To Send an encrypted message, make sure that your Private Key is unlocked, and that all message recipients are included into your Address Book, and their Address Book entries contain certificates.

If your Private Key is unlocked, you will see the Send Encrypted checkbox on your Compose page. Select this checkbox to encrypt your message. If you send a message with attachments, the entire content of your message, including all attachments, will be encrypted with the recipients Public Keys (taken from their Certificates), and with your own Public Key. As a result, if a copy of the encrypted message is stored in your Sent Mailbox, you will be able to read (decrypt) it.

If you select both Send Signed and Send Encrypted options, the message will be composed as a Signed message, and then the entire content (including the message headers and your signature) will be encrypted.

Use the Encryption Method WebUser setting to specify the encryption "cipher".

When you receive an encrypted message, its content is not displayed:

You need to activate (unlock) your Private Key first. With the Private Key unlocked, the WebUser Interface module tries to decrypt all encrypted messages with your Private Key. If it succeeds to decrypt the message, the message content is displayed:

Encrypted RC2(40bit) Subject: My Report From: The Agent <agent@company.dom> To: The Center <center@company.dom> Hello, Sorry, no report this month. Please stay tuned... Yours, The Best Agent.

When you want to keep the message in your Mailbox, but you want to keep it in the decrypted form, click the Decrypt button. The Server will try to decrypt the encrypted message. If it succeeds, it will store the decrypted message in your Mailbox and will remove the original encrypted message.

When you receive an unencrypted message, you may want to encrypt it in your Mailbox. Activate (unlock) your Private Key, and click the Encrypt button. Your Private Key is not used for encryption (the Public key from your Certificate is used), unlocking the Private Key is needed only to prove that you will be able to decrypt the message after it is encrypted.

You can automatically encrypt certain messages coming to your Account. See the Rules section, the Store Encrypted action.