Hi Kurumi,
First off, thank you for establishing and maintaining this forum!
I read data from my Kaifa MA309 / wired MBus interface using a raspberry / python script using your lib.
Reading the topics here in the forum I could confirm my findings, that 2 telegrams are sent each 5 ms cycle and that the data sent each cycle is 376 bytes.
Pasting the received data into GXDLMSDirector / Tools and translating however, it cannot not decrypt the encrypted message part - see pasted code below.
The xml output created by the code on the raspberry Pi using the python lib detected ciphered content (<GeneralGloCiphering>). But could also not decrypt it despite providing the translator with the cipher key.
The cipher key is correct: got it via the web portal of my provider and i double checked, that it is the key for the corresponding meter (serial no).
My provider specified security suite 1 and AES128-CBC - however, reading the topics here i learned that the AES mode used by the meter is not CBC but CGM!!
However, i assume if i specify suite 1 in GXDLMSDirector it will decrypt using GCM?
Here now the Director translation / raspberry dump / Director setting screenhot:
Thak you for any hints on that - im currently stuck
_____________________________________________________________________
Director translation window dump (correctly detecting 2 telegrams, but no decryption):
BlockCipher key: 32 55 31 63 78 44 58 31 6A 4E 66 55 43 30 43 54
Authentication Key:D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF
1: 68 FA FA 68 53 FF 00 01 67 DB 08 4B 46 4D 10 20 03 DE E1 82 01 55 21 00 04 BD D9 5D BD 7E 89 B0 BF A9 2F 73 5D BD 05 82 C1 80 B7 33 F7 58 CF BE 28 6B DF 8C 06 B3 24 18 F7 AA A8 1F 35 7F 59 07 9D 64 B1 E4 1E D7 AC 5B 8D 9C 4C 95 59 40 4C 4D 6D 88 F4 F6 6D AF 30 79 AC C8 61 BE 3F 37 71 B9 90 12 9B 55 F1 58 CA F9 8E 8F 0A B5 BD 3D 23 90 DD A2 89 25 1A 51 D6 1D BC D1 77 1B 3C 70 B8 FB 60 70 68 56 DC 5F 6A 39 06 77 13 DB 3D 44 F4 78 48 5F ED 5A 1C 72 1D 2C 38 64 28 C3 F4 1A D2 B3 FC F3 A8 2E B8 E1 DF 3C 83 2C F8 B9 03 73 98 8D 9A 46 73 79 0B E5 6C 1C CD 68 79 3A 67 F9 30 CD 80 F8 84 F6 EF 06 6D 79 BA 9C A5 4F 01 19 B6 7E 8C 80 DC B0 DA 24 4D D9 B8 61 B8 79 6D 73 E4 D3 D0 5B 39 A0 B7 11 86 53 57 EA 66 3F 9B A4 2B 4A 62 93 31 8A 50 0C A2 67 CE 14 0C 43 0E F6
<WiredMBus len="FE" >
<TargetAddress Value="67" />
<SourceAddress Value="1" />
<!-- Command: SndUd -->
<!-- A-Field: 255 -->
<!-- CI-Field: 0 -->
<!-- Primary station: 103 -->
<!-- Secondary station: 1 -->
<NextFrame Value="DB084B464D102003DEE1820155210004BDD95DBD7E89B0BFA92F735DBD0582C180B733F758CFBE286BDF8C06B32418F7AAA81F357F59079D64B1E41ED7AC5B8D9C4C9559404C4D6D88F4F66DAF3079ACC861BE3F3771B990129B55F158CAF98E8F0AB5BD3D2390DDA289251A51D61DBCD1771B3C70B8FB60706856DC5F6A39067713DB3D44F478485FED5A1C721D2C386428C3F41AD2B3FCF3A82EB8E1DF3C832CF8B90373988D9A4673790BE56C1CCD68793A67F930CD80F884F6EF066D79BA9CA54F0119B67E8C80DCB0DA244DD9B861B8796D73E4D3D05B39A0B711865357EA663F9BA42B4A6293318A500CA267CE140C430EF6" />
</WiredMBus>
2: 68 72 72 68 53 FF 11 01 67 2A 78 DF C7 6C FA 81 B2 5D 9D 11 05 97 4B E3 24 F4 34 E6 4F F9 E0 72 9A AE 4E 31 63 EC AB C3 B7 C4 58 4A 8A 38 5C FB 50 14 AD 35 8C CE 98 74 A1 D3 89 AA B0 3E 6D 9D 01 13 7A 3B B8 F2 09 A9 C4 5D 36 5A 90 54 A8 D3 31 45 48 50 4D EC 73 CA 9B FA 88 D2 6C 44 C1 2A 86 35 84 DD 91 62 75 17 2E FD 00 14 00 9E 23 47 C0 C6 7F 96 FC B0
<WiredMBus len="76" >
<TargetAddress Value="67" />
<SourceAddress Value="1" />
<!-- Command: SndUd -->
<!-- A-Field: 255 -->
<!-- CI-Field: 17 -->
<!-- Primary station: 103 -->
<!-- Secondary station: 1 -->
<NextFrame Value="2A78DFC76CFA81B25D9D1105974BE324F434E64FF9E0729AAE4E3163ECABC3B7C4584A8A385CFB5014AD358CCE9874A1D389AAB03E6D9D01137A3BB8F209A9C45D365A9054A8D3314548504DEC73CA9BFA88D26C44C12A863584DD916275172EFD0014009E2347C0C67F96FCB0" />
</WiredMBus>
____________________________________________________________________
Dump of the data processed by the python implementation on the raspberry:
68fafa6853ff000167db084b464d102003dee1820155210004bdd95dbd7e89b0bfa92f735dbd0582c180b733f758cfbe286bdf8c06b32418f7aaa81f357f59079d64b1e41ed7ac5b8d9c4c9559404c4d6d88f4f66daf3079acc861be3f3771b990129b55f158caf98e8f0ab5bd3d2390dda289251a51d61dbcd1771b3c70b8fb60706856dc5f6a39067713db3d44f478485fed5a1c721d2c386428c3f41ad2b3fcf3a82eb8e1df3c832cf8b90373988d9a4673790be56c1ccd68793a67f930cd80f884f6ef066d79ba9ca54f0119b67e8c80dcb0da244dd9b861b8796d73e4d3d05b39a0b711865357ea663f9ba42b4a6293318a500ca267ce140c430ef6f2166872726853ff1101672a78dfc76cfa81b25d9d1105974be324f434e64ff9e0729aae4e3163ecabc3b7c4584a8a385cfb5014ad358cce9874a1d389aab03e6d9d01137a3bb8f209a9c45d365a9054a8d3314548504dec73ca9bfa88d26c44c12a863584dd916275172efd0014009e2347c0c67f96fcb0be16
<WiredMBus len="FE" >
<TargetAddress Value="67" />
<SourceAddress Value="1" />
</WiredMBus>
<WiredMBus len="76" >
<TargetAddress Value="67" />
<SourceAddress Value="1" />
<GeneralGloCiphering>
<SystemTitle Value="4B464D102003DEE1" />
<CipheredService Value="210004BDD95DBD7E89B0BFA92F735DBD0582C180B733F758CFBE286BDF8C06B32418F7AAA81F357F59079D64B1E41ED7AC5B8D9C4C9559404C4D6D88F4F66DAF3079ACC861BE3F3771B990129B55F158CAF98E8F0AB5BD3D2390DDA289251A51D61DBCD1771B3C70B8FB60706856DC5F6A39067713DB3D44F478485FED5A1C721D2C386428C3F41AD2B3FCF3A82EB8E1DF3C832CF8B90373988D9A4673790BE56C1CCD68793A67F930CD80F884F6EF066D79BA9CA54F0119B67E8C80DCB0DA244DD9B861B8796D73E4D3D05B39A0B711865357EA663F9BA42B4A6293318A500CA267CE140C430EF62A78DFC76CFA81B25D9D1105974BE324F434E64FF9E0729AAE4E3163ECABC3B7C4584A8A385CFB5014AD358CCE9874A1D389AAB03E6D9D01137A3BB8F209A9C45D365A9054A8D3314548504DEC73CA9BFA88D26C44C12A863584DD916275172EFD0014009E2347C0C67F96FCB0" />
</GeneralGloCiphering>
</WiredMBus>
Appended a pic with the…
Appended a pic with the Director / Tools / Translator cipher setting
Hi, The proble is not in the…
Hi,
The proble is not in the ciphering. DLMS standard is defining that Security Suite is using GMAC and I was able to decrypt the data without problems. The problem is that CRC is counted for the message length and that is wrong. In your data the length is 250 (0xFA)when it should be 248. Ask manufactuer to fix this.
This can be easily check from the Blue Book.
Figure 159 – Daily billing data without / with DLMS/COSEM security applied
CRC is not included for the payload length (L).
BR,
Mikko
Mikko, thank you very much…
Mikko,
thank you very much for your availability and your fast reply!
Indeed, there is also no problem with the lenght field or the checksum in my case - if the (Mbus) length field (0xFA) would not match the telegram lenght / checksum position then Director would raise the error <!-- Invalid checksum --> (or simular)
I am sorry, but I was just too stupid to work with Director properly:
I somehow expected DLMS Translator also to do the encryption directly in the Messages output window .
But of course just one by one...:
Copying the payload of the 2 telegrams (from the messages output window) to the PDU tab did the trick. PDU-> XML also does the decryption. Now I know it works and can focus on coding again.
Thank you and
BR
Michael
Hi Michael, The data is…
Hi Michael,
The data is coming in multiple frames and PDU is not parse automatically as a default. Select "View" and "Complate PDU" and you can see the data as XML. You can test that with the python data.
BR,
Mikko
Again regarding the…
Again regarding the decryption:
Mikko,
Whereas GXDLMS Director is able to decrypt my message / PDU content with the given encryption key, I cannot make it work with Gurux.DLMS lib (python). I thought putting this topic into the lib forum but as it is related to my first post i kept it here:
I always get the following xml output regardless if I try to translate the message (messageToXml) or the PDU (pduToXML), i.e. the translate function is not able to decrypt my data:
<GeneralGloCiphering>
<SystemTitle Value="4B464D102003DEE1" />
<CipheredService Value="210004BDD95DBD7E89B0BFA92F735DBD0582C180B733F758CFBE286BDF8C06B32418F7AAA81F357F59079D64B1E41ED7AC5B8D9C4C9559404C4D6D88F4F66DAF3079ACC861BE3F3771B990129B55F158CAF98E8F0AB5BD3D2390DDA289251A51D61DBCD1771B3C70B8FB60706856DC5F6A39067713DB3D44F478485FED5A1C721D2C386428C3F41AD2B3FCF3A82EB8E1DF3C832CF8B90373988D9A4673790BE56C1CCD68793A67F930CD80F884F6EF066D79BA9CA54F0119B67E8C80DCB0DA244DD9B861B8796D73E4D3D05B39A0B711865357EA663F9BA42B4A6293318A500CA267CE140C430EF62A78DFC76CFA81B25D9D1105974BE324F434E64FF9E0729AAE4E3163ECABC3B7C4584A8A385CFB5014AD358CCE9874A1D389AAB03E6D9D01137A3BB8F209A9C45D365A9054A8D3314548504DEC73CA9BFA88D26C44C12A863584DD916275172EFD0014009E2347C0C67F96FCB0" />
</GeneralGloCiphering>
________________________________________________________________
My test code is:
encryption_key = "32553163784458316A4E665543304354"
telegramdata = "68fafa6853ff000167db084b464d102003dee1820155210004bdd95dbd7e89b0bfa92f735dbd0582c180b733f758cfbe286bdf8c06b32418f7aaa81f357f59079d64b1e41ed7ac5b8d9c4c9559404c4d6d88f4f66daf3079acc861be3f3771b990129b55f158caf98e8f0ab5bd3d2390dda289251a51d61dbcd1771b3c70b8fb60706856dc5f6a39067713db3d44f478485fed5a1c721d2c386428c3f41ad2b3fcf3a82eb8e1df3c832cf8b90373988d9a4673790be56c1ccd68793a67f930cd80f884f6ef066d79ba9ca54f0119b67e8c80dcb0da244dd9b861b8796d73e4d3d05b39a0b711865357ea663f9ba42b4a6293318a500ca267ce140c430ef6f2166872726853ff1101672a78dfc76cfa81b25d9d1105974be324f434e64ff9e0729aae4e3163ecabc3b7c4584a8a385cfb5014ad358cce9874a1d389aab03e6d9d01137a3bb8f209a9c45d365a9054a8d3314548504dec73ca9bfa88d26c44c12a863584dd916275172efd0014009e2347c0c67f96fcb0be16"
pdudata = "DB084B464D102003DEE1820155210004BDD95DBD7E89B0BFA92F735DBD0582C180B733F758CFBE286BDF8C06B32418F7AAA81F357F59079D64B1E41ED7AC5B8D9C4C9559404C4D6D88F4F66DAF3079ACC861BE3F3771B990129B55F158CAF98E8F0AB5BD3D2390DDA289251A51D61DBCD1771B3C70B8FB60706856DC5F6A39067713DB3D44F478485FED5A1C721D2C386428C3F41AD2B3FCF3A82EB8E1DF3C832CF8B90373988D9A4673790BE56C1CCD68793A67F930CD80F884F6EF066D79BA9CA54F0119B67E8C80DCB0DA244DD9B861B8796D73E4D3D05B39A0B711865357EA663F9BA42B4A6293318A500CA267CE140C430EF62A78DFC76CFA81B25D9D1105974BE324F434E64FF9E0729AAE4E3163ECABC3B7C4584A8A385CFB5014AD358CCE9874A1D389AAB03E6D9D01137A3BB8F209A9C45D365A9054A8D3314548504DEC73CA9BFA88D26C44C12A863584DD916275172EFD0014009E2347C0C67F96FCB0"
tr = GXDLMSTranslator()
tr.comments = True
tr.pduOnly = True
tr.completePdu = True
tr.blockCipherKey = GXByteBuffer.hexToBytes(encryption_key)
msg = GXDLMSTranslatorMessage()
msg.message = GXByteBuffer(telegramdata)
pdu = GXByteBuffer()
xml = ""
# 1.)
# assemble PDU from telegrams and translate
while tr.findNextFrame(msg, pdu):
xml += tr.messageToXml(msg)
# 2.)
# OR: translate the PDU (string PDU data) directly.
# the same PDU string (pdudata) is decrypted successfully in Director!
#xml = tr.pduToXml(pdudata)
print(xml)
________________________________________________________________
What is missing? Can you please point me in the right direction.
It can't possibly be related with the data length problem you mentiononed the 1st post as Director can decrypt the PDU..?
Thank you and
Best regards
Michael
Hi Mikko, > Select "View"…
Hi Mikko,
> Select "View" and "Complate PDU" and you can see the data as XML.
Yes, thank you, that did the trick for the Messages Output window, now I can see the deciphered xml there as well.
Hi, Because data is coming…
Hi,
Because data is coming in multiple frames you need to get all the frames before PDU can be handled. Your PDU looks corrent.
Check this example. Set block cipher and authentication keys and you can get the correct output.
https://github.com/Gurux/Gurux.DLMS.Python/tree/master/Gurux.DLMS.Push…
BR,
Mikko