无法使用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但没有成功。我已经阅读了很多关于它的信息，我发现的唯一线索就是我必须从我的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

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

Answer 1

Size of session key

由于您使用的是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 |
                     +-------------------------+-------------------------+-------------------------+

First block of decrypted plaintext

如果解密明文的前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

也许加密是双键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 3

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