[messaging] countering active attacks against autocrypt messaging

Thu Jul 26 01:30:08 PDT 2018

Hi Michael, Bryan, 

On Thu, Jul 19, 2018 at 18:05 +0100, Michael Rogers wrote:
> 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

For the current incarnation of countermitm we tried to limit ourselves 
to use PGP crypto-primitives. I don't immediately see the advantages
of using DH handshakes here.  If it's about freshness then there might
be other non-crypto ways to ensure that -- eg blocking the
auth/invitenumber after a first message arrives at the inviter. 

Regarding freshness: last week we had a usability session which resulted
in the creation of a 18 people verified group -- it was initiated by one
person showing a group invite countermitm QR code and everybody around
(12 people or so) joining in parallel. Afterwards individuals showed a
fresh invite code in 1:1 interactions in subsequent encounters, 
resulting in the eventual 18.   

IOW, it's not clear that a contact/group-invite code should always ever be used once.  
It's certainly clear, however, that the issue of freshness/re-use needs to be discussed 
in detail in the countermitm paper, including business-card and other use cases. 
i created an issue to track the use cases: 
https://github.com/nextleap-project/countermitm/issues/65
Ultimately, at least with delta.chat, we are aiming to perform user-testing 
and gather user feedback/needs early autumn before settling on protocol 
policies/changes. 

Someone at the user sessions had an idea, btw, on how to join safely a group
in a public setting / room: use a box where you put the mobile phone in
and which has an opening at the top -- anyone can now "scan" and put
their device on the opening until it "beeps".  This way the inviter code 
is hidden from all cameras/observers and there is no too-bright-to-scan problem.
You could even print out the QR code so you don't need to put a phone 
into the box but just a piece of paper.  I like thinking of such 
practises and crypto-protocol considerations in conjunction and measuring
usefulness by actual outcomes for people. 

best,
holger

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

> pub  rsa2048/9FC527CC 2012-04-09 [expires: 2019-07-02]
> uid                   Michael Rogers <michael at briarproject.org>
> sub  rsa2048/FFAC69C3 2012-04-09 [expires: 2019-07-02]
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180726/0c4831f9/attachment.sig>