Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC4153: Exclude non-cross-signed devices #4153

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
+222 −0
Open

MSC4153: Exclude non-cross-signed devices #4153

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
a9071b1
initial draft of invisible crypto
uhoreg Jun 10, 2024
33cb6a5
use MSC number
uhoreg Jun 10, 2024
f02666f
clarifications and respond to PR review comments
uhoreg Jun 25, 2024
b2c9541
respond to review comments and add some more clarifications
uhoreg Jan 31, 2025
5e01739
fix typo
uhoreg Jan 31, 2025
010b294
additional clarification
uhoreg Jan 31, 2025
ea450d2
another typo
uhoreg Jan 31, 2025
31748ab
add cross-signing status for clients
uhoreg Feb 19, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 32 additions & 11 deletions proposals/4153-invisible-crypto.md
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

  • Client embodying these values (preferably cross platform).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that EW and EX both implement this, via their respective labs flags.

EW's setting looks like this:

image

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving @escix 's question to a thread:

I am a non-technical person, so apologies if I am not making sense in my comments.

Currently, EX uses three identity confirmation methods:

  • Use another device= This is the easiest one as all cryptography is already done in another device.

  • Enter a recovery key= This, I believe, is the Security key to obtain the encryption key from the server.

  • Can't confirm= This is to reset my message history and setup a new Security key.

If I understand properly, this MSC is to make login, identity verification and backup on the first login simple and efficient.

Login: dealt with username and password

Identity verification: Unless the persons are next to each other this will be an out-of-band confirmation. If the persons are next to each other this can be verified by scanning a QR code or something. On an out of bound scenario, this can be a phone call and confirmation of emojis or random numbers. However, in the current proposal, in the first use it is proposed to accept the identity by default. This will improve the user engagement, but can an advance section present so the above methods can be used by advanced users?

Backup Security keys: I think, by default, the encryption keys must be saved in the server and also in the device (downloaded as a file). Both can be protected with the same Security key.

So on the first login, use the username and password to login and presented with the option for identity verification with a skip button for non-technical users. Then proceed to 'backup encryption keys' with a Security Key.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your questions aren't easy to understand, but:

However, in the current proposal, in the first use it is proposed to accept the identity by default. This will improve the user engagement, but can an advance section present so the above methods can be used by advanced users?

Yes, it is proposed that users will trust other users' identity on first use, but it will still be possible to verify other users' identity explicitly via QR codes or emoji. And some applications may expose a feature where they will only send messages in rooms where all users have been explicitly verified in this way. I don't think there are any plans to support that in EX, but that would be a matter for the Element X issue trackers, not this Matrix spec proposal.

Backup Security keys: I think, by default, the encryption keys must be saved in the server and also in the device (downloaded as a file). Both can be protected with the same Security key.

I think that when you say "Backup Security keys", you mean what we now refer to as the Recovery key? (see also element-hq/element-meta#2394 (comment)). I don't think this MSC changes anything in this area.

Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# MSC4153: Invisible Cryptography
# MSC4153: Exclude non-cross-signed devices

End-to-end encryption was first introduced to Matrix in 2016. Over the years,
more encryption-related features have been added, such as key verification,
Expand All @@ -25,14 +25,20 @@ The changes below only apply to clients that support encryption.
Clients should create new cross-signing keys for users who do not yet have
cross-signing keys.

Users should have Secret Storage with a default key that encrypts the private
cross-signing keys and key backup key (if available)
### Users should have Secret Storage

Secret Storage allows users to keep secrets on the server so that they are
accessible when the user logs in to a new device.

The spec currently does not give recommendations for what information is stored
in Secret Storage, or even whether Secret Storage is available to users. A
user’s Secret Storage should contain the user’s cross-signing secret keys and
the key backup decryption key (if the user is using key backup). This ensures
that users have a more consistent experience.
that users use cross-signing and key backup on new devices.

Users should have Secret Storage with a default key (a key referred to by
`m.secret_storage.default_key`) that encrypts the private cross-signing keys
and key backup key (if available).

### Verifying individual devices of other users is deprecated

Expand Down Expand Up @@ -71,26 +77,30 @@ know that Alice’s cross-signing keys had changed, even if Bob has other device
that were previously logged in. Such a mechanism could be proposed by another
MSC.

### Room keys should by default not be sent to non-cross-signed devices
### Room keys and secrets should by default not be sent to non-cross-signed devices

Since non-cross-signed devices don’t provide any assurance that the device
belongs to the user, and server admins can trivially create new devices for
users, clients should not send room keys to non-cross-signed devices by
default. Clients may provide users the ability to encrypt to specific
non-cross-signed devices, for example, for development or testing purposes.

### Messages from non-cross-signed devices should be untrusted
In addition, users should not send secrets (via Secret Sharing) to their own
devices that are not cross-signed.

### Messages from non-cross-signed devices should be ignored by default

Similarly, clients have no assurance that encrypted messages sent from
non-cross-signed devices were sent by the user, rather than an
impersonator. Therefore messages sent from non-cross-signed devices cannot be
trusted and should be displayed differently to the user. For example, the
message could be displayed with a warning, or may be hidden completely from the
user. Again, clients may be allow the user to override this behaviour for
specific devices for development or testing purposes.
trusted and should not be displayed differently to the user. Again, clients
may be allow the user to override this behaviour for specific devices for
development or testing purposes.

## Potential Issues

### Client support

If a user has devices that are not cross-signed, they will not be able to
communicate with other users whose clients implement this proposal completely,
due to the last two points. Thus we encourage clients to implement
Expand All @@ -100,6 +110,17 @@ make it optional) until most clients have implemented cross-signing.

TODO: status of cross-signing in clients

### Bots and application services

This is a special case to the issue above, but seems to be a large enough class
that it deserves its own mention: support for cross-signing in bots and
application services may be less common than in interactive clients. When a
client fully implements this proposal, users will be unable to interact with
bots and application services in encrypted rooms if they do not support
cross-signing.

TODO: status of cross-signing in bots/application services
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cross-signing in general is relatively easy to implement, but receiving messages from bridges may be a more complicated issue: most encryption-capable bridges (i.e. mautrix-*) only generate keys for the bridge bot, not every ghost, which means messages are sent with a different user than the user who created the megolm session.

We likely have to invent some new mechanism to "delegate" crypto to another user so that clients wouldn't get scared when ghosts send messages encrypted by the bridge bot. Generating keys for every ghost would be ridiculously wasteful, the bridge is a single entity so there's no reason for it to have more than one encryption device.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you say "most encryption-capable bridges (i.e. mautrix-*) only generate keys ...", are you talking about device keys? Can you explain how megolm session distribution works with mautrix bridges? Is it something like: bridge generates megolm session, bridge bot sends megolm session to recipient, ghost sends encrypted message to room?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, exactly

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was some discussion about this in #element-x-ios:matrix.org

For clarity: the wasteful part is not the device key generation itself, but rather the resulting large number of olm sessions when clients have to encrypt megolm sessions for each ghost individually.

Matthew suggested that the ghost could create a device with no identity key (to prevent olm sessions being created) and use it to sign the bot's device.

I'm thinking ghosts will probably need a cross-signing key (because that's the real root of trust). Maybe ghosts could just upload the bot's cross-signing key? They'd have the wrong user_id, which clients could detect to realize it's a ghost user. The key could also have a special usage field or something else as an extra ghost identification. Or maybe the user_id field should be the ghost, but there could be a new bridge_bot_id field which points at the bridge bot.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, there's also another related annoying part: double puppeting, where bridge logs in with your account to bridge messages you send from the remote network using your real account instead of a ghost. Currently it works the same way as ghosts in terms of encryption: create megolm keys with bridge bot, send with double puppet.

The number of double puppets is generally much lower than the number of ghosts, so technically it would be fine to create a full e2ee session (which the user can then cross-sign normally). However, that would mean the bridge receives decryption keys for messages in all your rooms instead of only its own rooms, which is not great.

I don't think it's worth creating a separate mechanism for trusting double puppets, but at least the "upload bot's cross-signing keys to ghost" mechanism wouldn't work for double puppets. Creating a device without identity keys could work for both though

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that it's a bug that we're accepting messages encrypted using a key that we received from a different user, because that seems bad from a cryptographic point of view. So I'm not too keen to try to work around it. I also don't think that we should have bots upload cross-signing keys of different users.

If the big issue is in receiving encrypted messages, maybe the easier solution would be to add a flag in the device keys object to indicate that the device doesn't want to receive any keys?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The flag to not receive encrypted messages sounds good, that'd at least solve the double puppeting issue of receiving unwanted keys. Sending messages would still require creating olm sessions from every ghost that sends messages though

Technically there's also the option of deciding that appservices were a mistake and switching to MSC4144, but having to build duplicates of a bunch of different mechanisms like member lists and membership actions would be unfortunate

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've written MSC4261 to propose adding a flag to mark devices that don't want to receive room keys.


## Alternatives

## Security considerations
Expand All @@ -111,7 +132,7 @@ No new names are introduced, so no unstable prefix is needed.
## Dependencies

Though not strictly dependencies, other MSCs improve the behaviour of this MSC:
- [authenticated backups
- [Authenticated backups
(MSC4048)](https://github.com/matrix-org/matrix-spec-proposals/pull/4048)
will improve the user experience by ensuring that trust information is
preserved when loading room keys from backup. TODO: I think we also need to
Expand Down