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

Mark,

Let me try to summarize: your entire TOFU scenario is predicated on
"attacker [read: MITM] can modify code at some later point". That's
why you have TOFU.

The solution to such a problem is NOT "How do I handle a MITM", but
"How do I prevent MITM". The latter is clearly the realm of WebAppSec
(and, eg, the IETF's WebSec WG)

That's why I see the entire use case, while valid, as NOT being a
problem for this WG to solve - it's a problem countless other APIs and
WGs have to solve, and it's one that there is a clear group to deal
with it.

I believe this is the same point Arun was making during the F2F and
the security utility of the use cases. The so-called "Facebook" use
case relies on a set of security assumptions that, when actually
examined, are realized to be systemic underlying issues that are not
solved by cryptography alone.

I'm not moving the bar here - I acknowledge your use case, but I'm
trying to demonstrate why it's solving the problem at the wrong layer.

To put it more concretely: Assume you can perfectly mitigate the MITM
risk. This provides you the same level of trust as your first visit.
Is wrap/unwrap at all necessary at this point?

>From your explanation of the problem so far, the answer is no - and if
you disagree, please explain why.
If the answer is yes, then it's clear that the real issue is
mitigating MITM risks, not API sugar.

On Fri, Apr 26, 2013 at 4:17 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>
> 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:29:36 UTC