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

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

From: Mitch Zollinger <mzollinger@netflix.com>
Date: Mon, 14 May 2012 12:08:43 -0700
Message-ID: <4FB1583B.4060809@netflix.com>
To: <public-webcrypto@w3.org>
On 5/14/12 10:53 AM, Wendy Seltzer wrote:
> (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.

Hi Eric,

The MiM attack is prevented by device authentication that is done using 
some other means. I did not include an authenticated DH exchange (or key 
unwrapping exchange for that matter) for the sake of simplicity. If the 
doc needs clarity on this point, I'm happy to add the caveat that 
authentication is expected.


> -Ekr
Received on Monday, 14 May 2012 19:09:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:01 UTC