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
0x11044FD19FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
