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

On Fri, Apr 26, 2013 at 9:46 AM, Richard Barnes <rbarnes@bbn.com> wrote:
>
> 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.

Richard,

Please describe how this is not also a concern with the Web Crypto API.

For example, if you inject code within an origin (eg: via XSS), and
PostMessage the key out. Even if you do not have access to the raw key
material, you can use that to exfiltrate the set of operations out,
and thus do not need to maintain a persistent XSS.

I would suggest that the design constraint you mention has NOT been
part of the API discussion. Whether it should be is a separate
discussion, but at present and historically, I fail to see how the
situation you describe has at all been addressed.

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

Rather than turning this into yet-another-discussion of "Who are we
trying to address" and debates about good hygiene, can we first focus
solely on the *functional* aspects and reach consensus there, which
should hopefully be far less troublesome?

Received on Friday, 26 April 2013 17:51:36 UTC