Backchannel

The problem: “I authenticate, therefore I am”

User profiles (like your Google or Facebook accounts) are broadly used in online systems. But when applied to communication and collaboration tools, user profiles have three important shortcomings.

First, user profile systems create an attack surface for impersonation because anyone can present an identity – their own or otherwise – making it possible to fake a user profile and impersonate someone else. For example, it’s easy to change a single character of an email address (e.g., charlie@compàny.com), and copy the name and photo. In these social engineering attacks, victims are tricked to believe the attacker is trustworthy. Attackers then extract sensitive information, which could lead to professional, legal, financial, or even physical harm. These attacks are effective regardless of the strength of cryptography.

Secondly, user profile systems easily lead to context collapse, when an app brings together separate parts of a person’s life. While preparing this article, we interviewed freelance journalists working with sensitive sources across different publications. Many public-facing roles, like journalists and social workers, separate personal and professional. Unfortunately, mistakes are commonplace. For example, accidentally creating a personal document on their employer’s shared Google Drive. User profiles can lead to uncomfortable situations and put vulnerable people at risk.

Third, user profile systems often depend upon a trusted third-party. If the service is unavailable, or decides to restrict access, users lose access to their relationships and data. We want a digital authentication system that we can use in local-first tools.

What if a user profile database doesn’t exist at all, or the Internet isn’t accessible? Could we build secure collaboration tools within those constraints?

A vision for trusted digital relationships

We propose our four design principles as an alternative to existing digital identity primitives. These principles aim to shift our thinking of identity systems foundations from user profiles to digital relationships.

Relationships, not namespaces

In user profile systems, a namespace is used to avoid name collisions between multiple people that share the same name. A Twitter name, for example, must be globally unique across all Twitter users in the world. Public namespaces require significant moderation effort to prevent attacks such as impersonation, spam, fraud, and abuse. This moderation has significant financial and human costs.

But when we watch how people collaborate, we notice that users don’t always leverage these namespaces. Instead, collaborators can use synchronous points of contact to share access to their documents. In other words, there is a moment where two collaborators are in person or online at the same time. For example, Google Drive offers a “share link” feature. Users can give access to the document in a video call, bypassing the namespace altogether. Collaborative applications could leverage this already-established mental model as the primary method to share access to resources. Then, we could remove this dependency on a namespace and use relationship-based identity instead.

Recognition that resists impersonation

By recognition, we mean the process of understanding that the person you are talking to is who you think they are. User profiles force the recipient of a message to determine if the sender is genuine (or an imposter). This creates an attack surface by putting the burden of proof on the recipient of the message and pairing that with a public address or number. Instead, we’d like an identification system designed for trusted collaboration. Recognition should not require extra work on behalf of the user, but rather be a core component of the underlying system.

Phonebooks are great tools for recognition because they are local, private, and memorable. For example, if you meet someone named Becky who plays trombone, you could name her “Becky Trombone” and someone else could name her “Becky 101B.” This personal relationship is more recognizable to each individual than a single, self-described user profile named “Becky Smith.” Instead of a single global contact list (like Facebook), we want many personal contact lists (like phonebooks).

High availability and resiliency

It is worth considering the responsibility we give to custodians of our digital identities. While it is a crime for any post office employees to open mail, no such law applies to electronic messages. When we trust a third-party to maintain our identity, we entrust them with our integrity and privacy. We also give them the power to prevent access to any information associated with us.

If an identity provider disappears or decides to cancel their provider relationship for any reason, a migration is necessary. For example, in September 2020, Apple stopped providing identity to Epic Games, due to a legal battle. Everyone with an Apple identity lost access if they didn’t update their profile within a certain amount of time. In the best case, these events cause inconvenience for users and developers alike. In the worst case, user accounts are unrecoverable and they no longer have access to any of the data, app or products.

Secure and usable

Developing secure systems is a challenge, but cannot come at the expense of usability. Users have a low tolerance for complexity. Many systems with favorable security properties have failed to become widely adopted. Even so, a digital identity system should be secure (otherwise, everything might as well be publicly accessible).

Users will ignore, subvert or disable security mechanisms if they provide false positives or offer distractions. For example, users are habituated to warnings after only the second exposure to a warning. Therefore, we believe identity systems need to be less reliant on warnings and notifications. They must be resistant to socio-technical security threats, while providing certainty about what is happening. A system that is secure by design means it does not require significant effort to verify the security of their communications.

Review of existing systems

We conducted a review of existing digital identity systems, using the four above-mentioned design principles of relationships, recognition, high availability, and security usability as a guiding framework.

Email addresses, social media accounts, and phone numbers are examples of elegant global namespaces that are easily usable and understandable. However, these systems rely on a single identification number attached to a user profile. The ownership of these profiles is typically not independently verifiable. This dependency requires users to trust a single authority, which introduces security and integrity concerns. With the exception of email, these systems are typically not resilient to limited connectivity or censorship across borders (e.g., in China). Furthermore, email and phone numbers provide lucrative attack surfaces for spam and social engineering attacks.

Social proofs and distributed ledgers aim to remove dependency on a single third party. By definition, they are publicly verifiable systems. However, this property does not remove the burden of proof that a particular account is genuine – thus, social engineering attacks are still possible. These systems also exclude people who do not wish to maintain a public presence on social media, and distributed ledgers often require a level of technical expertise and legibility for account recovery. Overall, these systems still strictly enforce a global namespace, similar to phone numbers and email. The main contribution of these systems then, is who controls the infrastructure. This is interesting in its own right, but doesn’t address any of our other design principles.

PAKE (Password Authenticated Key Exchange) algorithms provide a nice solution to this problem, because they represent a relationship between two devices. Instead of a single number for an individual, it generates a single symmetric key as a digital security token, proving that an out-of-band exchange was performed at a particular moment in time. However, PAKE is still not widely used in user-facing applications, and is undergoing standardization by the IETF. PAKE may be well-suited for trusted digital relationships if we can improve usability and provide some design paradigms for real-world use cases.

Above was a summary of our detailed review; see Appendix I for more detail.

Backchannel

Having identified the deficiencies in existing systems, our 4 design principles work to:

• leverage real-world relationships
• resist impersonation attacks
• adhere to local-first principles
• be secure and accessible

Identities in Backchannel are created by redeeming a one-time invitation code. The code, much like the role of a phone number, is a lookup method to connect two people. Unlike a phone number, the code is temporary, and immediately discarded after use. Once a user passes this code to another, both of their applications generate a strong shared cryptographic secret using SPAKE2, a PAKE protocol. This shared secret represents the relationships between those two users, and is used to generate a secure end-to-end encrypted connection.

Users then assign a name for each other, rather than naming themselves. Names in Backchannel are private – i.e., they are only seen by the person who created them, just like in a phone’s contact list. Naming contacts privately is important. Because there is no self-described user profile system, a user cannot be impersonated by someone else within the application.

We acknowledge that Backchannel’s current design is not well suited to group communication, because each new contact requires its own synchronous connection to establish a name for them. Our future work will outline three approaches to design for group communication.

For now, the rest of this essay will discuss the technical design of Backchannel, as well as address common user experience challenges, and offer recommendations for use in production applications.

Invitation codes

Invitation codes have low entropy, that is, they are easy for a computer to guess. Therefore, each connection attempt should allow only one guess. If the code is incorrect, the connection fails and users have to try again with a new invitation code. To reduce the chance of an attack, Backchannel enforces that invitation codes expire after 1 minute. While we suggest 1 minute, production applications could choose a shorter or longer period of time – it just depends on the threat model.

The expiration of invitation codes gives certain advantages. There is no equivalent of “giving someone your permanent address or number” with this design. Although perhaps inconvenient for some use cases, this property can also be a strength. This design is inherently resistant to anonymous spam.

We also explored word-based invitation codes, which were something like “hazel deaf hasty.”These codes have a certain appeal, but many users preferred numeric codes. We found in user testing that word-based codes were prone to mishearing and misspelling, particularly when working across language boundaries. Given a need to localize word codes to potentially hundreds of languages and literacy levels, the benefit of numeric codes is the obvious choice for a global audience.

Once the invitee enters the code correctly, then the devices connect to each other and create a shared encryption key. Both parties should be in communication at the same time to confirm that they have both seen “Connection Secured” messages. If there is an active attacker on the network trying to guess codes, users may see an error, even if the code is correct.

Names

Once the two sides have connected using an invitation code, PAKE generates a shared symmetric key that represents the relationship. This key is a globally unique and secure identifier that can be used to create a secure end-to-end encrypted communication channel. To reuse these channels over time, each user assigns a meaningful name for the key.

These names are memorable in terms of a person’s internal recognition system of others in their social life, and thus also only visible to the person who created them. The name that the user assigns to a contact only needs to be different from the others in their private contact list; nobody else will see them.

The names in Backchannel adhere to the design principles of petname systems. A petname system is a key-value store between a memorable name and a globally unique value. You’ve used a petname system before: your phone’s contact list.

Therefore, Backchannel is a petname system between local-first memorable names and globally unique symmetric cryptographic keys.

In Security Usability of Petname Systems, the authors outline design principles for crafting a naming system. We applied the following subset of those principles to Backchannel:

• A Key must be strongly resistant against forgery.
• Each petname must be unique, so as to properly mentally distinguish entities from each other.
• The petname is only visible to the user who created it.
• If the user chooses a petname that is not unique, they should receive a warning in the interface that prompts them to pick a different name.
• The user should be able to edit a previously applied petname.
• If a suggestion is provided for the petname, the user must accept that suggestion with explicit action.
• The absence of a petname should be clearly and visually indicated.

Although Backchannel is designed for one-on-one relationships, it would be possible to extend this primitive for groups. See Group Communication to learn about crafting meaningful petname systems in group settings.

Linking Multiple Devices

A common need for most identity systems is to authenticate the same user over multiple devices. The design challenge then, is to solve how users recognize each other across multiple devices. We borrowed design primitives from popular desktop messengers, such as Signal and Telegram. In this design pattern, two devices are linked using a QR code.

One design challenge when linking multiple devices is that a contact list could diverge if names are edited individually or with different names on different devices. For example, if you edit a contact’s name on your phone, that edit should also appear on your laptop. To account for this, the open source prototype uses Automerge, a type of CRDT.

In order to combat these editing consistency issues, every device in Backchannel contains an Automerge document called the “system document,” which includes application settings and the contact list. A device is the same as a contact, except it has special privileges to also synchronize this system document. Each device-device relationship is represented by an encryption key generated through the same invitation code process as a contact. The synchronization protocol and thus the contact list is protected from eavesdroppers using AES-GCM end-to-end encryption.

Losing a device

Losing a device is a typical concern for users when synchronizing data and encryption keys across multiple devices. If someone is able to physically breach a device, they could access all of the private data on the machine, including the contact list and the encryption keys for receiving future messages. The core problem with local-first identity is rooted in the lack of a centralized server that manages device access. Typically, this server could authoritatively “lead” the synchronization process, and deauthorize devices. Since we do not require this server in Backchannel, we devised a custom method to revoke device access in case of device loss.

For clarity purposes, in this article we’ll call the device that initiates the unlink process the “leader” device (the laptop, in the below example) and the “follower” device is the device to be unlinked (the phone). The leader sends a tombstone message to all other devices and monitors their acknowledgment of the message. A tombstone is a message that is sent to all other devices to indicate that they should self-destruct and delete all their local data, including knowledge of encryption keys, contact lists, and message history. This can work effectively, but depends upon the followers receiving the tombstone message successfully.

If the follower is unable to synchronize with the leader device for some reason, the tombstone message may never be received, and the data never deleted. Therefore, this method is more secure when there is a server that forwards tombstone messages immediately when the follower opens the app, even if the leader happens to be offline.

Researchers have devised a relatively new experimental protocol called DCGKA, which is a way to approach this problem with the added security of forward secrecy. (Weidner et al., Key Agreement for Decentralized Secure Group Messaging with Strong Security Guarantees, ACM CCS 2021.)

Application Prototypes

Backchat is a chat application designed for ad-hoc communication in sensitive environments. Although it is only a research prototype (and we strongly advise against using it outside of a research context) it was designed to support people like journalists, researchers, and lawyers who often need to communicate “off-the-record.” It has no sign-in, and no accounts. With Backchat, we show it is possible to replace phone numbers with a digital identity system that is more resistant to social engineering attacks.

Here is a location-sharing prototype. This design prototype is modeled after Google’s location sharing feature, which allows you to see the precise location of your contacts through a map interface. This is an often-requested feature for on-the-ground journalists and researchers during scenarios of heightened risk. We also think it is a useful demonstration of this system’s value; precise location can be a very personal data point that some users are hesitant to share or they may want to ensure that their location isn’t accidentally shared with the wrong person.

Preview is a design prototype that demonstrates the power of Backchannel for freelance journalists, authors, or researchers. Preview allows authors to see, review, and incorporate changes from multiple reviewers without creating a different version of a document for each reviewer. Typical document sharing systems assume all reviewers are invited into a shared “space” (sometimes called team or drive). This prototype differs from typical document review applications, because reviewers do not see each other’s reviews by default.

Findings

It’s good for trusted collaboration

Overall, we find that Backchannel is good for small, trusted groups or one-on-one communication. Because each contact needs to be verified through a synchronous process, ( where users are online at the same time), it would be time-consuming to scale this invitation process to very large groups or public settings. As such, Backchannel is not a good fit for use cases that require public-facing profiles or a stable address, such as a retail business.

We suspect this method of authentication will be useful for high-risk targets inside of corporate or institutional settings, where phishing and impersonation attacks are part of the threat model. This could be an interesting case for future research.

One collaboration feature we prototyped was creating a magic URL link, rather than a code to establish the connection. These URLs, while greatly improving the user experience on the receiving end, increase the risk of phishing. This approach is common, including sending the key directly to the other person in a URL, which is how many secure applications work today, including Briar and Wormhole.app. The problem herein lies that this opens an attack vector for this key to be intercepted at a later date. It then becomes the burden of both parties to ensure that all copies of the key are deleted. One-time invitation codes via PAKE protocol reduces the risk of interception. The long-term secret is never shared or seen by any user or participant in the system.

Petnames work

Another finding was that recognition really works with someone based on your past relationship with them! We experimented with two different methods of inputting a petname – written and drawn. Reactions were surprisingly positive regarding drawing petnames, ranging from delight at the playfulness of it, to its practicality for logogram-based languages (e.g., Chinese). Handwriting also emphasises the fact that it’s the user’s own, personal representation of the relationship.

In the Backchannel interface, we use the phrase “Enter a nickname for your contact” on the screen that prompts the user to create a petname. We tested a few different design mockups which explicitly referenced petname, but the word sometimes had the wrong connotations. Petname is not a mainstream term, and is synonymous with a nickname which is more immediately recognizable. We tried “moniker” for a while but it had the same issues as petname while being even more obscure and technical.

Another thing we learned is that petnames shouldn’t be machine generated, and they must rely on some explicit user interaction. One thing we tried was keeping the code as an automatically generated temporary identifier until a petname was chosen. While marginally improving the UX, it visually tied the code with the petname which implies the code is an identity. It also doesn’t enforce the petnaming, meaning someone could simply have contact identified as “weak secret” codes, which have no meaning on their own.

Invitations require new mental models

The first concern for journalists when interacting with sources for information, is the assurance that the form of communication they are using feels comfortable and safe for the source. To this end, it is important that adding a contact is easy. The form of communication must provide confidence to the user, ensuring them that a secure channel has been opened between the two parties. We realized that while our design of “create” and “use” eventually made sense, first-time users were slightly confused by what steps to take in order to add a contact and establish a communication channel.

It remains difficult to establish whether the friction arose from an issue inherent to the paradigm, the unfamiliarity of it, or the visuals of the interface. The encryption primitives we decided to use at the start of the project and the mental model it requires from users departs significantly from the status quo. For example, a symmetric key generated by an invitation is globally unique and secure, and represents the relationship between those two devices. Each user has a different relationship with every other user, and is named differently by every person with access to that relationship. This departs significantly from user profiles, where each user names themselves and broadcasts that name to every other user.

Notably, very few users remarked that they did not need to sign up for an account to use applications with Backchannel’s relationship-based identity. Once they were presented with the fact that they did not need an account, they were pleasantly surprised and found this to be a positive part of the design.

Numeracy vs. Literacy

Our initial assumption was that words were easier to type, copy and paste, numbers easier to communicate over a call, and QR code ideal for a face-to-face meeting. We built a prototype to test all three together. Our word code prototype used a word list that is 512 words long. This is just right to split in half and use to encode two 8 bit bytes for a total of 16 bits of entropy. Splitting the word list in half ensures that the code will include two words that are different.

Word codes seemed to be preferred by the target users in our sample (journalists and researchers). However, this finding could be because our sample had high literacy rates, as writing is a majority of their day job. Participants outside of our target sample noted that numbers may be more useful. Two participants remarked that people may opt to use numbers instead of words when each participant has a different mother tongue than the other. In other words, if a common high-literacy language does not exist between two people, numbers would be easier to communicate with fewer errors.

For the word codes, initially used the PGP wordlist, but some of these words are difficult to read, say, and spell. One is also able to achieve some “unsavory” combinations that we can’t really include here without a PG-13 label. In 2016, the Electronic Frontier Foundation published an improvement to the Diceware word list that removes profanity and homophones. In May 2020, Nick Moore published a high-quality (but shorter) word list that sorts words by their pronounceability.

Overall, despite this work on improving word lists, our user testing shows that codes made of numbers are much more legible and accessible to a global population.

Group communication

When multiple people want to connect over a particular document, a problem arises: how do you securely author petnames for all of the participants in the group? This is a user experience problem that has three potential solutions. We did not prototype or test these user experience ideas with Backchannel but suspect that they would be interesting to explore for future research:

Petnames only. This option essentially enforces petnames explicitly as the only naming convention. This is the default behavior for group SMS on Android, where you will see a list of phone numbers with no names until you explicitly add names for each person. Although tedious, it does provide a layer of security against phishing from unknown contacts. To apply this to an app similar to Backchannel, one should explicitly indicate that no name has been chosen yet for that contact. The interface could also provide a view of the key in order to differentiate contacts from each other in the case there are many who are unnamed, but we suspect this interface could cause confusion.

Referrals. Referrals are alleged names recommended by a third-party. In other words, whoever created the group could choose to “gossip” their petnames to everyone else in the group. This would provide a much easier and smoother transition to selecting a petname for each person in the group. It could also mean that all names of individuals are chosen by the group. However, this breaks the principle of the petname system where petnames are local and memorable for the user. Therefore, this could be an opt-in feature with clear sign posts in the user interface about what information is about to be shared with whom.

User profiles. User profiles are self-announced names. For external use, the group together decides the name of itself to other groups. For internal use, each user profile is announced to every other user within the group. This is how Signal and WhatsApp work today. The key difference here would be prioritizing the local name over any self-announced user profile.

Known vulnerabilities

Backchannel uses similar primitives as Magic Wormhole, a Python command line tool and protocol for transferring files between two devices. Known vulnerabilities are outlined well in Magic Wormhole Documentation..

Wormhole codes can be short because they implicitly contain a common rendezvous server URL. As a result, successful operation depends upon both clients being able to contact that server, making it a SPOF (single point of failure) […] In particular, grumpy people could disrupt service for everyone by writing a program that just keeps connecting to the rendezvous server, pretending to be real clients, and claiming messages meant for legitimate users.

The version of Backchat that exists today is very much a prototype. As such, we do not recommend that anyone use Backchat for highly sensitive scenarios. One security improvement would be to introduce forward secrecy. See a demonstration of this in an example by Martin Kleppman, which combines the Signal protocol with SPAKE2.

Every linked device copies the contact list. In other words, each device has access to all shared secrets that represent the user’s contact list (i.e., their relationships with other users). Unlike the Signal protocol, we do not create a new public key for each device. This simplifies the cryptography significantly while also improving usability. This means it is possible to build more user-friendly applications by removing limitations on message history, but also introduces potential security challenges if a device is lost, stolen, or hacked.

Users in Backchannel as well as Magic Wormhole can choose their own Relay URL (called a rendezvous server URL in Magic Wormhole). This server infrastructure facilitates the SPAKE2 algorithm, and should have good denial of service (DoS) protection. A good start would be to rate-limit requests or require users to go through some CAPTCHA-style challenge to prove they are in fact a human and not a robot before using the API. Furthermore, the system administrator of the Relay could use Document IDs to see that two peers are talking to each other. However, the Relay should not have access to the encryption key, and thus cannot decrypt any of the messages between the peers.

To reduce the reliance on a single point of failure, one could create a server infrastructure that is decentralized itself, using a federated protocol like SMTP or a peer-to-peer protocol that uses a distributed hash table. However, these approaches significantly increase code complexity, and could introduce more user experience hurdles depending on the implementation. Additionally, they also introduce privacy concerns because social network metadata (IP addresses and Document IDs) would be shared with not just one server administrator, but multiple server administrators. Using a distributed proxy such as I2P or Tor would hide this information, however this approach may be demonstrably slower.

Conclusion

Backchannel demonstrates a relationship-based identity paradigm that is secure and usable. We conducted usability testing with journalists and researchers in the United States and Europe with diverse backgrounds. Overall, we find that Backchannel is well-suited for one-on-one collaboration and communication. Further research is required to support group scenarios. The Backchannel prototype allows a user to maintain the same contact list across multiple devices. Applications do not have to sacrifice key features offered by user profile systems.

Backchannel establishes identity via invitation codes exchanged simultaneously between two people. Our user testing showed that numeric codes are more accessible than word-based codes. We also recommend that these codes should expire to prevent them from being guessed by an unintended recipient. Overall, these features result in resistance to anonymous spam and impersonation. Compared to user profiles, Backchannel’s identity paradigm is more resilient to present-day forms of social engineering attack, without sacrificing usability.

Backchannel combines PAKE and petname systems. PAKE’s invitation codes provide security without requiring trust in a third party system. Petname systems provide user-friendly and secure identity management by eliminating personalized profiles that can be used to impersonate a user. Taken together, these elements offer an identity primitive that is global, unique, and memorable. The resulting system allows for totally local authentication of any message received without relying on third-parties.

With this research we propose an alternative point of view on digital identity altogether. We see great potential for relationship-based digital identity to replace user profiles in applications designed for small groups of trusted participants.

If you have questions or feedback about this work, we invite you to contact us: @inkandswitch or [email protected].

Acknowledgments

Thank you to Herb Caudill for his open source local-first relay project; Salman Aljammaz and Martin Kleppmann for architecture and cryptography advice; all of the journalists and freelancers who participated in our user testing; those who provided feedback on earlier drafts of design and writing including Adam Wiggins, Ivan Reese, Kelsey Smith, Ngọc Triệu, and Eileen Wagner; and the Ink & Switch staff that inspired new ideas and asked hard questions during the research process. Rolodex image credit: The Center for Land Use Interpretation.

Appendices

Appendix I: Full review of existing systems

Here we conduct a review of existing digital identity solutions. We use these four design principles (described in section 2) as a guiding framework:

• Relationships, not namespaces
• Recognition to resist impersonation
• High availability and resiliency
• Secure, but usable

Email

Email is the world’s second most ubiquitous communication system, lagging only behind the telephone. By some estimates, more than four billion people have email accounts, including more than 90% of the US population over the age of 15. Loss of control of an email account can have immediate and dire consequences. It’s standard for password resets to be authenticated by demonstrating ownership of an email account, so access to email implies access to almost everything else. Because of this, we consider email as more than just a communication system, but also as global infrastructure for digital identity.

Email’s federated design makes it usable across borders, globally accessible, and somewhat friendly to local-first use cases. However, its digital identity system is incredibly fragile. There is no built-in authentication mechanism. Anyone can add a series of headers to their email to disguise themselves as someone else. In the U.S. alone, seniors report losses of more than $3 billion per year to fraudsters and scammers, and many of these scams happen over email. These vulnerabilities, when paired with highly usable and familiar interfaces, present a wide attack surface. Although email accessibility makes it tempting to use as a basis for digital identity, we recommend avoiding it as a basis for trusted digital relationships.

Phone Numbers

A phone number can act both as an onboarding and authentication system. Users register their account and prove ownership over a phone number via a one-time code. Sometimes, users can opt to add an extra security layer via SMS-based 2-factor authentication. Once implemented at scale, phone numbers offer an elegant global namespace that is easily usable and understandable.

However, phone numbers are still subject to socio-technical vulnerabilities. Phone numbers rely on a single number that is public and maintained by a third-party network provider. Attackers easily spam and spoof numbers. There is no guarantee that that phone number actually represents the intended person. This can happen in a variety of ways, including a compromised network, a phone number rotation, or SIM jacking.

A phone’s contact list, however, is suitable for recognition and resiliency. By default, users name each other in a local contact book instead of creating a user profile. There is no global user profile system attached to all phone numbers. This is better than email, because if a phone number is new, it will show as a string of numbers (and not someone’s name).

Public Key Infrastructure

Public key infrastructure facilitates the exchange of public keys. This is a famously difficult process to complete in a secure manner. After exchanging keys, a sender and recipient can exchange authenticated messages. If a message’s signature does not match, an impersonation attack is likely. In reality, there are countless reasons why a user may not sign a message. For example, invite links to collaborative editors via email may not be authenticated. Furthermore, confirming a key fingerprint requires significant user cognition and attention to detail.

Key management and identity verification are hard enough. But the revocation of a key pair renders all prior messages unreadable. Complexities in key management discourage even experienced users from rotating their keys. In the worst case scenario, users may embrace their public key as a form of immutable identity. Public keys are not suitable as an identity because a long hex string is not a memorable username, and a short hex string is not secure. In the best case, companies create entire platforms around PKI, so that keys can be shared, rotated, and verified. But, this type of system relies on third-party infrastructure and is not resilient. As a result of these limitations, it is likely that users who have exchanged public keys will communicate without them.

We give PKI a poor rating for relationships because each user announces themselves, including their email and name in some cases, to a key. Users must trust that these self-announced values are correct and not impersonated. Relatedly, we provide a poor rating for resiliency because you must trust the PKI owner to maintain the integrity of these identities.

Social Proof

User profiles can be more trusted with the addition of social proof. A social proof is a public demonstration of identity supported by other people. For example, a Facebook identity with no posts and zero friends could be less trustworthy. Keybase is one user profile database where users prove ownership of other social media accounts.

While social proofs are a usable way to create trust, they are still subject to social engineering attacks. For example, attackers can scrape and copy a user’s Twitter account history and profile information. These systems are also by definition, publicly verifiable. This provides a search interface for all users. Thus, it makes it even easier to copy the likeness of another user’s profile. The burden of proof that a particular account is genuine is still on the recipient of a message.

Furthermore, verifying social proof relies on third-party servers. If you change your social media profile name or Keybase account name, all social proofs become invalid. It excludes people who do not wish to maintain a public presence on social media. This makes social proofs rather fragile for long-term use with diverse audiences.

Distributed Ledgers

Distributed ledgers are often (but not always) based on public, blockchain consensus namespaces. Any device can verify each piece of data on a distributed ledger. This structure addresses the consolidation of power in one single entity.

However, the trade-offs in these systems are significant. Publicly readable ledgers create security usability hurdles with higher stakes. If an attacker steals your secret key, anyone can claim to be you and there is little you can do about it. Furthermore, if you lose your account details or lose your device, there is no real-world “locksmith.” Most applications solve these problems by giving a copy of your keys to a third-party, or splitting keys between other people. This then leaves us with two separate attack surfaces – a trusted third party and a public ledger.

Lastly, distributed ledgers still create a global namespace and assume individual user profiles. The main contribution of a distributed ledger then, is who controls the infrastructure. This is interesting in its own right, and has some merit to improve the resiliency of particular systems, but doesn’t address any of our other design principles.

PAKE

PAKE (Password Authenticated Key Exchange), is an authentication method that establishes a strong shared secret between two parties from a short password. PAKE is often used to create secure end-to-end encrypted communication between two parties.

PAKE algorithms provide a nice solution to our authentication problem. They are more resistant to phishing, by basing authentication on real-world trust. However, PAKE is not yet widely used in mainstream applications. Research shows that PAKE implementations need to effectively communicate when failures occur, so that people do not fall back to using insecure authentication methods. PAKE may be well-suited for a digital identity system based on digital relationships if we can improve usability.

Appendix II: Related work on Petnames

Phonebooks

Popularized in email clients and cell phones, phone books are useful precisely due to their dependency on petnames. Phone numbers, although global, are not static. Phone numbers change ownership as they exist within a global namespace with relatively small entropy. The security usability principles for petnames begin to break down with long-term usage when applied to phone numbers.

When a text message arrives from a number that is not yet known, chat applications typically employ a Contact Request or Message Request.

However, WhatsApp, Telegram, and Signal try to give some hints about who might be texting. To do this, they allow user profiles to display prominently in the interface. This re-opens an attack vector for impersonation that a simple petname system, like on Android text messages, prevents.

Unfortunately, the breadth of applications that re-introduce user profiles into phonebook contact lists have made it easier for attackers to take advantage of targets through social engineering and impersonation.

WeChat expands the typical contact list to also offer not just nicknames, but tags and notes that can provide extra context and aid in searching through your contact book for a particular person.

Briar

Briar asks you to pick a nickname for yourself when you start the application. It also then asks you to create a nickname for your contact when you first add them to your contact list. This so-called nickname is private, so based on the literature this would actually be the petname, whereas the nickname is the name you called yourself when creating your account.

When the nickname and petname of your contact do not match, you see both names in your contact list. By displaying that nickname in the contact list, Briar re-introduces impersonation as an attack vector. It also increases the complexity of the interface by introducing a new mental model between the petname and the nickname. Backchannel models its naming list on a phone’s contact list, which only has one name - the petname - as the primary identifier in the contact list.

Secure Scuttlebutt

Secure Scuttlebutt is a peer-to-peer social network. Patchwork is a client for this social network that allows users to create nicknames for other people. These nicknames show up publicly in the user interface, and anyone within a certain social distance can see them. In a petname system, we would classify these names as referrals, and the user’s chosen username as their nickname. These referrals are useful in a public feed like Scuttlebutt where multiple people are communicating with each other, but not everyone knows who everyone else is. However, these nicknames could introduce an attack vector for harassment or abuse, so they should only be utilized in combination with strong moderation controls.

SyncThing

SyncThing is a file sharing application that facilitates managing multiple devices. When you add a device to SyncThing, you associate its machine-readable identifier (Device ID) with a human-readable name (Device Name). The device name is not required and could be overridden by the announced name of the device. This could introduce an attack vector if a device is able to join the network and announce itself as an innocuous name.

Appendix III: Backchannel open source library

We have published a reference implementation and proof of concept. This library is published under an MIT license and is on GitHub.

Invitation codes

Invitation codes are split into two pieces. The first third is the mailbox, and the rest is the password. The mailbox is used to discover two devices. The mailbox may be visible to anyone monitoring the network and the operator of the relay, and thus is presumed to be insecure. Because of this, the mailbox should not be in any way derivative or related to the password. The password part of the invitation should be sufficiently random, and we recommend at least 16 bits of entropy.

In the Backchannel prototype, we use a single WebSocket server to discover devices called @local-first/relay. Each device announces their mailbox to this server, called a Relay. Devices must connect to the same relay in order to discover each other. The relay then creates a stateless message-forwarding proxy between the two peers. In other words, the server does not modify the data, only re-sends any data it receives from Device A to Device B, and vice versa.

In each relay connection, peers choose a randomly-generated UserID, which is a string of 4 random alphanumeric characters. This is ephemeral and cannot be used as a meaningful identifier for a single user over time. This prevents clients from connecting to themselves and also allows them to manage different synchronization states between multiple peers.

Once two devices are connected to each other, the shared secret key is then used to end-to-end encrypt the Automerge synchronization protocol between participants.

Once a symmetric key has been created, we can re-use that key to create a secure connection. To prevent eavesdropping of this secret key, Backchannel clients create a derived hash of the key, called a Document ID. This should be a one-way hash, such as SHA 256. Similar to the PAKE protocol described above, clients use the Document ID to discover other devices. This technique enables privacy so that third parties can provide a relay service without learning any information about the contents of the conversation.

The Backchannel network protocol can be implemented in multiple ways, including using a distributed hash table, local wifi network through mDNS, Bluetooth, or carrier pigeon. The manner of communication does not matter, and third parties that route these packets (such as server administrators and internet service providers) are assumed to be untrusted participants.

WebRTC could increase security and performance, especially when sharing large files. However, WebRTC still requires a signaling server and in many cases also a TURN server, so dependency on a server (or two) at some point is still required for this method. WebWormhole is an application that uses PAKE along with WebRTC to send large files.

Database

Once a relationship is established, a Contact record is created on the local device. A Contact contains the key, the petname, and a relationship ID (the sha256 hash of the key). Chat messages are decrypted when they are received and stored on the user’s local filesystem in plain text. The Backchannel prototype assumes that the app is running in the browser, so all data is stored locally in the browser’s IndexedDB.

Nothing is stored on servers, although production applications would likely implement a backup server for increased availability. This can be done in a variety of ways, and we only offer implementation details for the prototypes we created that adhere to local-first principles. In your application, you could store information anywhere – as long as each user’s contact list is private.