W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2012

Fwd: [from ekr] More on key isolation/netflix use case

From: Wendy Seltzer <wseltzer@w3.org>
Date: Mon, 14 May 2012 13:53:11 -0400
Message-ID: <4FB14687.9050401@w3.org>
To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
(I'm not sure why this didn't go through directly, since Eric is
subscribed as an Invited Expert -- perhaps with a different email
address?)

-------- Original Message --------
Date: Mon, 14 May 2012 16:07:28 +0000
From: Eric Rescorla <ekr@rtfm.com>


The Netflix use case document posted by Mitch shows an example of a
DH key exchange designed to create a secure key between Alice
and Bob without the JS getting it.

    To support Diffie-Hellman key exchange using WebCrypto, we might
do something like this:

    // In this example, we use the following webcrypto APIs:
    // DiffieHellman object ctor
    //   DiffieHellman(p, g)
    //
    // (member function) generate() internally creates ‘a’ & returns ‘A’
    // ‘a’ is never visible in Javascript
    //   generate()
    //
    // (member function) computeSS() takes ‘B’ & calculates ‘ss’
    //   computeSS(B)

    // example usage of above APIs to create ‘ss’
    var dh = new DiffieHellman(p, g);
    var A = dh.generate();
    // we now send ‘p’, ‘g’, and ‘A’ to the server which responds with ‘B’
    // after receiving ‘B’ we generate ‘ss’ which stays inside our dh object
    dh.computeSS(B);

    At this point, we have created a shared secret which is inaccessible
    to Javascript, but we can’t yet do anything useful with it. In order
    to transform the shared secret into something usable we need to use a
    key derivation algorithm (RFC 2631? or something simpler?) to compress
    or expand the keying material ‘ss’ to keying data which is the
    appropriate size for some other algorithm."

I agree that this creates a shared secret not known to the JS, but what
stops
the JS from mounting a MITM attack. I.e., it generates it's own DH key pair
(c, C) and provides C to boththe local browser and the remote end. At this
point, it shares K_ac with the browser and K_bc with Bob. Absent some
method for verifying that a DH share came out of a compliant browser,
it's not clear to me what security benefit has been achieved here.

-Ekr
Received on Monday, 14 May 2012 17:53:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:10 UTC