How Secure Is Your Secure Email

Introduction

General

The internet is racing ahead at such a speed that some of the things we used to marvel at are starting to appear a little less so because we have gotten very used to them. Email is one such ancient wonder. It is a convenient way of contacting your friends, family, colleagues, or business associates, from afar and in a format we have all been familiar with since the invention of writing paper. It is informal, universal, acceptably reliable without guaranteeing delivery (and the convenient deniability), and asynchronous without requiring the recipients to be online. It is an irreplaceable mode of human interaction, especially in situations when you don't want to be so "instant" (as in IM).

This once killer app is so commonplace that we barely even think about it anymore, until the recent chilling discovery and other similar reports revealing that emails have become one of the most priced treasure troves and assault weapons in this age of Surveillance Capitalism. It is especially vulnerable with disastrous financial consequences if the email accounts are employed as the second factor in the 2-factor authentication scheme. Not surprisingly our Free Enterprise quickly springs into action offering a dazzling array of "secure email" products with varying degrees of cost and no set architectural style. Unfortunately most of us are not technically savvy enough to sort through the complexity in order to formulate an adoption strategy.

This blog post intends to outline the result of an informal review on popular secure email products currently on the market, to discuss their insufficiencies, and finally to introduce a new product purposely designed to preserve "Our Rights to Act Free". After the product reviews, we hope you will be convinced that there is a lot to be desired on current generation of the secure emails. We will then offer an alternative that answers those obvious challenges not addressed by any of the products we will have reviewed.

Service Providers as Attack Surface

Chief among the difficulties we consumers face when signing up for a service is the stipulation by the provider forcing us to trust their services without getting any "provable" transparency in return beyond the boilerplate privacy policy and terms of use. Based on reported incidents in the recent past, it is safe to assume that all third-party services can be compromised and often do. We are not even counting their exposure to government actors through court orders, subpoenas, search warrants, and digital wiretap. It is to our own benefit that we should prefer being left to our own devices for privacy protection, over which we have immediate and direct control, instead of relying on someone else. We must demand that all third-party providers offer auditable supports at least on the level of PCS (Post Compromise Security). Architecturally, a self-relying "fat" client ought to be preferred over "fat" server, the operations of which must be auditable. Provable transparency and auditability must be offered to achieve reliable privacy protection, with the operative word being provable.

Other than making those services accountable, the alternative design of Ai-Fi.net is to offer a "provably secure" email service, compatible with the email federation infrastructure but inherently "warrant proof" by maintaining smallest possible footprint and retaining no private data in our servers. Taking advantage of the Signal Protocol and distributing majority of the traditional server logic externally (to the fat client) and transparently based on a public blockchain for serving requests, we believe we have achieved the bulk of our goal. We even manage to eliminate the customary requirement on account sign-up to avoid entanglement with any user PII (Personally Identifiable Information). We can't compromise what we don't have.

Ai-Fi SecureEmail as a Free Service

Notwithstanding the success of our architecting an account-less/password-free, privacy-centric and decentralized trustless framework, we did hit a snag in devising our pricing model. In order to insulate Ai-Fi.net, the service provider, from any possibility of hacking into users' PII, it is not straightforward to work out a payment scheme that inevitably requires our users to submit their financial PIIs. Since there is no account to base fee collection on, cryptocurrencies may offer an option for collecting charges per request at micro increments, but are not sound enough to guarantee their anonymity, while well recognized solutions like Monero are too expensive and slow to support micropayments to be collected per service request. They also attracts plenty unwanted attention from the government bodies and their proxies.

Fortunately, through painstaking efforts, we manage to leverage many existing Internet infrastructures without needing to build our own counterparts incurring substantial expenses like email repositories and forwarding transports, which makes the cost of running our services exceedingly low. This low-cost architecture affords us the option of offering a payment-free service if we can find some modest financial support or cultivate certain commercial extensions to the infrastructure for income stream. In keeping with our belief that the preservation of all our fundamental human rights ought to be free for each and every one, we have decided to release the Ai-Fi SecureEmail, also known as PlexiMail in our Counterseal bunding, free of charge for all non-commercial uses.

Note that our SecureEmail offering has gone through many rounds of revisions and brandings, ranging from SecureEmail, PrivateMail to the latest PlexiMail. Consider them the same for the purpose of discussion in this blog.

Reading Outline

The first half of this writing is to set up some unbiased yardsticks by which various secure email products may be compared intelligently. However, after our reviewing all those products from many different angles and comparing them with our own Ai-Fi SecureEmail, we can pretty much classify them collectively as the "current generation" of secure emails. Common to all, the following are their glaring insufficiencies:

1. Email Federation not preserved: Current generation of secure emails invariably requires their subscribers to sign up with new email accounts, which are not compatible with their existing ones with Google, Microsoft, Apple, Yahoo, and such.
2. Unwarranted large footprint: This is the consequence of issue 1 above. Under a single email provider, it is easier to claim "end-to-end" encryption, but exposes 100% of your metadata to the providers, which are subject to a large number of government requests for user data. (This cited report is published in 2013. There is no reason to believe the number of requests had diminished since.)
3. Account sign-up and service pricing endangering users' (financial) PII

If you are in the opinion that those issues above are problematic and unacceptable, you are pretty much out of luck. You need to wait until current secure email industry improves and evolves to its next generation. Fortunately, we have a good news for you. Our Ai-Fi SecureEmail has taken the first step in gravitating towards the next generation of secure email services, with no fee obligation to boot. Dig deeper into the first half if you want to wade through the terrain of current secure email product offerings. For those impatient and curious readers, you can jump directly to the value preposition section of our next-gen secure email offering in the second half of the document. Better yet, after collecting some rough ideas about us, go directly to the Get Started page for experiencing it first hand.

The last part of the second half of this write-up is to introduce the general Ai-Fi architecture and explain how the SecureEmail fits into the general schema of things in terms of the Ai-Fi Domain Security, which offers the following facilities:

• The private storage space for prekeys, residing in the Ai-Fi HomeServer as a Tor hidden service.
• The backup/restore support for decryption keys of received secure emails
• The recovery passphrase repository for the Ai-Fi Crypto Wallet

Securing Our Emails

Issues to Consider in Securing Our Emails

There is no absolute security. The effectiveness of a security measure can only be assessed in relative terms. Two door locks are obviously more secure than one. But no number of locks installed on a single door can make the protection absolute. Security and privacy are relative concepts. Absolute security or absolute privacy doesn't exist.

Usability is another relative concept, which is highly subjective and critically important when a security apparatus is being evaluated. Frequently we are forced into the position of weighing usability against security. They tend to be on the opposite ends of the adoptability scale. All three concepts: security, privacy, and usability must be examined in the context of their targeted purpose based on comparative measurements in relative terms. A well engineered contraption for protecting a door does absolutely nothing to prevent break-ins through the windows. Protection mechanisms are designed for a specific set of threats.

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 looks into a few noteworthy vendors representative of their respective technologies in order to compare features and to learn the lay of the land. We introduce our Ai-Fi SecureEmail offering in the second half. In the end we hope you will be convinced that a fully private and secured email service is achievable only through the strength of a healthy and comprehensive foundation, which is sorely missing in the current secure email market.

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

• Data Confidentiality:

  

  Needless to say the content of a secure email must be kept confidential, which is usually effected by a digital lock that may only be opened by the intended recipient. Immediate follow-on questions are:

  • For a specific recipient, is this (digital) lock/key set the same for all incoming secure emails? If the answer is yes, then once someone, e.g. NSA, got hold of this key it was game over. All your previous and future "secure" emails are no longer locked after successfully picking a single lock. To protect against this single lock vulnerability, the lock mechanism must possess the property of PFS (Perfect Forward Secrecy), namely each individual email has its own lock and key pair different from those of all other emails.
  • How is the lock/key set produced? In PGP secure email standard this key is created based on the Public Key Cryptography, which frequently requires a third party to publish and maintain the public keys. In some other products, e.g. Virtru, this key is not based on Public Key Cryptography and therefore without the protection of a privately held "private key" of the key pair. The users obviously prefer to be the only custodian of their own private key, after achieving that the directory for all the public keys becomes the next thorny issue.

• metadata Privacy:

  

  The lock/key pair protects a single round of correspondence. However, even without the capability of peeping into your messages, knowing your circle of email friends collected over a prolonged timeline tells a lot about you. This "relationship map" is part of the metadata, which describes all your social footprints and associations through emails collected over an extended period of surveillance. Obviously you don't want any "third party" to learn your writing to a psychiatric clinics, visiting women's shelters, booking a hotel room next to a Las Vega casino, or contacting your counterpart of the other company in a merger negotiation. If Edward Snowden were among your correspondents, you would be on NSA's radar screen instantly. You want all your metadata protected in addition to the sensitive contents of your emails. You want your provider shields you from leaking any metadata to protect your innocence.

• Adversary Identification and Defense:

  

  The emails you sent hop around from one MTA (Message Transfer Agent, operated by Google, Hotmail, Yahoo, etc.) to the other MTA through some dynamic and widespread delivery paths before reaching the destination mailbox. Each of those MTAs may belong to some different email service providers. This flexible delivery routing scheme is what affords emails the "federation" architecture, the universal addressability of individual email addresses (more later), and a level playing field for all service providers. Unfortunately it also exposes them to any prying eyes present along the way. They are vulnerable to attackers of the following types:

  • Peeping Toms, casual or purposeful.
  • Small-time hackers conducting IP scanning, mostly over Local Networks, or phishing to steal passwords and other credentials
  • Organized attackers conducting cyber-terrorism, intelligence surveillance, cyber warfare exercises, with or without notices or warrants

  Carefully and defensively implemented email encryption is usually sufficient to ward off the first two threats above. Organizational attackers are more formidable, with the full institutional resources behind them, including the serving of search warrants. In the case where search warrants are served and complied with, the email service providers effectively become part of the attacks^{[Going Dark]}.

There is an excellent YouTube video on the confusing issues of "security" regarding several popular messenging and email applications in this YouTube video. You might find it informative.

Secure Email Functional Matrix

Feature Comparisons

With the email issues we care about more clearly defined, we will next review the myriad of architectures adopted 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 feature checklist:

• Federation: Is the secure email service capable of participating in the global email federation? Does your secure email service still conform to the existing email standards? Among all the important functions of traditional email architecture, federation is the most powerful one, which allows someone to send from, e.g. abc@gmail.com, to, e.g. xyz@hotmail.com. Unlike other messaging services in social networks or instant messengers that tend to favor a limited number of behemoth service providers like Facebook, WeChat, and WhatsApp, email federation offers a level playing field so that all email services, large and small, may coexist harmoniously through the federation infrastructure. We must make sure that the secure email service we adopt is compatible with existing email community so that we continue to benefit from this well-accepted federation ecosystem, without which you will not be able to reach all the friends in your email circle. Strictly speaking an email service that does not support federation is non-email^{[Secure Email Review]}.

• End-to-end Encryption: Is the encryption end-to-end? While your email is encrypted, it is also critical to know if it's encrypted by parties along the SMTP trips from MTA to MTA, which could be just an encrypted relay path, or if they are indeed end to end, which allows only the Author and Recipient to decrypt it and no one else. For instance, if your MSA (Message Submission Agent) is Gmail, only the first hop of submitting your email is encrypted and not qualified as end-to-end. We obviously prefer the encryption to be end-to-end and not indirectly mediated by the service providers or any third parties. However, not all "end-to-end" encryption schemes are created equal:

  • PFS: Is PFS (Perfect Forward Secrecy) offered? Usually the encryption is based on Public Key Cryptography and typically the recipient is not present to negotiate with the author of the email in real time for a dynamic session key, without which your encryption stops protecting you once your key pair is compromised, including all your past and future emails. In other words, the protection does not move forward indefinitely (hence the lack of PFS). End-to-end encryption does not automatically offer PFS.
  • Key Store: Is the CA (Certificate Authority) required or offered? Almost no email client relies on publicly issued CA certificates for authentication due to their expenses, hassle in maintenance, and the tricky issue of certificate revocation. OpenPGP or similar self-signed certificates are instead adopted for consumer-grade secure email authentication. Many secure email services store the private keys at their servers, which are retrieved by entering a password. The popularity of “Trust On First Use” (TOFU) authentication in secure email, borrowed from SSH with self-signed certificates, demonstrates significant demand for host authentication that is low-cost and simple to deploy without struggling with the "strength" of a password. While TOFU-based applications are a clear improvement over completely insecure authentication protocols, they do leave users vulnerable to even simple key directory attacks, especially in relation to the trust bestowed upon the service providers. Allowing the email owners to safekeep their own private key is highly desirable, albeit demanding additional technical sophistication in detecting possible compromises on their public keys.

• Private MS: Where in the world is your MS (Message Store)? Traditionally when we analyze cryptographic algorithms we concern ourselves with the expected inputs and outputs of the system. But real systems leak all kinds of extra information, namely the metadata, critical to your privacy. Furthermore, there are many so-called ‘side channels’ — which include operation time, resource consumption, cache timing, and RF emissions — which can often be used to extract secret key material if your MS is out of sight somewhere else. The longer your emails are out of your direct reach and under the "care" of someone else such as those cloud providers, the more attackable they become^{[NSA Breaking SSL]}.

• Metadata Protection: This is the most difficult issue to address, the lack of which is often the outcome of lacking Private MS explained above. To send secure emails without the support of federation or relying only on proprietary email routing, those emails are often required to be aggregated at the storage facility of the service provider prior to delivery. This aggregation of all emails sent from a specific "From" address leaks the private meta-information about the "To" recipients in the author's social circle. Even the Tor network will not be able to help shield your privacy, since this aggregation forces all your emails to go through a MITM (Man In the Middle). This leaked metadata. Similarly, if you are required to own a user account from a specific secure email service provider (e.g. Tutanota, Mailfence, Protonmail, or Hushmail) before sending secure email, the meta-information about your circle of email friends is also exposed to the service provider and vulnerable to search warrants. Security and privacy are all about "attack surface". This aggregation enlarges it.

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.

**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 lacks "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 (, which actually increases the likelihood when foreign entities are involved). 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 metadata 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 signed-then-encrypted messages are complicated, lack the ability to detect and reject tampering prior to decryption, offer no strongly unforgeable message authentication code, lack deniability, allow surreptitious forwarding, use outdated crypto (ElGamal, DSA, CAST5, CFB, etc), and usually have a sub-128-bit security level.

^{[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 mitigations:

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

Threat Modeling

For security and privacy protection, we need a threat model to guide our selection of tools.

The "threat modeling" is the practice of identifying and prioritizing potential threats and security mitigations to protect something of value, such as confidential data or personal information. Specifically, In securing our emails, we aim to protect our privacy and don't want our email content to be read by anyone other than its intended recipient. Moreover, there is no reason for us to allow any nonparticipants to know when and how our email exchanges within our social circle have ever taken place. Those background information is commonly referred to as "metadata", which can be as valuable as their underlying content being delivered.

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. Metadata attack: The metadata 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 metadata 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 to 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. Yet, we will demonstrate later, if architected correctly, a service provider can even make its users non-targetable and hence subpoena proof.

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.

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). There is a YouTube video laying the groundwork for discussing the security and privacy issues regarding emails, using ProtonMail as an example due to its popularity, in this YouTube video.

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.

• DIME is not compatible with a conventional mail environment supporting SMTP/IMAP. Instead, to achieve the "darkness", the newly proposed DMTP and DMAP are used in lieu of the popular SMTP/IMAP with numerous tricks in hiding metadata as illustrated in the diagram above. Simply put, DIME is NOT part of the Internet email ecosystem other than the fact that the message format follows RFC 5322. It is not capable of federating with any of the existing popular email transfer agents, one of the most attractive features of conventional email services.
• DIME relies on KS (Key/cert Server) for key (signet) management and end-to-end encryption. The KS and its supporting agents such as DNS and CA (Certificate Authority) creates trust dependency on the DIME infrastructure.
• According to the above diagram, DIME's end-to-end encryption is between the email Author and the MDA, not directly with the Recipient. This is hardly end-to-end. It obviously does not support "Perfect Forward Secrecy" either, as only the signets are involved in encryption/decryption without the dynamic key negotiation during the delivery cycle.
• There are three levels of encryption: trustful, cautions, and paranoid. It is not clear how the tradeoffs are to be made. As the email services are not typically performance critical, there is no reason not to opt for the top "paranoid" grade of security services unless that top paranoid grade costs you substantial hassle. Similar tradeoffs have been offered in the past, or were made for us by vendors to overcome resource limitation, that end in disaster. If you need convincing, just review the history of "Wireless Security" (or rather "Wireless Insecurity" more appropriately), all of which underwent many revisions from the initial ill-defined Wired Equivalent Privacy (WEP) in 1997, to WPA, to WPA2, to WPA3, (which finally reached the TLS quality). All the diversions along the way simply reflect the wishful thinking of members of the Wi-Fi Alliance. ("Wishful thinking" is the only term to describe the follies: WEP was at the outset considered as the "Wired Equivalent" privacy, which can't be further from the truth.) Loads of useless standards-writing would have been saved had TLS been adopted on the first day of launching the wireless hardware. Similar arguments can be made against DIME's three levels of encryption. See more arguments against it in our blog on security.
• It turns out that in the case of DIME, the "Paranoid" mode severely restricts the devices on which you can carry out your reading and writing of emails as the PKI key pair is localized in a single device initially without the means to securely transport it to other devices on which the user also wants to email.
• One of the reasons for offering the varying degree of "levels of encryption" is the fact that you must trust Lavabit with your email address and your credit card used to make payment to Lavabit. Your emails, your identity in terms of email address, and your credit card number are all physically in the possession of the Lavabit servers. If you don't trust Lavabit, you don't have the DIME support. (This is one of the major differences between Ai-Fi Email and DIME. Under Ai-Fi, there is no account to tie your emails to. Your emails are authenticated through some key pairs in your Ai-Fi Crypto Wallet, which make your email as secure as any Bitcoin transaction. It is not associated with any credit card, other email addresses, phone#, etc. The decryption of the incoming emails is handled by the key pair physically stored in the wallet with perfect deniability in this regard.)
• One of DIME's goals is to minimize metadata. DIME takes its cue from the well constructed Tor network to accomplish the anonymous transport of your emails with minimal amount of metadata. The question is why not just adopt the tried and true Tor network for the anonymization? Obviously current email standards pass around your email with your email address in the header in cleartext, which gives away metadata. However, you can easily obscure the "From: " part of the email by adopting an author name like "nobody", "from-nowhere", or "do-not-care" and hide the real author in the encrypted portion of the email. This is equivalent to sending an email with no sender information. In fact, Ai-Fi Email offers just such a feature automatically.
• As the DIME mail transport services hide metadata, including even the author's email address in the header, there are a very limited value-added services which can be offered, among which is the spam mail filtering that is impossible to stop even on the simple white-list basis. DDoS is another such tough issues, as the email services and their ISP cohorts have very limited clues regarding where those DDoS attacks are originated from.

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 metadata surrounding the key generation and message routing/delivery. metadata 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 metadata 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 metadata 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. It offers 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. In other words, there is no protection of your metadata. 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 metadata.
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 metadata. 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 Design

Requirements

For a service provider, the best way to offer privacy protection is not to store any sensitive user data, make all metadata transparent and public, and open-source all remaining logics so users may roll their own as functional extensions while still fully integrated with the core fabric. On the flip side, users must be able to verify the integrity of the service infrastructure that impacts them individually through user-initiated monitoring and auditing built into the fat client. Privacy data is intrinsically, well, "private", and best not outsourced to any service providers.

Although Ai-Fi SecureEmail has borrowed heavily its encryption scheme from Signal Protocol, all other Ai-Fi foundational services designed to support above requirements are independently designed. Clearly Signal has set a standard for messenging applications when we think about concepts like privacy, security, and trust, but we think Ai-Fi.net has managed to move the needle forward in a significant way relative to the tremendous progress made by Signal:

1. Comparing with XMPP or Matrix Network, Signal does not support federation. Users create their own private social circles enclosing only those who are conscious about privacy and security willing to adopt Signal app.
2. Signal starts off requesting users to sign up for an account tied to their mobile phone numbers. In other words, at least one PII is exposed unless the users go through the hassle and expenses of acquiring a burner phone. On the other hand, it is straightforward for a user to get a "burner" email address independently from all their other personally identifiable email addresses. The pseudonymity of Ai-Fi SecureEmail is well preserved.
3. Although Signal Messenger as a service nobly promises not ever to allow government to obtain access to Signal user data, still there are real data of interest to those government actors being processed (not necessarily collected/recorded) by Signal. A brief case history from Signal's perspective may be found here. However, the government would not have been able to even issue a sensible subpoena if Signal did not tie user accounts with their phone numbers. Once a PII is exposed, it subsequently puts a lot more metadata in jeopardy. An account-based service invariably begets undesirable consequences.
4. Signal open-sources all its codes, including those running on the server side. However, without the ability to easily "attest" their server logic, Signal subscribers must build up a certain amount of faith on Signal as a provider. Alternatively, Ai-Fi SecureEmail takes cue from Blockchain technology and places most of its processing through a blockchain-based Blockchain Registry whenever sensitive user data are involved, such as the contact discovery and prekey store locating. It also makes the ownership of those data auditable by individual owners themselves (through their fat clients). The email exchanges and their key negotiation take place outside of Ai-Fi services. Unlike Signal, Ai-Fi as a service provider is unlikely to be subpoenaed when it has so little to offer.

In contrast, Ai-Fi has managed to accomplish the following goals in its secure email product offering:

1. Preserving the Email Federation

2. Foundational Support for Signal End-To-End Encryption with Forward/Future Secrecy

   • Asynchronous Messaging
   • Prekey Store: Prekey storage may be either delegated to Ai-Fi cloud or managed by individual users by supplying their own storage spaces for total independence from Ai-Fi as a service provider. One of the options is for users to deploy their own prekey store as a Tor hidden service, on a HomeServer under the Ai-Fi Domain model.

3. Metadata Privacy

   • Pseudonymity: The email address to be secured under Ai-Fi.net is the only exposed/published pseudonym, completely insulated from all other PIIs of the email address owner. This requirement of disassociating the email address from all other PIIs of the owner is not compatible with the prevailing practices of any email service providers, which invariably start off demanding an account sign-up. This service account creates a new attack surface and potentially may turn into a new PII, which is made worse if a payment is required that link the email account with owners' credit cards.
   • Account-less: By design, an account is created to track its owner (for whatever reasons), which is obviously counter to the wish of the owner who wants to reveal as little as possible. It is made worse if it ties in to a payment scheme as it typically does.

4. Warrant-Proof Service Infrastructure

   • Although not as decentralized as the Bitcoin blockchain, by not maintaining user accounts and any PIIs, there is no identifiable persons or things recorded by Ai-Fi SecureEmail services to be seized by any issuance of warrant.

5. Auditability

   • Certificate Transparency
   • Ownership Wallet
   • Monitoring and Auditing of Ownership Changes

Provable Privacy Protection of Ai-Fi

The diagram below illustrates the principle of operation for the asynchronous Ai-Fi SecureEmail exchanges:

In accord with its design principle, the Ai-Fi SecureEmail relies on a "fat" client for users to conduct their protected email sessions, with most glue logic tied in with the public blockchain-based SecureEmail Blockchain Registry. The Ai-Fi services are just a bunch of microservices enforcing a limited number of open-sourced integrity constraints such as initial email account verification, service request routing and prekey store locating, with all user credentials and session data (keys) published on the Ai-Fi Blockchain Registry, a trustless and decentralized blockchain application. Ai-Fi.net firmly believes that privacy and metadata are best not escrowed with any service providers, including Ai-Fi.net.

On sending, once the recipient is discovered and the key materials are obtained through the Blockchain Registry, the email content is encrypted by Ai-Fi Central and sent to the sender's MSA (Message Submission Agent) to be delivered to the recipient's MS (Message Store, aka Mailbox), taking advantage of the global email federation infrastructure. Additional side benefits of integrating with the email federation is the coattail effect of operating under a large and well-run public email provider in terms of delivery efficiency, storage reliability, and even the protection against DDoS (Distributed Denial of Service).

Pseudonymity for PII Protection

If a user "binds" their Ai-Fi Central App to an email address which has been used, published or even compromised in the past, Ai-Fi SecureEmail can only offer encryption/confidentiality for their email exchanges. Anytime that email address appears in an email header, its metadata ought to be considered vulnerable and insecure. To obtain the full protection to your metadata, the user is advised to procure a "burner" address (more later).

In the context of Ai-Fi SecureEmail, the ownership of an email address under Ai-Fi is "bound" or attached to the Ai-Fi Crypto Wallet created when the Ai-Fi Central App is first installed. The key pairs in the Ai-Fi Crypto Wallet is as close as it gets to something resembling "identity" without implicating any PIIs. One of the cryptographic key pairs in the wallet is designated as the "owner" of the email address. This ownership construct is very close to that of the Bitcoin's, but with an notable difference. The exchanges of Ai-Fi SecureEmails, unlike Bitcoin transactions, are not being tracked or published by the Ai-Fi Blockchain Registry, which operates on the meta level working with credential-related metadata exclusively.

Application of Tor

Ai-Fi.net service APIs are all in HTTP; Tor is extensively applied throughout as part of the foundational services. Coupled with the account-less nature of the services, there isn't any identifiable object for Ai-Fi to attach its tracking implements on even if it wanted to.

In the case of deploying a dedicated/private prekey store, users may integrate it into the Ai-Fi HomeServer and take advantage of the option of configuring it as a Tor hidden service running behind a private/home firewall or NAT.

Ai-F Crypto Wallet Protection and Recovery

The Ai-Fi Wallet, built into the Ai-Fi Central to be self-managed, is a substitute for the service account typically required by just about all the digital services. This crypto wallet needs to be protected by Ai-Fi users themselves, including the wallet recovery seed and private keys. This is the price to pay for not surrendering your PIIs to any third parties when interacting with any third-party services. It is also what is customarily demanded of anyone who dabbles in cryptocurrencies. For this requirement, Ai-Fi.net offers a service that stores your secrets in incognito mode, retrievable only through a cryptographic key pair generated by a combination of passphrase of guaranteed minimal strength and client-side salt. Due to its supreme function and the incognito nature of its design, we have a detailed write-up on this utility.

Ai-Fi SecureEmail

Set It Up

Installation

The breakthrough of Ai-Fi SecureEmail design is chiefly attributable to the foundational support by the Ai-Fi.net infrastructure which works in the background, unseen but critical to the daily operations. With most of the complexity shielded, the actual configuration and sending/receiving secure emails on the other hand are quite straightforward:

1. Download the Ai-Fi Central app, bind your app to an email address. This email address used in this binding process acts as your Ai-Fi Identifier. If pseudonymity is desired, one may opt to create a brand new "burner" email address for operating the Ai-Fi Central app.

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 involving Ai-Fi service.
   • For additional anonymity, register with Ai-Fi.net for 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 later sections.

Under the cover, the actual key pairs for your configured email and cover addresses 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 private 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 with which are recorded in the blockchain-based Ai-Fi Blockchain Registry 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.

Mitigating the Threat Against Metadata

Ai-Fi SecureEmail encrypts your email end-to-end. Ideally, for extra high metadata privacy, you may like to consider acquiring a secret and separate email account, not tied to your Real Names or PII, in order to operate your SecureEmail pseudonymously. To cut off the traceability of any emails you send or receive, we'd suggest the acquisition of a new "burner" address, which is like a "burner phone", acquired for a specific purpose. Its existence is known only to its intended audience under a specific context for a specific period of time. Nowadays signing up for a new email address is fairly straightforward and free. Just make sure you don't allow this new address to be linked with any of your PIIs and your other known email addresses. This article offers a few practical pointers for acquiring a burner address.

Keep it in mind that any metadata protection scheme has a life cycle in accord with the growth of your social and business circle. It warrants frequent review and renewal. Injecting purposeful "disinformation" when applying for a new email address will further protect your privacy. Also, make sure your email client does not attach your IP address to the mails you send. Nowadays, most popular email clients (gmail, outlook, etc.) don't record the sender IP address anymore. A "burner" email address can be quite effective in hiding your identity in sending or receiving emails.

Encryption and Metadata

Authentication and Encryption

As described, in order to take advantage of Ai-Fi SecureEmail, the installation of the Ai-Fi Central app is required in order to provide a home for your encryption key pairs in the Ai-Fi crypto wallet built into the app. 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 (frequently used and tied to many of accounts established in the past), phone#, bank accounts, credit card numbers, social security numbers, etc.). The key pairs in your Ai-Fi Central app are the real actors pulling the strings behind all the Ai-Fi functions, including your secure emails, with the customary backup/recover functions. This construct based on cryptographic key pairs is identical to those made popular by all cryptocurrencies. 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 copy of which is kept in the secure store on the owner's personal phone with secure backup support.

Metadata Protection

Under Ai-Fi SecureEmail, the owner of the email accounts need to set up the following:

1. Email account specification: This is the email account to be secured and its IMAP access password. Ai-Fi.net, coupled with the support of your the Ai-Fi Blockchain Registry will ensure you are the rightful owner of the email account by verifying with your email provider in a publicly verifiable manner and attaching a cryptographic key pairs to support your ownership.
2. Secure email cover address: This is the address offered by Ai-Fi.net for the express purpose of mapping the recipients of any incoming emails from their "cover addresses" to their intended actual ones. It is in the format of xxxx@ai-fi.net and will be first delivered to a server provided by Ai-Fi.net, which in turn forwards it to the real recipient. This is to cut off the traceability of your emails from the provider of your MS.

The Tor Network is automatically adopted when the Cover Email Address is opted. Under Ai-Fi SecureEmail, if the sender adopts a "burner" address and writes to a cover address, both the content and its associated metadata will be greatly obscured.

So, right at the outset, you need to create an Ai-Fi Crypto Wallet and provide up to two email addresses to Ai-Fi.net. The possibility of Ai-Fi.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 Registry Blockchain/Ledger with the owner's public key recorded. The owner of the email address, namely your Ai-Fi Central App, is responsible for monitoring any changes/transactions regarding their email address.
3. The authentication must be originated from the initial TOFU (Trust On First Use) process, which typically involves a trusted exchange of identity confirmation at the first time. It is assumed that personal and private interactions are conscientiously exercised to establish the first successful TOFU in the beginning.

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 Preserves Email Federation

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 metadata carried in conventional email transports having the same exposure in the context of Ai-Fi SecureEmail except the body of the email, which is encrypted end-to-end. However, the sender's and recipient's SecureEmail addresses are not tied to any PII, which may be revealed only in the body of the secure email. This offers the opportunity for obscuring the metadata:

   • Only the prekeys of the "real" recipient (indicated inside the encrypted email body) are used to encrypt the email. The "To:" part of the email carries the "cover address" to obscure their identity.
   • The sender may send the email through Tor to anonymize the sender's IP address.

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 without possessing it physically is always a concern even if the Perfect Forward Secrecy is maintained. The next step up 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" may be hosted in your designated server, PC, or mobile phone, owned by you and completely in your possession within your protected Ai-Fi Domain. Your open-sourced personal Ai-Fi SecureEmail 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 or even structured through Ai-Fi as a Tor hidden server. 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.

Ai-Fi Enterprise Support

The enterprise support for Ai-Fi SecureEmail in the commercial, institutional or ecommerce settings is different from the consumer version due to its large data volume and the complexity in maintaining a commercial entry in the Ai-Fi Blockchain Registry. Contact Ai-Fi.net for any enterprise support if you are interested in learning more.

In this section we will document some fragmentary use cases which may be of interest to enterprises.

Anatomy of a Phishing Attack

As a practical matter, taking a recently documented email phishing attack as example, your SecureEmail simply will not fall victim to this rather sophisticated phishing attack. Ai-Fi SecureEmail will duly warn its users about those unsolicited emails from an unknown sender regardless how authentic looking it appears at the first phase of TOFU.

Ai-Fi Cover Address

The Big Reveal

Back in 2019 there was a news coverage on how Google has been recording our online shopping play by play for the last 16 years, in the pretense that it allows us to manage our purchase records better. It is quite strange this unsolicited help from Google was not offered to us until after its revelation by CNBC after 16 years of diligence by Google "on our behalf". This whole incidence was a wake-up call to quite a few of us.

Taking advantage of the full integration of Ai-Fi SecureEmail into our current email infrastructure, you can notify your favorite ecommerce sites and change your email address to a "cover address" which maps back into your original email account. Upon receiving the email from your e-merchant, the Ai-Fi forwarder for your cover address will restore the recipient address and encrypt the email before delivering it to your email account. This will eliminate the Google surveillance on your purchases once and for all.

Enterprise Solution

It is not difficult to see if a merchant chooses to install the Ai-Fi SecureEmail Enterprise inside of its firewall, which delivers ecommerce correspondence to its customers directly end-to-end without going through the Ai-Fi Forwarder, there are additional benefits to its customers, such as phishing avoidance, shorter delivery path, doing away with cover addresses, and even eliminating Ai-Fi forwarder as a possible surveillance station.+

Vouching for Yourself

Ai-Fi.net encourages all ecommerce sites and enterprises to add in the "Sign In with Ai-Fi Security" button for granting access to their website to all Ai-Fi users.

From the perspective of the Ai-Fi users, it is password-free, self-managed single sign-on utility without the risk of leaking private data or being tracked, that encourages their continued interaction with the website. For the website itself, this privacy guaranty would positively increase its conversion rate. It also helps to rule out any MITM (Man In the Middle) hijacking the commercial correspondence between the website and their customers, which reduces the attack surface, protecting the enterprise itself and their customers at the same time.

This is how the email address may be safely used as the a factor in multi-factor authentication. It requires the customer to involve their mobile phones through their Ai-Fi Wallet to vouch for their identity without revealing their phone number, a highly cherished PII. Only information on the Ai-Fi Blockchain Registry ledger will be utilized to assist the log-in with a website, which requires the target Ai-Fi Wallet to answer a identity challenge through its private key. If Cover Address option is selected, an existing Cover Address or a newly created one will be tied and recorded by Ai-Fi Central to the specific vendor/enterprise.

If the website is motivated to add Ai-Fi custom code to assist the standard OAuth protocol, this "Sign In with Ai-Fi Security" button may be turned into an End-to-End single sign-on solution, applicable both to the ecommerce sites and to work under any enterprise settings.

The Ai-Fi Domain Model

Ai-Fi.net Domains

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 tool sets. The advanced technology of Ai-Fi.net affords our users the maximum level of privacy and security, achieved at the least amount of threat exposure 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 unproven trustworthiness, 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 due to the fact 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 email address 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 to 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 have examined various secure email products, analyzed many issues those products have been struggling with, and concluded it with the introduction of our Ai-Fi SecureEmail that answers many difficult security and privacy challenges based on the foundational support through 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.

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/）