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> 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 19:45:42 UTC