Audience: technical

Usable Secure Email Technology

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

The ultimate and fail-safe defense against data theft is to not have the data in the first place.

With ZSentry, 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.

ZSentry 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 conventional secure email systems that are notoriously difficult to use.

Therefore, Zmail is not only a secure solution for email, but also a solution that presents no additional targets for an attack on the servers or users' computers, that complements and interoperates with any current and foreseeable system without changes, plugins, or installation, 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, with two factor authentication, anti-spoofing, SSL SMTP and HTTP service. 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 impersonation fraud ("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.

PKI/X.509 and PGP

ZSentry complies with and extends X.509/PKI and PGP security standards, allowing secure first contact and reply without previous interaction (e.g., exchanging passwords, requiring registration) or work (e.g., searching a directory, solving puzzles). ZSentry also supports SAML and SSO, so that it can be part of a federated-identity ecosystem.

With only PKI and PGP, however, while the key management solution is secure, it is notoriously not usable (complexity, certificate revocation, and other issues that have been widely reported). 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.

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.

Even though conventional PGP and PKI/X.509 solutions are notoriously far too difficult to use, a number of providers use servers to automate some of the tasks that were previously done manually. While this does improve ease-of-use, it may compromise HIPAA/HITECH Safe Harbor conformance, and still has to deal with several limitations of the underlying technologies PGP and X.509/PKI.

For example, the lack of first-contact capability in PGP and X.509/PKI has been countered by server-solutions that set and request passwords, even though passwords are no longer considered secure for user authentication online, including in financial areas (for example, by the US FFIEC).

Why not passwords? Using passwords for user authentication is classified by PKI/X.509 as "weak authentication" and is notoriously insecure, reduces usability in a first contact, and creates online targets for username and password lists that can be used elsewhere. Although email security solutions may use PKI for encryption/decryption, they are not secure if they use passwords for authentication.

For example, ZixCorp uses PKI management in the background as part of the hosted service but users are authenticated using passwords. The Google Postini HIPAA solution also uses passwords for user authentication.

While PKI/X.509 and PGP server-solutions potentially increase usability, they also decrease security when compared with conventional PKI and PGP solutions. In particular, the combination username/password is notoriously easy to guess and hard to protect in servers. It is security-wise inadequate in general, in spite of all access-control assurances and audit procedures.

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.

IBE and Voltage

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/TLS is used to provide email security (e.g., as used by some Postini systems), it falls short of basic security requirements. For example, because SSL/TLS messages are only encrypted in transit, 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 ZSentry can also be used to directly provide support for other ZSentry applications, including interaction with existing modules such as Mail and Vault. If you are interested in using or developing a ZSentry application, please visit our Partner page, where you can request a Support Ticket and submit your suggestion.

Main Technical Notes
Overview   Key Features   ZSentry App   ZSentry Client   API   Smart IT   SAML & SSO
  Security   Usability   HIPAA & HITECH   Experience   Why ZSentry?   Red Flags   SUMMARY

Development and © by NMA

Trademarks and Copyrights as described in our Legal Statement. We protect Your Privacy.