How Secure Is Your Secure Email

How Secure Is Your Secure EmailIntroductionWhere Are We Today in Securing Our EmailsIssues to Consider in Securing Our EmailsSecure Email Product SurveyFeature ComparisonsClaims to ClarifyWhat’s the Matter with PGP?The Latest Efail Attacks on S/MIME and OpenPGPMitigation of Efail AttacksSecure Email Threat ModelModelingEffectiveness against ThreatsProtonMailDIME (Dark Internet Mail Environment) and Lavabit ServiceVirtru Secure EmailCriptext Ai-Fi SecureEmailSet It UpAi-Fi.net Design PrincipleAi-Fi Secure Email is Based on Conventional Email InfrastructureReferences

Introduction

The primary goal of Ai-Fi.net is to protect your privacy based on a secure virtual space of your own, your private Ai-Fi Domain, constructed out of Ai-Fi.net's tool sets. The advanced and modern technology of Ai-Fi.net affords our users the maximum level of privacy and security achieved at the least amount of threat from any third parties. It mobilizes your personal resources, such as your PCs, mobile phones, and Internet services incorporated into your Ai-Fi Domain, to build your own defenses against unwanted tracking, censorship, and surveillance. To earn this independence without relying on any third parties of unknown motives, our users are asked to involve themselves more in applying the underlying technology (but not much more, as it nicely turns out). We'd consider this involvement as a rewarding tradeoff.

The root cause of not being able to secure our emails, or any of our online identities and assets, is because we rely too much on other parties for crucial resources and services. To secure our emails, as will be explained in details later, we need the key pairs for encryption, the key directory for finding our friends, the "prekey store" to negotiate session keys dynamically for "perfect secrecy", the storage to store our emails without other people peeping in, and the ability to read our emails from our many personal devices from anywhere in the world. Ai-Fi.net allows you to carve out a piece of the Internet real estate which you can call home, the private "Ai-Fi Domain" of yours, through which you conduct your business in a self-reliant manner. Without this private home base of yours, it's difficult to establish a stable foothold in this age of surveillance capitalism. You need the protection of your own castle. You need to forearm yourself with the castle defense built into our Ai-Fi Domains.

Among all our solutions, the Ai-Fi SecureEmail is designed and released as a demonstration of the power of Ai-Fi.net in delivering secure/private/anonymous emails for our users. The below diagram is a snapshot of some other notable applications supported by Ai-Fi.net castle infrastructure. Ai-Fi SecureEmail is just one of the Ai-Fi features that is immediately useful for many of us. You may be interested in learning more about us from our web site at https://ai-fi.net for other privacy-preserving applications based on the same foundation of your "Ai-Fi Domain".

In this blog, we will examine various secure email products, analyze many issues those products have been struggling with, and conclude it with the introduction of our Ai-Fi SecureEmail that answers many difficult security and privacy issues based on the underlying support of Ai-Fi.net.

Our aim is to create happy users of Ai-Fi SecureEmail and move them on to other advanced privacy and security focused Ai-Fi products: Ai-Fi Private Social Networking, Ai-Fi Cloudless Private Dropbox, Ai-Fi IoT Security Perimeter, and many more coming down the pipe.

 

Where Are We Today in Securing Our Emails

Issues to Consider in Securing Our Emails

Security and privacy are relative concepts. Absolute security or absolute privacy doesn't exist. Usability is another relative concept. Worse yet, usability is highly subjective in addition. All three concepts, the security, privacy, and usability, must be examined in their targeted applications under specific context based on comparative measurements in relative terms.

In this report, the application context is "secure email". This is not intended as an exhaustive survey covering all vendors on the market. Rather, it reviews a few noteworthy vendors representative of their respective technologies in order to compare features and to learn the lay of the land. We offer an introduction of our Ai-Fi SecureEmail in the second half. In the end we hope you will be convinced that a fully private and secure email service is achievable only through the strength of a healthy and comprehensive foundation.

Emails have been around for a long time since the beginning of the Internet era. It is a convenient way of contacting your friends, family, colleagues, and business associates. It is informal, universal, reliable without guaranteeing delivery (quasi-deniability), and asynchronous without requiring the recipients to be online.

In this context of secure email, we will base our comparison on the following feature considerations:

Secure Email Product Survey

Feature Comparisons

With the issues we care about our emails more clearly defined, next we consider the myriad of features offered by various service providers and check if they've accomplished what they set out to do. The below diagram is borrowed from the spec "DIME Architecture & Specification 2018"[DIME], which summarizes the traditional email architecture quite nicely with popular acronyms explained. Note that MUA is a fancy way of naming the email client, which is the software that the email Author and Recipient run on. Emails are passed around based on the SMTP protocol, which may involve any number of MTAs along the way. The email author relies on the MSA, the service provider the author signed up to originally, to initiate the transport of their emails. The recipient typically uses IMAP protocol to retrieve their emails from the MS (Message Store) of their own MDA (Message Delivery Agent) at the last MTA stop. Note that all the MTAs involved in delivering the emails may be run by different self-governing email service providers like Gmail, Yahoo mail, Outlook.com, AOL Mail, etc.. Jointly they form a "federation" in order to enable senders from one domain to send emails to any recipient of another domain.

There are many so-called "Secure Email" services around, which make various function claims. For you as an informed consumer evaluating secure emails, we would recommend working from the following checklist of features:

There are an increasing number of projects working on next generation secure email or email-like communication. In the table below we examine a few popular and representative products for comparison purposes with the Ai-Fi SecureEmail offering, which we believe is demonstrably superior. For a more extensive survey of those secure email services, you may be interested in visiting the survey paper here.

 ProtonMailPGP Based (CounterMail, Hushmail, Mailfence, Tutanota, etc.)LavaBit/DIMEVirtruAi-Fi
Email FederationNo (requiring bridging)YesNoYesYes
End to End Encryption**YesYesYesYes~~Yes
PFSNoNoNoYes~~Yes
Key StoreAt provider'sAt provider'sResiding with Clients PrivatelyAt ServerResiding only with Clients Privately
Private Mail StoreNoNoNoNoYes
SP Meta-data ProtectionNoNoNoNoYes
      

**Without exceptions, all secure email providers claim "end-to-end encryption". However, the follow-up question ought to be whether it is mediated by the email providers or any other third parties, which are technically a MITM (Man In the Middle) with all its risk implications, including the fact that this end-to-end encryption is no longer "warrant-proof". For instance, Mailfence keeps the private keys of its users, which is as MITM as you can get. All other email providers provide email storage and key management, which could also be turned into MITM contraptions.

~~ Not all end-to-end encryptions and PFS properties are created equal. More on Virtru later[Virtru Review].

This blog intends to ask questions regarding the claims made by those popular secure email services, to explain why most of them are outdated with known vulnerabilities, to compare features in more precise terms beyond confusing semantics, and to highlight those distinct features in the Ai-Fi SecureEmail offerings made possible only through the latest technologies.

The secure email functions offered in Ai-Fi.net are only part of an integrated whole that delivers a consistent set of privacy and security infrastructure. The PFS and Private Message Store in the above table are natural extensions of the core functions of Ai-Fi.net, which are managed through the crypto wallet associated with the protected email address. Without the backing of a sound privacy/security architecture, many of the critical secure email functions are difficult to achieve. This Ai-Fi SecureEmail may be viewed as a demonstration of the power underlying the Ai-Fi.net architecture.

The first half of this blog is rather lengthy in explaining why PGP and S/MIME, the more popular technology, are outdated and broken, and the services like Virtru are not really suited for personal protection. If you are of the same opinion or only curious about Ai-Fi SecureEmail, then jump directly to the second half[Ai-Fi].

Claims to Clarify

There are many so-called secure email services on the market (like those identified in the above table), including both paid and free ones. They make a variety of security claims that may be summarized as follows:

  1. Emails are encrypted during delivery from hop to hop before reaching the destination provider. They are encrypted between the email client and the email server, but exposed on the servers of various email providers. Since the encryption is not end to end, there will be men in the middle who can see your emails. The plain Gmail is in this category.
  2. Emails are encrypted before sending to the recipient. This is end-to-end encryption based on OpenPGP, S/MIM, or their many variations. As the encryption key is statically generated, it is lacking "Forward Secrecy" and furthermore it is subject to all kinds of man-in-the-middle (MITM) attacks. Efail is the most recent case of MITM attacks, which is discussed in more detail later.
  3. Emails are physically secured away from NSA surveillance when stored. ProtonMail claims it hosts emails in a location outside the US jurisdiction. It implements end-to-end protection through PGP, but also boasts that it is the only email system the NSA can't access. This is indeed a curious claim, as the traffic in and out of the US is all subject to NSA surveillance regardless whether the emails are hosted in foreign soil or not. The logic that this temporary storage outside of US protects you from NSA scrutiny is highly unsound.

At least for now, the focus has been on confidentiality through encryption. Most encryption schemes offer no Perfect Forward Secrecy. Potential attacks on email meta-data and public key directories are largely ignored, mostly due to limitation on various adopted technologies.

What’s the Matter with PGP?

Most so-called secure email services offer Public Key Encryption with or without CA (Certificate Authority) and their encryption keys are statically generated without the ability of carrying out the dynamic key negotiation for a session key with the recipient. Among its many deficiencies, one glaring defect of PGP-based schemes is this lack of "Perfect Forward Secrecy", a highly desirable property that the compromise of any long-lived cryptographic keys such as the private/public key pair does not put any previous correspondence in jeopardy. This deficiency is due to the fact that often OpenPGP messages are sent and read from different machines, at different times, and in different order, the typical traits of email delivery. This asynchronous nature of sending and receiving precludes the creation of ephemeral keys that require both parties to be online, much like what is carried out by TLS, one of the strongest, tried and true security standards.

The legend has it that the CIA, NSA, and many other three-letter agencies are a patient bunch. They may have all your correspondence in a stash waiting for the keys to be deciphered, perhaps through quantum computing one of those days. The lack of Perfect Forward Secrecy can be a real bummer for any of us 10 years down the road when quantum physicists have enough reliable qubits. Quoting the same expert cryptographer: "If the NSA is your adversary just forget about PGP".

The Latest Efail Attacks on S/MIME and OpenPGP

In addition to their lack of Perfect Forward Secrecy, both S/MIME and OpenPGP are ancient standards and very slow-moving in addressing their security defects and ever increasing challenges. It is also highly "balkanized" in the sense that the OpenPGP ecosystem is made up of so many different parts that are only loosely coordinated, which begets complexity and retards coordinated effort in resolving any vulnerabilities[ Efail Postmortem]. For instance, recent reported "Efail" attacks are quite horrendous, affecting 65% of popular email clients. It is so serious that a web site has been set up to track the progress of the repair works required to ameliorate the defects[Email Attack1].

Under Efail attack, the encrypted email text may be surreptitiously altered without detection or consequences, and the altered text would subsequently trigger the sending of your decrypted content to bad places. The following offers more technical details:

  1. The sole encryption scheme CFB for OpenPGP and CBC for S/MIME both suffer from the malleability of plaintexts, namely that the encrypted text may be altered without affecting the decryption algorithm. The original content may not be easily obtained without the secret key but modification to it would not affect the decryption logic. The original text could be significantly altered by using carefully crafted "malleability gadgets". The email client software frequently either sidesteps integrity checks or fails to execute a clearly defined action even when the compromise on the text is detected.
  2. The rich HTML-formatted email allows for "exfiltration channel" so that the compromised email is manipulated to leak its content not easily detected or trigger malicious behaviors indirectly. These backchannels have been shown to exist for nearly every email client, ranging from classical HTML resources to OCSP requests and Certificate Revocation Lists.

One may notice that the MIC (Massage Integrity Check) is expected as a matter of course in popular SSL or TLS transport protocols. Unfortunately, those transports are not applicable here due to the inherent limitation of email services where the sender is unable to demand that the recipient is online to receive the message synchronously. This technical difficulty, plus other flaws caused by the complexity of the S/MIME format, introduces those unfortunate attacks.

If you need to know the latest on how security communities view the OpenPGP, read the following observation:

[PGP Issues]

This is just a round-about way of stating that PGP is outdated, which stands little chance of winning the arms race between hackers and the defenders of our security/privacy.

Mitigation of Efail Attacks

The Efail attacks on S/MIME and OpenPGP-based "secure" emails have exposed major defects in these two email standards. The published analysis shows that Efail plaintext exfiltration channels exist for 25 of the 35 tested S/MIME email clients and 10 of the 28 tested OpenPGP email clients. While it is necessary to change the PGP and S/MIME standards to reliably fix these vulnerabilities, Apple Mail, iOS Mail and Mozilla Thunderbird had even more severe implementation flaws allowing direct exfiltration of the plaintext that is technically very easy to exploit.

ProtonMail and the inventor of Pretty Good Privacy (PGP) Phil Zimmerman have released a strong statement dispelling recent reports that the encryption program should be disabled because of alleged vulnerabilities[Email Attack3], claiming "the Efail vulnerabilities are not flaws with the OpenPGP protocol, but are actually errors created during implementation of the program". Actually, almost all vulnerabilities in history are "implementation" related; the malleability of plaintexts in CFB and CBC encryption is at the root of the problems, which require fundamental fixes. Zimmerman and his cohorts went on to say "Both our recommendations and EFF's require user action on the part of the sender and recipient of messages". Well, it is interesting to find out how many of those users are so well informed and technically adept that the recommended "user action" can be carried out, which is summarized as follows: "Ensure that everyone you communicate with is also using unaffected implementations or has updated their PGP software. Be sure to get a verified confirmation from your contacts before sending sensitive information to them"[Email Attack4]. Despite all of these "actions" to be taken, they insist that "PGP" is not broken.

To fix the defects requires the revision of RFC 2045, 2440, 4880, 5652, and 5751. Almost all email clients such as Outlook, Google Mail, Apple Mail, Thunderbird, Foxmail, et cetera, must be modified to the new specifications if they ever come out at all. We can be certain that it will take a long time for those standards committees to agree on any resolution.

For the short term those academics who successfully launched and publicized Efail attacks recommend the following mitigationshttps://github.com/noiseprotocol/noiseprotocol.github.io/blob/master/noise.pdf:

  1. Decrypt the S/MIME and OpenPGP emails outside of email clients
  2. Disable HTML rendering

Clearly restricting secure emails to only plain text or proprietary Microsoft RTF format or decrypting them outside of the email clients is not going to be acceptable to email users. We need to go back to the drawing board.

Secure Email Threat Model

Modeling

For security and privacy protection, we need a threat model to guide our implementation focus. Based on our observation and reported incidents in the recent past, it is probably not too far off in assuming "Bad guys own any server infrastructure". The implication of this model is that we should rely primarily on the clients for protection, over which we have immediate and direct control, and demand all third-party providers for auditable services at least on the level of PCS (Post Compromise Security).

Specifically for email service, the threat model in terms of the malicious goals of the attackers is defined as follows:

  1. Email content attack: The adversaries want to break the encryption protocol and decrypt the cyphertext of emails. The adversaries have sufficient resources to store a large amount of emails collected over a long period of time for a particular target victim. If Google gmail is your service provider, a simple warrant delivered to gmail is sufficient to effect this attack as its TLS/SSL encryption protects only the transport and not the content.
  2. Meta-data attack: The meta-data about emails can be as narrow as the record of a single email between you and a particular contact of yours, say Edward Snowden, or as broad as the collection of all your correspondence, enough to profile sufficiently your circle of email friends, which is collected by the adversaries occupying a chokehold of where the majority of your emails passes through during their delivery and reception. If government is the source of the threat, a simple subpoena is sufficient to gather most of the meta-data interesting to them.
  3. Public key directory attack: The adversaries want to impersonate or masquerade as either the author of an email, to spoof the sender, or the recipient, to divert it to a compromised mailbox through attacks such as phishing, pharming, DNSpionage, MITM, or poisoning the public key directory.

In this day and age, the line between friend and foe is often blurred. The case history of secure email vendor Lavabit involving Edward Snowden's emails stored on its servers can attest the fact that email service providers may be turned into an adversary overnight per government or political pressure. This is where the secure email technology adopted by various vendors becomes crucial. Cleverly designed secure email service may render those threats nonoperational. You may be interested in learning one of those cases where the superiority of technology trumps grand jury subpoena.

To evaluate various secure email offerings, we will apply the threat model described above. Obviously the offered feature set is also an important evaluation criteria in addition to the defense against threats. The smaller the feature set includes, the less the built-in protection covers.

Effectiveness against Threats

 

ProtonMail

ProtonMail is one of the most popular secure email providers with open-sourced email clients decrypting emails end-to-end based on OpenPGP. It requires both the sender and recipients adopting email accounts with ProtonMail in order to realize the full function sets (This turns it into a "non-email", working only among ProtonMail subscribers).

We have voiced our opinion about its questionable claims on the advantage of being "Based in Switzerland" and will not repeat it here. We will only pay attention to technical aspects of the ProtonMail's offerings. The ideal technical solution to secure emails should not rely on the notoriously fickle government policies (unless "warrant-proof" is not legally allowed).

We'd like to dive into exactly how the so-called end-to-end PGP based encryption is implemented. Since the OpenPGP's stand regarding the public key directory (e.g. "web of trust") is not universally accepted, it has become the issue central to the schemes provide by various secure email providers with a host of approaches. We'll give a full description of ProtonMail's approach as a representative of this class of products.

Ignoring the issue of PFS (Perfect Forward Secrecy), the above diagram is fine and dandy except the thorny issue of how the public key is published to all interested parties. Base on the open source of ProtonMail client, its encryption scheme and key distribution are outlined as follows:

  1. The client uses the password-based SRP protocol to securely connect to ProtonMail server. The strong security between the client and server is achieved without the server knowing the password.
  2. The client encrypts its secret key by using the SRP password and ships the encrypted key to the ProtonMail server.
  3. ProtonMail server downloads the encrypted private key to any properly authenticated ProtonMail client (logged in through SRP). This is how the private key is passed around among all the ProtonMail devices belonging to the same account.
  4. The end-to-end encryption is based on OpenPGP.

Like the majority of the secure email products, there is no Perfect Forward Secrecy.

As indicated in Step 2 and 3, the private key is stored at ProtonMail's server, which creates the weakest link. Even though it is encrypted with the SRP password that ProtonMail has no knowledge of, the strength of the whole protection scheme is greatly reduced to that of the SRP password. In other words, ProtonMail is perfectly capable of decrypting your emails in most cases. Given the fact ProtonMail is not able to provide forward secrecy and having all your emails in its server storage, all your email contents can be handed over to any parties by ProtonMail in a pinch. I just tried to check the strength of my password using the popular password cracker zxcvbn, it took less than a second to crack mine by a ordinary PC of certain number of cores. ProtonMail has all the facilities to make the less demanding "offline guessing" on your password. Worse yet, once your password is compromised, your SRP protection is out of the window as well.

In summary, ProtonMail is not able to withstand any of those threats in our threat model defined previously. (After finishing writing this section, we found an academic paper based on a much more rigorous analysis that agrees with out conclusion.)

DIME (Dark Internet Mail Environment) and Lavabit Service

Lavabit is an open-source encrypted webmail service, founded in 2004. The service suspended its operations on August 8, 2013 after the U.S. Federal Government ordered it to turn over its Secure Sockets Layer (SSL) private keys in order to spy on Edward Snowden's emails. It started operating again with the newly proposed and not yet complete DIME architecture in 2017. Lavabit is certainly the longest running secure email service. Here we are only going to discuss the newly proposed DIME architecture, since its previous so-called secure email left a lot to be desired.

Lavabit and its push for DIME standards are a heroic effort in getting to what they consider "the next generation email" in a specification of 181 pages. However, it is not compatible with any of the traditional email service providers. Given the fact that their emails are encrypted, in direct conflict with the business model of those service providers, none of the email providers is likely to support the new DIME standard. The so-called "DIME emails" are hardly qualified to be emails under this standard and Lavabit is left to shoulder the cost of the complete "email" infrastructure. If it is not email anymore and forgoes all the federation possibilities offered by conventional email services, there are plenty of competing secure messaging transports out there that offer pretty much the same, including the crucial feature of not requiring the recipients to be online which is considered the most critical email feature. The well implemented secure IM of signal.org with private file transfers works reasonably well without losing much of what is currently being delivered by Lavabit. (Actually Signal guarantees both Perfect Forward Secrecy and Future Secrecy.) However, we would not call Signal's IM "Secure Email" since there are no matching agents corresponding to those MSA/MTA/MDA in conventional email.

DIME is brand new, with a very low level of deployment and experience. For reasons argued above this situation is unlikely to change. In contrast, considering the wide acceptance of traditional email services and the huge experience gained along the way, it is difficult to see how defects on DIME can be discovered and repaired in time to stay competitive.

 

Virtru Secure Email

Among all the secure email services, Virtru makes the most confusing claims. They declare similar functions as other providers, using the same terminology such as end-to-end encryption, privacy, and forward secrecy, but deliver some other things altogether different:

  1. End-to-end encryption: Yes, under Virtru, the secret message is encrypted by the email author and decrypted by the recipient with the key created by the originator. Both ends must collaborate in order to communicate, hence the description "end-to-end". However, the key is maintained by a "man in the middle". This is not the same "end-to-end" as in, e.g. OpenPGP, which doesn't have a "man in the middle".
  2. Forward Secrecy: Virtru's claim on Perfect Forward Secrecy is simply based on the fact that the keys applied during encryption "end-to-end" are different each time. This is effective, but not rocket science when the "man in the middle" exposure is tolerated. In fact it is trivial to extend OpenPGP to accommodate that by including a "man in the middle" mechanism.
  3. Privacy: This term has been thrown around all over Virtru's web site and promotion materials without exact definition. Note that "Encryption" only guarantees the confidentiality of the messages, not the meta-data surrounding the key generation and message routing/delivery. Meta-data is commonly recognized as "private", in addition to the encryption/confidentiality of our communication. With Virtru as the "man in the middle", there is very little meta-data hidden from Virtru. Virtru as a service provider knows when the email author writes the email, where it is sent to, and the date/time of the email routing and delivery. Those pieces of information are critical to protect your privacy. Furthermore, Virtru maintains an extensive set of logs on your email activities, derives your approximate location from your IP address, and uses cookies and other technologies for effecting the online tracking[Virtru Privacy]. It makes one wonder how much your "privacy" is left for Virtru to protect.

In other words, not all secure email providers are created equal and not all catchphrases mean the same.

Virtru also claims that its products are based on "open standards". Since they are not based on PGP and S/MIME, the best we can gather about the "open standards" is the TDF (Trusted Data Format), an open-source security wrapper created by Virtru co-founder Will Ackerly. It's used by the intelligence community to secure sensitive data, we're told. It is useful only in an intra-community setting, e.g. in the IC (Intelligence Community). However, in our opinion, TDF contradicts the very concept of privacy for individuals. The so-called TDF wrapper is exactly the set of meta-data which would aid one's adversaries in deciphering it.

Quoting an article in Forbes, Virtru's future goals "revolve around securing different types of files in different types of formats across different types of technology platforms – so that any type of data you want to protect can be protected, without risk of hack, theft, or misuse". To us as practitioners of security and cryptography, these are unnecessary and dangerous goals. Like TDF, they are unnecessary, since the encryption ought to be the outmost wrapper around the confidential data, after the delivery of which the recipients would better know well enough how to decrypt it, most likely based on the "types of files". These goals are also dangerous, since complexity inflates the attack surfaces and breeds vulnerabilities. Technically, these future goals of Virtru's and its adoption of TDF appear to be errors in software and service layering, which could be harmful for private inter-personal communications.

Quoting another article from The Register, "The ongoing revelations of PRISM and other US-led internet dragnets, fueled by leaks from whistleblower Edward Snowden, may render the premise of upstart Virtru laughable." Among those laughable premises is the claim of email DRM (Digital Rights Management) protection. Virtru declares the DRM as part of its capability: "To share information safely, you need to be able to control how it is used even after you send it." This desire for DRM control after the message is sent has been proven little more than a wishful thinking[DRM], unless one introduces some third-parties who "must be able to supervise users and data, enforce DRM protection rules, and maintain control of data, even after it’s left the organization." This futile attempt to achieve DRM reflects Virtru's strong slant for enterprise control and the general lack of concern or understanding for personal privacy in its service offering.

Virtru's various products do indeed offer supreme usability. This partially explains why it is popular in public sectors, which are mandated by federal law to comply with the federal Standards for Privacy and Security under HIPAA, CJIS (Criminal Justice Information Systems), or ITAR (International Traffic in Arms Regulations) requirements that restrict third party access to sensitive data. Obviously Virtru doesn't consider itself as "third party". We don't want to speculate unjustifiably on the fact that Ackerly served for eight years at the NSA as a cloud security architect prior to founding Virtru in 2012. It does make one wonder how loosely the governmental requirements could be interpreted and the potential for many back doors, intended or unintended, in this brand of secure email.

For email consumers searching for personal security and privacy solutions, without the burden of HIPAA/CJIS/ITAR, Virtru and its likes may not meet their requirements and, more importantly, their privacy concerns.

Criptext

The Criptext email service utilizes the same open source Signal Protocol as Ai-Fi.net. Both services offer the same nice properties of end-to-end encryption with PFS. However, for full protections Criptext requires both the sender and recipients to be users of Criptext with proprietary Criptext email addresses. For sending emails to non-Criptext email addresses, the protection downgrades to a passphrase and loses the PFS. Furthermore, to not lose incoming emails, the user must stay online and logged into at least one of the "Criptext devices" installed with Criptext software. This online requirement is a severe enough defect to place this secure email product into the "non-email" category.

Does Criptext store your emails in its servers? Well, Criptext claims that it never stores them in its servers. Rather, emails just "pass through" its servers momentarily until they get delivered to the users' devices. This implies three things:

  1. Regardless how momentarily it is, it turns Criptext into a MITM. (Criptext's servers aren't open sourced and its users may not run their own Criptext instance.)
  2. With Criptext being the MITM, it has full access to your meta-data.
  3. It is not federated, since the MDA (Mail Delivery Agent), the last stop of the email routing, must be one of Criptext's servers. It also has some odd online requirement on client devices. Both defects combined push it it into the "non-email" category.

All in all, Criptext achieves high degree of email confidentiality through Signal protocol but loses compatibility with the traditional emails. Furthermore, there is very little consideration invested in protecting your meta-data. It is a commendable effort in the "non-email" category striving for PFS, but leaves a lot to be desired on the privacy protection front.

 

Ai-Fi SecureEmail

Set It Up

TDB: why Johnny can't encrypt

The breakthrough Technology of Ai-Fi SecureEmail is chiefly attributable to the foundational support by the Ai-Fi.net infrastructure. To configure and to send/receive secure emails are quite straightforward:

  1. Download the Ai-Fi Central app, bind your app to an email address, and define/configure your Ai-Fi Domain as follows:

    • Specify various "branches" to be configured under your Ai-Fi Domain. Most of our users have a single branch, their home, unless it is to be configured for a community sharing the same "privacy/social boundary". In addition to yourself, include those who are allowed to visit the various branches of your domain in the ACL (Access Control List).
    • If Ai-Fi SecureEmail is all you are interested in, ignore the above complexity for now, configure all your devices as independent branches/devices, leave everything else to defaults, and continue from step 2 below.
    • Incorporate all your personal devices into various branches
    • Create various ACLs (Access Control Lists) for your branches so that your private network resources may be shared
  2. Bind/Configure/register you email accounts from any email service providers to Ai-Fi.net as follows:

    • Prove your ownership of those email accounts in terms of account ID and password, typically through the OAuth procedure provided by various email providers without direct Ai-Fi involvement.
    • For additional anonymity, register an "Email Cover address" (more later)
    • Receive your Safety Signature of those email accounts just registered
    • Specify where the MS (Message Store) is to be located within your Ai-Fi Domain (in terms of branch devices and their synchronization options).
  3. Send/Receive your Ai-Fi SecureEmail securely and anonymously to any other Ai-Fi email accounts

These user visible functions are explained by examples in the following sections.

Under the cover, the actual key pairs for your configured email and cover accounts are created automatically and transparently through the Ai-Fi Crypto Wallet created for your Ai-Fi Central app, which has its own key pairs for managing its Ai-Fi Domain. The encryption with both the Forward and Future Secrecy is performed in the lower routing/delivery layers without involving the users. Internally all emails managed through Ai-Fi infrastructure are protected as Ai-Fi digital assets, the key pairs associated which are recorded in an Ai-Fi Blockchain to effect the pseudonymity by segregating all PII (Personally Identifiable Information) from the Ai-Fi Domain management. In other words, given an email address, there is no way for Ai-Fi.net to tell which Ai-Fi Domain the email owner controls or where the MS (Message Store) physically resides amongst all the nameless Ai-Fi domains. Only the public key of the owner is publicly recorded.

If you are interested in the innards of the Ai-Fi SecureEmail architecture and other design details, finish reading the following two sections and then look into our specification on Ai-Fi.net Service Architecture.

Ai-Fi.net Design Principle

As a first step, in order to take advantage of Ai-Fi SecureEmail, an installation of the Ai-Fi Central app is required with an associated Ai-Fi crypto wallet automatically created. This wallet is not tied to any of your real world accounts (your "Real Names"; or PII, your "Personally Identifiable Information", in the jargon of security practitioners, such as your email addresses, phone#, bank accounts, credit card numbers, social security numbers, etc.). The key pairs in your Ai-Fi account are the real actors pulling the strings behind all the Ai-Fi functions, including your secure emails. You don't need an Ai-Fi account to take advantage of the various Ai-Fi services, only the Ai-Fi Crypto Wallet stored on your mobile phones, which currently are among the most secure consumer-grade devices with hardware-protected key rings.

Ai-Fi.net open-sources all the client logic, including that used by the Ai-Fi Central app in order to attest the exclusive nature of the private keys and their handling, the only copies of which are kept in the secure store on the owner's personal phone.

For Ai-Fi SecureEmail, the owner of the email addresses to be protected must additionally set up the following:

  1. Email account specification: This is the email account to be secured and its IMAP access password. Ai-Fi.net will ensure you are the rightful owner of the email account by verifying with your email provider.
  2. Secure email cover address: As an option, this is the secret email account you create with any email service provider that is not tied to your Real Names or PII. It is provided to Ai-Fi.net so we can cut off the traceability of any emails you send.

Note that there are potentially two "From" addresses involved. The outer "From", if opted for, is in clear text in the email header in order to conform to the email standards. The real "From" is revealed only after the decryption. The Cover Address is the "From" on the outer layer. This mechanism protects the meta-data very effectively. The Tor Network is automatically adopted when the Cover Email Address is opted. The "To" addresses may be utilized to anonymize the recipients as well.

So, right off the bat, you need an Ai-Fi Crypto Wallet and provide up to two email addresses to Ai-Fi.net. The possibility of Ai-F.net becoming a bad actor or forced to comply with search warrants is addressed as follows:

  1. The Safety Fingerprint: When the email accounts are specified to Ai-Fi.net, several public/private key pairs are created and maintained on users' mobile (account) phone, along with their secure hashes derived as the fingerprints, which are communicated to all email correspondents if the users choose to. This is to prevent the possibility of Ai-Fi.net forging and faking any accounts.
  2. The email addresses managed by Ai-Fi SecureEmail are publicly displayed on the Ai-Fi SecureEmail Blockchain with the owner's public key recorded. The owner of the email address is responsible for monitoring any changes/transactions regarding their email address.
  3. Any email exchanges must be able to trace to an original TOFU (Trust On First Use) process, which typically involves a trusted exchange of identity confirmation at the first time.

There you have it. To adopt Ai-Fi.net secure email, you create a set of friendly accounts and collect their Safety Fingerprints. From then on you are in charge of your security and privacy destiny, with built-in precautionary mechanisms to eliminate even the risk of the service provider itself, namely Ai-Fi.net, still very much a third party. The encryption and email routing are fully automated and largely transparent to you.

Ai-Fi Secure Email is Based on Conventional Email Infrastructure

To get more tangible feel for Ai-Fi Secure Email, let's look into an actual Ai-Fi Secure Email configuration. It adopts conventional email infrastructure with additional facilities:

  1. Both sender and recipient own their private Ai-Fi Crypto Wallets and bind to their respective email addresses. The sending and receiving of Ai-Fi Secure Email are conducted in the Ai-Fi client software natively.

  2. To encrypt Ai-Fi Secure Email end-to-end with forward and future secrecy, the sender retrieves the recipient's email public key from the Ai-Fi Email Key Store, which is equivalent to a self-signed certificate. As a recipient, in order to enter credential data such as the key pair into the Key Store, the Ai-Fi Crypto Wallet must first prove that she or he has an access right to the specified email account. This is the only guarantee offered and enforced by Ai-Fi. However, a compromised email account or even the email service provider may circumvent this check and enter the bad keys into the key store. To mitigate this potential risk, Ai-Fi provides various verification assistances to make sure a compromised email account can be discovered. Ai-Fi Secure Email adopts the mechanism of Safety Fingerprint, which is the easy-to-read hash of the recipient's public key, and warns the sender about its change and modification history whenever such compromise might have taken place.

  3. Since the Ai-Fi SecureEmail observes the public email standards, most meta-data carried in conventional email transports having the same exposure in Ai-Fi Secure Email except the body of the email, which is encrypted end-to-end. However, the sender's and recipient's email addresses are not required to be the same as their real identities, which may be indicated and protected only in the body of the secure email. This offers the opportunity for obscuring the meta-data:

    • Only the prekeys of the "real" recipient (indicated inside the encrypted email body) are used to encrypt the email. The "From:" part of the email carries the "cover address" to obscure their identity. The email owners must have access to both email addresses.
    • The sender may use a web-based email client and send the email through Tor to anonymize the sender's IP address.

    Note that in order to compromise the Ai-Fi Secure Email system, the attacker must have illegal access to both the real email address and its "cover address". The availability of the "cover address" lessens the risks of your email service provider being utilized or ordered (by warrant) to alter your prekeys. This is especially effective if the intended email address and its cover address belong to two different email services.

  4. Once the email is securely delivered and decrypted, the recipient has the option to either leave it at MDA (Mail Delivery Agent, the last hop of the email transport) or delete it from the MDA and stash it away privately. Obviously leaving it at the MDA is always a concern without the physical possession of it even if the Perfect Forward Secrecy is maintained. The next best thing is to keep it on a "Homeserver", e.g. in the context of NextCloud, maintained and managed privately in the cloud but without the REAL physical possession. In the Ai-Fi framework, the "Homeserver" is hosted in your designated server, PC, or mobile phone, owned by you and completely in your possession. Your open-sourced personal Ai-Fi Secure Email client decrypts the email with previous dynamically-negotiated end-to-end session keys, stores it away at its designated private host and is forever yours. It may be placed in a distributed fashion and remotely accessible. Once stashed away through the Ai-Fi framework with your Ai-Fi Crypto Wallet, the pseudonymity of the Ai-Fi public keys guarantees its privacy and secrecy. There is no traceability to its whereabouts once deleted from the MDA.

 

 


References

^[DIME] 2018 DIME Architecture & Specification

^[Email Attack1] Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels

^[Email Attack2] Efail Mitigation

^[Email Attack3] 5/2018 PGP isn't broken and you don't need to disable it, says inventor

^[Email Attack4] 5/2018 Statement from PGP developers about Efail

^[Efail Postmortem] 5/2018 Efail: A Postmortem

^[Email Prekeys] 8/2013 Forward Secrecy for Asynchronous Messages

^[Going Dark] 2017 Encryption and the "Going Dark" Debate

^[NSA Breaking SSL] 3/2013 How does the NSA break SSL?

^[PGP Issues] 7/2018 The Noise Protocol Framework

^[Secure Email Review] 4/2018 Overview of projects working on next-generation secure email by Open Technology Fund

^[Virtru Privacy] 2/28/2019 Virtru Values Your Privacy and Security

^[DRM] 10/2012 LGR - History of DRM & Copy Protection in Computer Games

^[Email Spoofing] [8/2013 Forward Secrecy for Asynchronous Messages ](https://www.infosecurity-magazine.com/news/mailsploit-allows-spoofed-mails/