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

>
>
> Nico,
> I was probably a bit unclear :-(
>
> I also share your view that you must be able to trust the
> browser.  My intent was claiming that trusting downloaded
> code has limitations which for example makes it unsuitable
> for implementing protocols like TLS.
>
> There are already a few JS-APIs that does crypto in Firefox
> (generateCRMFobject and signText) but they do a single
> operation and have a built-in GUI as well.
>
> MSFT's CertEnroll needs to muck around in the platform which
> was a cool idea 1998 (win98) but today (with a lot of added
> security precautions) it us just a major PITA.
>
> I think that the use-cases could need some more work to see if
> they really are for real.  Encryption is fine but so far large-scale
> object encryption has failed to materialize due to a lack of
> suitable key distribution techniques which is the reason
> why TLS has completely taken over S/MIME.
>
> I.e. it may not be enough with an API, you may need supporting
> infrastructure.
>
> I will follow these developments with interest!
>
> I would personally forget about local keystores because that's
> you will only end-up with signText V2.
>
> Anders
>
> On 2011-06-07 19:07, Nico Williams wrote:
> > On Mon, Jun 6, 2011 at 11:16 PM, Anders Rundgren
> > <anders.rundgren@telia.com <anders.rundgren@telia.com?Subject=Re%3A%20Smart%20Card%20support.%20Re%3A%20Request%20for%20feedback%3A%20DOMCrypt%20API%20proposal&In-Reply-To=%253C4DEE7F76.1010101%40telia.com%253E&References=%253C4DEE7F76.1010101%40telia.com%253E>> 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?
>
>
I think everyone's been thinking *waaaay* too deep into this and its uses.
 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:


   1. performance - I now have a local/native way to generate MD5 and SHA
   hashes, perform symmetric encryption or HMAC signing a data set, etc.
   2. 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.
   3. 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.

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.

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.

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


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

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