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

On Thu, Jun 9, 2011 at 12:16 PM, Nico Williams <nico@cryptonector.com>wrote:

> 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.
>

Not to the extent of talking about integrating with smart cards and key
stores, etc.  That's an entirely separate proposal and can be built on top
of or beside this.  In my scenario, you asked "where does the key come
from?"...well it can come from a direct exchange, from loading up a file, or
(later on) from a smart card or a key ring on the OS - some of these are
application driven and some are user driven/initiated.  The point is, these
are problems that are solved *before* these crypto APIs are consumed and
have no bearing on them.


>
> >  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?
>

The application would (potentially) be the only thing that can decrypt it,
given that it doesn't persist its key.  If a malicious piece of code on the
local system was able to extract the local storage and extract the keys from
the keyring in the browser/OS (many people click "OK" blindly at User Access
Control prompts :) ), they could decrypt all local storage across many
origins in one fell swoop.


>
> 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.
>

I don't even understand where trust issues arise.  I see no security
implication of any script calling these APIs.  The APIs need to be fed data
from somewhere, and that's either coming from the same origin or the user of
the application.  These APIs are "dumb" and have no security side effect.

Do you think it's dangerous because a script can encrypt data in the name of
obscurity?  Other than that, I don't see where specifically these APIs
present a hazard.


>
> > 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.
>

The script trust issue is above and beyond this API - you're thinking about
the next step.  If a proper trust system isn't in place for users to
initiate and drive keys/certs, then no application has to use these APIs for
data exchange.  But like I noted, there are many other uses for these APIs
besides data exchange.

Hell, I could make an argument that it helps distribute workload by having
clients generate SHA digests and sending the digest to the server, rather
than the server doing it for all the clients.  Imagine I use FileReader and
read in the binary Blob and then want to SHA that blob and send the blob
along with its digest to some other peer, who can then validate.


>
> 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.
>

I think we can break this down; we have two problems:

   1. Performing cryptographic functions, application driven
   2. Performing trusted key resolution/exchange for the subset of
   cryptographic functions that require them.
      1. Application driven - server exchanges with client over secure
      channel and typical authentication system, application manages the key.
      2. User driven - user my provide a key via smart card, choosing a key
      from their OS key ring, selecting a private key file, whatever.

I am focusing on #1, and you are focusing on #2.  They are not the same
problem in my eyes.  #2.1 and #2.2 are also not the same problem.  However,
both #2.1 and #2.2 would occur first and then use #1 for the subset of
crypto functions that are key based; once a key is received, the application
can go to town.  How that key is received and whether it can be trusted by
the user is a problem that needs to be solved, but is not a prerequisite to
these simple/dumb APIs.


>
> Nico
> --
>



-- 
................................................................

*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
<http://twitter.com/jarrednicholls>