javacard - 删除数据字段中带有 SSD AID 的 APDU 命令，返回 6985

Question

我有一个包含 SSD(补充安全域)的 Javacard，我想删除它。通常，当我想从我的卡中删除一个小程序或一个包时，我会在成功的相互验证过程之后发送以下 DELETE APDU 命令(不需要 MAC 或数据字段加密，Security Level == 0 足以用于 DELETE APDU 命令):

--> 80 E4 00 00 LC 4F <AID Len> <AID>
<-- 90 00

上面的命令适用于普通的小程序。但是当我把我的SSD的AID放进去的时候，卡的响应是69 85个状态字，意思是“使用条件不满足”。
由于我的卡中启用了委托(delegate)管理功能，并且 ISD 中加载了公共(public) token key 和收据 key ，我认为可能提到的错误是由于未在 DELETE APDU 命令中使用删除 token 。所以我计算了删除 token 如下:
全局平台卡规范 2.2.0.7:图 C-8:删除 token 计算

DeleteToken = RSA_Sign("00 00 LC 4F <SSD AID Len> <SSD AID>", TokenPrivateKey)

然后我尝试使用以下命令删除 SSD:

--> 80 E4 00 00 <LC+Len(DeleteToken)> 4F <SSD AID Len> <SSD AID> 9E <Len(DeleteToken> <DeleteToken>
<-- 69 85

但我又得到了 6985 状态字。有谁知道问题出在哪里以及如何解决？
更新:
我什至用 P2 = 0x80 尝试了 DELETE APDU 命令。删除带有所有相关对象的 SSD。但它也失败了:

-->  80 E4 00 80 09 4F <SSD AID Len> <SSD AID>
<--  6A 86 (= Incorrect P1 or P2 parameter)

更新 2:
我什至尝试在安全 channel (SecLevel = 03) 中发送 DELETE APDU 命令。但同样，我收到了 6985 个状态词。我需要使用哪种哈希算法来生成删除 token ？据我所知，GP 规范没有指定散列算法。
更新 3:
提到的 SSD 是从卡的 ISD 包中实例化的 0E特权，这意味着:
安全域+委托(delegate)管理+DAP验证
更新 4:
我想我找到了问题!
引自 2.1.1_Mapping_guidelines_v1.0.1-Final.pdf :

6.1. DELETE

6.1.2. Recommendation

Data Field Sent in the Command Message

(blah blah)

On an implementation supporting Supplementary Security Domains, if an attempt is being made to delete an instance of a Supplementary Security Domain and the Supplementary Security Domain has the DAP Verification privilege (bit 7 of the privileges byte set), the Security Domain is not deleted and a response of '6985' is returned.

问题1:知道为什么要这样实现/推荐吗？使这种类型的 SSD(具有 DAP 验证权限的 SSD)不可移动的目的是什么？
更新5:
我尝试使用 INSTALL For REGISTRY UPDATE 更改我的 SSD 的权限以从中删除 DAP 验证权限，然后删除 SSD。但它失败了 6A 80状态字(表示“数据字段中的参数不正确”)。

-->  00 A4 04 00 08 A0 00 00 00 03 00 00 00
<--  6F 10 84 08 A0 00 00 00 03 00 00 00 A5 04 9F 65 01 FF 90 00

-->  80 50 00 00 08 DF 4B 4B B7 15 35 5A 93
<--  00 00 41 89 00 24 94 97 41 21 01 02 00 77 5C 2B 50 27 5A F4 8A 18 C0 8B 2D C2 20 50 90 00

-->  84 82 00 00 10 30 AD 04 C4 60 A2 80 8B 5A 61 7E 49 3A 39 B6 C6
<--  90 00

-->  80 E6 40 00 16 08 A0 00 00 00 03 00 00 00 00 07 <SSD AID> 01 80 00 00
<--  6A 80

问题2:INSTALL For Registry Update 命令有什么问题？

Answer 1

使用 RSA 时的委托(delegate)管理 token 应使用 SHA-1 作为 PKCS#1 方案的散列机制。我有一些未经测试的signing code和组装token data .作为一个开始，这可能会有所帮助。
关于问题2:
我以前没有这样做过，但是您将 SSD AID 和作为应用程序 AID 再次传递给 .仅当您要修改应用程序的权限时才需要应用程序 AID，例如默认选择的权限。
反而:

80 E6 40 00 16 08 A0 00 00 00 03 00 00 00 00 07 <SSD AID> 01 80 00 00

我会试试这个:

80 E6 40 00 16 <Length SSD AID> <SSD AID> 00 01 80 00 00