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

Anders,

1) How is the user "proving who they are"? What are the authentication layers? PIN is not enough.
2) where is the ACL list stored?
3) where are the PKI keys stored?
4) who is the issuers of the 3rd party code signing certificate? Root certificates and even issued signing certificates can be stolen.
5) Even if I was phished once we can ensure the transaction is only authorized once and only for the specified amount.
6) how can I de-authorize any private PKI keys, established trusts, ACL lists?
7) how are man-in-the-middle attacks prevented?
8) Backup of keys and ACL if stored locally.

Proper crypto and signing layers are a must but so is authentication layers.

I would love to discuss this further.

Erik

Sent from my iPhone

On Sep 16, 2013, at 3:47 PM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

> Hi,
> This feature have been discussed for ages.  I heard about more than 15 years ago!
> 
> I believe this is not useful (unless you go to extremes such as dedicated PIN and signature terminals),  because it will only really work for security-conscious people but they only represent _a_fraction_ of the user-base.
> 
> Is then all doom and gloom?  No, the root of the problem is that (particularly in the US...) passwords and credit-card numbers is the norm and these are highly susceptible to various kinds of spoofing attacks.
> 
> One of the problems is articulated like this: If the user is tricked by logging in to "paypal.com.wondersite.com" this [presumably bad] site may get direct access to the user's payment credentials.
> This is not the case if the credentials are only usable in an _indirect_ way such as PKI.
> 
> What does this have to do with trusted UIs you may [rightfully] wonder?
> Not much, it is in the merchant end you have this problem because even if you have PKI you don't want evil merchants to withdraw money from your accounts.  The (IMO) best way to do that is through limiting access to your payment credentials so that it can only be used by trusted software.
> 
> The problem with trusted software is that it is either built-in or have to be installed and then automagically be trusted by the user.
> How can an average user have any opinion about what constitutes trusted software???
> IMO, they will _never_ be able to do that. 
> 
> Built-in trusted software is fine but put big constraints on the functionality and also suffer from serious standardization issues.
> 
> The solution which I'm advocating is that each payment network creates their own software but instead of letting the user decide if it is trustworthy or not, let the payment network's credentials declare which software is trusts.  This is BTW an almost exact copy of how current physical payment systems work.
> 
> http://webpki.org/papers/PKI/pki-webcrypto.pdf
> 
> This may not be (surely is not...) the perfect solution but I think it is workable.
> 
> Disregarding implementation issues,
> What are the concrete alternatives including pros and cons?
> 
> Cheers,
> Anders
>

Received on Tuesday, 17 September 2013 00:20:23 UTC