aes - WM-Bus扩展层解码

Question

我正在尝试使用扩展链路层在 C1 模式下解密来自 Kamstrup Multical21 的 wm-bus 电报。
负载连同 ELL 信息如下:
23 44 2D 2C 45 45 71 63 1B 16 8D 20 6A 31 FB 7C 20 39 A3 79 60 4B 90 BD FC BE 8D D8 CB 18 CE 77 DC 41 CE 8C

分析 CI = 8D 我发现有一个 ELL 具有以下数据:
CI(1 字节)CC(1 字节)ACC(1 字节)SN(4 字节)CRC(2 字节)
8D 20 6A 31 FB 7C 20 39 A3

文档说应该解密的缓冲区应包含来自 ELL 的 CRC，即:
39 A3 79 60 4B 90 BD FC BE 8D D8 CB 18 CE 77 DC 41 CE 8C

我从制造商那里得到了 AES key :
B9 7A 6D 4E C2 74 A4 6D 87 0E 31 27 D9 A0 AF 63

ELL 的初始化向量应为:
M-field A-field CC-field SN-field FN BC
2D 2C 45 45 71 63 1B 16 20 31 FB 7C 20 00 00 00

解密后得到如下结果:
08 3a 5f ce b2 8d 51 97 94 a2 5b fb 61 ab 2e c0
e4 20 c8 2a 43 ff 3a 75 6f 93 d0 ac 8c 79 b7 a1

因为开头没有2F 2F，所以有问题!有人可以帮助我并告诉我做错了什么吗？提前致谢。

Answer 1

我查看了最新的卡姆鲁普文档(“无线 M-Bus 通信卡姆鲁普水表 - MULTICAL® 21 和 flowIQ® 水表模式 C1，符合 EN 13757-4:2013”​​)

当我解密你的数据包时，我发现:25877968217E8E01000000000000000000

首先，Kamstrup 解密的数据包似乎不是以 2F 2F 开头。

解密数据包的前 2 个字节应该是 PLCRC(我现在无法确认 - 不能立即访问定义 crc 多项式算法的标准)，然后下一个字节是 79，这意味着它是一个紧凑帧，接下来的 4 个字节是另外 2 个 CRC，然后接下来的 2 个字节 0100 可能是信息，这是制造商特定的，我还不知道如何解释。

这个表应该是R type 1吧？ (在表面上，“Con.:”参数的倒数第三个数字应该是 1)所以它的格式是 [Info][Volume][Target Volume] - 2 bytes, 4 bytes, 4 bytes - 我有点假设那，因为这个数据包是一个紧凑的数据包，所以我没有得到长数据包的实际格式，例如小数位数 - 通常你需要 - 但你的值是零？所以小数点无关紧要。 (“长”数据包当然是每 6 个数据包左右？)

我得到的 IV 是:2D2C454571631B162031FB7C20000000这和你的完全一样。

我使用的加密包是:39A379604B90BDFCBE8DD8CB18CE77DC41所以我排除了你身上的 CE 和 8C？当我把它们放进去时，解密后的数据包变成了:25877968217E8E01000000000000000000BB49我怀疑这几乎是同一个数据包，后面有更多的 crc 内容，所以我真的不明白你做了什么来解密，因为你的结果完全不同？

好吧，也许你使用 AES/CBC/NoPadding，就像在 OpenMUC 中一样。

Kamstrup 使用 AES/CTR/NoPadding。这就是他们不必解密 16 字节 block 的倍数的原因？在我的 Java 代码中看起来的方式如下:Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding");