Re: Reiterating the Key Ownership/SOP Issue

On Wed, Jan 15, 2014 at 4:48 AM, Anders Rundgren
<anders.rundgren.net@gmail.com> wrote:
> Trying to shed some light on this thorny issue...
>
> Using HTTPS with CCA (Client Certificate Authentication) you can indeed [in theory]
> authenticate to _any_ site on the Internet.  So why isn't that considered a problem?
> Because the authentication is performed through _trusted_browser_code_ which also

Are they the same browsers that claim plain text HTTP is good, but
HTTPS using opportunistic encryption via self signed certificates are
bad? Or the same browsers that consider RC4 "High Military Grade?" Or
the same browsers that don't provide TLS above 1.0?

> involves the user in the final decision.  Issuers know this and trusts the code and
> (maybe) users for doing the right thing.
Well, in an ideal world, the user would not have to make a decision
because many will make the wrong decision. Peter Gutmann's Engineering
Security spends a few chapters discussing how and why a user will make
a bad decision.

> Using SOP exceptions however, certificates and keys would be available to any site on
> the Internet (possibly also without user interaction).
I disagree. At minimum, it violates principal of least privilege
because some unknown external party could be granted access to
something they should not have access to.

> No serious issuers accept that
> "their" credentials are directly accessed by arbitrary code on the Internet.
What attacks follow after the user goes through the client
authentication gyrations? Perhaps they ask the user to enter his or
her username/password to verify the account?

> It would be
> like banks sanctioning payment card usage in "fake" payment terminals.  That's why some
> issuers turned to plugins: _to_be_sure_keys_are_only_accessed_by_known_and_trusted_code_.
*Cough*

> So there is as (I see it...) not really a "Key Ownership" issue,
You have one of two owners (I believe). First is the user if he or she
provisioned the key. Second is the other party (for lack of a better
term) if they provisioned the key (either locally with the owner's
permission or remotely and installed it).

Who gets to authorize usage? What if the user approved an external
party to use the identity he generated and the external party quietly
shares your identity information with a partner? Or what if the user
authorized another site to re-use the Bank of England identity?

Who gets to revoke those keys? If the user provisioned it, is it only
the user? If the Bank of England provisioned it, can both the user or
the bank cancel it in an attempt to reduce fraud? Or is the bank the
only party allowed to revoke the key. How do you even handle
revocation?

The real issues will be the legal ones, and they probably won't be
answered. Expect it to be a free-for-all with the users and relying
parties losing.

> but a genuine security problem.
Yes. For example, you *never* apply your secret or knowledge without
authenticating the remote service.

* A key provisioned by you, gets used an external party.
* A key provisioned by Bank of America, gets used an external party.

Even if the external party does not get to see the private key, they
still get to see the effects of applying your secret to the challenge
(or whatever mechanism is in place). Perhaps its an ECDSA with weak
k's so the private key is recovered.

And here's another adverse scenario:

* The external party gets to track you by just gaining knowledge of
the public key part.

These are better than cookies because they will survive browser cache
wipes and advertiser UUID resets.

And if there's identifying information in the certificate (like issued
by Bank of America), then the attacker gains additional knowledge for
a spear phishing attack.

> Addressing this through smart GUIs, is IMHO not really useful
> because _it_still_enables_naive_users_exposing_their_keys_to_arbitrary_web_code_,
> not to mention the fact that certificate selection becomes quite awkward and
> error-prone in the [likely] case you have more than certificate.
Yes.

> The X.509 domain indicator extension which Samuel Erdtman suggested would limit
> key access to a _single_site_ (or a set of sites) which IMO could actually work,
> but this concept has to date not received any support.
Not surprising. They want to run fast and loose.

Jeff

Received on Wednesday, 15 January 2014 15:09:53 UTC