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 <brynosau...@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 > <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 <hol...@merlinux.eu >> <mailto:hol...@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/ <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 >> <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@moderncrypto.org <mailto:Messaging@moderncrypto.org> >> https://moderncrypto.org/mailman/listinfo/messaging >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
