无法使用 SessionKey 解密 3DES

Question

我正在开发一个 C 项目来读/写 Desfire 非接触式卡片。 现在我实现了身份验证，并且能够从卡中读取数据，但它是使用 3DES 加密的。

我想解密下一条消息：

EB 54 DF DD 07 6D 7C 0F BD D6 D1 D1 90 C6 C7 80 92 F3 89 4D 6F 16 7C BF AA 3E 7C 48 A8 71 CF A2 BD D0 43 07 1D 65 B8 7F

我的 SessionKey（在身份验证步骤中生成）是：

44 E6 30 21 4A 89 57 38 61 7A B8 7C A9 91 B2 C0

我知道 IV={ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }

有了这些信息，我可以去here，选择3DES，CBC模式，我可以解密消息，我有办法知道它是正确的。 应该是，解密：

10 1a 01 31 32 ae 03 de 39 b0 00 97 7f 65 e9 43 93 89 53 5c 9e 04 a9 3f 95 71 24 0f 0a 9b f7 ee d4 5b 1b c6 78 7a f4 36

无论如何，我尝试使用 OpenSSL des 库来实现 C 代码，但我发现了下一个困难：

我需要 3 个 8 字节的密钥，但我有 1 个 16 字节的 SessionKey 长。

我尝试将 SessionKey 拆分为 Key1/Key2/Key1，但没有成功。 我已经阅读了很多关于它的信息，我发现的唯一线索是我必须从我的 16 字节会话密钥（将其作为密码）生成这 3 个密钥，但我觉得它对我来说太先进了。 如果这是唯一的方法，是否有任何关于 ossl 密钥派生（evp_bytestokey）的教程？有没有其他办法？

谢谢

编辑： 所以，现在我处于一个非常奇怪的位置。正如你们中的许多人所指出的，我已经从会话密钥中获取了前 8 个字节作为密钥 3（这就是我使用 Key1/Key2/Key1 所指的内容）。无论如何，它似乎不起作用，但它确实起作用了，这让我感到困惑。 我明白了：

Decrypted : 11 1B 00 30 33 AF 02 DF DE 01 00 00 00 01 01 00 14 C1 26 8F 03 20 20 41 00 30 39 01 00 00 00 00 00 00 00 00 00 00 75 B1

什么时候

Expected : 10 1a 01 31 32 ae 03 de de 01 00 00 00 01 01 00 14 c1 26 8f 03 20 20 41 00 30 39 01 00 00 00 00 00 00 00 00 00 00 75 b1

所以我得到了预期的结果，前 8 个字节与 01 进行异或运算。这有什么意义吗？正如在 OSSL 文档中所说：请注意，libcrypto 中同时存在 DES_cbc_encrypt() 和 DES_ncbc_encrypt()。我建议你只使用 ncbc 版本（n 代表新的）。请参阅 OpenSSL DES 手册页的 BUGS 部分和这些函数的源代码。 但是我只能访问旧版本...可能是问题吗？？

Answer 1

也许加密是双密钥 3DES，在这种情况下重复前 8 个字节，字节 0-7 作为字节 16-23：44 E6 30 21 4A 89 57 38 61 7A B8 7C A9 91 B2 C0 44 E6 30 21 4A 89 57 38。

有些 3DES 实现会自动执行此操作，有些则必须自己执行。

如果这不起作用，您需要在问题中提供更多信息。

Answer 2

会话密钥的大小

由于您提到 MIFARE DESFire 并且您使用的是 16 字节会话密钥，因此您可能使用 2 密钥三重 DES。这意味着 16 字节的会话密钥实际上是两个密钥（8 字节，或者实际上是 56 位，每个都有 8 个未使用的“奇偶校验”位）。

为了将其映射到具有 3 个密钥的 3DES，您只需将前 8 个字节附加到会话密钥的末尾，以便获得

+-------------------------+------------------------ --+ 16 字节会话密钥：| 8 字节 | 8 字节 | | 44 E6 30 21 4A 89 57 38 | 61 7A B8 7C A9 91 B2 C0 | +-------------------------+------------------------ --+--------------+ 24 字节 3DES 密钥：| 8 字节 | 8 字节 | 8 字节 | | 44 E6 30 21 4A 89 57 38 | 61 7A B8 7C A9 91 B2 C0 | 44 E6 30 21 4A 89 57 38 | +-------------------------+------------------------ --+--------------+

第一个解密明文块

如果解密后的明文的前 8 个字节与预期值不同，但其余字节匹配，这清楚地表明您在 CBC 模式下使用了不正确的初始化向量。

看看 CBC 模式的工作原理：

所以对于第一个块，明文计算为

P0 = DecK(C0) XOR IV

对于剩余的块，明文计算为

Pn = DecK(Cn) XOR Cn-1

这意味着只有第一个块的解密取决于 IV。其余块的解密则依赖于前面的密文。

由于您假设 IV 为全零，因此 XOR 操作什么也不做。因此，在您的情况下，第一个块的明文计算为

P0 = DecK(C0) XOR {0} = DecK(C0) = '10 1A 01 31 32 AE 03 DE'

由于此预期值与您获得的实际值有偏差 ('11 1B 00 30 33 AF 02 DF')。这很可能意味着您使用了不正确的 IV 进行解密：

P0 = DecK(C0) = '10 1A 01 31 32 AE 03 DE'
P'0 = DecK(C0) XOR IV = '11 1B 00 30 33 AF 02 DF'

您可以通过异或这两个值来计算您使用的 IV：

P'0 = P0 XOR IV
P'0 XOR P0 = IV

IV = '11 1B 00 30 33 AF 02 DF' XOR '10 1A 01 31 32 AE 03 DE'
   ='01 01 01 01 01 01 01 01'

由于这个 IV 的不同之处在于每个字节的 LSB 设置为 1，我想知道您是否不小心在 IV 上使用了方法DES_set_odd_parity()。这可以解释为什么 LSB（即，如果该值是 DES 密钥，则为奇偶校验位）被更改。

Answer 3

您可能不需要 3 个 32 位的密钥，而只需要 3*32 位中的一个，并且字节顺序良好 最好的问候