Extractability

All,

I changed the subject of this thread, because Ryan is raising again the
question of whether the extractable attribute makes sense at all. Or,
rather, the more general question of whether use-cases where the Javascript
is less trusted by the service than the UA is in scope for our work.

I believe we should decide on this more general question and then consider
the implications for extractable and for wrap/unwrap.

On that question, I don't believe it is our job in WebCrypto to perform
detailed application security analysis. We are providing tools to
application security engineers and the tools we provide are based on
use-cases.

For our use-case, we cannot use HTTPS to deliver our page because we have
to access non-SSL resources such as CDN content. Switching CDNs to SSL is
expensive in terms of cost, computing resources, and network overhead. And,
we no longer want to use SSL because our target devices do not and cannot
get accurate time. (There are a number of CE devices that wish to use the
HTML5 solution -- the standard has to consider them and not just
desktop browsers.).
In fact our whole reason for using WebCrypto is to build our own secure
application protocol to use instead of SSL.

As a result, MITM attacks against the Javascript are relatively easy.

Further, in the Netflix case then there is value in attacking the crypto to
extract the keying material because that allows you to bypass Netflix
service restrictions or deny service to the legitimate user. If keying
material is known to be non-extractable (modulo TOFU), then we can still be
assured that it is the same browser we are talking to (or at least a
browser to which the same user has migrated the keys, if they are
sophisticated enough to do that.)

...Mark


On Thu, Jul 25, 2013 at 9:42 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Thu, Jul 18, 2013 at 7:30 PM, Mark Watson <watsonm@netflix.com> wrote:
> >
> >
> > 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.
>
> If you think that this is relevant to the threat model, you absolutely
> need to provide an expansion on this.
>
> If you're suggesting the UA defend against "malware", then that's a
> non-starter. If you're talking about extensions or other such, then
> either the user was informed and consented, or it's malware. I don't
> see how you can arrive in a situation where neither party has
> authorized something AND that being a situation that we as a WG must
> deal with.
>
> > 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.
>
> Again, if this is the malware case, it's completely unreasonable to
> want to maintain this property.
>
> >
> >>
> >>
> >> 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
> >
>
> Naturally, I strongly disagree with this as being a reasonable goal for
> the API.
>
> It is, in my view, unreasonable to simultaneously suggest you 'trust'
> JS to perform crypto but then don't trust the JS performing the
> crypto. As we discussed from the very beginning, the mere act of
> permitting cryptographic operations is often more than sufficient to
> leverage any number of attacks - the formal analysis of PKCS#11 we
> discussed in our first F2F was very much a demonstration of this and
> why such a goal is unreasonable for any generic API.
>
> You're right, it absolutely makes a statement that "If you're going to
> run code, you trust the code you're going to run" - and using *other*
> mechanisms to improve or augment that trust (eg: extensions/sysapps,
> as we've also discussed extensively).
>
> As has also been discussed at length, if you're assuming a MITM that
> can modify JS, then it's entirely reasonable to assume that if they're
> not attacking the crypto, they're attacking any number of other
> aspects - including stripping out the crypto entirely. It's a never
> ending game of whack-a-mole that benefits no one, compared to actually
> dealing with the trust problem where it belongs - with the JS itself.
>