Red Flags In Email Security

Email encryption is gaining importance, for some very clear reasons:

• Email phishing, spam, email disclosure, and identity theft are major sources of fraud losses today.
• Protecting consumer privacy is becoming a duty for organizations worldwide.
• Organizations in regulatory privacy and security compliance regimes (e.g., HIPAA and FFIEC) need to communicate in a way that is compliant.
• After 02/2009, fines for non-compliance (HITECH Act) have sharply increased up to $1.5 million.

Solutions for email security, however, have been plagued by lack of both security and usability, even after almost 20 years of development. Of these systems, PKI X.509 was released in 1988, PGP in 1991, and the first practical IBE system was developed in 2000. SSL/TLS was first developed ca. 1996.

With PKI and PGP, while their key management solutions are secure, they are notoriously at fault in terms of usability (due to complexity, certificate revocation, public-key signing and other issues reviewed in the references [*]). This, in turn, creates security problems because users are not able to correctly apply expected procedures.

For example, in the work of Alma Whitten and J. D. Tygar [*], the authors report on a user test demonstrating that when the test participants were given even 90 minutes in which to sign and encrypt a message, the majority of them were unable to do so successfully.

How about newer versions? User interfaces get flashier, help files get longer but the usability problems remain. After almost 20 years of development, improving the graphical user interface and the help dialogue in those email security products seems to have reached a point of diminishing returns.

Users find PKI or PGP public-key management hard to understand, hard to use, and counter-intuitive. When you send a postal mail, for example, you do not ask the recipient to first send you an envelope. And you do not ask who they trust. But that is what happens when you send a PKI or PGP message -- you need to first ask the recipient for her public-key. Which must be digitally signed by someone that is trusted by someone you both must trust.

With IBE (Voltage™, MessageGuard™), while it is usable it is not secure (mandatory key-escrow, no key revocation, and other issues).

In IBE, the recipient's private key (which allows received messages to be decrypted) is provided by and is available at a server, the PKG (the Private Key Generator). In the IBE design, both the recipient and the sender must trust the PKG. But, for example, if the PKG provides the recipient's private key to other parties in addition to the recipient, this breaks the sender's message confidentiality. There is nothing that you, the sender, can do about it. You do not even know about it. There is a false sense of security. Oblivious to what is happening you may continue to send what, you think, are secure messages. This can happen without the recipient's cooperation or knowledge, in spite of assurances by the PKG and best efforts by the recipient to safeguard her private-key.

Because IBE has no key revocation, a compromised private-key cannot be terminated when desired. IBE has a built-in revocation delay that is equal to the time remaining for key expiration. This implies a very large or even undefined delay for key revocation.

Further, think about whether you want a hacker, a bug, a virus, or even someone working with the PKG server providing your "secure email" service, to have access to your private-key -- the same private-key that can decrypt any email you send. You don't.

When SSL/TSL is used to provide email security (e.g., as used by Postini™), it falls short of basic security requirements. For example, because SSL/TLS messages are only encrypted in-between servers, third parties can compromise message security and integrity at the security-gaps created at each end-point (i.e., not only at Postini but also at the user's ISP, DSL provider, and any other intervening server or cache system), and at the user's machine.

Thus, conventional email authentication and encryption solutions (PKI, PGP, IBE) are either secure but not usable, or usable but not secure. SSL/TLS is not an email authentication and encryption solution.

NMA developed ZSentry to allow any two parties to easily establish a secure and private communication channel (e.g., a secure email message exchange), without the usability and security shortcomings of conventional technologies such as PKI, PGP, IBE, and SSL/TLS.