中本聪论文
智能卡是一种安全地持有私钥而不会将其从存储中放出的设备。 信用卡上的芯片是“智能卡”(是的,术语不明确-卡和芯片可互换地称为“智能卡”)。 有较小的USB可插拔硬件读取器,仅可容纳芯片(没有实际的卡,例如此卡)。
但是有什么用? 几年前的w3c研讨会概述了其中的一些内容:多因素身份验证, 状态接受的电子标识 ,数字签名。 所有这些都是更大范围的一部分–使用互联网现在是主要的通信手段。 我们正在将大多数现实活动在线上转移,因此,有一种方法可以识别我们在线的人(例如,到政府,银行),或者能够在线(具有法律价值)签署文件。
因此,欧盟引入了eIDAS法规 ,该法规定义(除其他事项外)电子标识和数字签名。 在那里建立的框架旨在具有法律约束力的电子通信,这在许多情况下都很重要。 您是否进行过打印符号扫描练习? 未经授权的人可以访问您的电子银行吗? 好吧,该法规应该解决这些以及更多问题。
两因素身份验证是另一个更广泛的概念,它具有大量次优解决方案。 OTP令牌,Google身份验证器,短信代码确认。 所有这些都有问题(例如时钟同步,短信拦截,费用)。 有类似YubiKey的硬件令牌,但它们仅提供智能卡具有的功能的子集。
但这不仅仅涉及法律上认可的在线行动和两因素身份验证。 它开辟了其他可能性,例如更安全的在线信用卡付款-例如,将卡放在阅读器中并输入PIN,而不是输入卡号,CVC,日期,名称,3d密码等。
经过这么长时间的介绍,我发现了一个问题:浏览器不支持智能卡。 在法律认可电子签名的欧盟中,始终很难使它们与浏览器一起使用。 到目前为止的解决方案:Java applet。 Java applet可以通过java crypto API与智能卡进行交互,从而提供签名功能。 但是,随着Java applet的弃用,这个持续不断的奋斗时代将很快结束(这是一个奋斗-必须至少单击两次确认并保持Java处于最新状态,即使对于开发人员来说也是麻烦的)。 几年前,在Firefox和IE中曾经有一种使用window.crypto和CAPICOM API做到这一点的方法,但这些方法已被弃用。
最近的趋势是使用“基于云”的方法,其中密钥位于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
中本聪论文