通用标准（FTP 类）的智能卡和安全通道要求

Question

在Cammon Criteria标准的第二部分，有一个名为FTP的类。在Smart Card和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/LifeCycle：

TSF 应提供通信渠道 在它自己和另一个在逻辑上是可信的 IT 产品之间 区别于其他沟通渠道，并提供有保证的 识别其端点并保护通道数据 从修改或披露。

• FTP_ITC.1.2/生命周期：

TSF 应允许 [分配：另一个受信任的 IT 产品] 启动 通过可信渠道进行通信。

• FTP_ITC.1.3/生命周期：

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

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

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

Answer 1

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

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