Re: Trusted UIs. Was: proposed navigator.mozPay() changes

I will try my best to answer these very good questions...

Kumar McMillan <kmcmillan@mozilla.com> Wrote:

> Do you have a concrete example of how PKI can be used to mitigate phishing attacks?

Using plain vanilla TLS client certificate authentication mitigates phishing.  Well, it doesn't permit you from logging in to a bad site but even if you do the bad site cannot use the authentication on any other good or bad site.

> I want to understand it better. Are you envisioning some token system where a user
> never reveals their private key (obviously) but instead signs tokens to grant limited
> access to merchants?

The core idea is that the user during signup gets a token (=key) that can only be used by software that the issuer of the key have accepted.  Merchants never get any direct access to keys, they can only "activate" the (by the issuer) trusted software which under the user's control may sign a payment authorization and transfer it with postMessage ().  If the merchant is bad or not may also be possible for the trusted software to find out by scanning black- or white-lists or through checking the merchant's certificate.  Note: the browser doesn't have to know _anything_ about who is trustworthy or not; it only have to provide the "mechanics".


> How would a non-technical user be protected against phishing for
> access to the token generator service?

The primary client-token would be static but could be used in two entirely different modes: Federated like 3D Secure or push-through-the merchant which I guess is more like EMV.

Being phished during the signup procedure remains a possibility.  I don't believe there can be a cure for that.  Note that signup may also be done in an office using NFC which may be necessary in the EU for new customers.

Signing up for a bad payment provider is still possible.  The primary reason why PayPal and similar third-party providers exist is because the standard methods for credit-card payments on the Internet are stone-age-like.


Erik Anderson <eanders@pobox.com> wrote:

> 1) How is the user "proving who they are"? What are the authentication layers? PIN is not enough.

In most cases PKI would be the primary credential.


> 2) where is the ACL list stored?
> 3) where are the PKI keys stored?

This is actually outside of the architecture but here is a hint of what I'm counting on:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/tee-se-combo.pdf


> 4) who is the issuers of the 3rd party code signing certificate? Root certificates and even issued signing certificates can be stolen.

There is no third-party code signer!  The issuer of the payment credential is (usually) the signer of the trusted code to go with it.  The user doesn't have to trust it and the browser only have to apply its mechanics.

> 5) Even if I was phished once we can ensure the transaction is only authorized once and only for the specified amount.

Since each transaction authorization presumably is signed and targeted for a specific payee, it should be pretty hard to use it multiple times or change amounts.


> 6) how can I de-authorize any private PKI keys, established trusts, ACL lists?

You can delete keys in case you don't want/need them anymore.  ACLs represent trust by the _issuer_ in software and is not likely to be editable.  If a user doesn't trust the software they shouldn't use the payment service.

> 7) how are man-in-the-middle attacks prevented?

I think this is a pretty large question so I would like to get a specific scenario to dwell over...


> 8) Backup of keys and ACL if stored locally.

There is currently no specific solution for this.   This part may also be subject to policies because some keys may be "synced to the cloud" and some wouldn't.

Cheers
Anders

Received on Wednesday, 18 September 2013 16:15:51 UTC