Here is an excerpt from OWA 2K3 Web Administration Tool, regarding so called BCC forking:

"By default Outlook Web Access will submit a separate message for each entry on the BCC line of an encrypted message. This means that a separate message will be submitted for each entry on the BCC list. This is the most secure option. Outlook Web Access also allows for one separate message for all BCC entries or one encrypted message with no separate BCC forking."  

OWA Web Administration Tool -> S/MIME ->BCC Encrypted E-mail Forking

This is the most secure option phrase. It's surely true, but it is not clear why. Why is sending a separate copy of the message to each recipient with a "Bcc:" more secure than sending one copy to each recipient? What kind of security does this add? What are the benefits and what are the costs?

Continue reading "What problem does BCC Encrypted E-mail forking solve?"

All digitally signed emails contain information about the certificate used to place the digital signture: the issuer ID and the certificate serial number. This information is needed to retrieve the certificate and verify the signature. It is possible that the certificate is unknown to the mail application that is trying to do verification. In this case, the application can use the certificates appended to the signature, if they were added by mail sending agent. To perform full verification of the signature, validity of the certificate must be checked as well. This is why all the certificates in the validation path can be included in the signature as well.

Imagine a message containing a simple 'Hello!' text and weighing 13KB. Sounds suspicious, doesn't it? So did such message seem to Alice and therefore the Test Team set out to look for the source of the heavy weight of the simplest of messages.

Continue reading "The included Chain and Root"

To check how various mail clients handle problems with secure electronic mail, we asked Alice to send a Sour Cream Chili Bake recipe to Bob and Dave (in BCC). She sent the message encrypted altogether with the recipe (an image scanned from a magazine) attached to the message. Unfortunately for the recipients, but according to our plans, the message was damaged along the way to the server and last few bytes were chopped off. We shall see how various mail clients cope with this particular email.

Continue reading "Sour Cream Chili Bake - the encrypted and corrupted messages"

Typical webmail clients treat S/MIME-encrypted messages as an attachment, usually keeping its name "smime.p7m". OWA acts similarly when the attachment was sent with a client other than OWA. If the message was sent with OWA, the attachment is missing.

An interesting thing is that when the user activates the follow-up flag the attachment appears.

This phenomenon does not occur when the message is triple-wrapped.

Let us draw the Cryptigo E2K3 Test environment briefly:

There is a company that exchanges electronic mail with its business partner. Unfortunately, some of the partners were obliged to encrypt all their electronic mail. This way, our company was forced to start encrypting email to some of its partners. To cut the costs the company decided to outsource as much services as possible. They did not install any PKI-related services or machines, purchased their certificates in a well-known commercial CA and ordered their Exchange administrator to learn about S/MIME and PKI: "it can't be that complicated, you'l surely love it".

Analogous situation can happen in large companies that implement PKI and secure email in each division in turns.The divisions that have not turned to PKI and secure email yet are forced to handle incoming encrypted emails or have to use encryption in some workstations only.

The mail client most often used in the company is the OWA 2000,but Outlook 2003 is popular as well. Not all the users that receive encrypted mail expect it - the CA has published their certificates in its LDAP directory, so they are publicly available for anyone that wishes to encrypt email to them.

Following (virtual) users were employed in our tests

Alice, who uses Outlook to receive and send her professional mail, Bob, a roaming user that uses the OWA, Dave, who is a secure email guru (he is not an employee of the company, nonetheless sometimes he is asked to help with various secure email related problems), and finally the Administrator, who has no knowledge or experience with encryption, certificates or PKI. In contrast to Alice, Bob and Dave, the Administrator is a real-life person, cooperating with the test team.

This blog contains observations that Cryptigo Test Team has been making during the on-going E2K3  test drive focused on encryption and digital signature issues arising during both user's and  administrator's everyday practice. More accurately, we tried to put ourselves in E2K3 users' and  administrators' shoes to reproduce the problems they meet while performing routine tasks related to  e-mail security such as installing encryption certificates or preparing encrypted e-mail. Most  observations we make will be put in regular documents, but those that do not fit in this form and  may still be of value to E2K3 users and administrators will be published here.
 
The Cryptigo Test Team was initialy founded to research problems with diagnostic information provided by mail applications when handling secure - digitally signed and encrypted - electronic mail messages. The idea came from Cryptigo software users who reported that even secure email enabled applications, such as OWA 2KE3 and Outlook  have problems with effectively informing their users of problems related to secure email. This is contrary to our initial belief that such problems will occur only in web-mail clients and other non S/MIME mail applications.

Cryptigo Test Team:

Ewa Kanclerska
Maciek Kardasinski
Vizvary Istvan