[messaging] countering active attacks against autocrypt messaging

[azul]

Hi Bryan,
Thanks a lot for your feedback. I'm processing it bit by bit and
starting to track it as issues.
I'll reply to the parts I have been thinking about so far in this email.
I'll continue processing the remaining parts and might reply to them later.

Hi everyone,
To allow for specific comments I'll link to the github issues.
Please reply to the list with comments of general interest. I'm happy to
include these in the issues afterwards.

> Hi Holger,
>
> Great, thanks for pointing this out.  I also (so far) mainly looked at
> the setup contact protocol in section 2.1, and am so far responding
> only to that part.  I’ll first discuss freshness, then UX,
> considerations - sorry for the slightly rambling E-mail.
>
> ### Freshness:
>
> First, I second Michael’s concern about the “crowded room” attack and
> the potential for Alice’s phase-1 Autocrypt info packet to get used
> two or more times without Alice realizing there’s a problem. 
To me the first step to tackle this is to clearly disallow reuse of QR
codes and raising alerts if reuse attempts are detected. One problem i
see with this solution is DOS attacks and reacting to connection
attempts after a (seemingly) successful verification: An observer of the
mail exchange could resend Bobs 'vc-request-with-auth' message from a
different email address. My understanding is that this would look like a
second legitimate contact request which would lead to a warning and
error case. It would not allow reading encrypted messages - but it would
DOS the verification attempt.
(tracking this issue here:
https://github.com/nextleap-project/countermitm/issues/62)

> More generally, I am concerned that that there seems to be a limited
> amount of obvious “freshness-assuring” information embedded in the
> protocol - or at least it’s not obvious what’s guaranteed to be fresh
> per exchange, in what way, how that’s enforced, etc.  As a result, I’m
> concerned with potential replay attacks a MITM attacker might be able
> to pull off against either Alice or Bob.
>
> As one example:  What data exactly is in the ‘vc-auth-required’
> message that Alice sends to Bob in step 3?  Does it contain the
> INVITENUMBER or any other “fresh” information specific to Bob and/or
> to this particular exchange?  If not, I would worry about whether an
> attacker can replay an old ‘vc-auth-required’ message from the
> Alice-Bob interaction later to impersonate Alice in a fake connection
> attempt to someone else, e.g., Charlie, making it appear to Charlie
> like Alice is trying to connect to him although she’s not.  Not sure
> how this would necessarily be to the attacker since if the attacker
> doesn’t have Alice’s public key and thus won’t be able to decrypt
> subsequent communication over the faked connection between Alice and
> Charlie - but it could be disruptive at least: e.g., confuse Charlie
> with this apparently-spam contact request, and as such cause
> reputation damage to Alice…
>
> Another related issue is that I see nothing that looks like a
> timestamp in any of the messages, which makes me worry a bit about
> what kind of disruption an attacker might be able to cause by
> recording and delying/replaying messages after “a long time” at
> various stages.  I don’t yet have much in the way of very specific
> attacks here, but maybe one outside possibility for example might be
> that the attacker disrupts Alice’s and Bob’s genuine original attempt
> to connect, so they give up and intend to try later, but never get
> around to it…  But then perhaps months or years later, once the
> attacker has stolen, cracked, or coerced Alice’s (or Bob’s) key, the
> attacker “finishes” the exchange at that long-delayed time, making Bob
> (Alice) think they’ve successfully (re)connected with an old friend
> when in fact they’ve reconnected with an attacker-Pwned key.  
>
> This is clearly closely-related to the above general freshness issue,
> and I’m not sure whether just fresh randomness, very-loose timestamps,
> or both might be part of relevant solutions, but at least one or the
> other in some fashion seems important.  Especially since your
> requirement of INVITENUMBER and AUTH to be only "at least 8 bytes”
> seems to suggest that these numbers are intended to be secure and
> unguessable only over short timescales of an interactive protocol, not
> over the long timescales of potentially background or long-time-period
> attacks.
I agree with the overall idea that we need to ensure freshness. The most
simple approach to me seems to track the time a QR code was shown or
scanned on the respective device. The invite would remain valid for one
day. If no message is received in that timeframe the record is removed
from the database. This way we would not need to transfer timestamps or
worry about synchronized clocks and timezones etc.
(tracking this here:
https://github.com/nextleap-project/countermitm/issues/63 )

> ### UX considerations
>
> The first bullet in the “Open Questions” section, suggesting that the
> INVITENUMBER and AUTH be made reusable across different peers, is very
> appealing from a UX prospective but seems like a non-starter from a
> security perspective due to the freshness issues, at least with the
> rest of the protocol as it currently stands.  
>
> From this perspective, I’d like to +1 Michael’s comment: “Is it
> possible to prevent attacks of this kind without assuming that the
> trusted channel from Alice to Bob (QR code) is confidential?”  It
> would indeed be nice if the QR code, whatever it contains, could be
> printed on a business card, but then we *must* assume that information
> is non-confidential.
I totally agree. I think the business card use case is a different
scenario and should not be considered a verified contact. We must not
only assume that they are non-confidential but even can be tampered with
(i.e. replaced with similar cards with different QR codes).


> As background that might suggest some solutions to this UX-security
> tension, it might be worth looking at the secure device connection
> process that I developed in my PhD thesis many years ago, in Section
> 2.1 (funny numbering parallel :) ) and Figure 1 of this paper from
> OSDI ‘06:
>
> ...

> Also, a trivial space/bandwidth optimization: if two or more ephemeral
> secrets are needed (like INVITENUMBER and AUTH), it seems like
> slightly more space/bandwidth-efficient and just generally preferable
> protocol design to have just one SEED or NONCE and use key derivation
> techniques to produce separate ephemeral secrets for different
> purposes within the workflow.
I think I also proposed this at some point of the discussion during
writing. One of difficulties we face within the OpenPGP ecosystem is
that as far as i know all the kdfs are based on hash functions that are
not memory-hard or hardened against GPU or ASIC optimization. At the
same time we need the algorithm to work within a reasonable time on
somewhat outdated mobile phones. Argon2 seems like the obvious answer to
that problem - but that would add another dependency. In addition we'd
need to pick parameters that work for everyone now and provide an
upgrade path that prevents downgrade attacks. I assume all of these
problems have already been solved in other contexts.
(https://github.com/nextleap-project/countermitm/issues/64)

Cheers,
 Azul