通用浏览器访问智能卡的体系结构？ 或者：如何弥合从浏览器到PC / SC堆栈的差距？
从通用浏览器（通过http连接到服务器）访问本地智能卡的可能的客户端体系结构有哪些，最好是使用Javascript，对最终用户来说最小的安装麻烦是什么？ 服务器必须能够至less向卡发出其select的APDU（或者可以将其中的一些委托给它所生成的客户端代码）。 我假设在工作PC / SC堆栈的客户端可用性，完成与智能卡读卡器。 至less在Windows，XP，现代OS X和Unix之后，这是一个合理的假设。
我到目前为止确定了以下选项：
- 一些自定义的ActiveX。 这就是我现有的应用程序所使用的（我们在内部开发的），一旦IE获得安装ActiveX的许可，部署对于客户来说是非常容易的，但是它不符合“通用浏览器”的要求。
更新 ：ActiveX主要由不推荐的IE支持，包括IE11; 但不是由边缘。 - 一些使用Netscape Plugin API的PC / SC浏览器扩展，看起来像上面的平滑扩展。 我find的唯一一个现成的软件是SConnect ，但它看起来几乎没有活力 ，它的API 文档（webarchive）不再正式可用，而且与特定的智能卡供应商有着紧密的联系。 原则可能很好，但是为每个平台制作这样一个插件将会是很多工作。
更新 ：许多浏览器（包括Chrome和Firefox）都会丢弃NPAPI支持。 - 运行在Oracle的JVM（1.）6或更高版本上的Java Applet，它随
javax.smartcardio。 从function的angular度来看，这是很好的，有据可查，我可以忍受一些已知的错误，但是我担心接受Java作为浏览器扩展的不可抗拒的下滑螺旋。
任何其他的想法？
另外：是否有某种方法可以防止恶意服务器（例如，提供3个错误的PIN码来阻止一个卡，仅仅为了它的恶劣;或制造一些更邪恶的东西）浏览器的任何PC / SC接口的滥用。
事实是，浏览器不能与（encryption）智能卡交谈而不是build立SSL。
您需要使用浏览器执行的其他代码才能访问智能卡。
有几十个定制和专有的插件（使用你提到的所有三个选项）出于各种目的（签署是最stream行的，我猜），因为没有标准或普遍接受的方式，至less在欧洲，我确信其他地方以及。
创build，分发和维护自己应该是一个爆炸，因为浏览器每个月都会发布，而且每个新发布的版本都会根据UI技巧进行更改，所以您可能需要经常调整代码。
而且你可能会希望具有GUIfunction，至less要求用户访问卡或其上的某些function的权限。
为了创build一个多平台，多个浏览器插件，可以使用firebreath之类的东西。
就个人而言，我不认为把PC / SC暴露给networking是件好事。 PC / SC本质上是一个低级别的协议，当暴露这个时，你可以暴露块级访问你的磁盘，并希望“在Web上的应用程序是我的只有他们performance好”（这应该回答你的“也“）。 与此同时，像SConnect这样的瘦板是最容易创build的，它提供了一个javscript plugin.sendAPDU（）风格的代码（或者包装所有的PC / SC API，让javascript调用者处理相同级别的细节如本地PC / SC API使用情况）。
为此目的创build一个插件通常是由急剧的电stream缺陷驱动的。
解决未来（移动等）是另一回事，像W3C webcrypto和OpenMobile API这样的东西最终可能会以某种方式创build一些将客户端密钥容器公开给Web应用程序的东西。 如果你的智能卡目标是密码学，我的build议是避免PC / SC和使用平台服务（Windows上的CryptoAPI，OSX上的Keychain，Linux上的PKCS＃11）
任何一种devise都有要求。 这一切都适用，如果你想使用密钥而不是任意的APDU-s。 如果你的要求是发送任意的APDU-s，那就创build一个插件，然后继续。
更新 （8/2016）：Web正在讨论一个名为WebUSB API的新API。 您可以使用Chrome v54 + 。
此标准将在所有主stream浏览器中实施，并将取代对Smard卡的第三方应用程序或扩展的需求:-)
所以新的答案是YES！
和OSI类似的架构栈是：
- PC / SC
- CCID v1.1
- WebUSB API
- USB驱动程序， 即libusb 。
注意： Google声明他们将在2017年放弃Chrome应用程序 。
前一个开关 ：
现在（2015年），您可以使用chrome.usb API创buildGoogle Chrome应用。
然后通过CCID兼容接口访问智能卡阅读器。
它不是跨浏览器，而是JavaScript可编程和跨平台的。
无论如何，现代浏览器不再支持Netscape Plugin API（NPAPI）。 而Java小程序正在被浏览器厂商解雇。
我刚刚发布了一个解决这个问题的testing版插件。 此testing代码可在此处获得：
https://github.com/ubinity/webpcsc-firebreath
这个插件基于Firebreath框架，并且已经在Linux / WinXP / Win7下用Fireofx和Chrome进行了betatesting。 提供源代码和扩展包。
基本的想法是提供一个PCSLite的API访问，然后开发一个更友好的JS-API。
这个插件正在积极开发，所以随时发送任何报告和请求。
对于你的第一个问题，我有一点希望：要么你满足于智能卡function的一小部分（如签署电子邮件或PDF），那么你可以使用一些现成的软件（如PKCS），理想的维护智能卡公司，或者你想要更广泛的function，需要投入相当大的精力在自己的。 当然PCSC是可以select的起点。
至less对于你的“也：”有一些希望。
1）注意，某些规范（例如ICAO /德国BSI TR-3110）要求采用一种方法，即在PIN未被阻止的情况下，但是在错误计数器在答复之前遇到1的情况下尽可能使用大量的时间。 必须使用不同的命令启用最后的尝试，否则不会进行进一步的比较和错误计数器调整。
2）通过要求安全的消息来简单地保护validation命令。 敏感的应用程序使用安全消息的一切，所以第一步会话密钥被取消，这是第二次适用于所有后续的命令和响应。 其效果是，在错误计数器的比较或修改完成之前，由于错误的MAC，命令被拒绝。
还有另外一个浏览器插件，类似于http://github.com/cardid/WebCard上提供的@cslashm提供的插件。; 也是开源的，可以根据原始问题的要求安装“最小安装麻烦”。 你可以看到一个使用http://plugin.cardid.org的例子;
WebCard已经在IE 8到11，Chrome和Firefox在Windows中以及在Mac OS X中的Chrome和Safari中进行了testing。由于仅仅是PC / SC的包装，它需要在Mac OS X中从http：//安装智能卡服务smartcardservices.macosforge.com
由于Chrome和Firefox将停止NPAPI插件的支持，因此没有安全的解决scheme来维持读取智能卡的会话，而不是您的证书有相互SSL的支持，我回答了类似的问题来源 ，它可能帮帮我
它的脏，但如果它是可接受的/可行的在客户机上安装一个桥梁守护进程/服务，那么你可以写一个本地桥接服务（例如在Python / pyscard），通过REST接口公开智能卡，在本地服务（外观）和远程服务器API之间进行调解的浏览器。
谈到Chrome，您现在可以使用Google提供的智能卡连接器应用程序 ，捆绑PC / SC-Lite端口和通用CCID驱动程序。
应用程序本身通过前面的评论者提到的chrome.usb API工作。
因此，现在有可能开发人员只编写PC / SC API之上的部分（由连接器应用程序公开），而不是重写整个堆栈（从最低级别开始 – 原始USB）。
客户端，客户端，客户端…插件，.. JSApis ..那么..对于某些我们知道这一点：所有浏览器，当与Apache或IIS服务器进行通信时，实际上签署“ 东西 ”时，HTTPS / SSL握手过程需要。
例如，像这样的一个典型的Apacheconfiguration：
SSLVerifyClient require SSLVerifyDepth 10 SSLOptions +FakeBasicAuth +StdEnvVars +ExportCertData +OptRenegotiate
启动密码键盘popup，用户必须插入智能卡引脚继续。
那么，我的想法是：为什么不转向服务器，并调整该行为，以便上传一个字节stream的东西签署握手时签署的东西？
