[messaging] countering active attacks against autocrypt messaging

Sun Jul 8 03:36:28 PDT 2018

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.

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.

### 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.

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:

	Persistent Personal Names for Globally Connected Mobile Devices
	http://bford.info/pub/net/uia-osdi.pdf <http://bford.info/pub/net/uia-osdi.pdf>

My goal there was to ensure that the users must explicitly check and confirm some ephemeral randomness, whose validity is short-lived and derived from an online process, while also avoiding the need for the users to copy or enter many numbers or text.  In particular, the workflow has each device display a short pseudorandom strong (encoded as words in UIA, but a short digit string would be fine too), and the other user has to use a multi-select to pick the strong shown on the other device from a list or “None of the above”, which leads to abort.  This basically means that the user actually has to “enter” nothing but that multi-select, which would be even simpler and more natural on a touch-based smartphone (my PhD thesis was before those :) ) - but using the multi-select rather than just a “Confirmed? Yes/No” ensures that the user actually *must* do the comparison rather than just lazily clicking “yes” out of habit.  I still think something roughly along these lines could potentially make a great secure-connect process, at least between devices that at least have some kind of display, which I figure pretty much any Autocrypt-capable (i.e., E-mail-reading-capable) device should.

Of course, the more conventional process of just generating a freshness-protected 4- or 6-digit code on either or both devices that the other user has to enter, as Apple’s security mechanisms commonly use for example, is probably reasonable too from a security perspective, requiring a little more but not too much data-entry, and people are by now accustomed to entering short codes like this in security workflows.

Coming back to the details of how these principles might be applied to Autocrypt’s secure connect workflow, I’m thinking that it would be good if *most* but not quite all of the phase 1 Autocrypt connect information that Alice sends to Bob could be generic for all contacts and included in a QR code printed on business cards, etc.  In particular, the key fingerprint, E-mail address(es?), but not the INVITENUMBER/AUTH.

As a further UX enhancement, it would be nice if this generic information would integrate cleanly with the vCard format, so that users who want to include their name, E-mail, PGP fingerprint, etc., into a QR-encoded vCard printed on their business card, need not have two separate “vCard” and “Autocrypt” QR codes on the same business card.  For example, the static phase 1 information might consist of an Autocrypt extension field to the vCard format, which reuses and refers to the E-mail address and PGP key fingerprint info in the standard fields of the same vCard instead of duplicating them.

Now, when Bob uses his device to scan Alice’s static QR code - either from Alice’s phone display directly or from Alice’s business card that he took home after meeting her in person - Bob’s device produces a fresh nonce and sends that to Alice in the ‘vc-request’ message.  Alice’s device, on receiving this message, informs Alice that someone who claims to be named Bob is trying to connect to her and offers to open the secure-connect workflow if it’s not open already (which it would be if Alice was showing Bob the QR code on her device).  Alice’s device then produces a fresh nonce as well, ensuring that both Bob and Alice contribute to the freshness-assurance (perhaps just in case either of their RNGs are broken/flawed in some way or whatnot), and that gets used as a key-tweak for all the subsequent authenticated-encrypted messages they exchange, and as part of producing random one-time codes that Alice and/or Bob must subsequently verify on their devices, either by direct entry or by multi-select as in UIA.

I believe that this kind of process would ensure that (a) all the static, “boilerplate” information needed for each exchange could safely come from a printed QR code or any other non-confidential channel, (b) the actions Alice and Bob take to confirm the connection are tied to short-term, freshness-ensured secrets that a MITM attacker can’t readily exploit later using replay or long-term attacks, and (c) per Michael’s concerns, it’s always to both users exactly how many distinct secure-connect events they’re involved with, i.e., the attacker can’t make it look to Alice or Bob that they’re just doing one connect when they’re really doing two.

The question of “how fresh is fresh” is important: I understand that we want Autocrypt exchanges to be somewhat delay-tolerant, because some E-mail servers are slow and might take minutes to propagate E-mail and such.  So the timeouts on the validity of the freshness-ensuring material might be fairly generous and large - e.g., 10 minutes? an hour? several hours? configurable? - but the important thing is that they ensure an attacker can’t use replay attacks to do bad things days, months, or years later.

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.

Cheers
Bryan

> On Jun 30, 2018, at 1:00 PM, holger krekel <holger at merlinux.eu> wrote:
> 
> 
> Those interested in e-mail and more general messenging encryption
> security might find it interesting to read the countermitm-0.9.1 release
> of the "countering active attacks against Autocrypt" effort:
> 
>    https://countermitm.readthedocs.io
> 
> It discusses new key verification protocols which are implemented
> as a "Labs" feature in https://delta.chat, released to F-droid.
> It also discusses key consistency research and implementation
> efforts around https://claimchain.github.io/ .
> 
> While the doc deliberately focuses on Autocrypt e-mail encryption
> (https://autocrypt.org) most of the results can likely be applied
> to other messengers.
> 
> The research effort is ongoing and we'd welcome feedback
> and PRs against https://github.com/nextleap-project/countermitm
> We want to release a 1.0 version of this doc end of the year.
> Part of the work has been funded by the European Commission
> but lots is happening independently in various communities.
> 
> holger
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180708/799301e7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180708/799301e7/attachment.sig>