[messaging] Can a pre-shared public key prevent MITM-attacks?

[Justin King-Lacroix]

True, I missed out TOFU. I would argue, though, that TOFU gives you a
weaker guarante: authentication *as long as the first message was not
tampered with*.
(Also note that SSH and OTR end up using this approach in practise, but
they weren't designed to -- you're supposed to check the key fingerprint
before saying "yes".)

TOFU systems also require careful design to achieve the properties you
describe vis-a-vis MITM. In particular, while all encrypted messaging
systems require a way to roll over the key, they must not support a "set
session key to X" message, or similar, or the adversary can use it to
switch from active mode to passive mode. This is not as trivial as it
sounds -- I think SSL reauthentication lets you do exactly this.

Otherwise, I agree with what you've said.

J
On 7 Dec 2015 14:34, "Sam Lanning" <sam at samlanning.com> wrote:

> You are forgetting one other approach though TOFO (Trust on First Use),
> which is getting significantly more traction recently, for example in
> Signal, and OpenSSH actually uses this approach. And as long as on the
> first communication, you are only being passively attacked, and not
> actively (full MITM), after the keys have been exchanged and stored, a MITM
> cannot occur after that point. Further to this, it allows you to verify
> out-of-band later on that you have been communicating with the correct
> keys, which can then give you authentication for all previous messages.
>
> More specifically, a sustained attack on TOFU requires:
> 1) An active MITM attack on first communicaiton.
> 2) An active MITM for every communication thereafter (which is v.
> difficult in today's mobile world of networks anyway).
> 3) The two parties to never verify their keys out-of-band.
>
> Failing to do (1) will mean that the parties successfully set up
> communications, failing to do (2) or (3) will mean that the parties will be
> able to detect they have been being attacked up until now.
>
> Cheers,
> Sam.
>
> On Mon, Dec 7, 2015 at 1:52 PM, Justin King-Lacroix <
> justin.king-lacroix at cs.ox.ac.uk> wrote:
>
>> No. Even in principle, this is essentially impossible -- two parties with
>> no relationship basically can't communicate securely.
>> There are lots of approaches to the problem, but they all involve
>> breaking the 'no relationship' constraint. PKI -- and thus iMessage,
>> WhatsApp -- does it by introducing a well-known trusted third-party. PGP /
>> Web of Trust does it by relying on social graphs. OTR and SSH leave it up
>> to you: they show you the key fingerprint, and it's up to you to work out
>> whether it's the right one.
>> But in general, the problem you're describing has no solution.
>>
>> (Once you've exchanged keys, of course, there are a multitude of way to
>> create a secure channel on that basis. But you need to exchange keys
>> somehow first.)
>>
>> Justin
>>
>>
>>
>>
>>
>> On 6 December 2015 at 23:43, U.Mutlu <for-gmane at mutluit.com> wrote:
>>
>>> Justin King-Lacroix wrote on 12/06/2015 03:23 PM:
>>>
>>>> There are basically three common ways to authenticate a DH key exchange:
>>>>
>>>>     1. If you and your partner *already have* a shared secret: you mix
>>>> it
>>>>     into into the key exchange somehow. This is the 'shared key'
>>>> mechanism, and
>>>>     is the basis of (eg) PAKE. The crux of this mechanism is that the
>>>> key
>>>>     exchange will fail unless both parties knew the shared secret.
>>>>     2. If you and your partner have long-term public keys, and *each
>>>> already
>>>>     knows the public key of the other*: you use the corresponding
>>>> private
>>>>     keys to augment the key exchange. This one basically breaks down
>>>> into two
>>>>     categories, depending on what kinds of long-term public keys you
>>>> have.
>>>>        1. If you have signing keys, then you digitally sign the DH
>>>>        transaction to authenticate it. You also need to hash the
>>>> long-term public
>>>>        keys into the shared secret, or you introduce an identity
>>>> misbinding
>>>>        vulnerability.
>>>>        2. If you have DH-type keys, then you basically do the DH crypto
>>>>        twice, using both sets of keys.
>>>>     3. If you and your partner have long-term public keys, and you
>>>> *don't
>>>>     know* each other's public keys, then you need someone to vouch for
>>>> you.
>>>>     In most people's heads, that means "PKI", but SSH/OTR-style
>>>>     check-the-fingerprint is potentially viable.
>>>>
>>>> There's also a whole raft of academic literature on more subtle ways you
>>>> can authenticate your DH transaction using the properties of the
>>>> environment, like the availability of secondary, very low-bandwidth
>>>> channels (think Bluetooth pairing); I can direct you to one or two of
>>>> those
>>>> papers if you're interested. But those three are the 'classically
>>>> strong'
>>>> ones, and the ones that are the easiest to understand.
>>>>
>>>> Justin
>>>>
>>>
>>> Hello, thank you,
>>> I'm interested in a practical and ultimate MITM-prevention method
>>> to be used in computer communication using TCP.
>>>
>>> All the papers and examples I read on MITM-prevention do expect
>>> that one already has safely (pre-) exchanged the public keys
>>> of a signing algo like RSA for signing+enc+dec.
>>>
>>> And just that exactly is now the question I'm seeking an answer for,
>>> ie. does there exist an algorithm for sending/exchanging the public keys
>>> safely (that is guaranteed authentic) over the public internet,
>>> w/o human interaction by the two parties?
>>>
>>> Said differently:
>>> Public keys are by definition of course public, but there is the "little"
>>> problem of authentically transmitting it to the other party, for example
>>> the public key of an ephemeral RSA method to be used as nonce in session
>>> creation with PFS: here Alice needs to be sure that Bob receives her
>>> new pubkey, and not that of someone else in the middle (MITM).
>>> Any algorithm known for solving this elementary problem of securely
>>> exchanging the public keys?
>>>
>>> --
>>> U.Mutlu
>>>
>>>
>>>
>>> _______________________________________________
>>> Messaging mailing list
>>> Messaging at moderncrypto.org
>>> https://moderncrypto.org/mailman/listinfo/messaging
>>>
>>
>>
>> _______________________________________________
>> Messaging mailing list
>> Messaging at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/messaging
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151207/6c792274/attachment.html>