[messaging] countering active attacks against autocrypt messaging

Thu Jul 19 10:05:26 PDT 2018

For what it's worth, I think this workflow is on exactly the right
track. Keeping the information in the QR code static and
non-confidential makes the protocol robust and flexible with regard to
how the QR code is distributed.

I like the use of short authentication strings instead of scanning a
second QR code, and I think we may even be able to reduce the workflow
to a single string read by Bob:

* Alice displays or prints a static QR code containing the fingerprint
of her long-term public key and her email address
* Bob scans the QR code and sends Alice message 1, containing his full
long-term public key, email address, and a single-use DH public key
* Alice replies with message 2, containing her full long-term public
key, a single-use DH public key, and a signature over Alice and Bob's
long-term public keys, email addresses and DH public keys with her
long-term private key
* Bob checks Alice's long-term public key against the fingerprint from
the QR code, verifies Alice's signature, and replies with message 3,
containing a signature over Alice and Bob's long-term public keys, email
addresses and DH public keys
* Alice verifies Bob's signature

At this point each party is sure that the other party controls the email
address and long-term public key they presented. The freshness of each
party's own DH key ensures the freshness of the other party's signature,
so we don't need a separate nonce. Bob is convinced that Alice's
long-term public key, email address and DH public key belong to the
person he met. But we still need to convince Alice that Bob's long-term
public key, email address and DH public key belong to the person she
met, rather than to someone else who scanned her QR code.

For this we can use a single short authentication string (such as a
six-digit number) derived from the DH shared secret. Bob reads the
string, and Alice enters it or picks the right one from a lineup. By
recognising Bob's voice (or ideally, by being present when he reads the
string), Alice is assured that the person she met knows the DH shared
secret.

Now for the part I'm not sure about (which I think would also apply to a
workflow where both parties read strings). Reading the string proves
Bob's knowledge of the DH shared secret, and Bob's signature proves that
the owner of Bob's long-term public key is participating in this run of
the protocol, and claims ownership of Bob's email address and DH public
key. But do we also need a binding in the other direction - a MAC over
the keys and email addresses with a MAC key derived from the shared
secret, to prove that the owner of each DH public key is participating
in this run of the protocol, and claims ownership of the corresponding
email address and long-term public key? Or is that redundant?

I'm concerned that without this additional binding there might be a
possibility of some kind of unknown key share attack, although I can't
see the details.

If we do need this additional binding then Bob's MAC should be included
in message 3. If we also need the binding for Alice then Alice should
reply with message 4 containing her MAC, at which point Bob's device can
display the short authentication string.

Cheers,
Michael

On 08/07/18 11:55, Bryan Ford wrote:
> P.S.  I perhaps should have been clearer about the user-visible
> secure-connect workflows I’m envisioning in the discussion below,
> particularly the one utilizing static info printed in a QR code on a
> business card.  To summarize, here are the two user workflows I’m
> currently considering: 
> 
> 1. Immediate in-person:  Alice and Bob both have their devices in the
> same (potentially crowded) room.  Alice opens her Autocrypt E-mail
> client and initiates Secure Connect, which displays the QR code for Bob
> to scan and proceeds with the rest of the process.
> 
> 2. After-the-fact:  Alice and Bob meet in person but just exchange
> business cards, perhaps because one of them doesn’t have their
> Autocrypt-enabled device with them, or perhaps because they’re in a
> hurry and just don’t have the time yet for the secure-connect process.
>  So Bob takes Alice’s business card home, and sometime later, scans her
> Autocrypt-enabled vCard.  He calls her up on the phone or some other
> channel that he trusts at least in a “TOFU” sense to exchange the
> ephemeral verification codes on.  Perhaps Bob’s Autocrypt-enabled device
> even provides a button to call Alice at one of her phone numbers while
> activating the secure-connect process with her static info.  Alice and
> Bob (perhaps implicitly) verify that they recognize each other’s voices
> on the phone, Alice reads to Bob the random string/code her device
> displays, and Bob does likewise for Alice.  They each select the correct
> verification codes, and complete the connection.
> 
> Does this make sense?
> 
> Bryan
> 
>> On Jul 8, 2018, at 12:36 PM, Bryan Ford <brynosaurus at gmail.com
>> <mailto:brynosaurus at gmail.com>> wrote:
>>
>> 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
>>
>> 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
>>> <mailto: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
>>> <https://countermitm.readthedocs.io/>
>>>
>>> It discusses new key verification protocols which are implemented
>>> as a "Labs" feature in https://delta.chat <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 <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 <mailto:Messaging at moderncrypto.org>
>>> https://moderncrypto.org/mailman/listinfo/messaging
>>
> 
> 
> 
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x11044FD19FC527CC.asc
Type: application/pgp-keys
Size: 15088 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180719/526eb41c/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180719/526eb41c/attachment.sig>