On 5/10/12 8:31 AM, Jarred Nicholls wrote:
On Thu, May 10, 2012 at 11:11 AM, Eric Rescorla <ekr@rtfm.com> wrote:
On Thu, May 10, 2012 at 7:56 AM, Jarred Nicholls <jarred@webkit.org> wrote:
> Where the private key is directly accessible by script loaded from
> same-origin?
>
> Compromised server injects hostile script into a page response, grabs the
> private key, posts it to a foreign server, and now the private key has been
> stolen and used to decrypt any data between the server and its clients
> out-of-band.

Yes, this is the case people raise most often. I see a number of
problems with this
line of argument.

To take the specific example of encrypted data where the key pair used to
decrypt it is stored in the browser, it has bad interactions with:

(a) Any time the user somehow wipes his client-side state. I don't have data
on this to hand, but last time I looked this happened quite often.
(b) Any time the user switches browsers, with sync thus becoming a critical
path item opening a whole new can of worms. 

Imagine how I would build an encrypted version of gmail with this design,
for instance.

Right.  Not to mention that the same argument can be made regarding stealing the unencrypted data and posting it to a foreign assailant, where obtaining the key means little to nothing when it is just a means to an end, i.e. stealing a particular client's encrypted data.  Whether this is a use case to solve or not is to be determined, officially.  Keeping things truly secured on the client would probably amount to a much wider scope to the API, e.g. a combination of signed JS code and a secured JS execution context.
 

Just to clarify one point around the question: Which is worse, stealing the key or stealing the data? The unsatisfying response is "It depends on the key and the data." It's easier to answer with less uncertainty in the case where the key cannot be easily renewed (HSM protected keys are a good example): in these cases a compromise to the key means that a security hole cannot be plugged with a new firmware load that plugs the application level flaw, which is a common response.

Mitch


For both these reasons, it seems likely that any Web app that uses this API will
want to favor designs that don't require long-term browser-side persistence of
keys, or at least can auto-refresh them, the way that BrowserId does now.
Of course, for any interactive protocol, you should be using crypto
that provides
PFS, so this kind of key theft is an issue would have much less salience.

Most vendors have secure sync protocols already that would be fairly easy to enhance to sync stored keys.  While it is a consideration in terms of adoption and practical usage, I believe this is a problem that's out of scope of the API and WG.
 

-Ekr