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 <[email protected] > >> <mailto:[email protected]>> 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 <[email protected] > >>> <mailto:[email protected]>> 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 > >>> [email protected] <mailto:[email protected]> > >>> https://moderncrypto.org/mailman/listinfo/messaging > >> > > > > > > > > _______________________________________________ > > Messaging mailing list > > [email protected] > > https://moderncrypto.org/mailman/listinfo/messaging > > > pub rsa2048/9FC527CC 2012-04-09 [expires: 2019-07-02] > uid Michael Rogers <[email protected]> > sub rsa2048/FFAC69C3 2012-04-09 [expires: 2019-07-02] >
signature.asc
Description: PGP signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
