Re: Key provenance

On Fri, Oct 4, 2013 at 2:23 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>
> On Oct 4, 2013, at 5:07 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> On Fri, Oct 4, 2013 at 2:03 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>> Hey all,
>>>
>>> I've been thinking about some identity use cases for WebCrypto, and in several cases, it seems useful for someone who looks at a key object to be able to tell if it only exists in that browser instance.  The "extractable" attribute provides part of that, but you still have to know that the key was generated by the host, and not by importKey or unwrapKey.
>>>
>>> Proposal:  Add an attribute to the Key interface ("provenance" or "source") that specifies how the key was introduced to the API.  Possible values are "generate" and "import", indicating that the key was generated by the browser or imported by some other JS code, respectively.
>>>
>>> It seems like it would be trivial for browsers to set this attribute, and there are no other API changes needed.  And it seems like being able to know this property of keys could lead to some interesting applications.
>>>
>>> Cheers,
>>> --Richard
>>
>> Can you please describe these applications?
>>
>> I'm extremely reticent to introduce API surface changes simply because
>> it "might" be useful, without a clear and demonstrated use case (and
>> how an application cannot already accomplish this today).
>>
>> I do not see any such need for this today, since an application can
>> already know - because keys are not shared and fully controlled by the
>> application.
>
>
> The example I'm working on now requires this precisely because it involves sharing keys.
>
> Suppose you've got a site that is using an identity federation system such as OpenID Connect or Persona.  If you look at how these systems work today, they're based on assertions that anyone can present.  So they've got replay vulnerabilities -- the relying party doesn't know that the entity presenting the assertion is the one that the identity provider issued the assertion for (the subject of the assertion).

What's your threat model here? Are these protocol-level deficiencies?
And is this really a replay vulnerability, or a confused deputy
problem?

What I'm getting at is why can you not simply bake the origin in as
part of the messaging system, at least from the attack I've understood
you've described.

If you're concerned about MITM-style attacks, isn't that what both
HTTPS and Channel Bindings are meant to address?

>
> On the other hand, if the assertion could be bound to a key pair whose private key exists only in a single browser instance, then the relying party could be assured that the assertion is for the current browser instance by verifying that the browser possesses the private key corresponding to the assertion.

I see this as a non-feature.

It should be entirely valid for a Browser to aggregate Key objects via
"the Cloud", while still maintaining the "extractable" attribute, much
in the way they can sync passwords, autofill data, bookmarks, etc.

As such, this 'provenance' attribute (which will inevitably become a
cloaca of bad ontologies, as we've previously discussed, particularly
during the Mountain View F2F when this was raised by Gemalto) would
fail to accomplish what your goal is - which seems to be ensuring that
a key is restricted to a single browser.

>
> In this process, both the IdP and the RP want assurance that the private key exists only in the subject browser instance.  However, in the current system, you need to know both (1) the "extractable" attribute of the key and (2) whether the key was generated imported -- and only the party that generates the key pair knows that.  Whichever party didn't generate the key doesn't know whether the other side imported the key from elsewhere -- in which case the identity might not be for this browser instance.  So in addition to extractability, the private key needs to be tagged with its origin.

The IdP, by virtue of being the *Id*P , should always be the one that
knows how the key was generated.

>
> This can't be done today because there's no such thing as non-stealable information in the current DOM API.  Key handles are unique in this regard.
>
> Hope that helps,
> --Richard

I'm sorry, could you explain what you mean by "non-stealable information"?

I'll also note that WebCrypto as part of the Web Platform APIs is not
necessarily part of the DOM APIs (that is, WebCrypto has nothing to do
with mutating the document object model)

Having this use case is extremely valuable, because it does allow us
to discuss more concrete terms about what the problem space is, what
the possible solutions are, and what the downsides are to the
solutions. I'm not convinced that provenance is the right path for
this, but I'm still trying to make sure I understand the problem.

Received on Friday, 4 October 2013 21:35:00 UTC