Usable Secure Email Technology

Zmail provides On-Demand and On-Site solutions for secure email that is usable by anyone. Zmail uses the ZSentry Technology and the SaaS-ST solution developed by NMA, Inc.

The best defense against data theft is to not have the data in the first place.

With Zmail, your login credentials and your keys are not at risk anywhere. There simply is no password list or keys that could be attacked. ZSentry protects both the privacy of your communications and the keys that protect your privacy.

Zmail does not require any changes to email standards or applications. Our previous experience with email development, since the ARPANET days, convinced our team that any change in how email works would be very costly, very slow, not usable, and never complete.

Further, Zmail takes into account that The Most Important Feature of a secure email system is Usability.

In practice, users will rather use an insecure email system that is easy to use than a secure email system where, more often than not, even the help text seems intimidating. If security is too difficult or annoying, users may give up on it altogether.

ZSentry technology allows Zmail to be easy to use when compared with simple, familiar, conventional email systems — not when compared with other secure email systems.

Therefore, Zmail is not only a secure solution for email, but also a solution that presents no targets for an attack on the servers or users' computers, that complements and interoperates with any current and foreseeable system, and that, as The Most Important Feature, is Usable.

Zmail Technology Fulfills Your Requirements

Zmail is a secure email interface that uses the software and email address that you already have. Zmail works using technologies already built into your browser and email software, on Windows, Mac OSX, or Linux, and is compatible with Outlook, Thunderbird, Mac Mail, Eudora, Gmail, Yahoo, AOL, Firefox, Internet Explorer, Safari, and other user applications. When you use Zmail to encrypt your email, Zmail also protects your decryption key, your signing key, your usercode, and your password. They are not at risk anywhere.

Eliminating security targets also eliminates (as opposed to reduces) their risk and maintenance cost. There are other systemic benefits of eliminating security targets, such as reducing complexity, eliminating their back-up and restore operations, potentially large reduction in insurance costs by eliminating hard-to-defend attacks (e.g., hacker and collusion), and increased availability.

Technology Application

The application and importance of this work is measured by the current number of email users: more than 500 million:

There are 100 million personal mailboxes worldwide.(Radicati Group, November 2003)

There are 412 million corporate mailboxes worldwide; each one processes about 110 messages daily. (Radicati Group, July 2003)

Organizations, the largest market sector for secure email, have a clear need for email security. For very compelling business reasons including legal requirements, organizations need to send and receive private and secure messages between specific endpoints.

However, email encryption is not a mainstream application today -- not even for organizations, where there is an evident need to protect business and customer information. What's missing is the Most Important Feature of all: Usability -- including ease of use and ease of deployment.

Secure and Usable

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

• Protecting consumer privacy is becoming a duty for organizations worldwide.
• Organizations in regulatory privacy and security compliance regimes (e.g., HIPAA and FFIEC) increasingly need to communicate with partners in a way that is compliant.
• Email phishing, spam, email disclosure, and identity theft are major sources of fraud losses today.

In providing ease of use in email security, we have been motivated by the absence of a secure email system that is both secure and usable, even after almost 20 years of development. Of these conventional systems, PKI X.509 was released in 1988, PGP in 1991, and the first practical IBE system was developed in 2000. SSL/TLS, first developed ca. 1996 and very successful in ecommerce today, falls short of the email security requirements.

With PKI and PGP, while the key management solution is secure, it is notoriously not usable (complexity, certificate revocation, and other issues).

For example, in a paper by Alma Whitten and J. D. Tygar, "Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0", 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 Zmail 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.

Application Development

The secure and private communication channel established by Zmail can also be used to directly provide a number of Zmail Applications, such as secure voting with zvote, or bidding, payments, e-commerce, and access control functionality. Some of these Zmail Applications may have additional methods provided by Zmail and also by the customer.

If you are interested in using or developing a Zmail Application, please submit your request Ticket at the Support Center.