Re: Non-extratability

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


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

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.


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