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

On Mon, Jun 6, 2011 at 11:16 PM, Anders Rundgren
<anders.rundgren@telia.com> wrote:
> On 2011-06-07 03:58, Nico Williams wrote:
>> That said, a smartcard interface is the most we could do in terms of
>> browser integration with JS crypto APIs, and even that is pretty lousy
>> -- the user can't possibly know what some script intends to do with
>> some key, nor can the browser figure it out either.  And yet, if we
>> don't even do that, then what do we expect a JS crypto API to do for
>> us, in terms of security?  A JS crypto API will NOT help us improve
>> security unless we also greatly improve server/script authentication.
>
> Well, that's one approach.  I'm fairly skeptical about the prospects
> for trusted code and therefore delegate the gory stuff to the browser
> itself.  Creating a multistep E2ES (End-to-End Security) provisioning

Wait a minute.  If we don't even trust the browser, we're done, we
might as well go home.

Now, I understand that local security is a challenge.  But from a
network protocol point of view we have no choice but to assume local
security.  (Even if we relied on one-time passwords/keys, we'd still
have the problem that a compromised end-point with access to a user's
credentials can misuse the user's session.)

But there's a major distinction between trusted code in the browser's
TCB, and code that is downloaded.  The latter is not trusted nor
trustworthy unless we rely on code signing (and even then, the code
signer probably doesn't audit the source code nor any build systems,
in which case code signing adds less than one might think, though
still more than nothing, even if only marginally).

So let's not say that we can trust scripts because we can't trust
browsers!  That's a serious fallacy.

> scheme like KeyGen2 based on a set of JS-methods and objects seems
> infeasible; it will most likely turn up as MSFT's "CertEnroll" which
> has been replaced by proprietary solutions since it simply doesn't
> work.  MSFT is reportedly replacing it with something more along the
> lines I propose, running in trusted code and uses XML Schema.

I don't follow this comment.

> That said, a JS crypto API would be great but it does not eliminate other
> solutions it may complement it.

Great... for what?

Prediction: sites will claim that they use AES-256 or whatever as a
badge of trustworthiness, and they will use such algorithms -- in
their scripts, and mostly just so they can make such claims.  And yet
look ma! no security!

Nico
--

Received on Tuesday, 7 June 2011 17:08:12 UTC