[messaging] countering active attacks against autocrypt messaging

[Michael Rogers]

Hi Holger,

On 30/06/18 12:00, holger krekel 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/ . 

I went straight to the protocol for adding contacts (section 2.1)
because that's a problem I'm currently interested in. Apologies if I've
missed something that's mentioned elsewhere in the spec.

The threat model assumes that an active attacker can't read a QR code
that Alice shows to Bob, and the protocol depends on this for security
(Alice authenticates Bob's contact request by checking that he knows the
AUTH from her QR code).

Is this a safe assumption in, say, a crowded room, or a room with CCTV?

It seems that if an attacker can read the QR code and complete the
protocol faster than Bob, the attacker can be added to Alice's contact
list. From Alice's point of view, the protocol completes successfully.

What happens next depends on the implementation. As far as I can see,
the spec doesn't say that Alice must reject an AUTH value that's already
been used. If Alice fails to do so then she may accept the attacker's
vc-request-with-auth *and* Bob's vc-request-with-auth, in which case
both Alice and Bob will think that the protocol succeeded. Alice will
end up with two verified contacts, one of which is the attacker.

On the other hand, if Alice rejects Bob's vc-request-with-auth because
the AUTH has already been used, and if Bob's implementation shows an
error message when the protocol terminates early, then Bob will see that
the protocol failed and may ask Alice to try again. The protocol will
succeed on the second try, and again Alice will end up with two verified
contacts, one of which is the attacker.

Is it possible to prevent attacks of this kind without assuming that the
trusted channel from Alice to Bob (QR code) is confidential?

It seems to me that it's only possible if we also have an
authenticated-but-not-confidential channel from Bob to Alice - in other
words, two QR codes. But I'd love to be proved wrong because I can see
the usability benefits of using a single QR code.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x11044FD19FC527CC.asc
Type: application/pgp-keys
Size: 14255 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180702/fb89f47d/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180702/fb89f47d/attachment.sig>