[OTR-dev] Draft of Security Analysis

[Ian Goldberg]

On Mon, Mar 06, 2006 at 04:35:35PM -0800, Andrew S. Morrison wrote:
> We wanted to send along the draft of some of the results of our security
> analysis before we give a talk on it in a few days in hopes we could get
> some comments. We believe we've found a few good attacks.
> 
> http://www.stanford.edu/~amo/DRAFT_otr_analysis.pdf
> 
> The paper is just a draft right now. We're hoping some people on this list
> could take a look at the "Attacks Found" section and read through to make
> sure the attacks are legitimate. After a round of getting comments from
> you guys and some others we'll send the final version of our paper and the
> Murphi code we used to model OTR. That'll be in about a week and a half.

I took a (very) quick look, but I'll be travelling tomorrow, and may not
have email access again before your talk.

3.1 Version Rollback

    Version rollback, I think, is only a serious concern when it's
    invisible (in SSL, for example).  In OTR (at least the gaim-otr UI;
    I can't speak for the others), it's clear when you're sending and
    receiving encrypted messages, and when you're not.  Additionally,
    it's made clear when you're using version 1 of the protocol, so you
    can take the precaution of asking your buddy to say her name.

3.2 Attack on Strong Deniability

    The attack relies on Bob publishing incorrect MAC keys.  But that
    doesn't make sense; Bob publishes the MAC keys in order *to protect
    himself*.  Intentionally publishing incorrect ones (or, he may as
    well just not publish them at all) would only serve to weaken his
    own deniability.  Note also that Alice and Bob each publish the MAC
    keys, so they'd *both* have to be intentionally trying to make their
    own conversation not deniable.

3.3 Message Integrity

    Good call on this one.  Bizarrely, it doesn't turn out to be a
    security hole in the deployed software because there's a bug in it. (!)
    The deployed software only publishes MAC keys that were used to
    receive messages, not ones on messages it sent.  This is safe,
    because it knows for sure that it'll never trust a MAC key that it's
    already published.  I also believe that even if Bob is cheating, and
    doesn't publish any MAC keys, but only Alice publishes the MAC keys
    of the messages she receives, they still get strong deniability:
    Mallory can take one of the messages Alice received (and
    subsequently published the MAC key for), and substitute a g^y of his
    choosing.  He can then recompute the keys and MACs for future
    messages in the transcript.  [It's late, and I'm doing this quickly,
    so I don't guarantee this is correct.  I'll think about it some more
    in the next couple of days.]  Assuming this is correct, you indeed
    found a problem with the spec, but not in the implementation,
    because the implementation turns out to be more secure than the
    spec.

3.4 Authentication Failure

    I don't see the problem here.  Alice believes she's talking to Bob,
    because she *is* talking to Bob.  If Mallory is passing messages
    through unmodified, she may as well be a wire.  It's not a security
    problem if Mallory sees encrypted messages, and her being able to
    stop Alice and Bob from talking to each other is just a Denial of
    Service attack, which we explicitly don't care about.


Thanks for the analysis!  Feel free to email me or the list with any
questions, comments, or radical doubts.  ;-)  [Though, as I mentioned, I
may or may not have email access from Tuesday morning to Thursday.]

   - Ian