Re: Use case classification, and associated security models

----- Original Message -----
> From: "Emily Stark" <estark@MIT.EDU>
> To: "James L. Davenport" <jdavenpo@mitre.org>
> Cc: public-webcrypto@w3.org
> Sent: Tuesday, June 12, 2012 4:11:07 PM
> Subject: Re: Use case classification, and associated security models
> 
> These use cases should be qualified by the assumption that all the
> servers
> storing the encrypted data are honest-but-curious, right? When a
> smart card
> is used for authentication or signing, it seems possible to protect
> the
> user from a malicious server (as is being discussed in other threads:
> by
> having the browser obtain the user's permission to authenticate with
> a
> particular key, or by having the browser require the user to approve
> the
> statement being signed), but this protection doesn't seem easily
> obtainable
> when the key on the smart card is being used for decryption. Almost
> certainly out-of-scope, but it might be nice to have a decryption
> operation
> that outputs the plaintext in some UI that's isolated from the
> application

Indeed, this is exactly the kind of browser feature we may want to spend a little time describing to browser makers that helps make the crypto API more secure to use. I can imagine privileged (chrome) UI elements that are used to type plaintext into and decrypt and read plaintext in that are not accessible by content JS. I plan on working on an extension that does this in the future. The UX here will be tricky. And of course, I agree this is way out of scope:)

David 

> (instead of returning the plaintext to the application), and some
> kind of
> ciphertext that can only be decryptable by this isolated-output
> decryption
> operation.

Received on Wednesday, 13 June 2012 17:14:11 UTC