【问题标题】:Is OpenSC fully based on PC/SC or does it also use different commands?OpenSC 是完全基于 PC/SC 还是使用不同的命令?
【发布时间】:2019-12-16 23:21:32
【问题描述】:

我正在尝试学习智能卡编程的基础知识,我想为卡添加对 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 与所有智能卡不兼容的事实让我认为它使用专有命令)。

【问题讨论】:

    标签: smartcard javacard pkcs#11 pcsc opensc


    【解决方案1】:

    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 的组合更好。

    【讨论】:

      【解决方案2】:

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

      OpenSC 正在尝试在卡上创建一个 PKCS#15 应用程序以用于 PKCS#11 访问。如果你不能这样写或者数据已经以专有格式存在,事情会变得非常复杂。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-03-14
        • 2014-09-26
        • 2023-03-17
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多