- From: Erik Anderson <eanders@pobox.com>
- Date: Tue, 24 Nov 2015 16:19:38 -0500
- To: Web Payments IG <public-webpayments-ig@w3.org>
>> Speaking as someone who works in the "financial industry" who also >> attended the W3C's WebCrypto Next Steps workshop, PKCS#11 has a >> design which is hostile to usage in browsers, particularly around >> providing a meaningful user experience and easy-to-understand >> interaction flows for user consent. Yubikey only exposes the PKCS#11 to the soft card module/PIV Applet, not to the browser JavaScript. It would be a disaster for every shopping cart to have to load up low level crypto primitives just to checkout and make a payment. https://w3c.github.io/websec/hasec-charter Is the rough charter on how to exposed hardware crypto to the browser. Please participate and provide Wendy feedback. > http://webpki.org/papers/permissions.pdf [3] I agree, however some form of a human confirmation is required. End users dont understand security so if given the opportunity to make a choice they will make the wrong choice. The prompt should say "The site wants access to Bank of America wallet to send a $55.12 payment to Fred". Of course now we need to localize the text, currency convert it, make the wallet aware of 3 way party transactions so it can make a meaningful dialog. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf Is soooo intuitive. Just add a JavaScript interface ontop of that API and feel the pain. >> I personally consider "PKCS#11-in-browser" a fundamentally flawed >> idea. If PKCS#11 is exposed to the browser, why not only expose it to trusted browser extensions? https://browserext.github.io/charter/ Please help provide input to the Browser Extension charter. This way a trusted extension (ie a wallet provider or payment agent) is downloaded from the Google/Apple store and it alone implements the payment interface with low level access to crypto primitives. App developers just get a simple "make payment API" call. > Me too but the W3C folks apparently thinks differently: > https://w3c.github.io/websec/hasec-charter.html [4] > >>> This can be used to safely assure transactions even in a >>> compromised browser. >> >> Nothing can assure that, but hardware tokens can be used to minimize >> the risk of exposure. Nothing is 100% but it will significantly reduce the RISK, which is what KYC/AML and fraud prevention is all about. >> Particularly interesting in this area is U2F, which is already >> supported by most modern Yubikeys, and the new Token Binding >> extension to TLS: >> >> http://www.browserauth.net/ [1] >> >> U2F can be used in conjunction with Channel Bound Cookies to bind >> cookies to a hardware token: >> >> http://www.browserauth.net/channel-bound-cookies [2] Public/Private keys isnt the right answer. You might want to take a look at 1) 2013 President Obama tells the world the US Government must stop sabotaging public cryptography. NSA has been sabotaging the general public cryptography for decades. page 22 of https://www.whitehouse.gov/sites/default/files/docs/2013-12-12_rg_final_report.pdf 2) August 2015 - NSA tells the world don't trust the security Bitcoin was built on. ECC (Elliptical Curve Cryptography) is very susceptible to quantum computing attacks. - https://www.nsa.gov/ia/programs/suiteb_cryptography/ - ECC vulnerabilities https://eprint.iacr.org/2015/1018.pdf (Pay particular interest to this one) We need to move away from using public/private keys as the form of identity. Its definitely not a credential that's bound to the individual. Erik Anderson Bloomberg
Received on Tuesday, 24 November 2015 21:59:27 UTC