为什么我的 SIM 卡向 EXTERNAL AUTHENTICATE APDU 命令返回 6985？答案

【问题标题】：Why my SIMCard returns 6985 to EXTERNAL AUTHENTICATE APDU Command?为什么我的 SIM 卡向 EXTERNAL AUTHENTICATE APDU 命令返回 6985？
【发布时间】：2021-07-20 04:54:17
【问题描述】：

我有一张基于 Javacard 的 SIM 卡，规格如下：

D:\>gp -i
# GlobalPlatformPro 325fe84
# Running on Windows 8.1 6.3 amd64, Java 1.8.0_20 by Oracle Corporation
Unlimited crypto policy is NOT installed!

IIN: <Censored by OP>
CIN: <Censored by OP>

Card Data:
Tag 6: 1.2.840.114283.1
-> Global Platform card
Tag 60: 1.2.840.114283.2.2.2
-> GP Version: 2.2
Tag 63: 1.2.840.114283.3
Tag 64: 1.2.840.114283.4.0
-> GP SCP80 i=00
Tag 64: 1.2.840.114283.4.2.21
-> GP SCP02 i=15
Tag 65: 1.2.840.114283.5.4
Tag 66: 1.3.6.1.4.1.42.2.110.1.2
-> JavaCard v2

Card Capabilities:
[WARN] GPKeyInfo - Access and Usage not parsed: 01180100
[WARN] GPKeyInfo - Access and Usage not parsed: 01140100
[WARN] GPKeyInfo - Access and Usage not parsed: 01480100
[WARN] GPKeyInfo - Access and Usage not parsed: 01180100
[WARN] GPKeyInfo - Access and Usage not parsed: 01140100
[WARN] GPKeyInfo - Access and Usage not parsed: 01480100
Version:  32 (0x20) ID:   1 (0x01) type: DES3         length:  16
Version:  32 (0x20) ID:   2 (0x02) type: DES3         length:  16
Version:  32 (0x20) ID:   3 (0x03) type: DES3         length:  16
Version:  33 (0x21) ID:   1 (0x01) type: DES3         length:  16
Version:  33 (0x21) ID:   2 (0x02) type: DES3         length:  16
Version:  33 (0x21) ID:   3 (0x03) type: DES3         length:  16
Version:  34 (0x22) ID:   1 (0x01) type: DES3         length:  16
Version:  34 (0x22) ID:   2 (0x02) type: DES3         length:  16
Version:  34 (0x22) ID:   3 (0x03) type: DES3         length:  16
Version:  35 (0x23) ID:   1 (0x01) type: DES3         length:  16
Version:  35 (0x23) ID:   2 (0x02) type: DES3         length:  16
Version:  35 (0x23) ID:   3 (0x03) type: DES3         length:  16
Version:   1 (0x01) ID:   1 (0x01) type: DES3         length:  16
Version:   1 (0x01) ID:   2 (0x02) type: DES3         length:  16
Version:   1 (0x01) ID:   3 (0x03) type: DES3         length:  16
Version:   2 (0x02) ID:   1 (0x01) type: DES3         length:  16
Version:   2 (0x02) ID:   2 (0x02) type: DES3         length:  16
Version:   2 (0x02) ID:   3 (0x03) type: DES3         length:  16
Version:   3 (0x03) ID:   1 (0x01) type: DES3         length:  16
Version:   3 (0x03) ID:   2 (0x02) type: DES3         length:  16
Version:   3 (0x03) ID:   3 (0x03) type: DES3         length:  16
Version:   4 (0x04) ID:   1 (0x01) type: DES3         length:  16
Version:   4 (0x04) ID:   2 (0x02) type: DES3         length:  16
Version:   4 (0x04) ID:   3 (0x03) type: DES3         length:  16
Version:   5 (0x05) ID:   1 (0x01) type: DES3         length:  16
Version:   5 (0x05) ID:   2 (0x02) type: DES3         length:  16
Version:   5 (0x05) ID:   3 (0x03) type: DES3         length:  16
Version:   6 (0x06) ID:   1 (0x01) type: DES3         length:  16
Version:   6 (0x06) ID:   2 (0x02) type: DES3         length:  16
Version:   6 (0x06) ID:   3 (0x03) type: DES3         length:  16
Version:   7 (0x07) ID:   1 (0x01) type: DES3         length:  16
Version:   7 (0x07) ID:   2 (0x02) type: DES3         length:  16
Version:   7 (0x07) ID:   3 (0x03) type: DES3         length:  16
Version:   8 (0x08) ID:   1 (0x01) type: DES3         length:  16
Version:   8 (0x08) ID:   2 (0x02) type: DES3         length:  16
Version:   8 (0x08) ID:   3 (0x03) type: DES3         length:  16

Warning: no keys given, defaulting to 404142434445464748494A4B4C4D4E4F

当我想用它进行相互验证时，我收到69 85（不满足使用条件）错误状态字：

D:\>python mutual_auth.py

Connected to Card with ATR = 3B9F95803FC6A08031E073FE211B670110B26094101401

---> 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 37 CD BA 7B B4 57 B5 1B
<--- 00 00 C6 D8 6A 1C B2 02 14 13 20 02 00 00 71 90 98 C2 77 8A 07 3D 4A 4B F1 4D D4 FB 90 00

:: Calculated "Session Keys" based on host and card challenges:
    Session ENC: 43cc9d7949a13e83d22626400645c4c143cc9d7949a13e83
    Session MAC: 4abaaa3864d8fbf2ae0ac430c550ef564abaaa3864d8fbf2
    Session DEK: e1fbe0ccb299f3dcf756308f94fa4fb5e1fbe0ccb299f3dc

:: Card cryptogram verified successfully.
    
---> 84 82 00 00 10 22 66 0D BB EF 34 74 D3 11 43 98 00 F6 15 B9 ED
<--- 69 85

Error: Failed to Mutual Authenticate!

外部身份验证命令有什么问题？

注 1：我可以使用不同的 Javacard（SCP02-i15）成功地进行相互身份验证，这意味着该工具可以正确创建会话密钥和 MAC 值，但是当我想与我的 SIM 卡进行相互身份验证时，我收到了 6985。

注意 2：根据生成的会话密钥，卡密码是正确的。

注意 3：我什至在未修改的 APDU (i=1A) 上尝试了 C-MAC，但没有任何改变。

验证会话密钥：

基于 INITIALIZE UPDATE APDU 命令及其响应我们得到：

Host Challenge: 37 CD BA 7B B4 57 B5 1B

key_diversification_data : 00 00 C6 D8 6A 1C B2 02 14 13
key_info : 20 02
sequence_counter : 00 00
card_challenge : 71 90 98 C2 77 8A 
card_cryptogram : 07 3D 4A 4B F1 4D D4 FB

让我们用上面的数据验证生成的会话 ENC 密钥的正确性。根据 KeyInfo 数据，出 SIMCard 使用 SCP02。在 SCP02 中我们有：

card_auth_data = host_challenge + sequence_counter + card_challenge + 800000000000000

==> card_auth_data = 37CDBA7BB457B51B0000719098C2778A8000000000000000
card_cryptogram = 3des_cbc_enc(card_auth_data, ZERO_IV)[-8:]

正如您在上面看到的，我们生成的卡密码等于卡在 INITIALIZE UPDATE 响应中返回的值。所以会话 ENC 密钥具有正确的值。

让我们为 External Authenticate 命令生成主机密码：

host_auth_data = sequence_counter + card_challenge + host_challenge + 800000000000000

==> host_auth_data = 0000719098C2778A37CDBA7BB457B51B8000000000000000
host_cryptogram = 3des_cbc_enc(host_auth_data, ZERO_IV)[-8:]

如您所见，上图中生成的 host_cryptogram 与我发送到卡的值相同。

所以我唯一可能遇到的问题是外部身份验证命令中的 MAC 值。假设正确生成了会话密钥（我们无法使用问题中提供的信息验证其值，并且我不想公开我的卡的静态 MAC 密钥）。这个问题还有其他可能的根源吗？

【问题讨论】：

您的 Python 脚本很可能有问题，但您没有共享代码。如果您使用的是 GPPro，为什么需要使用不同的 Python 脚本？
@k_o_ 我确定 Python 脚本没有任何错误。它与其他 Javacard 成功完成了相互验证过程。问题仅出现在我的 SIM 卡上。我尝试了 GPPro，但不幸的是它在某些版本的 Windows（包括我的）上返回 Error: SCardTransmit got response 0x57 (null: null)。
@k_o_ 并且可以使用问题中的会话密钥来验证 Python 脚本的正确性。我会添加它。
您的卡是否使用某种密钥派生？例如。基于密钥多样化数据和主密钥，在使用它计算会话密钥之前，计算出 S_ENC、S_MAC 和 S_DEK 的一些派生密钥。

标签： javacard sim-card globalplatform

【解决方案1】：

仔细阅读您的问题后，我发现您使用的是 SIM 卡。

SIM 卡通常不会暴露 SCP02/SCP03。这样做的原因是这些卡并不打算供最终用户在读卡器中使用。 SCP02/SCP03 被禁用。对于远程更新，MNO 只是在 SM 或 BIP 或 CAT_TP 上使用 SCP80。这是一个不同的SCP。报告的 SCP02 可能是误报，一些 SIM 卡不是很符合规范。
另外，如果您的卡可能支持 SCP02，您确定您拥有 SCP02 密钥吗？ MNO / SIM 卡供应商在输出文件中分发通常仅用于 SCP80 协议的 Kic/Kid。

【讨论】：