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

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

I have a similar observation on the discussion of key isolation or hiding the key from JS in yesterday's call. In my opinion, any key generated by the JS (as a result of invoking the API) should be accessible to the JS. Keys that are not generated by JS (like keys in a smart card, pre-generated in the browser, etc.) must not be accessible to JS, and their use must also be restricted on policies like same-origin.

I saw in Section 5 ( Security) item #3 of http://html5.creation.net/webcrypto-api/ , that JS can ask for signature using a cert that was used to establish SSL connection. In my mind, accepting a client certificate is a decision made by the server, and the browser can present any certificate that matches the CA list proposed by the server. In such cases, malicious servers can obtain signatures using certificates of other domains.

Thank you,
Seetharama

-----Original Message-----
From: Wendy Seltzer [mailto:wseltzer@w3.org] 
Sent: Monday, May 14, 2012 11:53 AM
To: public-webcrypto@w3.org
Subject: Fwd: [from ekr] More on key isolation/netflix use case

(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 Tuesday, 15 May 2012 14:52:04 UTC