[Feature] Notify about new session/linked device

[vasyugan]

Is there an existing request for feature?

• [X] I have searched the existing issues

What feature would you like?

Show a notification on the old device about any new device being connected, add a session manager where existing sessions on other devices can be inspected and deleted.

Anything else?

To connect a new device, one apparently only needs the recovery passphrase, no second factor such as a password or a user name. On the old device, no notification appears informing the user of a new device having been connected, there is also no session manager as in Element or any other messenger I know of.

This means, that a malicious intruder can read all your chats without you having any chance to notice. (unless I have overlooked someing)

I am confused because this seems like such a glaring security hole that it is very hard for me to believe that this hasn't been thought of. Is this functionality hidden somewhere or what is the rationale behind choosing this design?

[ThomasSession]

Hi there. Thanks for the message. Yeah it is something we have thought about and the main issue is that something like this would be very easy to circumvent, and so we would rather not give a user a false sense of security. A malicious user could get around this fairly easily so we would have to build the feature and tell user we can't be 100% sure about the situation. We are still considering alternatives but it isn't something that can be easily added in a way that is 100% reliable.

[vasyugan]

Hi there. Thanks for the message. Yeah it is something we have thought about and the main issue is that something like this would be very easy to circumvent

So just to make sure that I correctly understand what you are saying: Do you consider Element's / Matrix' session manager to be inherently insecure? Do you say that a malicious user can easily inject themselves if they have obtained my credentials (user name, password, passphrase) without their session being listed in the session manager? I am a total layperson, so I have no way of assessing whether such a scenario is likely or possible, I just would like to think that if it is that easy, the folks over at Element/Matrix would have thought about this.

[KeeJef]

Just to provide some additional context that will hopefully answer your question: In Session, although we have the concept of "linked devices" at the UI level, this concept doesn’t really exist at the network level. To your decentralized swarm and the wider network, "linked devices" appear as the exact same client. This is because when you link devices, you're essentially sharing the private key (13 word seed) associated with your public Account ID / Session ID.

This means the network currently has no way to distinguish whether a new device was linked or to show you a list of linked devices.

A naive approach to address this is, whenever you link a new device by sharing your private keys with it, the new device generates a unique key pair that is stored locally on the device. The device then registers this key pair and device information in a configuration message (an expiring message that contains encrypted account information on your swarm) and signs future requests to the network with this key pair alongside the shared private key. This approach would allow you to get a list of linked devices and an access log from the Service Nodes in your swarm, indicating the devices (unique keys) that accessed your swarm.

This method would prevent attackers who have access to only your 13-word seed from silently scraping new messages from your swarm without your knowledge. When they attempt to link a new device, their client will update your configuration message with information about the new device and its unique key. Even if they modify their client, your device will still request the access log from the Service Nodes in your swarm, and your device will recognize a unique key pair it didn’t previously know about, warning you of the newly linked device.

However, things become much more complicated if a sophisticated attacker gains access to one of your devices. In this case, they can scrape both the 13-word seed and the unique key from your device. They can then use these keys alongside a modified Session client to pretend to be one of your existing devices, which wouldn’t even raise an alert if you checked the Service Node access log.

There are some measures you can take to make extraction of the per device keys more difficult, such as relying on the native device’s secure enclave to generate and store per device keys. These enclaves are usually available on modern Android and iOS phones, though support is patchy on desktop devices and depends on the hardware and operating system. If the key is stored in the enclave, it becomes significantly more difficult and expensive to extract, though not entirely impossible. However, if we were to proceed with this, desktop devices would have to take a best-effort approach: trying to use their enclave (TPM) if available, but falling back to storing the per device key on in the db if not. This is something that is hard to communicate effectively to users.

There are other approaches that rely on a similar straightforward method described above but also introduce key ratcheting, which can mitigate some of the downsides of device compromise but fails to protect the account in all cases. This is what Element does, according to my understanding https://eprint.iacr.org/2023/1300.pdf. Key ratcheting is much harder in a decentralized network where client devices can never be 100% sure of the state of a conversation and ratcheted keys can be missed altogether, leading to lost messages. Element and Matrix are federated and rely on the establishment of a centralized server, which makes key ratcheting much easier.

Additionally, generating unique per-device keys has privacy implications. The nodes in your swarm would now be able to determine how many linked devices you have. Although this is a relatively minor leak since they wouldn’t know what type of devices they are or any other relevant information, they would still know that different devices are accessing the same information. Another aspect other messaging apps have better access to is IP addresses—they can tell you the different IPs accessing your account since you connect to their centralized servers directly via your IP. This can also be a clue as to whether someone has compromised your account. Your swarm in Session doesn’t have access to this information since we use onion routing to communicate with your swarm.

I believe a good direction would be to implement the straightforward approach I outlined, along with the optimistic use of the devices secure enclave. This should cover most users' use cases and will improve as operating systems get better access to TPMs and secure enclaves. However, it’s also important to find a good way to warn users when they link devices that don’t have a secure enclave/TPM. That being said, this isn’t an area of current focus for us, but I do expect us to implement something like this in the long term.