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. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
