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

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!

    cheers,
      harry

>
> -------- 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