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

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


On Thu, Apr 25, 2013 at 3:07 PM, Ryan Sleevi <sleevi@google.com> wrote:

> As discussed at the F2F, in order to understand whether wrap/unwrap
> makes sense within the Web Crypto API (that is, independent of any
> other specifications), we need to gather use cases - particularly
> those that show this is something that cannot be accomplished by
> polyfilling.
>
> A recap of some of the important points to consider:
>  - A key that is not exportable is a key that is not wrappable
>  - Conversely, a key that is wrappable is in fact exportable, as an
> 'attacker' can control the wrapping key used under the current
> proposal
>  - The Web Crypto API specifically makes no statements about key
> storage or implementation. We have intentionally, as part of the API
> design, avoided any such discussion of cryptographic modules or other
> intra-API boundaries.
>
> For example, on
> http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0208.html
> , the following use case was proposed:
>
> "This could be a use case for key wrap/unwrap, however. Imagine a
> service with long-lived keys (e.g., a secure file storage service)
> that can be accessed from multiple UA instances. Then the server would
> want to have the client that generates a long-lived key cache an
> encrypted copy on the server (wrap), then provision those keys out to
> UAs (unwrap)."
>
> Such a use case can be satisfied today using our existing primitives
> (export+encrypt, decrypt+import), so wrap/unwrap does not add any
> unique value here to something that can be polyfilled.
>
> Ideally, use cases will also target something along the lines of "This
> is impossible to do with the API without the assistance of the UA,
> because of X", since that helps identify the missing functionality
> from polyfills.
>
> For example, the Web Crypto API itself is impossible to do without
> assistance of the UA because of:
>   - Lack of strong entropy (hence getRandomValues)
>   - Lack of assurances regarding constant time (as a virtue of JS)
>
>