4

在Cammon Criteria标准的第二部分中，有一个名为FTP的类。在智能卡和Java卡的安全目标中，提到卡必须满足这些要求。下面您会看到我的JCOP v2.4.2 r3智能卡的此类的两个元素：

6.1.9.10 FTP_ITC.1/CM Inter-TSF可信信道

  • FTP_ITC.1.1/CM：

TSF 应在其自身和另一个受信任的 IT 产品之间提供一个在逻辑上与其他通信渠道不同的通信渠道，并提供对其端点的可靠标识并保护渠道数据不被修改或泄露。

  • FTP_ITC.1.2/CM：[编辑精炼]

TSF 应允许放置在发卡机构安全环境中的 CAD 通过可信通道发起通信。

  • FTP_ITC.1.3/CM

TSF 应通过可信通道发起通信，以便在卡上加载/安装新的应用程序包。应用说明：Java Card 平台上没有动态包加载。只有在发卡机构的要求下，才能在卡上安装新软件包。

6.1.14.2 FTP_ITC.1/LifeCycle Inter-TSF 可信通道

  • FTP_ITC.1.1/生命周期：

TSF 应在其自身和另一个受信任的 IT 产品之间提供一个在逻辑上与其他通信渠道不同的通信渠道，并提供对其端点的可靠标识并保护渠道数据不被修改或泄露。

  • FTP_ITC.1.2/生命周期：

TSF 应允许 [分配：另一个受信任的 IT 产品] 通过受信任的渠道发起通信。

  • FTP_ITC.1.3/生命周期：

TSF 应通过可信通道发起通信，用于[分配：设置卡生命周期状态和设置操作系统内部生命周期状态]。

问题是我如何测试卡以查看它是否符合这些要求？在向卡发送和接收 APDU 时使用加密方法，是否满足该方法的证明？

无论如何，我可以向卡发送加密形式的 APDU 吗？我的意思是，我可以以加密形式而不是普通 (= 00a40400 ...) 向卡发送 SELECT APDU 命令吗？可能吗？

4

1 回答 1

0

如果您不是卡的制造商，则无需证明要求。您只需要索取认证报告即可。当然，您可能仍需要为您的特定应用程序遵守保护配置文件/安全目标。在这种情况下，您必须确保遵守上述先前制定的规则。这可以被审查和 - 如果保护级别足够高 - 被审计。

如果您有全球平台密钥，您可以将加密的 APDU 发送到卡上。然后，您可以通过 GP 安全通道使用 STORE DATA 来个性化卡上的应用程序（小程序）。当然，这种情况下的小程序必须已经被编程为使用卡上 GP API 解包 APDU。但是，按名称选择的名称由卡运行时拾取，并且应该以明文形式发送。

于 2017-09-16T00:11:19.967 回答