I'm not a paranoid security freak, I just don't feel that a gazillion non-standard java applets all requiring a secure install is exactly thrilling.
The Swedish BankID have recently scrapped their Java applet for custom native code. I believe all bets are off regarding the long-term outlook, Anders Martin Paljak wrote: > On Apr 29, 2010, at 18:32 , Anders Rundgren wrote: >> Peter Stuge wrote: >>> Anders Rundgren wrote: >>>> What I *do* consider a problem is exposing PC/SC to browser code. >>> What API would be OK? Is PKCS#11 much better? >> There should (IMO) not be any crypto API exposure in untrusted browser code. >> >> Mozillas's <keygen> shows that you don't have to. >> >> Microsoft's CertEnroll is a horribly broken scheme based on API access >> from the browsers. It typically requires you to *lower* security settings >> to run at all and still it may ask the user for permission to "enumerate >> CSPs" which is utter nonsense for 99% of all users. > > > This idea is both limiting and kind of idealistic - that all functionality is > implemented in something you need to download and/or comes from a "trusted" > source. Like the way SSL is implemented in the browser, digital signatures > (other than just signing a hash) should also be a standard so that it could > be implemented as a commodity piece and the implementation could be chosen by > the user (like you can choose a browser). > > Theoretically signed applets (which are required to access javax.smartcardio) > should also fix/make harder the problem of arbitrary exposure. > > Operating systems and other layerings are meant to help you expose the lowest > level stuff to outer world. Really paranoid people turn off Javascript by > default but the casual joe could not imagine web without javascript or flash > (OK, people who try flash-ad-free internet usually fall in love with it). > > Not having *really* "trusted" environments (like the TPM promise or HSM based > code) means that there is always an attack vector. I understand that there > are issues whenever you expose your card to an environment where "unknown > code" can access it. But this is the case with casual token use with Windows. > Smart cards enforcing access policies, PINpads etc are all created to > mitigate some of those attacks. > > In the end there's the balance between features and security. And the > abstract term "trust". Maybe browsers should have a "do you want to allow > site X to access your smart cards?" dialog in addition to the "trust" setting > in JVM that comes from an signed applet? Would that be better? I don't know, > maybe playing with Java policy files allows to restrict the access. > > For me Java got a +1 with 1.6 and ability to access smart cards. > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
