Re: ISSUE-35 - Use cases for Wrap/Unwrap - TOFU

Ryan,

You claimed in the meeting that there was no security difference between
key wrap/unwrap in the UA and key wrap/unwrap in JS, in the absence of
pre-provisioned keys.

My example illustrates a clear security difference.

We can talk through the details (see comments below), but the above point
remains.

On Fri, Apr 26, 2013 at 1:54 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Fri, Apr 26, 2013 at 1:15 PM, Mark Watson <watsonm@netflix.com> wrote:
> > Thanks to Richard for the acronym:
> >
> > WebCrypto wrap/unwrap use-case: TOFU
> >
> > Trust On First Use is a commonly used approach in which credentials are
> > established in an essentially insecure way and then, assuming the "First
> > Use" was not subject to attack, subsequent security is strong. Examples
> > include:
> > - downloading and installing a browser, including a root CA trust store,
> and
> > subsequently using Internet Banking sites
> > - installing ssh credentials on first use
> > - certificate "pinning" e.g. accepting a self-signed cert on first
> > connection, and storing that identity for subsequent "hands free"
> > connections
> >
> > The approach makes life more difficult for an attacker, since they must
> be
> > present at the "First Use" in order to launch an attack.
> >
> > WebCrypto wrap/unwrap can be used to implement TOFU in the face of an
> > attacker who might replace service Javascript with their own as follows:
> >
> > Step 1) (First Use) The client and server establish a shared secret key,
> Ks,
> > installed within the UA using WebCrypto, with usages = [ unwrap ] and
> > extractable = false
> >
> > This could be done in a number of ways, for example
> > (i) client generates a public private key pair ( Kcpu, Kcpv ) with usage
> = [
> > unwrap ]
> > (ii) client sends the public key Kpcu to the server
> > (iii) server generates a symmetric key, Ks, wraps this using the client
> > public key Kcpu and sends the wrapped key to the client
> > (iv) client receives the wrapped symmetric key, Ks, and unwraps it
> >
> > Step 2) (Subsequent use) To begin a secure communication session, the
> server
> > generates a symmetric key Kh and wraps this using Ks. Kh has usages = [
> > sign, verify ] and extractable = false.
> >
> > The client receives the wrapped Kh, unwrap ir and subsequently uses Kh
> for
> > signing and verifying client-server messages.
> >
> > Implementation options
> >
> > We now compare implementation options for this model
> >
> > A) JS polyfill wrap/unwrap on top of UA-implemented WebCrypto
> >
> > In this case, the wrap/unwrap methods are implemented in Javascript using
> > the remaining WebCrypto primitives. To support this, using the proposed
> > JWE-based wrap/unwrap, it must be possible to use Ks to decrypt the CMK
> of a
> > JWE structure. The CMK is then used to decrypt the JWK structure within
> the
> > JWE and finally importKey() is used to import the key (Kh) into
> WebCrypto.
> >
> > An attacker who can modify Javascript during Step 2 has access to the raw
> > key material for Kh prior to the importKey() step.
> >
> > B) UA-implemented wrap/unwrap
> >
> > In this case, the UA implements the wrap/unwrap methods as proposed. An
> > attacker who can modify Javascript during Step 2 cannot access Kh
> because:
> > - Ks has usage "unwrap": it cannot be used to decrypt the CMK directly
> as in
> > case (A)
> > - Kh has extractable = false, so it cannot be exported or even wrapped
> once
> > installed
> > - The extractable property of Kh cannot be modified during the unwrap,
> since
> > it is specified inside the protected JWK which can only be decrypted and
> > acted on by the UA.
> >
> > ...Mark
>
> Mark,
>
> Simple distinction - In the *Web Crypto API*, how do you distinguish a
> user who has keys from an attacker who is being deceptive and saying
> they don't?
>
> That is, in the security model, Step 1 seems like it can trivially
> subverted via a number of means - "This is a new device", "I lost my
> key", etc.
>

Whether and how the attacker can cause a reversion to Step 1 depends on the
design of the rest of the system and this problem applies to any use of the
TOFU approach.


>
> Note that the threat model of "an attacker who might replace service
> Javascript with their own" has, so far, been a NON-GOAL of this API -
> that is, it's entirely outside the set of reasonable security
> parameters being attempted here (as the past discussions over the last
> year have shown).
>

You asked for a scenario where there is a security difference between key
wrap/unwrap in the UA and key wrap/unwrap in JS. Your paragraph above just
says you don't like this scenario or don't think it should be in scope, but
doesn't invalidate the scenario.

Actually, replacement of the services Javascript is a very real concern for
us so I can't accept that discussion of this possibility should be out of
scope.


>
> Your description of "attacker" in Situation A fails to describe who
> they're attacking, and what the threat model is. Are they attacking
> the service? Or the user?
>

Either or both. The point is that the secret key is available to the
attacker in scenario (A) and not in scenario (B). I think this counts as a
significant difference from a security perspective. If we expand this
example to a complete description of a service using this we would see
whether the release of the secret key to an attacker negatively affects the
service or the user or both. I'm sure there are also examples where it
affects neither.


>
> If the user, an attacker who has the ability to inject/modify JS is an
> attack that, from the user's perspective, is fundamentally "Game
> Over". There is no need to attack key material - they can fully
> impersonate or access any data (including cookies), so we consider
> this a fundamental break of security. Attempts to add incremental
> 'security' (which it isn't, really) atop this model are pointless.
>
> If it's "attacker" against the service, I would strongly argue that's
> out of scope.
>

Well, the whole reason we wish to use WebCrypto is to provide better
security for our service, so I couldn't accept that is out of scope. I
think many people would like to use WebCrypto to build services which are
secure both for users and service providers.

...Mark