SecureEmail as a Digital AssetDigital AssetsUnderstanding BlockchainPrivacy and BlockchainRoot Registry Off the Stellar NetworkAi-Fi Digital Asset ManagementAccount-less Ai-Fi ServicesAi-Fi SecureEmail Binding to an Email AccountRoot Registry Entry SpecificationRoot Registry and Its Off-Chain Key-Value SnapshotsBinding Conflicts and Risk of ForgeryAi-Fi SecureEmail Attack ScenariosRoot Registry's Maintenance of the BindingConsistency Checking of an Ai-Fi SecureEmail BindingByzantine Split-World AttacksTOFU as the Last Line of Defense
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:
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.
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:
It contains an immutable ledger, the alteration of which is considered intractable due to the large number of participants.
It enforces a set of integrity constraints:
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:
Privacy is not tenable, as it is against the public nature of the blockchain.
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:
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.
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:
In the following, we will be using our support for Ai-Fi SecureEmail as an example of our powerful Ai-Fi digital asset management.
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:
A binding transaction involves the following operations:
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.
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.
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 offers multiple layers of protection:
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:
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.
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.
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.
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:
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.