Expire the verification-property of QR codes

[Hocuri]

• This issue supersedes and summarizes Expire QR Codes #5126; see that issue for more historical context.
• Depends on Propagate verification status via Autocrypt-Gossip attribute #7080.

In the text below, "Alice" is the person who creates the QR code, "Bob" is the person who scans it.

Motivation

This will give verifications / green checkmarks a clearer meaning - today, a lot of contacts are verified, but many of them are verified by a bot, or via some QR code handed out a long time ago. Also, some people share their QR codes on Mastodon, which means that everyone could setup a "verified" contact with them, making the verification meaningless.

Details

• This issue is only about expiring the verification-property of QR codes. The create-contact / invite-to-group property will not expire. I.e. if the QR code is expired, it will still create a contact / invite to the group, it just won't create a verification for either side.
• Bots should never see anyone as verified.
• Bob will still get a one-directional verification with Alice if he scans an expired QR code. Changing this is a future possibility (see below).
• Core will need to generate a new QR code everytime the UI requests one.
• We should probably reset all existing verifications in a migration, because "old" verifications are less strong then "new" verifications. This will also solve the problem that Already verified key-contacts are "re-verified" by a different contact #7107 created a lot of weird verifiers.

Future possibilities

Note: The plan is to quickly merge a simple improment; please don't discuss any of these future possibilities before this is implemented. I just collected and summarized all the future possibilities from the discussion in #5126. (or, if you do want to discuss about one of these already, create a new issue for it rather than discussing them here :))

• Call it "verified by" rather than "introduced by" again, because this is what every other messenger calls this feature.
• Add a button "Reset QR codes" that will reset all QR codes (all invite-contact QR codes, resp. all QR codes that invite to a particular group).
• Limit the number of joiners per QR code in order to combat a possible spam wave and to prevent the online-leak.
• Let QR codes' verification expire also on Bob's side
  • Pro: it's not clear where the QR code came from - it could have been manipulated in transit.
  • Contra: In order for Bob to notice that the QR code expired, this information needs to be put into a new parameter t=TIMESTAMP in the QR code. But an attacker who manipulates the QR code could just manipulate the t= parameter, too, assuming that the attacker knows when Bob will scan it. In general, if we want to save Bob from getting an unwanted verification if an attacker tricks him into scanning a QR code, we would need to use dynamic QR codes that only work if Bob scans Alice's screen in real-time.
  • Contra: It's a lot harder for an attacker to manipulate a QR code than to observe it - e.g. if someone puts their QR code on their website or into their SM profile, it's trivial to observe it, but hard to manipulate it.
  • Alternative: Somehow find out whether the QR code was transferred through a secure channel, and if so, mark Alice as verified.
  • Alternative: A dynamic QR code that changes, and only works if Bob directly scans it.
• We can let QR codes expire completely (i.e. scanning them will only show an error message) after a day or so. Then, there should be a UI to get a longer-lived QR code. Then, we could also add UI for setting a custom name like "Cryptoparty" or "Onboarding Bob 4", which will then be shown at the start of the chat with Bob.
• On Alice's side, we can add an info message to the chat "Bob scanned your QR code at DATE", for a bit of extra information where this new contact comes from. (proposed here).
• After securejoin completes, open the edit-contact screen so that the user can rename the contact if they want to.

Further reading

• https://securejoin.readthedocs.io/en/latest/ explains the current protocol and the considerations that led to it. Delta Chat doesn't actually implement expiry yet, which this issue is about.

[link2xt]

In general, if we want to save Bob from getting an unwanted verification if an attacker tricks him into scanning a QR code, we would need to use dynamic QR codes that only work if Bob scans Alice's screen in real-time.

Alternative: A dynamic QR code that changes, and only works if Bob directly scans it.

Inserting TOTP code inside of a QR code might actually be simpler than directly including timestamps. On Alice side, each time we show a QR code, generate current TOTP code and display it. No need to refresh it on screen, Alice can check against some older codes when a message is received and refresh the code with a large time step. When vc-request-with-auth is received, check for the recent TOTP code and mark Bob as verified if the code is not outdated. For Bob we can solve the problem of someone tricking Bob into verifying Alice using old QR code by marking Alice as verified not immediately after scanning, but when an acknowledgement is received from Alice. If no acknowledgement is received but we already have a key, then ok, Bob gets unverified key-contact for Alice.

As for actual changes, I started a PR #7116 and as these changes should happen in the same release, they will likely go into the same PR or a PR stacked on top of #7116.

We can let QR codes expire completely (i.e. scanning them will only show an error message) after a day or so. Then, there should be a UI to get a longer-lived QR code. Then, we could also add UI for setting a custom name like "Cryptoparty" or "Onboarding Bob 4", which will then be shown at the start of the chat with Bob.

As we aim for minimal changes, this can be excluded from the issue. We can always add expiring QR codes later. Error handling is needed anyway because of the option to reset QR codes manually.

[iequidoo]

For Bob we can solve the problem of someone tricking Bob into verifying Alice using old QR code by marking Alice as verified not immediately after scanning, but when an acknowledgement is received from Alice. If no acknowledgement is received but we already have a key, then ok, Bob gets unverified key-contact for Alice.

If we talk about SecureJoin v1 (not v2 in proposed in #6884 ), isn't v*-auth-required already an acknowledgement? As far as i remember, it always worked this way -- we verify Alice only at this step even if we had her key before for some reason.

[Hocuri]

For Bob we can solve the problem of someone tricking Bob into verifying Alice using old QR code by marking Alice as verified not immediately after scanning, but when an acknowledgement is received from Alice.

But this doesn't make anything more secure, because a MitM attacker could just send the acknowledgement, saying 'sure, the QR code you just scanned was very new'.

As we aim for minimal changes, [letting QR codes expire completely] can be excluded from the issue. We can always add expiring QR codes later. Error handling is needed anyway because of the option to reset QR codes manually.

Sure, this is why I put it under "Future Possibilities".

[iequidoo]

For Bob we can solve the problem of someone tricking Bob into verifying Alice using old QR code by marking Alice as verified not immediately after scanning, but when an acknowledgement is received from Alice.

But this doesn't make anything more secure, because a MitM attacker could just send the acknowledgement, saying 'sure, the QR code you just scanned was very new'.

A MITM can't just send the acknowledgement because it must be signed with Alice's key (which is true for v*-auth-required currently). So if Bob sees Alice as verified contact, he did receive the acknowledgement from Alice, i.e. the QR code wasn't old and probably it's indeed Alice who showed him the QR code. At least the time window for attack is greatly reduced.
...

v*-auth-required already an acknowledgement? As far as i remember, it always worked this way -- we verify Alice only at this step even if we had her key before for some reason.

I was wrong, there's indeed a verify_sender_by_fingerprint() call in securejoin/bob.rs:start_protocol(), so Bob verifies Alice immediately after scanning the QR code.

[Hocuri]

A MITM can't just send the acknowledgement because it must be signed with Alice's key (which is true for v*-auth-required currently). So if Bob sees Alice as verified contact, he did receive the acknowledgement from Alice, i.e. the QR code wasn't old and probably it's indeed Alice who showed him the QR code. At least the time window for attack is greatly reduced.

At the point where the acknowledgement is sent, Eve has already replaced Alice's fingerprint, so that Bob believes that Eve's fingerprint belongs to Alice. This means that Eve can sign the message, and Bob will think that Alice signed it.

Eve doesn't even need access to the server if she can manipulate the QR code:

Prerequisites:

• Alice sends a QR code via an insecure channel where Eve can manipulate it. Bob scans the QR code after some time (i.e. the verification-property has already expired).
• Alice and Bob do not check whether they have the correct email address of each other (since the email address in chatmail is just random characters, this is pretty likely).
  • Alternatively, if Eve does have access to the server (classic MitM), she can do a similar attack where Alice and Bob see the correct email addresses of each other.

Steps:

• Eve recompiles Delta-Chat-Core, setting the verification-timeout to 1000 years. (it's probably easiest for her to use Delta Chat via the Python-JsonRPC-bindings)
• Eve creates a profile with the same name and avatar as Alice's
• Eve replaces the whole of Alice's QR code with her own QR code (which, to the user, looks identical to Alice's QR code, because the profile has the same name and avatar
• Bob scans replaced QR code, and gets the confirmation that the QR code hasn't expired.
• Eve creates a second profile, with the same name and avatar as Bob. Using this profile, she scans Alice's QR code.
• Bob now thinks that Eve is Alice. Alice now thinks that Eve is Bob. Eve can do the classical MitM of decrypting, reencrypting, and forwarding messages.

In general, if Eve can replace the whole of Alice's QR code, there is not a lot Delta Chat can do. We can mitigate the risk with some of the "Alternative"s I listed under "Future Possibilities", but for now, I think we should first make sure that Alice doesn't see Bob as verified, as written in the OP.

[link2xt]

Current setup contact protocol consists of the following steps:

1. QR code scan
2. vc-request with invite code from Bob to Alice
3. vc-auth-required with Alice's key sent to Bob
4. vc-request-with-auth from Bob to Alice
5. vc-contact-confirm

For a minimal change to close this issue we need to make Alice not mark Bob as verified when vc-request-with-auth is received, but auth code is outdated. The simplest way is to store a new auth code with a timestamp in the database each time QR code is shown. Once it is expired, remove it and ignore vc-request-with-auth messages from Bob.

For group join protocol is the same, but last message is a "member added" message. We need to keep even old auth codes because they result in adding Bob to the group, but we should not mark Bob as verified in this case.

On Bob's side nothing changes. Making Bob not mark Alice as verified for old codes is out of scope for the issue.

The change should be implemented on top of #7116 and include a migration to reset all verifications. Then we merge it into #7116 and merge the whole #7116 once it is reviewed.

[iequidoo]

At the point where the acknowledgement is sent, Eve has already replaced Alice's fingerprint [...]

Well, we don't protect from classic MITM where Eve can modify messages or QR codes transferred insecurely. I was talking about another attack when Bob already has Alice's key (unverified) and then Eve shows him true Alice's QR code causing Bob:

• to think that it was Alice who showed him the code because Alice's key becomes verified. If we don't limit QR codes' TTL, Eve has enough time to carry the attack.
• to think that this Alice's key is a correct way to contact Alice, but maybe Alice has multiple profiles or doesn't want Bob to contact her at all.