- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Wed, 18 Sep 2013 23:16:43 +0200
- To: Kumar McMillan <kmcmillan@mozilla.com>
- CC: public-webpayments@w3.org, Erik Anderson <eanders@pobox.com>
On 2013-09-18 18:25, Kumar McMillan wrote: > On Sep 18, 2013, at 11:15 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote: > >> 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". > > I still don't understand how this would work from a user's perspective. If I could see a video or diagram showing real world use maybe I'd understand it better. From what you've written it sounds like you're asking non-technical users to manually enter a unique, short-lived token into each site they want to use. Users will never do this. The idea is essentially creating a web-based counterpart for physical PIN-terminals used in brick-and-mortar shops. The lower part of page #2 of http://webpki.org/papers/PKI/pki-webcrypto.pdf shows a possible user-experience. A static PIN is all you need to enter. On the web you probably first have to select payment method since every payment network probably wants they own UI (PIN-terminal). Compare that to VISA/MC 3D Secure: 1. Fill in all the boring credit-card details (which can easily be phished or misused by the merchant) 2. Fill in the 3-digit "security code" 3. Finally being redirected to your issuer and having to fill in a password, or use an external OTP token or similar. Fortunately all US merchants have ignored 3D Secure although it is a "requirement" :-) Anders > >> >>> 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 21:17:15 UTC