通用浏览器访问智能卡的体系结构? 或者:如何弥合从浏览器到PC / SC堆栈的差距?

从通用浏览器(通过http连接到服务器)访问本地智能卡的可能的客户端体系结构有哪些,最好是使用Javascript,对最终用户来说最小的安装麻烦是什么? 服务器必须能够至less向卡发出其select的APDU(或者可以将其中的一些委托给它所生成的客户端代码)。 我假设在工作PC / SC堆栈的客户端可用性,完成与智能卡读卡器。 至less在Windows,XP,现代OS X和Unix之后,这是一个合理的假设。

我到目前为止确定了以下选项:

  1. 一些自定义的ActiveX。 这就是我现有的应用程序所使用的(我们在内部开发的),一旦IE获得安装ActiveX的许可,部署对于客户来说是非常容易的,但是它不符合“通用浏览器”的要求。
    更新 :ActiveX主要由不推荐的IE支持,包括IE11; 但不是由边缘。
  2. 一些使用Netscape Plugin API的PC / SC浏览器扩展,看起来像上面的平滑扩展。 我find的唯一一个现成的软件是SConnect ,但它看起来几乎没有活力 ,它的API 文档(webarchive)不再正式可用,而且与特定的智能卡供应商有着紧密的联系。 原则可能很好,但是为每个平台制作这样一个插件将会是很多工作。
    更新 :许多浏览器(包括Chrome和Firefox)都会丢弃NPAPI支持。
  3. 运行在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的东西签署握手时签署的东西?

Interesting Posts