OpenSC是完全基于PC / SC还是也使用不同的命令?



我正在尝试学习智能卡编程的基础知识,我想为卡添加对PKCS#11的支持。供应商不提供任何PKCS#11模块,所以我想使用OpenSC(该卡未列出与OpenSC兼容(。

据我所知,场景应该是这样的:

  1. 计算机上的软件使用OpenSC实现的PKCS#11 API。
  2. OpenSC与PC/SC一起工作,以便构建APDU并将其发送到卡。
  3. 该卡处理命令 APDU 并使用响应 APDU 进行回复。

我需要知道是否足以实现一个能够识别和处理 ISO-7816 指定的所有命令的小程序。

特别是我无法弄清楚整个 OpenSC 实现是否仅依赖于 ISO-7816 指定的命令,或者它是否还使用特定命令(OpenSC 与所有智能卡不兼容的事实使我认为它使用专有命令(。

OpenSC不兼容所有智能卡的事实使我认为它使用专有命令

不,不是真的,而是相反。ISO 7816-4 列出了许多基于文件或记录的智能卡的命令。很少有卡可以完全实现ISO 7816-4中编写的所有命令。此外,即使他们这样做了,标准中也存在许多差距,例如没有清楚地描述错误条件,甚至关于文件系统"根"的多个选项,专有参数,专有命令,没有明确的安全消息传递等。

从这个意义上说,这是一个可怕的标准;你应该把它看作是文件系统卡制造商行业创造他们都可以坚持的东西的糟糕尝试。


此外,支持 7816-4 并不意味着支持任何特定用例。没有关于如何获得签名的说明。至少有PKCS#15(现在也反映为ISO标准(指定了可以找到文件和密钥的位置。但是,如果创建签名,还必须知道创建哪种签名以及应使用哪个命令来执行此操作。

换句话说,通常像OpenSC这样的"中间件"总是必须做一些事情来支持特定的卡。不支持一张卡并不意味着OpenSC以任何方式"错误",它只是意味着对该卡的支持 - 如果它确实文件系统卡或可编程卡 - 尚未测试/实现。


请注意,PC/SC 只是从操作系统(从它源自的 Windows 操作系统开始(处理智能卡的一种标准化方法。这些命令只需要符合ISO 7816-4,但它根本不关心发送什么样的命令或以什么顺序发送。没有任何与PC/SC兼容的智能卡,只有兼容的读卡器(或者,因为它们不仅可以读取,智能卡接口设备或IFD(用于ISO 7816-4兼容的智能卡。

一些硬件令牌也可能与PC/SC兼容,仅仅是因为它们模拟读取器和芯片的组合,或者因为它们内部读取器和芯片(更便宜/更慢的(。其他人在更高层次上工作并使用PKCS#11,它直接定义了加密令牌的接口,并且可以说比ISO 7816-4或-15组合更好地定义。

编写此类实现的最大问题是数据存储在卡上的方式和位置。虽然数据类型和用于访问它们的命令在 ISO-7816 中确实是标准化的,但用于写入的命令却不是。此外,卡在允许的文件类型方面差异很大,并且它们通常还需要标准ISO命令的专有扩展名。

OpenSC正在做的是尝试在卡上创建一个PKCS#15应用程序以用于PKCS#11访问。如果您无法编写它或数据已经以专有格式存在,事情可能会变得非常复杂。

相关内容

  • 没有找到相关文章

最新更新