浏览器中本机智能卡支持的案例

智能卡是一种安全地持有私钥而不会将其从存储中放出的设备。 信用卡上的芯片是“智能卡”（是的，术语不明确-卡和芯片可互换地称为“智能卡”）。 有较小的USB可插拔硬件读取器，仅可容纳芯片（没有实际的卡，例如此卡）。

但是有什么用？ 几年前的w3c研讨会概述了其中的一些内容：多因素身份验证， 状态接受的电子标识 ，数字签名。 所有这些都是更大范围的一部分–使用互联网现在是主要的通信手段。 我们正在将大多数现实活动在线上转移，因此，有一种方法可以识别我们在线的人（例如，到政府，银行），或者能够在线签名（具有法律价值）至关重要。

因此，欧盟引入了eIDAS法规 ，该法规定义（除其他事项外）电子标识和数字签名。 在那里建立的框架旨在具有法律约束力的电子通信，这在许多情况下都很重要。 您是否进行过打印符号扫描练习？ 未经授权的人可以访问您的电子银行吗？ 好吧，该法规应该解决这些以及更多问题。

两因素身份验证是另一个更广泛的概念，它具有大量次优解决方案。 OTP令牌，Google身份验证器，短信代码确认。 所有这些都有问题（例如时钟同步，短信拦截，费用）。 有一些硬件令牌，例如YubiKey ，但它们仅提供智能卡具有的部分功能。

但这不仅仅涉及法律上认可的在线行动和两因素身份验证。 它开辟了其他可能性，例如更安全的在线信用卡付款-例如，将卡放在阅读器中并输入PIN，而不是输入卡号，CVC，日期，名称，3d密码等。

经过这么长时间的介绍，我发现了一个问题：浏览器不支持智能卡。 在法律认可电子签名的欧盟中，始终很难使它们与浏览器一起使用。 到目前为止的解决方案：Java applet。 Java applet可以通过java crypto API与智能卡进行交互，从而提供签名功能。 但是，随着Java applet的弃用，这个不断挣扎的时代将很快结束（这是一个挣扎-必须至少单击两次确认并保持Java为最新，这对开发人员来说也是一个麻烦）。 几年前，曾经有一种使用window.crypto和CAPICOM API在Firefox和IE中做到这一点的方法，但这些方法已被弃用。

最近的趋势是使用“基于云”的方法，其中密钥位于HSM上。 这当然很有用，但是身份识别问题仍然存在–要访问HSM上的密钥，同样需要两步验证。 将硬件令牌“掌握在手中”可以增强安全性。

爱沙尼亚（世界上数字政府最多）的聪明人比Java或HSM有更好的解决方案-允许与其ID卡（是/有智能卡）进行交互的浏览器插件。 解决方案在这里和这里 。 效果很好–您安装了一个插件（一个多功能安装程序），并且可以使用javascript签署文档。 您还将安装正确的PKCS库，以及允许使用硬件令牌进行TLS 1.2身份验证（标识和身份验证与签名）所需的根证书。 这种方法的缺点是，它有些脆弱，并且取决于浏览器的异想天开–如果某些浏览器决定弃用某些插件API，则必须不断升级插件，并且有被完全破坏的风险。

另一种方法是“本地服务”方法，它有两种风格。 一种是–安装一个公开应用程序的本地应用程序，该应用程序公开一个HTTP接口，并使用javascript和正确的同源配置将您签名所需的文件发送到该服务，然后将结果作为HTTP响应获取，然后可以再次使用javascript，附加到请求签名的页面。 不利之处–安装服务以监听没有管理员权限的给定端口。 另一种方法是让应用程序挂接到自定义协议（例如signature：//）。 因此，每当页面要用户签名时，它都会打开signnature：// path-to-document-to-sign，由本地安装的应用程序拦截，执行数字签名，然后将结果推送到（one-时间）在文档的元数据中指定要签名的URL。 像这样的事情是由4identity.eu实现的，并且确实有效。

现在，签名是一回事，标识（TLS客户端身份验证）是另一回事。 据称，一切都应该在这里进行-PKCS＃11是一个标准，应该允许使用智能卡进行TLS客户端身份验证。 现实是-事实并非如此。 您通常需要特定于供应商的PKCS＃11库。 OpenSC是一个很酷的工具，可与许多智能卡一起使用，仅可与Firefox和Safari一起使用。 Charismatics commercial是一种软件，应该可以与所有智能卡一起使用-嗯，并非总是如此。

而这里的问题是智能卡供应商。 之所以需要OpenSC和Charismatics，是因为即使有一些PKCS标准，智能卡还是一团糟。 这不仅是一团糟，而且是封闭的，秘密的一团糟。 在大多数情况下，APDU（您发送到智能卡以与其进行通信的命令）都是秘密的。 即使您购买了成千上万张卡，也不会了解它们-您只能获得了解它们的定制供应商软件。 然后，您必须对他们进行反向工程，才能知道如何与他们实际交谈​​。 它们不仅在供应商之间不同，而且在不同供应商的卡型号上也不同。 因此，爱沙尼亚的方法实施起来更简单-他们只有一种类型的智能卡，发给所有公民，而且他们大多处于控制之下。 在其他国家，这真是一团糟。 至少要支持十二种不同类型的卡。

因此，我的首要要求是向智能卡供应商（数量不多）提供服务-请修复您的混乱情况。 摆脱多余的“通过模糊处理获得安全性”，使浏览器无需额外的欺骗就可以与您通信。

我的第二个请求是对浏览器供应商的请求–请本机支持智能卡加密。 不幸的是，由于上述智能卡混乱（除其他事项外），硬件加密已明确从Web加密API中排除。 作为后续措施，有一个硬件安全工作组 ，但据信它仍在“进行中”，我的感觉还不是很多。 在w3c中，重要的是，浏览器供应商必须同意在其成为标准之前实现某些东西，而且我听说有些人反对智能卡集成。 由于上述混乱，我猜是。

您可能会说–标准化将解决此问题。 好吧，到目前为止还没有。 欧盟官员已经意识到了这个问题，eIDAS法规可能会受到这些技术问题的阻碍，但它们无能为力，因为欧盟不是标准化机构。

因此，归结为浏览器和智能卡供应商共同努力一劳永逸地解决此问题。 因此，请这样做以启用更安全和合法合规的网站。

翻译自: https://www.javacodegeeks.com/2017/02/case-native-smart-card-support-browsers.html