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
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.
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.
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.
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:
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:
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:
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:
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:
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.
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. firstname.lastname@example.org, to, e.g. email@example.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:
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.
|ProtonMail||PGP Based (CounterMail, Hushmail, Mailfence, Tutanota, etc.)||LavaBit/DIME||Virtru||Ai-Fi|
|Email Federation||No (requiring bridging)||Yes||No||Yes||Yes|
|End to End Encryption**||Yes||Yes||Yes||Yes~~||Yes|
|Key Store||At provider's||At provider's||Residing with Clients Privately||At Server||Residing only with Clients Privately|
|Private Mail Store||No||No||No||No||Yes|
|SP Metadata Protection||No||No||No||No||Yes|
**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].
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:
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.
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".
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:
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:
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.
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:
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.
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:
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 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:
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.)
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.
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:
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.
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:
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.
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:
In contrast, Ai-Fi has managed to accomplish the following goals in its secure email product offering:
Preserving the Email Federation
Foundational Support for Signal End-To-End Encryption with Forward/Future Secrecy
Warrant-Proof Service Infrastructure
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).
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.
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.
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.
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:
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.
Bind/Configure/register you email accounts from any email service providers to Ai-Fi.net as follows:
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.
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.
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.
Under Ai-Fi SecureEmail, the owner of the email accounts need to set up the following:
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:
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.
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:
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.
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.
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:
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.
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.
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.
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.
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.+
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 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.
^[Email Spoofing] [8/2013 Forward Secrecy for Asynchronous Messages ](https://www.infosecurity-magazine.com/news/mailsploit-allows-spoofed-mails/）