无法使用SessionKey解密3DES

Question

我正在开发一个读取/写入Desfire非接触式卡的C项目。 现在我已经实现了身份验证，我可以从卡中读取数据，但它是用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但没有成功。 我已经阅读了很多关于它的信息，我发现的唯一线索就是我必须从我的16byte SessionKey中生成这3个密钥（将其作为密码），但我觉得这对我来说太先进了。 如果这是唯一的方法，是否有任何关于ossl密钥派生的教程（evp_bytestokey）？还有其他办法吗？

感谢

编辑： 所以，现在我处在一个非常奇怪的地方。正如你们许多人所指出的那样，我已经从Session Key获取了前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

所以我得到预期的结果与01的前8个字节异或。这有什么意义吗？与在OSSL文档中一样，它说：请注意，libcrypto中有DES_cbc_encrypt（）和DES_ncbc_encrypt（）。我建议你只使用ncbc版本（n代表新版本）。请参阅OpenSSL DES联机帮助页的BUGS部分以及这些函数的源代码。 但是我只能访问旧版本......这可能是问题吗？

Answer 1

会话密钥的大小

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

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

                     +-------------------------+-------------------------+
16 byte session key: | 8 bytes                 | 8 bytes                 |
                     | 44 E6 30 21 4A 89 57 38 | 61 7A B8 7C A9 91 B2 C0 |
                     +-------------------------+-------------------------+-------------------------+
24 byte 3DES key:    | 8 bytes                 | 8 bytes                 | 8 bytes                 |
                     | 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 2

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