SecureEmail as a Digital Asset

Digital Assets

A digital asset is any text or media that is formatted into a binary source and includes the right to use it; digital files that do not include this right are not considered digital assets. Some common types of digital file formats that are digital assets include photos, videos, spreadsheets, Word documents, PDFs, etc. In this document we focus on a different type that has strong implication to individual's PII (Personally Identifiable Information), such as the email address, mobile phone#, SSN#, credit card#, etc. Their issuance, ownership, and authorized uses are of critical monetary, commercial, legal and social importance.

We will explain how the Ai-Fi SecureEmail service is supported in protecting the email address holder's ownership, identity, and privacy of their email uses or transactions. We recommend our readers to review the highly complicated issues of email security and protection in a separate document.

The transport for Ai-Fi SecureEmail services is an implementation of the Signal protocol, supporting both online and offline key negotiations based on a pre-key store of the recipient. In addition to both the forward and future secrecy, it also affords the pseudonymity for the parties engaging in the email exchanges and prevention of any meta leakages based on the following designs:

1. Account-less Service Infrastructure: Privacy service is offered without requiring an (trackable) account sign-up. The APIs to SecureEmail services accept Tor anonymizing routing as an optional transport. The ownership of the email address is first verified (through sending and receiving verification code) and is attributed to a key pair maintained securely in user's Ai-Fi Identity Wallet, which may supply an infinite number of key pairs to achieve pseudonymity per situations.
2. Immutable Transaction Log: All public aspects of the asset are managed through a public blockchain (Stellar Network)
3. Open Auditability for Privacy Protection: Based on the immutable blockchain ledger all transaction logs are viewable by asset owners for the purposes of ownership auditing and automated reporting on suspicious activities.
4. Mobilization of Private Resources: Private network resources may be deployed (as pre-key stores, for example) to further eliminate metadata leakage.

We describe our service architecture for Ai-Fi SecureEmail in details for the rest of the document. It is anticipated that this powerful support may be generalized and extended to protect other digital assets as well.

Understanding Blockchain

The Blockchain technology, including the smart contract as a general purpose computation taking place on the blockchain, is considered the cornerstone of the touted decentralized digital infrastructure. Its technological power derives from the following guarantees:

1. It contains an immutable ledger, the alteration of which is considered intractable due to the large number of participants.

2. It enforces a set of integrity constraints:

   • Any transaction conducted on the blockchain requires the proof of ownership of the private key cryptographically matched to the account address (public key).
   • The cryptocurrencies stored with any blockchain accounts may be spent only once (against "double spending"), which is guaranteed when a new block is appended to the blockchain through the "mining" mechanism.

Based on this set of simple yet powerful properties, Bitcoin has achieved remarkable success However, it is unrealistic to expect it to eliminate or replace all existing "centralized" services, particularly in the following areas:

1. Privacy is not tenable, as it is against the public nature of the blockchain.

2. The public ledger is designed to record the activities of the real-world services and transactions, not to conduct them. There is a clear-cut perimeter between the public ledger and the real world, to just name a few:

   • The cryptocurrency wallet where the private keys are stored is not part of the blockchain. They can be kept on one's cell phone privately, or place in escrow accounts with Coinbase, Bitrated, Coinsavr, IBC Group, etc.
   • The exchange markets for cryptocurrency must be operated off-chain through, for example, the 0x protocol, which suggests the mechanism of Relayers that are squarely outside of the application perimeter of blockchain.
   • The blockchains don't operate in a utopian vacuum. They must accommodate governmental regulations and societal forces, which spawn external blockchain-related applications and secondary constructs.

Privacy and Blockchain

As explained previously, transaction privacy is not inherently supported by the public blockchain (or Bitcoin specifically). The privacy-centric Ai-Fi technology supplements the blockchain with many extended features such as end-to-end encryption, smart contracts, proprietary Ai-Fi Incognito cloud, and account-less services in order to guarantee the anonymity of our users in conducting their private social networking and protecting their privacy rights. A critical design effort made by Ai-Fi services is to reduce the Ai-Fi.net service footprint to a bare minimum and to demand due diligence on the part of Ai-Fi users for their own privacy protection. This design principle results in Ai-Fi.net's reliance on public blockchain for much of its transaction records, very thin Ai-Fi servers, recruitment of users' own network resources (Home Servers in the Home Cloud) and a relatively fat Ai-Fi client hosted on various mobile platforms as the Ai-Fi Central app.

The diagram below depicts the Ai-Fi architecture from the owner/administrator's perspective:

The users' desire is straightforward: access all their personal network assets privately and securely. All manners of authentication must be initiated from their most personal possession, their mobile phones, and managing all visitors' access rights from an ACL (Access Control List) and the TOFU protocol. The Ai-Fi Desktop will not function unless it is permitted by the owner and expressed through the Ai-Fi Central app on the mobile phone.

Fundamentally, in servicing the individuals, the Ai-Fi.net fades in the background and implements only certain critical foundational connectivities (glue logic) depicted in red-arrowed lines without involving account setup. However, for private social networking participated by multiple individuals or communities (not depicted in above picture), Ai-Fi.net offers an independent public registry rooted in blockchain so interacting parties may reach each other in a private and secure manner. As a design principle, Ai-Fi offers the minimally required glue logic so that the SecureEmail sender may discover the contact information of their predestined recipient. The actual reception of the SecureEmail interactions is separately governed by an ACL and the TOFU protocol.

In this document we will be focusing on the Ai-Fi registry implementation that supports the Ai-Fi SecureEmail where all Ai-Fi users discover the information about each other (mainly the pre-key) in order to send SecureEmail. The interactions among SecureEmail users in reaching others may be illustrated below:

Each Ai-Fi SecureEmail user is responsible for auditing the integrity and consistency of their pre-key information after publishing it on the Root Registry. Performing this auditing procedure is necessary to apply the "checks and balances" on the Ai-Fi.net as a service provider in order to prevent it from going rogue.

By design, Ai-Fi lacks the ability in recognizing any of the PII (Personally Identifiable Information) associated with those participants ("account-less") other than their email addresses. Note that a user may adopt any number of email addresses by creating additional ones when needed for the express purpose of pseudonymity. In other word, they may bind multiple email addresses to the Ai-Fi SecureEmail registry to defeat any unwarranted triangulation.

Root Registry Off the Stellar Network

Ai-Fi Digital Asset Management

• DID

  • Client Identity
  • Server Identity

• Service Discovery

• Service ACL

• Digital Asset

  • Ownership Acquisition/Transfer/Recovery
  • Smart Contract

Account-less Ai-Fi Services

Most popular Internet services like Facebook, Whatsapp, WeChat, Telegram, Google Apps, etc., almost always require an account "sign-up" before any "free" services may be rendered. This is fundamentally due to their reliance on selling their subscribers' personal data for profit while engaging in their "Surveillance Capitalism" business model. As the saying goes: "If it is free, you are the product". When you are degraded into a "product", an account set-up is a must in order for the underlying services to effect various tracking activities.

Ai-Fi.net is taking on an opposite approach. As a provider of privacy-preserving services, we intend to "rewire" the Internet in order to create a different business model. We offer straightforward, non-adulterated services for justifiable fees, without treating our users as targets to be exploited for marketable privacy data. Our business model is more oriented as a traditional public utility, providing transparent services without infringing upon the privacy rights of our subscribers.

Ai-Fi.net, as a conscientious service provider running for fees without posing as a cloak and dagger "free" service, exhibits the following characteristics:

1. Ai-Fi.net is "account-less". There is no sign-up procedure necessary. All we need out of our individual subscribers is an "Ai-Fi Identity Wallet", which is structurally identical to those wallets popularly adopted in various Blockchain based trust-less crypto currency services.
2. Ai-Fi.net adopts the trustless principles in various crypto blockchain services and goes beyond their popular functions as payment vehicles. We not only take advantage of the crypto blockchain as an immutable ledger, we extend it into a platform to support various trustless digital asset managements. Based on this new Ai-Fi platform, we are able to rewire those popular services like secure email, IM, Twitter, etc., onto our platform to preserve privacy and require no trust on Ai-Fi as a service provider. This new approach detaches Ai-Fi.net from engaging in any possible surveillance or tracking of any conceivable private data. This achievement is "provable", without the need to rely on Statement of Services or Privacy Statements.
3. We offer an unique digital cash system as a demo in our Ai-Fi digital asset management platform. All digital cashes are transferrable in an anonymous fashion, exactly the same way as for any fiat cashes. We even preserve the anonymity of traditional cash transactions.
4. For collecting fees, and more importantly, for effecting "pseudonymity", our services are rendered based on their respective contextual environments. Per different contextual environments, our users interact with Ai-Fi.net with multiple "identities", each of which are represented by a specific key pair defined through their Ai-Fi Identity Wallet. Our digital cash is offered in the same way as our Ai-Fi SecureEmail, based on our standard function set through our Ai-Fi platform. This newly created Ai-Fi platform is capable of rewiring most of our familiar Internet services.

In the following, we will be using our support for Ai-Fi SecureEmail as an example of our powerful Ai-Fi digital asset management.

Ai-Fi SecureEmail Binding to an Email Account

Root Registry Entry Specification

The digital content of an email address as an digital asset is simply its email address text, the ownership of which is tied to a cryptographic key pair stored in the wallet maintained with the Ai-Fi Central mobile app. Ai-Fi maintains an activity log for each email address, which is "rooted" to a Stellar account owned by Ai-Fi. Ai-Fi users claim their asset ownership through the email binding process, passing an email address ownership verification by Ai-Fi sending verification code to the email address and expecting the claimant returning the code correctly. The ownership may change hands as long as the new claimant is able to pass the verification process. A common case for the change of ownership is the case of a non-recoverable loss of Ai-Fi Identity Wallet (which is not really a change of ownership but rebinding to a new key pairs).

Logically, the activity log is a linked list:

, where the Head is the particular Stellar account (anchor) created and owned by Ai-Fi for the express purpose of managing the email address as a SecureEmail asset, with data entry "A" indicating the Root entry for email address, say "John.Smith@gmail.com", "B" describing the first owner including of its Stellar account (the public address of one of their IDs in the Identity Wallet), and "D" the last activity impacting the right to the asset. Data entries from "A" to "D" are listed in their timestamp order. The collection of all the activity logs maintained by Ai-Fi, including the relevant Stellar transactions, data entries, and possibly hashes for off-chain data set extensions, constitutes the SecureEmail Root Registry.

• In the Root Registry, considering only the ownership revisions, a non-root entry records the following:

  • Email address, the ownership of which is to be confirmed through mailbox verification procedure.
  • Anchor Account for receiving payments or fees for this particular Email address. It is also used to link all the history records related to the email address, regardless of the binding. As an extension or off-chain database to the Stellar Network, this is the only linkage associating the Stellar Network to related entries in the Root Registry. It is permanent in the Stellar Network once created. Ai-Fi maintains a special wallet for this large number of Stellar accounts.
  • Timestamp
  • Binding Account or the Stellar account that requests the specific operation.
  • Request Code and Arguments: the data for making the specific request (to alter the asset status), including both on-chain and off-chain data set.
  • Pre-key store (more later) designation of key negotiation materials, publicly available to all email senders.

• A binding transaction involves the following operations:

  1. Payment: Instruction for making payment to the Anchor Account
  2. Operation: Specifics to Add the new Binding Account to the list of name/value pair attached to the Ai-Fi Anchor Account.

List of Signatures includes both that for the Binding Source Account and for the specified Ai-Fi Anchor Account. Before signing the transaction, Ai-Fi verifies the ownership of the mailbox, the validity of the payment account, the fee amount, and the signatures.

The binding transaction is originally created by Ai-Fi Central, which submits it at the end of filling all the transaction data necessary to complete it.

Root Registry and Its Off-Chain Key-Value Snapshots

The Root Registry database is anchored on the Stellar Network and is immutable, constructed through Stellar transactions based on Ai-Fi specific smart contract. As the size of this key-value database grows, the bulk of it is maintained off-chain, keeping only the most recent or newer entries on chain to support the SecureEmail related resource discovery. In other words, the Root Registry periodically takes a snapshot of the database and stores the snapshots off-chain. Only new entries created between the period of snapshot-takings are maintained on-chain until their offloading into the off-chain snapshots.

The off-chain key-value store is maintained in a specific and static database. Only its checksum/hash is recorded in the Stellar Network. Since it operates on the level of raw data structure, this checksum is directly auditable by any one accessing the Root Registry.

Binding Conflicts and Risk of Forgery

Any binding request is accepted as long as the ownership of the mailbox is successfully verified and payment is made in operations described above. Multiple "owners" may make the same request and succeed in their respective transactions, with Ai-Fi maintaining only the atomicity of the processing of their independent requests. The binding may change hand, incurring cost per round of binding changes, and the last one wins out. Resolution of any detected conflicts in ownership of the mailbox in question is to be resolved by owners themselves by contacting their email service provider. Ai-Fi is only responsible to immutably record the modification requests in order to make sure all potential conflicts are reflected and discoverable through the transaction history on the Stellar leger. It is assumed that the responsibility of detecting the conflicts or unwarranted changes is on the shoulder of the true owner of the email address.

There is an unlikely but possible scenario where a compromised email account may be used to entrap unsuspecting Ai-Fi SecureEmail sender. This is only possible if the owner of the compromised email account is not a participant of the Ai-Fi community (or running Ai-Fi SecureEmail), in which case the Root Registry entry is set up by the attacker without the real owner to audit or contest its authenticity. Ai-Fi offers the TOFU (Trust On First Use) mechanism just to safeguard against this possible attack. More on this will be discussed in later sections.

Ai-Fi SecureEmail Attack Scenarios

Ai-Fi SecureEmail offers multiple layers of protection:

1. The email content is encrypted end-to-end against man-in-the-middle attack (MITM). It also offers Forward Secrecy, which requires each email delivery session to re-negotiate its session key. This must be achieved even when one end of the corresponding parties is offline.
2. The identity of the recipient is protected by a set of unbreakable key pairs based on public key cryptography. Ai-Fi adopts the same addressing scheme as the Bitcoin Blockchain technology and offers a blockchain wallet for protecting and managing those key pairs. There is no account sign-up required to establish the identity of Ai-Fi users except those self-generated key pair in Ai-Fi users' wallets. This is how pseudonymity is achieved in Ai-Fi.
3. The public key of the email address owners are discoverable through the Ai-Fi Root Registry, without relying on any CA (Certificate Authority) or other manual schemes for passing around certificates (such as the Web of Trust advocated in OpenPGP). The Ai-Fi Root Registry is built on top of a crypto Blockchain (currently through Stellar Network) as an off-chain extension and immutable (namely the entries or logs in the registry is not modifiable once entered). Its integrity is protected by frequent and regularly checking the consistency of data in the registry and constantly on the look out for suspicious alterations by the users (the stake holders) themselves.
4. Without the need of an Ai-Fi account and without involving any CA, the exposure of email metadata, or the information about how the sending/receiving of emails are conducted, including the identities of the corresponding parties, are greatly reduced. To further anonymize the email senders/recipients, the Tor routing protocol is supported strategically. The encrypted Ai-Fi SecureEmails may be sealed in multiple layers of "envelops" (Ai-Fi Cover Addresses) to further anonymize the corresponding parties.
5. Since Ai-Fi SecureEmail supports asynchronous key generation to gain Forward Secrecy, each Ai-Fi email address requires a pre-key store to prepare for dynamic key negotiation as a recipient. How and where this pre-key store is hosted is critical to the protection of metadata. Although Ai-Fi offers a default facility for those pre-key stores, the users are free to roll their own and announce it to the Ai-Fi community through the Root Registry. Maintaining a private pre-key store prevents metadata for email interactions from being leaked.
6. Since Ai-Fi doesn't support CA and is account-less, the attack surface of Ai-Fi as a service provider is greatly reduced and it offers no apparent focus for target tracking. After all, the less exposure through CA or account, the more private the Ai-Fi as service becomes. It has also successfully avoided those thorny certificate revocation issues if CA is in the path. However, the flip side is that the users must do more. TOFU (Trust On First Use) is the protocol the users of Ai-Fi must assume when the identities of the corresponding parties as reflected in their respective key pairs need to be confirmed. During the first contact with an acquaintance, the user must confirm the authenticity of the key pair rendered by the corresponding party. Ai-Fi strongly suggest to carry out this verification through some "out of band" channel, or through some communication scheme other than Ai-Fi, such as phone, popular IMs, Apple Face Time, Skype, etc. The hackers' penetration to multiple communication channels is much less likely. Once the trust for the key pairs are established through TOFU, any changes in later transactions would trigger verification steps all over again as if it is the first time.

This multi-level protection mechanism protects the Ai-Fi users from rogue email service providers. It even manages to guard against Ai-Fi.net itself by offering easy detection of any possible compromises.

The following possible attack may be mitigated through the various protection mechanisms of Ai-Fi:

Let's consider the email account access attack, which is when the access credentials (password, second security factor, etc.) are stolen or compromised. Although this is typically carried out by malicious attackers through illegal means outside of Ai-Fi framework and the email service provider is certainly a suspect as well (for instance when the email provider is under subpoena) when this breach takes place. This attack is mitigated as follows:

• If the owner of the email account is an active Ai-Fi subscriber, their corresponding Root Registry entry, coupled with the Stellar ledger, is detectably different from the data entered originally by the user. As the Stellar ledger is immutable, there is no way to alter the Root Registry data without exposing the attack by the owner of the email account.
• If the owner of the email account is not an active Ai-Fi subscriber and the attacker attach their own binding source account to the Root Registry entry, an unsuspecting Ai-Fi SecureEmail sender will successfully establish an end-to-end Ai-Fi session with the attacker. In this scenario, Ai-Fi would warn the email recipient about the fact that the recipient has never been contacted before and this first encounter warrants a TOFU (Trust On First Use) checking. We will give more details in a separate section about this later.

Root Registry's Maintenance of the Binding

All valid bindings involve Stellar payments. A successful binding has a specified validity period that expires after a defined time period per the payment/subscription type and amount, also recorded in the name/value pair of the current Binding Source Account. Once expired, any query to its associated Root Registry entry will fail.

To defeat the unwarranted collection of SecureEmail addresses, possibly for phishing or other variety of email hacking, the Root Registry demands a service fee even for read access.

Consistency Checking of an Ai-Fi SecureEmail Binding

The Ai-Fi Central goes through the aforementioned steps to establish its binding to an email address. Once successfully established, the owner of the email address regularly checks those data associated to its entry in both the Root Registry and the Blockchain. Any discrepancies or unauthorized modifications would indicate a security breach. As the Stellar network ledger is immutable, any suspicious breaches would leave detectable traces.

On the other hand, the consistency of those binding data are rigorously verified by the users who need to use those entries for sending secure emails. Before the sender of any email communication attempts to use the said account/mailbox, they verify the consistency of recorded data in both the Root Registry and the Stellar ledger. This is necessary as the Root Registry data are logically part of the Stellar ledger (but "off chain") and this checking logically holds together both parts of the ledger (on chain and off chain).

Note that all references to email addresses on the blockchain are through their hashed values. This is to prevent potential collection of large chunk of email addresses from the Stellar Network for spamming purposes.

Byzantine Split-World Attacks

Since the Root Registry is managed by Ai-Fi, which is mandated to maintain an off-chain database for the immutable Stellar Blockchain ledger, a potential Byzantine attack, or specifically the Split-World attack may be launched by no one other than Ai-Fi.net. This attack is possible if Ai-Fi is aware of the identity of users who make requests to Root Registry through the APIs managed by Ai-Fi itself. Based on its dominate position, Ai-Fi may produce separate "worlds" for the same email address based on who is interested in learning the information. Since Ai-Fi.net is the only actor who offers the tie-in of an email address to its reference entry in Stellar Blockchain, it may misuse this strategic advantage and launch the attack with ulterior motives. Note that this category of attacks is usually aimed at a specific class of targeted users. The typical solution is to create contacts among subscribing users, independently from AI-Fi, to jointly confirm and verify that there is only a single worldview through gossip protocol or similar communication schemes among clients, or to have multiple parties to jointly manage the Root Registry along with the Ai-Fi.net itself.

In the Ai-Fi architecture, there is a limited exposure of information in the Root Registry. Presently, only the Ai-Fi Anchor Account can be queried by submitting an email address, which is the only linkage between those two separate data chains, one in the Root Registry and the other on the Stellar Network. Note that this mapping table in the Root Registry is persistent and they don't change (immutable) once entered (not even affected by the changes in email address ownership). To further enhance the detectability against any misbehaviors on the part of Ai-Fi, snapshots of this mapping table is "publicly" taken periodically and offered to any third-parties who is interested in verifying its correctness and consistency with their counterparts in the Stellar Network. Any Ai-Fi client may participate in this verification process with special interest in the accounts belonging to itself.

Note that unlike the application scenario of CT (Certificate Transparency) for guarding public SSL certificates, under the Ai-Fi application scenarios the corresponding parties are socially associated and thus capable of initiating private interactions for any verification process whenever the authenticity of the other party is in doubt, among which the TOFU is frequently relied upon for this purpose.

TOFU as the Last Line of Defense

Obviously, if the owner of the email address in question is not an Ai-Fi user, all data in the Root Registry and the associated records in the Stellar network may be forged. In that case, the last line of defense is TOFU (Trust On First Use), which requires the sender of the secure Ai-Fi SecureEmail verifies and confirms that the recipient of the email can be trusted by contacting with them directly through some non-Ai-Fi channels such as other IM, Skype, Whatsapp, cell phones, etc.

A more sinister case of identity forging is the scenario where the Ai-Fi as the administrator of the Root Registry commits Byzantine attacks, specifically known as split-world attack. For instance, it may create two separate Ai-Fi Payment Accounts for the same email address, and give two different answers to the inquiries about the Root Registry entry and its associated data in the Stellar network based on who is making the inquiry. Since there is no third-party CA involved, Ai-Fi assumes the following straightforward approach to ward off against such an attack:

1. In providing its service, the Ai-Fi service administering the APIs issued by the users must not be in control of the traffic or know anything about the parties making the inquiry through the APIs. This may be partially accomplished through the Tor routing network.
2. As always, TOFU is the last line of defense. Only through TOFU the real identity of the owner of an email address may be unambiguously resolved. Any Byzantine attacks in forging the Stellar address of the email owner may be discovered by direct communication with the real owner.

Another risk the sender may face involves the possible scenario when the attacker is able to forge an Ai-Fi SecureEmail registry entry by fraudulently but successfully answering the email verification process without being the real recipient. Coincidentally the sender is sending a cold mail to the recipient without the means of performing the TOFU. For instance, hypothetically, someone writes to Edward Snowden's Gmail account without being a prior acquaintance and the SecureEmail binding could have been forged by Gmail itself with obvious ease or by some bad actor. In this risk scenario the sender is neither able nor intent to carry out the TOFU, and therefore falls outside the protection perimeter of Ai-Fi SecureEmail.