[WIP] QR codes, symmetric encryption, and a new securejoin protocol for broadcast channels

[Hocuri]

Part of #6884.

This will make it possible to create invite-QR codes for broadcast channels, and make them symmetrically end-to-end encrypted.

I posted the benchmark results at #6884 (comment)

Overview of the protocol when both sides have multi-device

The technical design

The QR codes / invite links and the network protocol build on the securejoin protocol in order to secure broadcast channels against MitM attacks, to securely exchange key material, and to add a member to the broadcast channel.

The mentioned securejoin protocol has 4 steps of exchanging messages. Rather than using the same protocol for broadcast channels, I will implement an improved protocol consisting of only 2 steps, described below. I will call it Securejoin v2.

The securejoin v2 protocol has these advantages over the old protocol:

• Less complexity (the protocol is now completely stateless on both sides except for creating the chats, and no 'shortcut' if Bob already knows Alice's key)
• Faster (fewer messages need to be exchanged)
• Slightly smaller QR codes (no need for a separate INVITE token)
• No unencrypted messages at all

If Securejoin v2 turns out to work nicely for broadcast channels, we can also use them for group and 1:1 invites, and remove the code for securejoin v1.

The QR code / invite link scheme

I will call the channel owner's device "Alice" and the device of the user who scans / clicks on the invite link "Bob".

Alice creates an invite link like this; QR codes contain the same text.

https://i.delta.chat/#FINGERPRINT&a=ADDR&b=BROADCAST_NAME&x=BROADCAST_ID&s=AUTH

where:

• FINGERPRINT is the OpenPGP fingerprint of the channel owner, which will allow the Bob to verify that the messages come from the correct sender, and that there is no MitM attack.
• ADDR is Alice's address, which will Bob to contact Alice.
• BROADCAST_NAME is the user-visible name of the broadcast channel, so that the user can be asked "Do you want to subscribe to BROADCAST_NAME"? after scanning the QR code / clicking the link.
• BROADCAST_ID is an internal ID, used in the database to correctly distinguish channels.
• AUTH is a secret token, used for two purposes:
  1. It allows Bob to send a symmetrically encrypted message to Alice, even though he doesn't have her public key yet.
  2. It allows Alice to verify that Bob actually scanned a QR code that allows him to join a channel.

The network protocol for joining a channel - Securejoin v2

In summary, Bob sends a message that is encrypted symmetrically with the AUTH token. Alice answers by adding Bob to the broadcast channel, and sending the broadcast channel's shared secret to Bob.

This is adapted from https://securejoin.readthedocs.io/en/latest/new.html:

1. a) Alice generates an invite code for this broadcast channel.

   b) The AUTH token is generated specifically for this broadcast channel; Alice remembers in the tokens SQL table that this AUTH token belongs to this broadcast channel.

2. a) Bob (the user) scans the QR code or clicks on the link. Bob saves Alice's fingerprint into the database and creates the broadcast channel chat; only messages signed with this fingerprint will be allowed in the broadcast channel.

   b) Bob sends a message with the header Secure-Join: vb-request-with-auth to Alice. (vb-request-with-auth follows the scheme of the securejoin v1 messages).

   In the encrypted part, this message contains Bob's own fingerprint Bob_FP in the header Secure-Join-Fingerprint.

   This message additionally contains all the information Delta Chat adds in every message: Bob's public key (so that Alice can send private messages to Bob), as well as Bob's display name and avatar (so that Alice can see who joined her channel; note that Delta Chat makes it easy to create an anonymous profile where the name and avatar are not identifying).

3. Alice decrypts Bob's vb-request-with-auth message using the AUTH token from step 1

   a) and verifies that Bob’s Autocrypt key matches Bob_FP and that the transferred AUTH matches the one from step 1.

   b) If any verification fails, the protocol terminates.

4. a) Alice adds Bob to the broadcast channel in her database,

   b) and sends a message with the header Secure-Join: vb-member-added to Bob.

   This message contains the broadcast channel's shared secret in the header Chat-Broadcast-Secret.

   This message is asymmetrically encrypted with Bob's public key; alternatively, it could be encrypted with the AUTH token, or with both the public key and the AUTH token.

5. Bob saves the shared secret into his database and is now able to decrypt messages that are sent into the channel.

If this network protocol works nicely in practice, we can start using it also for normal contact/group invites.

The symmetric encryption

Symmetric encryption uses a shared secret. Currently, we use AES128 for encryption everywhere in Delta Chat, so, this is what I'm using for broadcast channels (though it wouldn't be hard to switch to AES256).

• The AUTH token used to encrypt vb-request-with-auth has 144 bits of entropy (see fn create_id in the code). If and when we switch to AES256, we can just generate larger AUTH tokens.
• The secret shared between all members of a broadcast channel has 258 bits of entropy (see fn create_broadcast_shared_secret in the code).

Since the shared secrets have more entropy than the AES session keys, it's not necessary to have a hard-to-compute string2key algorithm, so, I'm using the string2key algorithm salted. This is fast enough that Delta Chat can just try out all known shared secrets. ¹ In order to prevent DOS attacks, Delta Chat will not attempt to decrypt with a string2key algorithm other than salted ².

Footnotes

1. In a symmetrically encrypted message, it's not visible which secret was used to encrypt without trying out all secrets. If this does turn out to be too slow in the future, then we can assign a short, non-unique (~2 characters) id to every shared secret, and send it in cleartext. The receiving Delta Chat will then only try out shared secrets with this id. Of course, this would leak a little bit of metadata in cleartext, so, I would like to avoid it. ↩

2. A DOS attacker could send a message with a lot of encrypted session keys, all of which use a very hard-to-compute string2key algorithm. Delta Chat would then try to decrypt all of the encrypted session keys with all of the known shared secrets. In order to prevent this, as I said, Delta Chat will not attempt to decrypt with a string2key algorithm other than salted ↩

[Hocuri]

This uses SEIPD v2, while in other places, we use SEIPD v1. I assume that we used SEIPD v1 because v2 didn't exist yet at the time, and SEIPD v2 is superior, so, we should use it?

[Hocuri]

Leaving a broadcast channel now uses the same code as leaving a group, so, we don't need this block anymore.

See this code a few lines above:

    if matches!(
        chat.typ,
        Chattype::Group | Chattype::OutBroadcast | Chattype::InBroadcast
    ) {

[Hocuri]

I removed this block because we're in the else clause of if is_contact_in_chat(context, chat_id, contact_id).await?, so, this was dead code

[Hocuri]

I removed this line because above we're ckecking ensure!(chat.typ == Chattype::Group || chat.typ == Chattype::OutBroadcast [...]), so, this was dead code

[Hocuri]

Bad news: The 2-step protocol designed here would reveal Bob's display name and avatar to the server operator, if the server operator can also see the QR code. While this a rare occasion, it's bad that it's possible - a server operator could scrape the interned for QR codes, and then see if it's possible to use it to get the display name and avatar.

After some discussions with @hpk42 and @link2xt, there are 2 alternatives: a 3-step protocol and a 4-step protocol that solve this problem, at the expense of taking longer. This is fine, though, because the current securejoin protocol also requires 4 steps.

After some more discussions, we settled on the 4-step protocol for now, because it is a lot less complex than the 3-step protocol:

Rationale:

• Since we can't do anything asymmetric in the first message from Bob to Alice, it has to be encrypted symmetrically.
  • Since this means that a server operator who has the AUTH token (by scraping the web for public QR codes) can decrypt this message, this message can't contain Bob's display name or avatar. We also don't want to leak Bob's cryptographic identity, so we also don't include Bob's public key (an alternative here would be to create a new keypair Bob-temp, which is what the 3-step protocol does, but this just adds unnecessary complexity).
• Since we want to give Alice the opportunity to review join requests (as a future improvement that doesn't require breaking the protocol), Alice can't send any private data in the second message.
  • So, she only sends her pubkey in the second message. Since Alice's fingerprint is in the QR code, a server operator who scraped her QR code from the web will also know the pubkey; this means that we can safely send the pubkey without potentially leaking any private data.
  • If we want to protect Alice's cryptographic identity from someone who sees her QR code, then this can be a future improvement (Alice can just create a new keypair Alice-temp for this) but is out of scope for now.
• In the third message, Bob can send his pubkey, avatar and displayname.
• In the fourth message, Alice can send her avatar, displayname, and broadcast invitation.

About the complexity "Alice needs to create a Bob-contact without knowing his fingerprint": It should be possible for Alice to receive and answer the first message without any database changes. This will probably mean that create_send_msg_jobs() and MimeFactory::from_msg() is not used, with some parts which are needed extracted into a separate function. I still have to check whether it makes sense to use MimeFactory::render().

The 4-step protocol in text form

Alice                   ---- QR code with symmetric secret  --->                         Bob
   |                                                                                      |
   |    <-- vc-request (symm-encrypted, no info at all except for Bob's email address) -- |
   |                                                                                      |
   | -- vc-pubkey-required (symm-encrypted, contains Alice's pubkey) -->                  |
   |    (an attacker who has Alice's QR code can anyways see her cryptographic            |
   |    identitiy, so, it's not a problem to put the pubkey here)                         |
   |                                                                                      |
   |  <-- vc-request-with-pubkey (symm-encrypted, contains Bob's pubkey, name & avatar -- |
   |                                                                                      |
   | -- vc-member-added (symm-encrypted, contains broadcast secret, name & avatar -->     |

Required security properties

Security properties we want:

• No MitM possible (assuming the server operator can't modify the QR code)
• No metadata sent in cleartext

Security properties we probably want:

• Even if the server operator sees the QR code, they can't find profile data
• Even if the server operator sees the QR code, they can't find Bob's key-fingerprint
• Possible to switch to quantumn-resistant cryptography (which means that we can't just put the pubkey or the first part of a DH exchange into the QR code, bc quantumn-resistant cyphers are long)

Other possibly-interesting security properties:

• Quantumn-resistant, assuming the channel opperator can't see the QR code (we can simply encrypt everything sensitive with the AUTH token for this)
• We can let Alice review Bob's request before answering to the silent SMS (this requires profile data in the first message, though, so it's probably incompatible with other security goals)

Security properties we don't need to talk about right now:

• Even if the server operator sees the QR code, they can't see Alice's key-fingerprint (this will require an Alice-temp fingerprint, which is independent of which protocol we choose)

[Hocuri]

I decided for the following next steps:

• Rather than using a new protocol for adding members to a broadcast channel, use the classic securejoin protocol. This is less work than switching to the new 4-step protocol, so that I can concentrate on finishing broadcast channels.
• After finishing broadcast channels (i.e. sometime in Winter), I will change all of Securejoin to use the newly-designed 4-step protocol, which I explained in the previous message.
  • This will require two releases for backwards compatibility reasons: One release that understands the new protocol (possibly with some advanced-settings switch to enable it), and another release that uses the new protocol by default.

[iequidoo]

Bad news: The 2-step protocol designed here would reveal Bob's display name and avatar to the server operator, if the server operator can also see the QR code. While this a rare occasion, it's bad that it's possible - a server operator could scrape the interned for QR codes, and then see if it's possible to use it to get the display name and avatar.

FTR: The display name and avatar aren't the main problem, but Bob's cryptographic identity. The display name and avatar could be sent in the 3rd, confirmation message.

an alternative here would be to create a new keypair Bob-temp, which is what the 3-step protocol does, but this just adds unnecessary complexity