Re: Non-extratability

Thanks for the comments.


On Fri, Sep 13, 2013 at 12:07 AM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
>
> On Wed, Sep 11, 2013 at 6:18 PM, Samuel Erdtman <samuel@erdtman.se> wrote:
>
>> Hi
>> I´m reading the discussion on Non-extratability of keys and find it very
>> interesting. I do not get all the details and have not read all the
>> historical mails between Mark and Ryan. But here is how I would like to use
>> non-extractable keys.
>>
>> == Asymmetric keys Usage ==
>> * User wants a key (and a certificate for the key)
>> * Javascript asks WebCrypto to generate an asymmetric key that should not
>> be possible to extract
>> * After generation JavaScript creates a P10 request with PoP(with data
>> from the user or data pre-configured for the user form the server)
>> * The user enters some kind of authentication data
>> * The authentication data and the P10 request is sent to the RA either
>> with CORS if the RA is not hosting this page or directly if RA hosting the
>> page.
>> * The reply contains a certificate for the key. The certificate could be
>> stored in Localstorage or IndexDB.
>> * Now my site have a key and a certificate I could now create a signing
>> service and an API over PostMessage and sell signatures to other sites.
>> * Other sites would load me and send me a message asking for a signature
>> * I would ask the user I he wants to sign the message or reject it. Here
>> I could also add some additional checks like password/pin to allow for two
>> factor authentication or signatures for more sensitive data (Anders might
>> like that)
>>
>
> That's up to your use case. Just be aware that such a scheme provides no
> added security in the presence of hostile JS that compromised your site. It
> only defends against the *remote* sites being compromised.
>
>
>> * The signature returned would be packaged as P7, XMLDigSig or JWS
>> depending on the requesting service.
>> (if desired we could do encryption too)(another scenario here is that the
>> site needing signatures generates the key and requests a certificate over
>> CORS then I would sell certificates)
>>
>
> Those certificates would not be usable outside of IndexedDB/LocalStorage,
> and, along with the key, be cleared whenever the user clears though. But
> sure, you can sell people pieces of the clear blue sky too :)
>

Not exactly sure about what you want to say with certificates not usable
outside IndexedDB/LocalStorage, of course the certificates would not be
usable in contexts where the key is not accessible (that is the point) and
yes they might be cleared by the user, but thats life.


>
>>
>> == Symmetric keys ==
>> This is similar usage but the provisioning has to be a bit different
>> * User wants a key
>> * JavaScript asks WebCrypto to generate a symmetric non-extractable key
>> * Either We could wrap this key with a key derived form a password or
>> with a asymmetric key loaded from the server (then we would have to
>> identify the key from the server in some way)
>> * WebCrypto is asked to wrap the key
>>
>
> This will fail, because two steps above, you marked the key
> non-extractable.
>

My bad, I was not thinking clearly the scenario has to be the other way
around, key coming from server.


> Extractability extends to wrapping. You cannot designate a wrapping key
> for non-extractable keys, for example. A non-extractable key cannot be
> wrapped.
>
>
>> * The wrapped-key is sent to the server directly or through CORS
>> * Now I can use this key for generating OTPs or encrypting data
>> * I would expose this to other services through a PostMessage API just as
>> for asymetric keys
>> * OTPs could be used in offline cases.
>> (this scenario could easily be turned around and have the server generate
>> the key and unwrap it in the client)
>>
>
> In this model, upon receiving the wrapped key, the client indicates
> whether or not the unwrapped key should be extractable.
>
>
>>
>> I want to protect my self from ever having the key touched directly by a
>> javascript that might have been compromised.
>>
>
> Then use TLS and CSP when provisioning your keys.
>

> Provisioning a key during hostile JS should not be a goal, because it
> induces unrealistic complexity and requires necessarily broad protocols
> that are typically a patent minefield.
>
>
>> Sure if compromised the attacker could create a signature oracle but not
>> steel the keys. I would also prefer keys not sent over the wire in clear
>> text not even over TLS.
>>
> If the browser now stores the key in a secure way e.g. some form of crypto
>> hardware I could almost claim non-repudiation for this service.
>>
>
> See the archives on why non-repudiation is both a non-goal and
> non-assertable.
>

> Further, the API makes zero claims about how the keys are stored, as
> stated in the spec.
>

I know, I´m just hoping.


>
>
>>
>> If the key is extractable one could steel it by compromising my site if
>> it is not extractable it is not possible to steal without compromising the
>> browser and preferable not even then (hardware). Of course cloning between
>> sites could not be allowed to give this properties.
>>
>
> The Structured Clone algorithm is orthogonal to the extractability. A
> non-extractable key may be cloned to other origins. However, those other
> origins do not have any further access to the key material than the
> originating origin. They do, however, possess a signing oracle.
>
>
>>
>> Hope this gave some insight on how I would like to use this at least and
>> what requirements it puts on the API.
>>
>> Best Regards
>> //Samuel Erdtman
>>
>
>