3

I am trying to decrypt wm-bus telegram from Kamstrup Multical21 in C1 mode with Extended Link Layer.
The payload together with ELL info is following:
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

Analysing CI = 8D I found that there is a ELL with following data:
CI (1 byte) CC(1 byte) ACC(1 byte) SN(4 bytes) CRC(2 bytes) 8D 20 6A 31 FB 7C 20 39 A3

The documentation says that the buffer which should be decrypted shall contain CRC from ELL, i.e:
39 A3 79 60 4B 90 BD FC BE 8D D8 CB 18 CE 77 DC 41 CE 8C

I have got the AES key from the Manufacturer:
B9 7A 6D 4E C2 74 A4 6D 87 0E 31 27 D9 A0 AF 63

Initialization vector for ELL shall be:
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

After decrypting, I get the following result:
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

Since there is no 2F 2F in the beginning, something is wrong! Can somebody help me and tell what I have done wrong? Thanks in advance.

n0p
  • 3,399
  • 2
  • 29
  • 50
Enmujnem
  • 31
  • 1
  • 3
  • Did you manage to find a solution to this? I get the same IV, but when decrypting, I get a different result (also not 0x2F2F). Also, I believe that the first number in the packet is the complete length, including the first byte. Your example has 0x23 (35 bytes), but the length of the packet shown is 36 (0x24). Have you tried removing the trailing 0x8C so you have the 23 bytes in total? – branchespark Apr 08 '15 at 17:52
  • Actually, I believe that Kamstrup uses format B, where L-field denotes length together with 2 CRC bytes. Also the two CRC bytes (39 A3) from ELL shall be included when decrypting the payload. Also both preceding CE and 8C at the end shall be removed (2 CRC bytes). I tried to decrypt the following buffer: 39 A3 79 60 4B 90 BD FC BE 8D D8 CB 18 CE 77 DC 41 but without success. – Enmujnem Apr 13 '15 at 10:03

2 Answers2

4

I had a look in the latest Kamstrup docs ("Wireless M-Bus Communication Kamstrup Water Meters - MULTICAL® 21 and flowIQ® water meters Mode C1 according to EN 13757-4:2013")

When I decrypt your packet I find: 25877968217E8E01000000000000000000

Firstly, it seems the Kamstrup decrypted packets does not start with 2F 2F.

The first 2 bytes of the decrypted packet is supposedly the PLCRC (I can't confirm that right now - don't have immediate access to the standard that defines the crc polynomial algorithm), and then the next byte is 79, which means it is a Compact Frame, then the next 4 bytes are 2 more CRCs, and then the next 2 bytes 0100 is probably the Info, which is manufacturer specific and I don't know how to interpret that yet.

This meter is probably R type 1, right? (on the face place, the "Con.:" parameter's 3rd last digit should be a 1) So its format would be [Info][Volume][Target Volume] - 2 bytes, 4 bytes, 4 bytes - I kind of assume that, since this packet is a compact packet, so I don't get the actual format the long packet would have, e.g. number of decimals - which normally you'd need - but your values are zeroes? so decimals doesn't matter. (the 'long' packet of course is every 6th packet or so?)

The IV I get is: 2D2C454571631B162031FB7C20000000 which is exactly the same as yours.

The encrypted packet I use is: 39A379604B90BDFCBE8DD8CB18CE77DC41 so I exclude the CE and 8C you had on yours? When I put them in, the decrypted packet becomes: 25877968217E8E01000000000000000000BB49 which is pretty much the same packet with some more crc stuff at the back, I suspect, so I really do not get what you do to decrypt, since your result is completely different?

Ok, maybe you use AES/CBC/NoPadding, as in OpenMUC.

Kamstrup uses AES/CTR/NoPadding. That is how they don't have to decrypt multiples of 16 byte blocks? The way that looks in my Java code is as follows: Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding");

Marinus van Zyl
  • 41
  • 3
  • Thank a lot fro your comments! – Enmujnem Sep 21 '15 at 08:53
  • Where you exactly find the documentation? I tried under Technical documents - water-meters-multical 21, but did not find any complete descryption of the protocol. – Enmujnem Sep 21 '15 at 09:04
  • I think you are right about the thing you have mentioned. I use a test Multical 21 on my desk, so zeros are expected and I have used a wrong decryption algorythm. It will be very usefull if you send me the link for the documentation you have mentioned. – Enmujnem Sep 21 '15 at 09:08
  • I got the document from Kamstrup. They shouldn't mind giving it to you? If you buy a meter, I'm sure they'll feel obliged to help you. Ask and you shall receive. But it is for them to give it out, not for me, sorry. I think you might also have to sign an NDA... there was some press saying wmbus is supposedly not secure enough, and since then the sub-protocols have proliferated and security through obscurity has reared its ugly head :-( you know how it is :'( – Marinus van Zyl Sep 19 '16 at 17:29
  • Thanks for the comment. I put this project aside for the time. – Enmujnem Sep 26 '16 at 09:09
  • by trial and error I could manually construct the format frame which is `02 FF 20 04 16 44 16` this results in the correct format-signature of `21 68` and recombines with the compact frame decoded above. The final application layer is then `02 FF 20 01 00 04 16 00 00 00 00 44 16 00 00 00 00` and decodes in a manufacturer specific info code `1` and current and historic meter index of 0m3 – Marwie Jan 31 '18 at 18:23
0

the hints here are very helpfull. There's one obstacle I stumbled across with the given message. The Length-Field is wrong and there are 2 bytes of garbage at the end.

I guess the original message was encoded in frame format B. That means the length field includes the frame CRCs and should be corrected after the CRCs are removed. After correcting the length to 0x21 (33 bytes + L-Field), I get the correct message and also can verify that the first 2 bytes of the decoded message contain the CRC16 of the remaining message.

Michael Wyraz
  • 3,638
  • 1
  • 27
  • 25