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

Question

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

6.1.9.10 FTP_ITC.1/CM 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可信信道

• FTP_ITC.1.1/生命周期：

TSF应在其自身和另一个可信IT产品之间提供一个通信通道，该通信通道在逻辑上不同于其他通信信道，并提供对其端点的确定和对信道数据的保护，使其不受修改或泄露。

• FTP_ITC.1.2/ LifeCycle：

TSF应允许分配:另一个受信任的IT产品通过可信通道发起通信。

• FTP_ITC.1.3/ LifeCycle：

TSF应通过可信的分配通道发起通信:设置卡片生命周期状态和设置OS内部生命周期状态。

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

不管怎样，我能用加密的形式把APDU发到卡上吗？我的意思是，我可以将SELECT APDU命令以加密的形式发送到卡片上而不是普通的(= 00a40400 .)吗？有可能吗？

Answer 1

如果你不是卡的制造商，你不需要证明这些要求。你只需要问一下认证报告。当然，对于特定的应用程序，您可能仍然需要遵守保护配置文件/安全目标。在这种情况下，您必须确保遵守前面建立的规则。这是可以审查和-如果足够高的保护水平-审计。

如果您有全局平台密钥，您可以将加密的APDU发送到卡上。然后，您可以使用GP安全通道上的存储数据来个性化卡上的应用程序(applet)。当然，在这种情况下，applet必须被编程来使用卡片上的GP API来打开APDU。然而，SELECT by名称是由卡片运行时获取的，应该以普通的方式发送。