Re: Key wrap/unwrap/import/export open issue - status

On Mon, Jul 22, 2013 at 8:11 AM, Ryan Sleevi <sleevi@google.com> wrote:

>
> On Jul 22, 2013 7:36 AM, "Mark Watson" <watsonm@netflix.com> wrote:
> >
> >
> >
> > Sent from my iPhone
> >
> > On Jul 22, 2013, at 2:42 PM, GALINDO Virginie <
> Virginie.GALINDO@gemalto.com> wrote:
> >
> >> Hi all,
> >>
> >>
> >>
> >> Let me share with you my understanding of the situation about the
> non-extractability attribute consistency in case of
> wrap/unwrap/import/export :
> >>
> >> -          We have a request to maintain non-extractability consistency
> over the API, including in the wrap/unwrap/import/export, with a clear
> balance on not having the javascript seeing the key material
> >>
> >> -          We have a possible technical solution which addresses the
> JWK case http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Notes_July
> >>
> >> -          We have in our scope other formats (aka raw and pkcs8/spki
> format) which may require a global mechanism – several principles discussed
> in the thread below but no technical description at the moment
> >>
> >> -          We had a request from Microsoft and Netflix to progress on
> that matter as soon as possible (see previous minutes meeting)
> >>
> >> -          We do not have any description of the import/export methods
> at the moment in our specification
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#SubtleCrypto-method-importKey
> >>
> >>
> >>
> >> As a WG we need to decide next path to progress. I see several options :
> >>
> >> -          Option 1 : integrate something that we have on the table now
> (JWK only solution), and build a solution for the other formats based on
> contributions of participants
> >
> >
> > One thing to consider is that the requirement for maintaining
> non-extractability is probably relevant only for new applications, since
> the extractability concept itself - as it appears in WebCrypto - is new.
> >
> > As such, if maintaining extractability is possible only with JWK then I
> don't see this as a big restriction since applications which need that can
> be designed to use JWK.
>
> Mark,
>
> This is not at all accurate. Every existing cryptographic API has this
> concept.
>
Strange that you say that, since you seem to have been arguing the opposite
up to now.

If "this concept" - that there is a security boundary between the user code
and the API implementation such that the user code should be considered
less trusted - is common, there should be no problem supporting is in
WebCrypto. But you argue consistently against this concept.


> This is extremely important to support the members and use cases that may
> make use of named, origin specific pre-provisioned keys. I do not see it at
> all appropriate to suggest these other formats (which are broadly supported
> and actually mature, secure standards) are somehow second class.
>
> Further, Netflix's concerns have so far been expressed in terms of named,
> pre-provisioned origin specific keys, so it seems like some awareness of
> 'existing' keys and apps are needed.
>
No, one of our requirements was for named, pre-provisioned origin specific
keys. Another requirement is for unwrap of non-extractable keys. We require
the latter for our application independent of the former. For example, we
don't expect desktop browsers to provided pre-provisioned origin specific
keys, but we would like them to be able to support Netflix without plugins
and for this we need unwrap of non-extractable keys.


> >
> >>
> >> -          Option 2 : decide we want to go for a broader scope
> addressing all our formats in a single solution
> >
> >
> > The two are not mutually exclusive. We can require the WebCrypto
> application to respect JWK attributes *and* work on
> extractability-maintaining wrap/unwrap for other formats.
>
> Mark,
>
> Is your view that the counter proposal for wrap/unwrap (eg: the editors
> draft) would be sufficient if JWK attributes were respected?
>
Yes.

> That is, unwrapKey with raw to get the CEK, which would be non-extractable
> via [named pre-provisioned internal attributes, explicit key attributes
> from generation ala CKA_UNWRAP_TEMPLATE, viral propagation of
> non-extractability]. You would then unwrap the JWK, whose attributes say
> non-extractable.
>
Another option is that the CEK is itself a JWK, the attributes of which say
non-extractable and usage unwrap. This might not be a JWE according to the
current draft, but it would work.

I am also not opposed to explicit attributes on the wrapping key, that
define the properties passed to unwrapped keys. But as I explained in my
other mail I think it gets a little complex.

And I'm not opposed to solving this with implicit rules, so long as they
are not tied to pre-provisioned keys and can actually be made to work. I
don't think this can be done, though.

This avoids needing to handle JWE in an implementation, only JWK, as
> already required by importKey.
>
> Is that sufficient for your uses?
>
Yes, provided the necessary attributes are defined and respected.

> Or do you still feel its a MUST to support the full JWE profile to meet
> your needs?
>
No. Please read my notes on the wiki (
http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Notes_July) where I explain
that your approach is fine provided the necessary attributes are defined
and respected.

...Mark



> >
> > ...Mark
> >>
> >>
> >>
> >> I’d be interested to have the views from WG participants on their
> preferred choice, or any other option you would like to submit to the WG.
> >>
> >> Thanks for helping the discussion to progress.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Virginie
> >>
> >> chair of web crypto wg
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: Mark Watson [mailto:watsonm@netflix.com]
> >> Sent: vendredi 19 juillet 2013 04:30
> >> To: Ryan Sleevi
> >> Cc: Harry Halpin; GALINDO Virginie; public-webcrypto@w3.org
> >> Subject: Re: Key wrap/unwrap/import/export open issue
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Jul 18, 2013 at 7:09 PM, Ryan Sleevi <sleevi@google.com> wrote:
> >>
> >> On Mon, Jul 8, 2013 at 5:12 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >> > Returning to the subject of the original post, and to start off the
> >> > discussion.
> >> >
> >> > Ryan has mentioned two other possibilities for solving this problem,
> so I'd
> >> > like to take a moment to describe my understanding of those.
> >> >
> >> > (1) Implicit unwrap semantics in pre-provisioned keys
> >> >
> >> > A pre-provisioned key with usage unwrap could be imbued with
> behaviors that
> >> > dictate the extractable and usage attributes of keys that it unwraps
> or even
> >> > that imbue the unwrapped keys with other such properties. The former
> would
> >> > be sufficient for "single step" key wrapping, where the final key to
> be used
> >> > for encryption, decryption, signature or signature verification is
> wrapped
> >> > directly with the pre-provisioned key. The special property of the
> >> > pre-provisioned key ensures that the final key has extractable =
> false.
> >> >
> >> > If you want to have two steps, for example the key you are
> transferring is
> >> > encrypted using a temporary Content Encryption Key (as in JWE) and
> then this
> >> > CEK is wrapped using the pre-provisioned key, then you not only need
> the
> >> > pre-provisioned key to force extractable = false and usage = unwrap
> on the
> >> > CEK, but it must also transfer a special property to the CEK, so that
> when
> >> > this in turn is used for unwrapping the resultant key always has
> extractable
> >> > = false.
> >>
> >> Correct. The "Named Pre-provisioned keys" is already imbued with
> >> special properties by definition, so this is consistent.
> >>
> >> JWK is not unique in this 'two step' form - consider multi-party
> >> RSA-KEM - you have the RSA key, the derived per-party KEK, and the
> >> shared, protected key.
> >>
> >>
> >> >
> >> > (2) Explicit attributes on wrapping keys
> >> >
> >> > A key with usage "unwrap" also has properties which dictate the
> attributes
> >> > of keys that it unwraps. Let's call these properties
> "unwrap-extractable"
> >> > and "unwrap-usages". Whenever a key, W, is used to perform an unwrap
> >> > operation, the unwrapped key, K, gets it's attributes set as follows:
> >> >
> >> > K.extractable = W.unwrap-extractable
> >> > K.usages = W.unwrap-usages
> >> >
> >> > Again, this is sufficient for single-step unwrapping. When the
> wrapping key
> >> > W is generated, the unwrap-extractable and unwrap-usages properties
> are set
> >> > to 'false' and the intended usages of the expected wrapped key,
> >> > respectively, When it comes to unwrapping the unwrapped key, K, gets
> the
> >> > appropriate properties.
> >>
> >> Correct.
> >>
> >> This matches PKCS#11's CKA_WRAP_TEMPLATE and CKA_UNWRAP_TEMPLATE
> >> properties, for which the smart card and secure element industry have
> >> long since embraced as sufficient for a variety of high-security needs
> >> (eg: eID cards, as a number of members have pointed out)
> >>
> >>
> >> >
> >> > However, if the intended usage of the key K is also for unwrapping
> (as in
> >> > the two-step key wrapping described above), we need a way to set
> >> > K.unwrap-extractable and K.unwrap-usages.
> >> >
> >> > Theoretically, we could go down the path of having unwrap-extractable
> and
> >> > unwrap-usages each be an array, popping the first value on each unwrap
> >> > operation, i.e.
> >> >
> >> > K.extractable = W.unwrap-extractable[ 0 ]
> >> > K.usages = W.unwrap-usages[ 0 ]
> >> > K.unwrap-extractable = W.unwrap-extractable[ 1 : ]
> >> > K.unwrap-usages = W.unwrap-usages[ 1 : ]
> >> >
> >> > (using python-like slice notation)
> >> >
> >> > It may not be necessary to explicitly expose these attributes on the
> Key
> >> > object: it may be sufficient to have them settable at key creation
> time.
> >> >
> >> > The other option is to have the extractable and usage attributes
> carried
> >> > securely with the wrapped key, as I have proposed.
> >>
> >> Note: This solution ONLY works with JWE-protected-JWK keys - it does
> >> not and cannot work with 'raw' or 'pkcs8'/spki. The smart card / HSM /
> >> SE industry certainly seems to recognize that mixing/matching as you
> >> propose only really works in an implementation-specific manner - see
> >> the CKM_SEAL_KEY proposal in the OASIS TC to see how the very nature
> >> of 'opaque' key blobs is left up to implementations because of this.
> >>
> >> You missed the third option though - which is that the (JavaScript)
> >> caller specifies the policy.
> >>
> >>
> >>
> >> As you explain below, that's not an option that maintains the
> extractability functionality. In this mail, I was exploring options which
> do that.
> >>
> >>
> >>>
> >>>
> >>> If I can sum up the discussion so far, the two objections against this
> >>> last point (eg: what is currently specified) are:
> >>> 1) It allows end-users to manipulate variables (eg: in the Javascript
> >>> console) to circumvent this
> >>> 2) In the event of an XSS, an attacker can unwrap a key and set
> >>> extractable to false.
> >>>   2.1) The first attack requires the attacker has previously observed
> >>> a wrapped key in transit (eg: MITM) before an XSS, then later XSSes
> >>> and replays the original key with 'extractable' as true.
> >>>   2.2) The second attack requires the attacker have XSSed the site,
> >>> the server send a wrapped key, and the XSS change 'extractable' to
> >>> true.
> >>>
> >>> I see #1 as an explicit non-goal for a general web spec - it's a
> >>> feature, not a bug.
> >>
> >>
> >>
> >> I don't see it as consistent with the existing extractable attribute
> though. We should be consistent. Following your approach, we should remove
> the extractable attribute (not that I am proposing this).
> >>
> >>
> >>>
> >>> #2.1 can (and should) be mitigated via HTTPS and related.
> >>> #2.2 can (and should) be mitigated via CSP and related.
> >>
> >>
> >>
> >> There are many ways in which the Javascript running on the users
> machine may not be the Javascript that either the user or the service
> provider expects. The extractability attribute provides some protection
> against such scripts obtaining the raw keying material once it has been
> installed, provided the browser itself is not compromised. We're not in a
> position to do security engineering for every possible application here,
> we're providing tools and extractability is a useful one.
> >>
> >>
> >>
> >> Given the above, it's completely reasonable to want to maintain this
> property with wrapped keys.
> >>
> >>
> >>>
> >>>
> >>> Finally, the Structured Clonability of Key objects permits other
> >>> creative uses that have strong parallels to existing software such as
> >>> middleware, for example, by having a 'trusted' origin perform the
> >>> unwrapping, and then postMessaging() to the untrusted origin (which,
> >>> for example, may not be able to support strict CSP policies), while
> >>> still preserving attributes.
> >>
> >>
> >>
> >> Sure, but you are making a bunch of assumptions or imposing a bunch of
> constraints on how applications are designed. What I can say is that for
> our application, this wouldn't work. Our security analysis suggests that we
> should in all cases attach a different level of trust to the Javascript
> code than we do to the browser code. Both can be compromised, of course,
> but the ways in which the Javascript can be attacked are more numerous and
> varied.
> >>
> >>
> >>
> >> ...Mark
> >>
> >>
>