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 byte) CC(1 byte) ACC(1 byte) SN(4 bytes) CRC(2 bytes) 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密钥：
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

我查看了最新的Kamstrup文档（“无线M-Bus通信Kamstrup水表 - MULTICAL®21和flowIQ®水表模式C1符合EN 13757-4：2013”​​）

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

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

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

这个仪表可能是R型1，对吗？ （在面部位置，“Con。”参数的第3个最后一个数字应该是1）所以它的格式是[Info] [Volume] [Target Volume] - 2个字节，4个字节，4个字节 - 我有点假设因为这个数据包是一个紧凑的数据包，所以我没有得到长数据包所具有的实际格式，例如小数位数 - 通常你需要 - 但你的值是零？小数无关紧要。 （“长”数据包当然是每6个数据包左右？）

我得到的IV是： 2D2C454571631B162031FB7C20000000 这跟你的完全一样。

我使用的加密数据包是： 39A379604B90BDFCBE8DD8CB18CE77DC41 所以我排除你对你的CE和8C？ 当我把它们放入时，解密的数据包变为： 25877968217E8E01000000000000000000BB49 我怀疑，这几乎是同一个数据包，后面还有一些crc的东西，所以我真的不知道你要做什么来解密，因为你的结果完全不同了？

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

Kamstrup使用AES / CTR / NoPadding。那就是他们不必解密16字节块的倍数？在我的Java代码中查看的方式如下： 密码密码= Cipher.getInstance（“AES / CTR / NoPadding”）;

Answer 2

这里的提示非常有用。我在给定的消息中偶然发现了一个障碍。 Length-Field 错误，末尾有 2 个字节的垃圾。

我猜原始消息是以帧格式 B 编码的。这意味着长度字段包括帧 CRC，应该在删除 CRC 后更正。将长度更正为 0x21（33 个字节 + L-Field）后，我得到了正确的消息，并且还可以验证解码消息的前 2 个字节是否包含剩余消息的 CRC16。