[messaging] countering active attacks against autocrypt messaging
holger at merlinux.eu
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:
Ultimately, at least with delta.chat, we are aiming to perform user-testing
and gather user feedback/needs early autumn before settling on protocol
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.
> 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
> 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.
> 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...
Size: 474 bytes
Desc: not available
More information about the Messaging