W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

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

From: Mark Watson <watsonm@netflix.com>
Date: Fri, 26 Apr 2013 16:17:35 -0700
Message-ID: <CAEnTvdBdfTYLZynNWkwjFtbsQZcy9DPTjtqte+mxWt7iUnWWNw@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Fri, Apr 26, 2013 at 2:15 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Fri, Apr 26, 2013 at 2:08 PM, Mark Watson <watsonm@netflix.com> wrote:
> > 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.
>
> If the only added benefits are "When the service's JS is replaced",
> then I think we're at an impasse here. We absolutely should not be
> trying to solve that problem - that's entirely the realm of WebAppSec,
> as has been discussed in the past.
>
> You've presented this as an issue with the Web Crypto API - that is,
> "if we had X, we could be secure under attack Y". I'm trying to
> explain that "attack Y" is such a broad class of attack that it must
> not and cannot be dealt with on a per-API basis - this is a
> fundamental issue to the web security model.
>
> That's why I have trouble with this use case - it's trying to solve a
> particular scenario at entirely the wrong level, relying on
> assumptions that are entirely incorrect for that level.
>

Again, you claimed that there was no security benefit to UA support of
unwrap/wrap compared to JS polyfill and I demonstrated a scenario where
this is not the case.

That doesn't mean that I see UA-based wrap/unwrap as a complete solution to
any particular problem or that finding such complete solutions should be
done here in WebCrypto. It just means that UA support of these primitives
has different security properties than JS polyfill. I think it should be
obvious that the security properties of the UA case are not worse than
those of the JS polyfill case. You may argue that they are
different-but-not-better in all realistic scenarios, but that is where we
disagree - to the extent of basing our service of such capabilities.

This API is going to be used for security engineering, not just for demos
of mathematical functions. To say that security-based arguments are
out-of-scope makes no sense and isn't anywhere stated or implied in our
charter.


>
> >
> >>
> >>
> >> 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
> >
>
> It's out of scope because we're not the WG that's trying to "solve"
> web security. There's other WGs for that.
>

There's a difference between saying that "solving web security" is not in
our success criteria and saying that any security-based argument
is inadmissible here. The former I agree with, the latter not.


>
> While we shouldn't make "insecure" decisions, neither should we
> attempt to tilt at windmills or try to solve problems in isolation,
> without any consideration for the holistic picture of what these
> attacks actually mean.
>

We can work up arbitrarily detailed security analyses for any of the
WebCrypto primitives, but we're not relying here on doing that for each and
every one. We're relying at least a little on the known past usefulness of
most of our primitives in other security APIs. The rest of the group are
convinced, without further analysis, that there is benefit to having
wrap/unwrap supported by the UA. You have conceded that point for the case
where there are pre-provisioned keys. The TOFU example relies on *exactly
the same principle* outside the "First Use" step. We're right at the
beginning with this API here and we'd like to move ahead to getting the
real-world experience which is necessary to bring it to its full potential.

...Mark
Received on Friday, 26 April 2013 23:18:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:16 UTC