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).

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.

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.