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

On Thu, Jun 9, 2011 at 10:32 AM, Jarred Nicholls <jarred@sencha.com> wrote:
> I think everyone's been thinking *waaaay* too deep into this and its uses.

Shouldn't we?  Surely we want to know if we're doing something here
that solves more problems than it creates, and so on.  The analysis
has to be deep.

>  It appears the only thing that comes to everyone's mind is data sharing
> between two entities over the web.  While that is one reason, and certainly
> is practical given a secure key exchange, the things that come to my mind
> are:
>
> performance - I now have a local/native way to generate MD5 and SHA hashes,
> perform symmetric encryption or HMAC signing a data set, etc.

Sure, but what for?  If you're signing or MACing documents... what
keys are you using? whence do they come? why do we trust the calling
script to use them?  These are the sorts of questions we must ask.

> data storage - this library wouldn't be trying to solve secure communication
> over the web...maybe I want to encrypt and store in localStorage, or write
> to the file system.

But... why shouldn't the browser (or platform) take care of local
storage encryption?  What advantage is there to be had from doing this
in a script?

One answer: browsers and platforms will be slow to ship encrypted
local stores, whereas scripts like this can be whipped up and deployed
in a matter of days.  But the trust issues remain.

> Browser engines are also used in local application shells.  I created
> Sencha's runtime based on QtWebKit port, and there's also Adobe AIR, etc.
>  I'd rather have a web-standard crypto library to write against than add my
> own native bindings like I do today so I can continue writing everything in
> JavaScript.

Yes, JS crypto APIs will be useful for embedded browsers where some
scripts are part of the local TCB.  That's a fair point.  I'm not sure
this will be enough to justify JS crypto APIs (though I'm certain
they'll happen anyways).

> As far as a web-based use case, one that comes to mind is identity
> verification.  Start with a secure up-front key exchange after some
> authentication between an authoritative store (server) and a client
> application (credentials + e.g. HTTPS) or a restored/loaded key from local
> persistence.  The client can then send information that is signed and
> verified as being from them (e.g. HMAC) and there was no tampering of data,
> to any number of end receivers that also hold the key.  This is at an
> application level clearly, not at the protocol level, which is the desire
> here.

I object to this, at least if we don't have a) a script trust system,
b) an interface to tokens (smartcards, softtokens).  It's not that
this approach is useless, but that it will lead to a false sense of
security.

> Just having these low-level APIs gives the applications power to do whatever
> scheme they want.  In general, I'm thinking in terms of a much larger
> picture than web communication, including local/offline tasks.

Whereas I'm thinking of trust issues.  It doesn't matter what the
application is or is doing -- if I can't trust it, then JS crypto APIs
don't change anything.

Now, we could just say that the TLS server cert PKI is all we need for
establishing trust.  That seems to be an underlying assumption.  Under
that assumption there's nothing really wrong with JS crypto APIs.  So
I should say that it is this assumption that I take issue with; I plan
on expanding on this soon.

Nico
--

Received on Thursday, 9 June 2011 16:16:30 UTC