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> 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
>
> It discusses new key verification protocols which are implemented
> as a "Labs" feature in 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) 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@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
