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

On Apr 25, 2013, at 6: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)

Important to note one further thing the UA provides, which is likely to be important here: 
 - Lack of assured separation isolation of keys from JS

You can emulate this with origin separation (which is what PolyCrypt does), but you're still vulnerable to (1) the origin where the keys are being stored (as opposed to the browser), and (2) attacks that can break that separation.

I think there are also a class of motivations which are about good security habits as opposed to hard security assurances.  The use case above, and many messaging-based use cases, could be implemented with the current API, but you would have to export private key material, which seems like a bad design pattern to encourage.  

--Richard

Received on Friday, 26 April 2013 16:47:24 UTC