Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal

Nico Williams wrote:
> You've sold me on one clever use for JS crypto APIs. Given that I can
> ignore my concern regarding false sense of security in other uses.
> I'm still concerned that developers will not use crypto correctly
> (consider the CBC padding oracle vulnerabilities we've seen in the
> past), so I'd rather we offer AEAD APIs than, or at least in addition
> to, say, raw AES APIs.

I think there are many levels to this. One is "give people tools that they could use correctly to do something reasonable and clearly better than what they can do now" and the other is "give people tools that guide them to doing things correctly, and make it difficult to do things incorrectly." Exposing a raw AES operation definitely doesn't fit in the latter category, but it does seem to fit in the former--because a browser-provided AES operation can mitigate some timing attacks that a pure-JS implementation has no hope of mitigating (AFAICT).

I have heard a lot of talk about SJCL being on the edge of being good enough to do something useful. People who are more adventurous than me are already using SJCL (or similar) to try to do real, important, work. Given that, I think it does make sense to have some low-level operations that make the use of SJCL (or similar) "safe enough" for some useful definition of that term, until high-level cross-browser crypto, key-management, and content-firewalling APIs are ready. A cross-platform secure PRNG API is an obvious improvement along those lines. 

The goals of the high-level crypto-related APIs are not clear. One ambitious goal would be to support use cases like a an HTML5 email app (like GMail) with S/MIME support. When you open up an encrypted S/MIME message, the browser can automatically decrypt it after the user has agreed to let it do so for this service. The browser allows HTML5 code (HTML+JS+CSS) from the provider to interact with the decrypted content, but it prevents any of the decrypted information from leaking--including leaking back to the email provider. When you reply or forward a message, somehow the web app can determine which keys to use for the recipients, without leaking unnecessary information about your social network back to the email provider.

To support this kind of use case, many things would have to change, besides supporting a crypto API and besides providing some kind of safe access to the user's keys. For example, the browser would have to limit the communication capability of the HTML5 code that is interacting with the decrypted data. And, it would have to prevent the contents of the decrypted data from affecting the layout of the part of the page that is observable to the HTML5 code that hasn't been trusted to have access to the decrypted data, because that would create a side channel. It would have to prevent prefetching of network resources linked from the decrypted content, and avoid it would have to avoid sending the referer header for links in the decrypted content that are clicked, for the same reasons. Etc., etc. 

How much of all of that would be the responsibility of the browser? How much of this responsibility can/should the browser pass off to the web app? Should we be focused on the browser enforcing a particular security model, or should we focus on the browser enabling web apps to enforce their own security models?

Cheers,
Brian

Received on Tuesday, 14 June 2011 00:37:10 UTC