Resilient and Usable Multi-Device Primitives

Many secure messaging applications in use today, and end-to-end encrypted (E2EE) applications more generally, share a common limitation: they require users to maintain control over, and to keep secure, a single cryptographic identity over the lifetime of their account. That’s a long time! Anyone who has enabled notifications for contact security code changes (in, say, WhatsApp) will understand how difficult it is to keep hold of a single cryptographic identity for an extended period of time (you will be bombarded with notifications).

At the same time, multi-device support provides a number of quality-of-life features for users: easy access to your account from multiple devices, with long-term logins for trusted devices and temporary access for untrusted devices; the ability to synchronise application data and settings; a natural means to migrate your account to a new device; and even acting as an informal backup when devices are lost or break. Diagram showing the progression of Alice's account, as she adds and removes devices over time. 1. She creates an account with her phone. 2. She signs-in with her laptop. 3. Her phone is stolen, so she removes it from her account. 4. She buys a new phone and links it to her account. In this line of work, we look to initiate the study of multi-device functionality as its own primitive. One that:

Provides those aforementioned quality-of-life features: multi-device use, synchronisation, migration, and backups.
Distributes trust between a user’s devices, making it easier to maintain control over and secure their account over the long-term.
Fits into existing usage patterns, and does not require additional effort or mental space from users.

Important, yet undervalued

Having an account permanently tied to the device you created it on is not ideal. Unfortunately, the multi-device support in end-to-end encrypted applications can be frustrating, at the best of times.

Ever wondered why WhatsApp and Signal only allow a phone to be your “primary” device? Or, even, why such a separation even exists in the first place? Oftentimes, adding a second device to your account will result in some weird and surprising experiences, like:

only being able to use the account when the primary device is online,
only having partial access to my data (e.g. partial message history),
slow and buggy synchronisation between my devices,
missing features on secondary devices,
loss of your original device requiring a full account reset despite maintaining control over your account from another device!

None of these issues are commonly present in popular non-E2EE applications and, though harder to achieve, they are not inherent to the E2EE setting either. Why, then, do they so often feel like an afterthought, bolted-on after-the-fact?

Competing security goals?

It is common to find that the multi-device components of a system are so far removed from the core protocol that they serve to undermine the very security guarantees the core protocol provides. We found this to be the case in both Matrix and WhatsApp (see Secure Group Messaging in Practice). Similar issues exist in Signal, too.

Let’s take forward secrecy and history sharing, as an example. Forward secrecy is a property commonly provided by key exchange protocols that, broadly speaking, ensures that compromise of a client now does not negatively affect the security of previous key exchanges. Lifting this property to the messaging layer, we might expect that compromising a client’s state now does not reveal any information about previous messages that have already been received and deleted from the client.

Now, consider the addition of multi-device support. What if such a message hasn’t been delivered to another one of the user’s devices yet? Or the adversary, posing as the compromised device, is able to request a copy of the deleted message from an uncompromised device that still holds it? It is clear that we need to carefully consider how these two components interact, and what security properties we actually want in this context.

The focus it deserves

Our work modelling device-oriented group messaging made progress in formalising and understanding this composition (in Secure Group Messaging in Practice). But it also highlighted a glaring omission in the literature: a lack of modelling that focused on multi-device support.

It is this void we aim to fill here, by initiating the formal modelling of multi-device support as a primitive in-and-of-itself, rather than an afterthought bolted on-top of an existing protocol. In doing so, we aim to identify the interface that such functionality aims to provide, as well as the varying security properties we may require from them (depending on the usage context and trade-offs).

By providing a clear interface and security guarantees to the main application protocol, we can minimise friction between conflicting security properties and, at the least, make any issues clearly visible to the protocol designers. We aim to exploit new advances in cryptography to provide a usable and full-featured experience that is resilient to the loss or compromise of a user’s devices. We believe it is possible to make this approach more usable than traditional, non-E2EE applications which require password-based logins (as one example).

I am hoping to release some of our initial results on this project soon. If you are interested in collaborating, please reach out; there is still lots to do!