librelist archives

« back to archive

webOTR threat modeling

webOTR threat modeling

From:
Meredith L. Patterson
Date:
2011-09-02 @ 19:20
Hi folks,

I've been thinking for a while about the usefulness of a web-based IM
service (akin to Meebo or imo.im) that supports OTR. Javascript crypto is of
course fraught with danger (see
http://www.matasano.com/articles/javascript-cryptography/ and
http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ if the
notion of JS crypto doesn't make you recoil in horror), but I think OTR is
actually a decent use case *if* users' messages can effectively be concealed
from the server that provides IM connectivity. What follows are some notes
I've written up about this particular problem space and the threats that
need to be considered. I would really appreciate feedback, particularly with
respect to attacks I've missed. I am not a cryptographer by any stretch of
the imagination and there is probably a lot I'm missing here, so please, if
you can school me, do so.

Best,
--mlp

Participants
=========
In this model, there are *clients*, users who each have a web browser that
supports SSL and Javascript; an *IM proxy server*, hereafter "server", which
hosts a web application through which clients can communicate via instant
messaging protocols such as AIM or XMPP; and *recipients*, other instant
messaging users who may be using the IM proxy server or may be using any
other IM client, e.g. Pidgin, Meebo, Gtalk, &c.

Threat Modeling Assumptions
======================
We assume that the server is honest but curious, even "curious to a fault"
-- i.e., the server will faithfully honor requests made of it, but will do
everything in its power to recover private keys, decrypt messages, &c based
on the traffic that passes through it. (We draw the line between "curious to
a fault" and "dishonest" at tampering with requests, e.g. providing trojaned
Javascript or man-in-the-middling the endpoints of a conversation. Note that
OTR's out-of-band fingerprint verification will prevent an MitM even in this
model; implementations SHOULD strongly encourage users to verify
fingerprints out of band.)

We also assume that the client's browser and the environment in which it
runs have not been backdoored to transmit cleartext to third parties, modify
Javascript, log keystrokes, or perform other adversarial activities. This is
not a reasonable assumption in a hostile environment. Clients with reason to
suspect the presence of keyloggers or trojaned browsers should use the
service we describe here from a known-trustworthy browser, e.g. one they
have provided themselves on read-only media. Ideally, if a client has to use
an untrustworthy machine, he should work from a liveCD distribution, though
this will not protect against a BIOS keylogger.

The server MUST host all Javascript sent to the client itself and MUST NOT
request any cross-site resources. No sourcing jQuery externally, no Google
Analytics, nothing. Sorry.

The client MUST communicate with the server over SSL. In a normal web
application scenario, SSL provides all the encryption that should be
necessary; however, in this use case, the server must forward each message
it receives on to its recipient, and if not encrypted, the cleartext message
could be observed on its way from the server to the recipient.

Furthermore, an honest but curious server should not be able to decrypt
OTR-encrypted user traffic. Thus, this design must ensure that the server
cannot obtain enough material to recover a client's private key.

Known Issues
==========
Random number generation is a major weak point in Javascript
implementations. As [4] observes, only Safari provides a cryptographically
strong Math.random. This presents a serious problem in the OTR context,
since OTR involves a great deal of random number selection; every message
sent requires a new Diffie-Hellmann key *and* a new and unique AES-CTR IV
[3]. Since the server can always see the recipient's Diffie-Hellmann key
g^y, it must NEVER be able to recover the x that the client uses to generate
its Diffie-Hellmann key g^x. It is possible that predictability in the
output of Math.random on the client side could lead to the server being able
to recover the client's sequence of exponents and thereby decrypt every
message the client sends to *any* recipient via the web app (since the
server can see the order in which the client sends messages, and can also
see each recipient's g^y). The SJCL library [4] provides a CSPRNG in the
form of a variant on Fortuna [2] that is seeded with entropy collected from
user mouse movements; however, this library is still quite young, and we
have not yet determined whether entropy collection takes place quickly
enough to sustain the rate of random number generation that OTR requires.
(Modifying SJCL to also gather entropy from keyDown events would refresh the
entropy pools faster; however, we are unsure whether this method exposes
clients to any additional risk.)

OTR also requires a long-lived authentication (DSA) key, and both generating
and storing this key are tasks for which the browser environment is not well
suited. The same random number generation issues described above apply to
DSA private key selection, so we will not rehash them. Given a suitable
string-to-key algorithm (cf. RFC 4880 [1]), it might be acceptable to store
the secret key encrypted within the browser (either in a cookie or using the
HTML5 storage APIs), but we consider this inadvisable: the HTML5 storage
APIs are immature, and cookie implementations are inconsistent across
browsers and could leak the encrypted secret key, which an adversary could
then subject to a dictionary attack. Furthermore, storing the authentication
key in the browser means that the client user must either keep a copy of his
authentication key in another location (e.g., elsewhere on disk, or on
external media) and load it locally every time he uses a new browser, which
negatively impacts usability, or must generate a new authentication key in
every browser he uses, which violates the principles behind OTR and exposes
the client to additional risk from the server if he fails to verify
authentication keys every time they are regenerated.

This suggests that authentication keys should be generated by the client's
browser, the secret key encrypted via a passphrase and a suitable S2K
algorithm, and the keypair stored on the server. A client can then request
the keypair associated with an IM account for which he has the proper
credentials from the server and decrypt the secret key in his browser. (The
server MUST NOT transmit a keypair for an account to a client who is not
already authenticated for that account.) This still exposes the client to a
dictionary attack by the*server* if he uses a weak passphrase, but since we
assume that the server will not try to forge messages from a client, this
doesn't appear to matter.

Other open questions/issues
=====================
Cryptographic:

   - How badly does a weak PRNG on one side affect the secrecy of
   Diffie-Hellmann?
   - How badly does a weak PRNG on one side affect the Socialist
   Millionaires' Protocol as used in OTR?

Implementation:

   - SJCL doesn't provide AES counter mode directly, though it indirectly
   does via CCM mode. _ctrMode() is marked in comments as "private" though this
   isn't all that enforceable in Javascript. Failing that, since a message in
   CCM mode consists of the message in CTR mode followed by an encrypted
   authentication value (aka "tag") and the client knows the size of the tag,
   the client could simply remove the tag before forwarding it to the server.
   Kludgey but works.
   - SJCL also doesn't provide a DSA implementation. One will have to be
   borrowed from some other crypto library, or written.

References
=========
[1] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer. "OpenPGP
Message Format." http://tools.ietf.org/html/rfc4880, November 2007.

[2] N. Ferguson and B. Schneier. _Practical Cryptography_. Wiley Publishing,
Inc., 2003.

[3] "Off-the-Record Messaging Protocol version 2".
http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html. Retrieved September 2,
2011.

[4] E. Stark, M. Hamburg, and D. Boneh. "Symmetric Cryptography in
Javascript." http://crypto.stanford.edu/sjcl/acsac.pdf, 2011.

Re: [remailer] webOTR threat modeling

From:
Nick Mathewson
Date:
2011-09-02 @ 19:42
On Fri, Sep 2, 2011 at 3:20 PM, Meredith L. Patterson
<clonearmy@gmail.com> wrote:
> Hi folks,

Hi, Meredith!  I'll try to say more once I've thought more, but I can
come up with initial ideas on some things right off.

> Threat Modeling Assumptions
> ======================
> We assume that the server is honest but curious, even "curious to a fault"
> -- i.e., the server will faithfully honor requests made of it, but will do
> everything in its power to recover private keys, decrypt messages, &c based
> on the traffic that passes through it. (We draw the line between "curious to
> a fault" and "dishonest" at tampering with requests, e.g. providing trojaned
> Javascript or man-in-the-middling the endpoints of a conversation. Note that
> OTR's out-of-band fingerprint verification will prevent an MitM even in this
> model; implementations SHOULD strongly encourage users to verify
> fingerprints out of band.)

I don't think "honest but curious" is a coherent threat model.
"Dishonest but risk-averse and unwilling to do anything they could get
caught for" might be.  But even that fails if the server is ever
compromised, since you've replaced one adversary with another.

[...]

> How badly does a weak PRNG on one side affect the secrecy of
> Diffie-Hellmann?

Very badly.  If Eve sees g^x, and she can predict y because of a bad
prng, she can calculate g^{xy}, which is exactly what she isn't
supposed to be able to do.

> How badly does a weak PRNG on one side affect the Socialist Millionaires'
> Protocol as used in OTR?

I believe it's similarly broken.  You definitely lose the
zero-knowledge property, since it relies on g_2 ^ { a_3 b_3 } being
unknown to any party , and a bad prng means that somebody can do a
better-than-average job of guessing the other party's random a_3 or
b_3 value.