search

nextleap-project / countermitm

thoughts on countering mitm-attacks on autocrypt
15 stars 5 forks source link

lack of checking when Bob knows Alice's FP #44

Closed carmelatroncoso closed 5 years ago

carmelatroncoso commented 6 years ago

a) If Bob's device knows a key that matches Alice_FP the protocol continues with 4b)

In step 4b) Bob just sends back his key, but he does not check that the email received is the same as the one he had associated to the value Alice_FP he had stored. Doesn't this open the door to an attack? As long as I know Alice's FP I can get Bob to engage. Am I missing something?

azul commented 5 years ago

Just trying to understand by rephrasing here: In 2.a) Bob just received a bootstrap code. Currently this happens via a QR code scan but later on there might be other mechanisms. So now the person who send the bootstrap code could have send a combination of a FP bob knows and a wrong email address. So say Egon used his own FP but send Alices email address instead. Bob's device will pick Egons key for Alices address. If Egon also is in a MITM position or collaborating with an attacker who is they can complete the handshake. The only way for Bob to notice would be that in the End his device displays... "Secure contact with Alice established". But he has been talking to Egon.

hpk42 commented 5 years ago

to fix this issue isn't it sufficient to write:

"a) If bob's device already verified that Alice's e-mail address is associated with Alice_FP the protocol continus with 4b)"

azul commented 5 years ago

The approach sounds good. I would use a different term than 'verified'. I think the main usecase here is verifying a contact i already have an autocrypt key for.

The other question for me is if we want to explicitely ask the user to verify that the email address matches the person they are talking to. I think we don't neet to but should make it very obvious who one is verifying by highlighting the email address during the process.