How Secure Is Your Secure Email

How Secure Is Your Secure EmailIntroductionGeneralService Providers as Attack SurfaceAi-Fi SecureEmail as a Free ServiceReading OutlineSecuring Our EmailsIssues to Consider in Securing Our EmailsSecure Email Functional MatrixFeature ComparisonsClaims to ClarifyWhat’s the Matter with PGP?The Latest Efail Attacks on S/MIME and OpenPGPMitigation of Efail AttacksSecure Email Threat ModelThreat ModelingProtonMailDIME (Dark Internet Mail Environment) and Lavabit ServiceVirtru Secure EmailCriptext Ai-Fi SecureEmail DesignRequirementsProvable Privacy Protection of Ai-FiPseudonymity for PII ProtectionApplication of TorAi-F Crypto Wallet Protection and RecoveryAi-Fi SecureEmailSet It UpInstallationMitigating the Threat Against MetadataEncryption and MetadataAuthentication and EncryptionMetadata ProtectionAi-Fi Secure Email Preserves Email FederationAi-Fi Enterprise SupportAnatomy of a Phishing AttackAi-Fi Cover AddressThe Big RevealEnterprise SolutionVouching for YourselfThe Ai-Fi Domain ModelAi-Fi.net DomainsReferences

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 free of charge for all non-commercial uses.

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:

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 offer an introduction of our Ai-Fi SecureEmail offering 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, 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:

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:

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 Metadata 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 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 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.

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/