[messaging] countering active attacks against autocrypt messaging

[holger krekel]

Hi Michael, 

On Mon, Jul 02, 2018 at 12:58 +0100, Michael Rogers wrote:
> 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.

It's certainly true that if the trusted channel can be observed by an
attacker and that attacker can send and maybe block messages
things get more complicated.  I'd like to get an idea how "QR-remote
scanning and injecting messages for impersonation attacks" ranks as a
real-world concern compared to other concerns (eg phone overall
compromised, or taken/lost etc).

> [...]
> 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.

It makes sense from a security point of view to default to 
one-time AUTH codes and maybe act/warn if a second contact request arrives. 

For using QR codes on business cards it's different btw -- probably there
should be different type of QR code for this so it's clear that
verification is only one-way (Bob has verified Alice's key but not vice
versa if AUTH is re-used). 

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

Probably not without introducing additional UI interaction at
which point doing two QR workflows might be more straightforward. 
Maybe some user-testing could reveal if a hint like 
"keep this QR code confidential" would at least convey 
the "trustedness" assumption to user. 

holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20180703/ee3a1837/attachment.sig>