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

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

From: Harry Halpin <hhalpin@w3.org>
Date: Mon, 14 May 2012 21:01:12 +0200
Message-ID: <4FB15678.1050900@w3.org>
To: Wendy Seltzer <wseltzer@w3.org>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On 05/14/2012 07:53 PM, 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?)

It was a bug in the membership database, Systems Team has been alerted. 
Do tell us anyone if your emails can't get through and you believe you 
are a member or invited expert!


> -------- 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 19:01:27 UTC

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