Re: Yubikey announces v4 with PKCS#11 smart card features

>> 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