[messaging] How secure is TextSecure?

[Trevor Perrin]

On Wed, Nov 5, 2014 at 10:46 PM, David Leon Gil <coruus at gmail.com> wrote:
> On Sat, Nov 1, 2014 at 3:02 PM, Nadim Kobeissi <nadim at nadim.computer> wrote:
>> ------ Original Message ------
>> From: "David Leon Gil" <coruus at gmail.com>
>>>
>>> They present an unknown key-share attack on TextSecure; this is rather
>>> serious, to say the least.
>>
>> I disagree that this is a serious attack.
>
> I agree, mostly: it's a serious protocol design mistake. But it is not
> usefully exploitable, AFAIK.


I work on TextSecure, so I may be biased.  But I don't think there's
any protocol mistake here, much less a serious one.

Moxie addressed this pretty well in [1], but I'll add to it.

Here's the basic pattern of the "Unknown Key Share" issue:

Bob wants to play a prank on Charlie.  He tells his girlfriend Alice
that he has a new phone number.  But he lies and gives her Charlie's
phone number instead of his own.

Alice texts "I love you!" to Charlie, thinking it's Bob.

---

We can add crypto, but in any system where Bob presents his contact
and authentication info to Alice there's going to be this risk.  This
isn't just TextSecure, it's almost everything:
 * In PGP Bob could present Charlie's encryption key to Alice
 * In OTR, SSH, or TextSecure Bob could present Charlie's fingerprint
 * In NameCoin, PKI, or any centralized service Bob could present
Charlie's username

I doubt any of these matter much.  I also doubt these problems can be
completely solved, though there are mitigations that help in some
cases.

For example, TextSecure's main key verification method is for both
parties to perform a mutual exchange of fingerprints via QR codes.  If
Alice and Charlie have not performed such an exchange, Charlie has no
reason to place strong trust in Alice's message that she loves him.
If Alice and Charlie *have* performed such an exchange, then Alice's
GUI should inform her when she performs a key
verification with a key she already knows about, so she can detect
Bob's attempt to claim Charlie's key.

The key verification process doesn't display this currently, and needs
work in general, but this is UI/UX improvement, not protocol changes.

The RUB authors propose a different mitigation, where Alice uses QR
codes to send Bob a challenge during key verification, and he responds
with a proof-of-possession of the private key.  That adds difficulty
but is still defeatable, since Alice could relay the challenge to a
confederate who challenges Charlie, and then relays the response back.

That also changes verification to require 3 QR codes, instead of 2.
That's a significant worsening of the UX.  So until we have NFC or
something to make round-trips easier, we're unlikely to do complex
verification protocols like that.

Trevor

[1] https://moderncrypto.org/mail-archive/messaging/2014/001030.html