Exclude Insecure Devices | Find/Document the recomended way for bots to verify themselves

[BillCarsonFr]

As part of #2700 devices which are insecure (not cross-signed by their owner) will be excluded from sending & receiving encrypted messages. This includes bots: if bot devices are not cross-signed, they wont be able to communicate any more.

We need to document options for bots to verify themselves; interactive verification via emojis is clearly not easy for bots to implement.

Some ideas:

• There used to be a Manually verify with text option on Element Web (removed in Remove manual device verification which is not supported by the new cryptography stack element-web#28588). Supposedly the user had to manually confirm the observed Ed25519 key matched the expected key; in practice everybody blindly smashed "Continue" so it wasn't the best UX, security wise.

  We could maybe reintroduce something similar, possibly as a dev tool, slash command, or advanced option.

  Bonus points if it forces the user to paste in the expected Ed25519 key rather than encouraging poor security practices. Doing so would obviously require the bot to display the Ed25519 key, but matrix-sdk-crypto does log the Ed25519 key on startup, so that shouldn't be a high bar. We could always expose some sort of --please-insecurely-expose-me-to-a-mitm-attack option if necessary.

  Edit: this solution now tracked at Manual device verification e.g. for bots like Mjolnir #2751.

• Give the bot the recovery key (eg, via an OS environment variable), allowing it to fetch the cross-signing keys from 4S. This should be easy enough, but might require changes to bot implementations

• Create a commandline tool which will take arguments of username, password, device id, expected ed25519 key, recovery key. It logs in, downloads the device list; if the given device has the expected ed25519 key then it uses the recovery key to obtain the cross-signing keys and cross-signs the device.

• The bot exposes an alternative interface (say, an HTTPS server) which can be used to help it verify itself. See MSC3062 for a proposal here.

[richvdh]

(Manual verification was removed from the UI in element-hq/element-web#28588)

[BillCarsonFr]

First thing, it is a blocker for rolling out Excluding Secure Devices for element (moderation bots will be excluded).

At least, we need to find a way to make it super easy for IT to verify the moderation bots.

Depending on what solution we choose, could be a lot of work on the bot framework (new bindings? )

[Half-Shot]

I think for the JS based bots we need to update https://github.com/matrix-org/matrix-rust-sdk-crypto-nodejs with the correct bindings. I spoke to @andybalaam about this and he suggested the bots can cross sign with a recovery key, so we just need to expose enough API surface for that.

(And then the bot-sdk itself needs updating, but that's more trivial)

[andybalaam]

I was taking a look at updating matrix-rust-sdk-crypto-nodejs to a recent rust sdk version today. Didn't get far but chat to me if you're looking at it @Half-Shot in case I made progress.

[andybalaam]

Here is my bot using the recovery key on startup:

https://gitlab.com/andybalaam/arnie/-/blob/main/src/matrix_config.rs?ref_type=heads#L149

Note: ideally you should only do this once, when setting up the bot, so you don't need to provide the recovery key permanently in the server environment.

[richvdh]

I was taking a look at updating matrix-rust-sdk-crypto-nodejs to a recent rust sdk version today. Didn't get far but chat to me if you're looking at it @Half-Shot in case I made progress.

It might be that matrix-rust-sdk-crypto-nodejs already exposes what we need? It's not that old a rust-sdk version?

[andybalaam]

My PR for updating matrix-rust-sdk-crypto-nodejs to latest Rust SDK release is: matrix-org/matrix-rust-sdk-crypto-nodejs#44 . The next step would be to expose the Recovery struct so it can be used in matrix-bot-sdk but that is tricky because it is accessed via Client, which is not yet exposed either, and not used by matrix-bot-sdk. Maybe we can expose the underlying code in a way that fits with how matrix-bot-sdk currently works. I haven't looked into it yet, since I am fitting this work in during spare time.

[Half-Shot]

I think I need to understand how this broadly works in a client today, and then might be able to advise how that might fit in with a bot-sdk application. At the moment the bot-sdk has it's own JS client, and the rust-sdk is mostly used just for the OlmMachine logic.

[andybalaam]

#2751 is a proposed solution to this problem