Ad-hoc Authentication and Contextual Identity

Authentication in cryptography tends to rely on rigid notions of identity. That is, we assume there exists a well-known mapping from a person to an identifier, then to a long-term public key, and work our way from there forwards. This baseline assumption works well for large organisations, such as in an enterprise, the government or military, because there exists one or more central parties that can be trusted to maintain these mappings. But there doesn’t exist an analogous trusted party for normal, everyday people. We investigate alternative formulations of authentication in cryptography that do not rely on global identification schemes, favouring localized or contextual authentication. Taking this to the extreme, we ask whether it is possible to provide strong notions of authentication without any shared notion of user identity, at all.

This is a broad problem space with many avenues for exploration. We consider:

Protocols that provide secure connections without encoding any notion of identity whatsoever, enabling users to authenticate one another in an ad-hoc fashion.
Protocols that enable people to build local identities that are specific to a particular context, without the need for a globally meaningful identifier to back them.
Protocols that maintain a single, long-term user identifier using only ephemeral key material, i.e. without the need to maintain a single, long-term cryptographic identity to go along with it.

This work is related to, and takes inspiration from, both the key transparency and key exchange literature. While key transparency traditionally works to secure the key distribution within the system depicted above (i.e., it assumes that users have a pre-agreed upon understanding of one another’s identifiers, then works to secure the distribution of long-term keys for those identifiers), we look to rid ourselves of some (or all) of these requirements.

1. Ad-hoc Authentication

Consider the following scenario. You and I know each other in real life, and would now like to have a secure video call. But we do not know each other’s public keys (gasp!), email addresses, or even phone numbers. Or, maybe we do, but we just don’t care: I already know who you are! I don’t need a company, government, or whoever, to tell me. Can we still build a secure connection despite my stubbornness?

This diagram depicts four family members chatting within a video call on a laptop, each of whom is identified with an email address. This family doesn't need a third party (like their email providers) to tell them who they are speaking with. Yet, the standard solution requires them to do so, if they want confidentiality.

2. Contextual Identities

Other times, it may just be that our use case doesn’t quite fit into the notion of identity assumed by this conventional model. For example, in online communal spaces such as Discord servers and Matrix communities, users traditionally identify one another by local identifiers specific to that community.

Diagram showing two secure spaces, one named "Tight Knits Community" and another called "Climbers Anonymous". Alice and Bob are able to connect to these spaces securely, but under local identifiers. For example, Bob is known as FairIsleQueen in the knitting community, and OffWidthMad in the climbing community. Despite this lack of global identity, their connections are secure.

Without a means to relate someone’s local identifier to their wider, real-world identity, we may ask: what purpose could an authentication guarantee serve? Rather than securing the user identities, we aim to secure the space itself, ensuring that any honest client’s connection to any particular online space is secure (even against a dishonest client sitting in-between). By securing each user’s connection to the space, we can then build secure connections between those users within that space. This secure space then provides a means for people to connect and build locally-relevant identities within that space.

3. Long-term Identities without Long-term Keys

In other circumstances, it may be the case that a user has a well-known public identity, but it may not be viable or convenient to maintain the security of a long-term cryptographic key. Here, we study the combination of ephemeral keys generated at time-of-use with an auditable log of an accounts’ usage.

This approach is already used in the wild. The Sigstore ecosystem, which aims to support software supply chain security, uses this approach to avoid the need for developers to keep hold of a long-term key to sign their software. In this system, developers are identified via an account on an OAuth provider, and are issued short-lived certificates at the point-in-time where they are signing a new release. To protect against a misbehaving certificate issuer, each certificate is added to an auditable log. Then, signatures are only considered valid once the associated certificate appears on the log.

We consider whether it is possible to apply a similar approach to consumer messaging applications, online video calls and more. We ask whether this is viable, and look for solutions to the usability, privacy and security issues that it brings. One pertinent example is the resulting loss of control, which we trade for convenience and the ability to detect misbehavior (rather than stop it outright). Of course, since service providers currently control the distribution of keys, it could be argued that we already lack this control over our identities, this approach just highlights the issue!

Interesting constructions to build

Solving these problems (1-3) in the real-world likely requires solving some interesting problems in the design of performant, privacy-preserving auditable logs. Do feel free to get in touch if this is work you are interested in.