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

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.

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).

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?

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.

Received on Friday, 26 April 2013 20:54:30 UTC