I have a ISKRA AM550 from "Kärntennetz" in Austria. They provide a read only interface which pushes a message every second. I recorded an example with a serial monitor:
7E A0 77 CF 02 23 13 BB 45 E6 E7 00 DB 08 49 53 4B 69 74 55 0B CD 5F 20 00 00 0C B0 3C BB 27 4E 90 5F 09 74 9D 5C 31 36 CC B7 47 57 C5 FC 3A 35 7B AB 06 17 46 94 BB 5C 93 73 82 5F D7 76 77 E5 D9 21 92 17 B2 71 25 E8 CA B2 C0 1B 84 2E 75 6A C8 D0 71 85 FB 2D DF 66 31 89 EF 3E 8C 03 DE 2B B9 C1 68 B8 BF A7 D3 A4 CE F3 19 3F 83 21 E0 06 44 B4 A0 82 3C 92 A0 C0 7E
The company provided me with a 16 byte "activation code", i guess it is to decrypt the message above. However i have no idea how to use DLMSDirector to make these messages readable. It would be great if you could help me out.
thanks for your fast reply and help. I now tried it again to connect to the smart meter via serial connection in the GXDLMSDirector. Now i get the error "Wrong CRC". Could you please assist me what i have to enter in the settings of the device to get it working?
Threre are some standard values in "System Title", "Block Cipher Key" and "Authentication Key". Should i keep them and only change Block Cipher Key? And what should i select at "Security"?
I tried it with only changing the Block Cipher Key and the result was the following:
1: 7E A0 77 CF 02 23 13 BB 45 E6 E7 00 DB 08 49 53 4B 69 74 55 0B CD 5F 20 00 00 0C B0 3C BB 27 4E 90 5F 09 74 9D 5C 31 36 CC B7 47 57 C5 FC 3A 35 7B AB 06 17 46 94 BB 5C 93 73 82 5F D7 76 77 E5 D9 21 92 17 B2 71 25 E8 CA B2 C0 1B 84 2E 75 6A C8 D0 71 85 FB 2D DF 66 31 89 EF 3E 8C 03 DE 2B B9 C1 68 B8 BF A7 D3 A4 CE F3 19 3F 83 21 E0 06 44 B4 A0 82 3C 92 A0 C0 7E
<!--Invalid data checksum.-->
<HDLC len="76" >
<TargetAddress Value="67" />
<SourceAddress Value="91" />
<!--Notification frame.-->
<FrameType Value="13" />
<PDU>
<GeneralGloCiphering>
<SystemTitle Value="49534B6974550BCD" />
<CipheredService Value="2000000CB03CBB274E905F09749D5C3136CCB74757C5FC3A357BAB06174694BB5C9373825FD77677E5D9219217B27125E8CAB2C01B842E756AC8D07185FB2DDF663189EF3E8C03DE2BB9C168B8BFA7D3A4CEF3193F8321E00644B4A0823C92" />
</GeneralGloCiphering>
</PDU>
</HDLC>
The "value" is equal to the original input from byte 24 to byte 118 and i cant find the encrypted data
Then your ciphering key is wrong. In the first post, you said that you are from Austria.
If you login to your power utility web portal you should see the ciphering key.
Can you see it there and verify that it's the same as what you have now?
I got the key from my provider in a letter by post. May I send it to you via Email? Then you can check it if there is really a problem or if I am just doing it wrong...
If that is ok for you, please tell me your Email adress.
i seriously cannot understand why, but i tried to read some more data packages today. They look the same and i did the same as last time, but now they work... One example:
One more question: Is there an API or algorithm for the decryption process on its own? My goal is to receive the serial data with an ESP8266 and send it to ioBroker via MQTT. But i have to decrypt the message either on the ESP8266 or on ioBroker to use the data.
(The pdu to xml function is not necessary, i can easily do this with scripts in ioBroker)
glad to hear someone else in Austria is also struggling with the Smartmeters here ;)
I'm currently trying to get access to the optical interface and decryption key from "Wiener Netze" there once was the ability to enable the customer interface but it has been removed after I wrote them that the datapackets are not decryptable.
Haha thats Austria... Beautiful country, but the bureaucracy... :D
I was fighting for the activation since November 2019 and got it working today after 100 calls, many friendly and helpful extern people like Mikko here and many lost nerves.
Unfortunately i can not help you, because i have a wired connection with the RJ12 connector. I think in Vienna you use the same model, but the interface is the optical port. In Carinthia the optical port is only for service by the provider. Maybe you can try to call them and annoy them until you get an appropriate answer. It is important that you tell them you mean the interface and not the web-portal. Always i mentioned "Kundenschnittstelle" they thought i mean the web-portal...
Fastest way is if you can decrypt it on the ioBroker. If you do it on the ESP8266 you need to implement it with ANSI C. If you do it on the ioBroker you can use higher-level programming languages.
You can convert data to XML or use GXDLMSClient GetData Method. It can find the frames and returns data from the received frame.
i am sorry, cryptography is not my best area. So i have some basic questions.
There are different types of AES decryption like AES-CBC, AES-ECD or AES-GCM. Which type do i have to use in order to decode my message?
And what are the additional inputs for the different types. For example, if i use AES-GCM i have to add an "IV" and a "GCM Tag". The IV should be the 8 byte of the system title and the 4 byte of the frame counter if I am correct. But where can i find the GCM Tag?
Sorry for the basic questions, but I expect that you know the answers, because you coded your program, which has to use these information.
unfortunately i was still unable to extract the algorithm. On your site https://www.gurux.fi/Gurux.DLMS.Secure you say, that one needs the authentication key too. What is this and where can i find it in my case?
And in the GXSecure class, i guess the correct method is "static byte[] decryptAesGcm". But in the description of it you say "return ENCRYPTED data". However, i would need the decrypted data.
I have the same ISKRA AM550 from Wiener Netze but can't get out the energy data.
What i receive from the entergy counter via IR is like
7E A0 67 CF 02 23 13 FB F1 E6 E7 00 DB 08 49 53 4B 69 74 92 ED 66 4F 20 01 CD 52 D5 24 AF 4B 82 C1 F4 AE A4 A6 AA F7 4F 6D 82 EF B2 62 2A 5B D5 65 8A 22 FE 91 A9 F2 BD 16 5C 43 CC E1 D8 28 E8 21 97 04 6B 79 A4 58 DD AB 6E 20 CF D7 DB 64 8D 6F 6A F8 FD 97 94 F4 F8 48 8F FC 08 B5 C8 DF 93 7E
message which seems to be too short.
What baudrate, databits, stopbits and parity are you using to receive?
Do you have to send something to the energy counter to receive that message?
Hey Stefan,
I had lots of emails with wiener netze about this... for a long time they hid the "customer key" in the webinterface and told me that the "kundenschnittstelle" is not supposed to be used yet.
now that they have unlocked it again and I will try to catch some data bits again and see if it works now.
The data I always got was "decode able" but not "decrypt able"
and you dont have to send anything the meter sends bursts of data every couple of seconds
9600 Data 8 Stop 1 Parity None
see this thread here: http://www.gurux.fi/node/13801
Ok so i can receive the information and get some data. I also have the key from the web interface, but i am not able to decrypt. the message seems to be shorter than normal. there is a filling byte 00 missing between E6 E7 and DB byte.
Ok i got something working.... i used a raspberry pi with IR reader on the interal UART.
Then i used "Gurux.DLMS.Push.Listener.Example.python" to read a push message:
7E A0 67 CF 02 23 13 FB F1 E6 E7 00 DB 08 49 53 4B 69 74 92 ED 66 4F 20 00 02 C7 F2 3F 48 3C 95 59 79 AF 84 15 BD C7 21 DE 26 F5 3B 1F C1 E6 EE 5B CC 0C 0B 33 CE C4 ED 88 A6 DC 6A 04 D7 6D C0 8B 1D B2 F8 D1 99 68 FA CF AE E5 49 1A 7F CC 17 36 94 25 E6 CE B9 30 29 A7 02 13 E6 8B 8E 62 BF 23 0B DD E4 09 85 48 99 7E
Next step was to decrypt it with my key, so i used the python code you provided in another post:
from gurux_dlms.GXByteBuffer import GXByteBuffer
from gurux_dlms.GXDLMSTranslator import GXDLMSTranslator
from gurux_dlms.GXReplyData import GXReplyData
from gurux_dlms.secure.GXDLMSSecureClient import GXDLMSSecureClient
from gurux_dlms.TranslatorOutputType import TranslatorOutputType
dataAvail = cl.getData(GXByteBuffer.hexToBytes(data), reply, notify)
print(str(dataAvail))
if not dataAvail:
print("notify data length: " + str(len(notify.data)))
if len(notify.data) != 0:
print("notify.data: " + str(notify.data))
#Handle notify.
if not notify.isMoreData():
#Show received push message as XML.
t = GXDLMSTranslator()
cml = t.dataToXml(notify.data)
print("cml" + cml)
notify.clear()
Output was:
notify data length: 74
notify.data: 60 C5 F5 E9 95 BD 2A A7 B8 9F 32 5F 7E 22 80 0F 02 EB 9C 72 52 8E B9 27 73 B7 12 02 4E E8 2A D4 5D 76 EF 2B AB C1 73 1D F8 FA 04 60 9C 60 CD AA 5B 89 17 3D 36 16 AC BD 89 6F 03 1B BA C5 5B 70 07 49 6D FD 8C 6E 66 48 0F A9
Traceback (most recent call last):
File "decrypt.py", line 23, in <module>
cml = t.dataToXml(notify.data)
File "/home/pi/.local/lib/python2.7/site-packages/gurux_dlms/GXDLMSTranslator.py", line 1732, in dataToXml
_GXCommon.getData(None, data, di)
File "/home/pi/.local/lib/python2.7/site-packages/gurux_dlms/internal/_GXCommon.py", line 309, in getData
raise ValueError("Invalid data type.")
ValueError: Invalid data type.
This message seems to be ok, but with my received key from energy privoder this message is not decryptable.
So is the message unusable or is it the key?
From my email with wien energy I surmise that they have no idea how this should work or if it even works. and after the first time I asked they just removed the customer key from the webportal... now that its back up maybe I ask them again...
Ah ok du warst das :D Ich hab schon viele viele Male urgiert, dass die Kundenschnittstellen wieder aufgedreht werden. Jetzt kann man sie wieder aufdrehen, aber anscheinend sind die Schlüssel falsch?
ja ich nerve sie schon damit seit der schlüssel das erste mal abrufbar war... die antwort war dann immer nur... ist noch nicht "offiziell zur vewendung freigegeben"
ja irgendwas stimmt mit dem schlüssel oder wie sies verschlüsseln nicht...
ich nerv sie auch schon Monate, dass ich das endlich verwenden kann. werden immer wieder vertröstet.
Das erste Mal als ich angerufen haben, wusste der Support gar nicht, dass es die Kundenschnittstelle überhaupt gibt :D Hab sie dann auf ihre eigene Homepage verwiesen zum Nachlesen.
Will die Zählerdaten über den IR in die Homematic Anlage bekommen. der homematic zählersensor ist mist und funktioniert mit dem Zähler nicht. Was willst du damit machen?
ich würde gerne meinen zähler mit einem RPi auf dem Homeassitant läuft auslesen. dazu werde ich dann warscheinlich dieses modul anpassen müssen: https://www.home-assistant.io/integrations/dsmr/
cool, ich hab home assistant ebenfalls auf dem rpi und die homematic ccu. ich spiele die daten in die ccu und hole sie dann mit dem home assistant ab.
also ähnliches problem ;-)
Hallo Leute - ich beiße mir auch die Zähne aus am entschlüsseln. Habe auch einen ISKRA AM550 von den WienerNetzen und den 256bit Key aus dem Webportal.
Wisst ihr schon, wie man das entschlüsseln kann?
Hier eine Message von meinem Zähler:
Ich glaube der key den die WN zur Verfügung stellen ist einfach falsch.
wenn du dir den GXDLMS Director runter lädst und dort unter tools DLMS Translator deinen Hex code eingibst dann sieht man zwar das die message korrekt formatiert ist aber ohne gültigen schlüssel lässt sich der CipheredService Value part nicht entschlüsseln.
Hi, da muss ich dir recht geben!
Ist auch meine Vermutung. Natürlich hab ich bei den Wiener Netzen schon urgiert und meine Infos hin geschickt ;-) Das dauert halt dann auch wieder bis da was kommt.
Ich habe leider kein Windows-Device zur Verfügung um das auch zu probieren.
Welche decrypt Methode wird denn da verwendet? AES-128-ebc oder -CBC oder was anderes?
Wisst ihr wie sich der IV zusammensetzt bei -CBC? Ich vermute es fehlt eher das, als dass der key com Webportal falsch ist.
CBC und du brauchst nur den Block Cipher, keinen IV
wenn das die message ist:
7EA067CF022313FBF1E6E700DB0849534B697492ED664F2000040C7ABD12E155FB0BE0E8F53D6DC9361FA91E640F0648D8F132FF0AF7C09FE1CD8F1146D9017F80B7A7E17784A31CEE33D59AA84C02362891D7A26260821C7498B8EBDC31814F9434246C26FA45737E
dann ist das der ciphered value
2000040C7ABD12E155FB0BE0E8F53D6DC9361FA91E640F0648D8F132FF0AF7C09FE1CD8F1146D9017F80B7A7E17784A31CEE33D59AA84C02362891D7A26260821C7498B8EBDC31814F9434246C26FA
für die encryption brauchst du IV = System title + Framecounter, im fall oben 49534B697492ED66 + 76737894 glaub ich...
Danke steve_cz für das Beispiel, doch da scheint was nicht zu stimmen:
1) bei deiner ciphered-value fehlt ein octet - es ist um eines zu kurz (oder um 15 zu lange)
2) woher nimmt man den framecounter?
3) eine "IV" braucht man nicht? "openssl enc -d" verlangt es bei aes-128-cbc aber, also nur "0000..." annehmen?
4) die IV müsste 32 lang sein, dein SystemTitle+FrameCounter ist aber kürzer. Mit 00 auffüllen rechts, links oder dazwischen?
Ich bin verwundert, dass der Beginn der ciphered value bei jedem paket gleich ist. Das ist bei deinem Beispiel "2000040C7A", also die ersten 5 Octets (ungeachtet Punkt 1)
Nachtrag: offenbar ist der IV bei jedem Paket gleich - darauf deutet hin, dass jeder cipher-block am Anfang gleich ist und man annimmt, das im ersten Teil der entschlüsselten Nachricht immer das gleiche drinnen steht (z.b. ein frame header gefolgt von einem Datum).
Bleibt also noch zu klären:
-) beginnt der cipher-block wirklich schon bei "4f", also ein Byte zuvor?
-) wie den IV korrekt zusammensetzen?
also wenn ich ein push nachricht vom meter und meinen WN schlüssel in den DLMS Translator von Gurux DLMS Director reingebe dann erhalte ich zumindest die info:
IDIS system title:
Manufacturer Code: ISK
Function type: Disconnector extension, Load Management extension, Multi Utility extension
Serial number: 728xxxxx
das wird auch der grund sein warum immer ein "gleicher teil" dabei ist.
also wird der schlüssel auch iwie korrekt sein... allerdings entschlüsselt er nicht den ChipheredService teil - daher war auch die vermutung von Kurumi, dass der Zähler die Daten einfach nicht korrekt verschlüsselt und ein Firmware update braucht.
Habe den DLMS-Translator nun zum Laufen gebracht. Sieht bei mir ähnlich aus.
Dennoch: der CipherText entschlüsselt nicht, und der Translator zeigt ein Oktet zu wenig an. Eventuell macht der SmartMeter als was falsch, oder der Translator?
Bist du mit WN in Kontakt wegen Firmware oder falschem Key?
Soll ich denen auch mal wieder schreiben?
Irgendwo habe ich mal gelesen, der Betreiber kann die Verschlüsselung auch deaktivieren. Schon danach gefragt?
same thing here...
ich hab WN schon geschrieben, dass die Datensätze mit dem Key nicht entschlüsselt werden können.
Wenn sich mehr Leute beschweren, ist das sicher nicht verkehrt ;-) Mich kennen sie auch schon von dem vielen hin und herschreiben. Ich hab sie über Monate gedrängt endlich die Kundenschnittstelle im Webportal wieder anzubieten....
Du könntest aber wegen der Firmware urgieren!
Ich hab mal irgendwo gelesen, dass WN die Verschlüsselung nicht deaktiviert, aber nicht danach gefragt. Bin eher davon ausgegangen, dass das eh funktioniert.
Ich habe von WienerNetze nun folgende Antwort bekommen wegen Nachfrage nach Key/Firmware:
"nach Rückmeldung unserer Fachabteilung informieren wir Sie, dass die Bereitstellung des Schlüssels für die Schnittstelle erfolgreich durch die Wiener Netze erfolgt ist. Wir bedauern Ihnen mitteilen zu müssen, dass wir Ihnen in dieser Angelegenheit nicht weiter behilflich sein können und bitten Sie, sich an den Hersteller Ihres Gerätes zur Auslesung der Daten zu wenden."
Ich hab noch keine Rückmeldung bekommen.
Meine Frage an die WN war, wie ein Datensatz vom Zähler mit dem Key aus dem Webinterface entschlüsselt werden kann.
Ein Beispiel des Datensatzes haben sie bekommen und den Key. Mal sehen, ob da etwas kommt.
Thanks, hopefully they start to think about it in some point.
Please keep us updated on any new information.
In the meantime I answered WN yesterday that I see this to *their* responsibility to provide the correct key and correctly encrypted or unencrypted data.
In addition, I contacted digitalgridsolutions.at for further support on a possible firmware bug, message description and contact persons at WN.
Hi Mikko,
do you remember from where you got the information about that firmware topic, and when approx?
Any minor little info piece could help us.
BR, Pocki
Hi Christoph,
Hi Christoph,
By accident I noticed that header checksum is invalid in the data the meter sends.
We are just making a few changes so you can show this with GXDLMSDirector.
We try to release new version today that you can use to show received data.
BR,
Mikko
Hi Mikko,
Hi Mikko,
thanks for your fast reply and help. I now tried it again to connect to the smart meter via serial connection in the GXDLMSDirector. Now i get the error "Wrong CRC". Could you please assist me what i have to enter in the settings of the device to get it working?
Thank you very much,
Christoph
Hi Christoph,
Hi Christoph,
There is a issue on the meter. CRC is wrong.
Before meter manufacturer fixes that you can get the latest version from the GXDLMSDirector.
Select "DLMS Translator..." under "Tools" menu.
Select "Ciphering" tab and set your key to "Block Cipher Key" field.
Then select "Messages" -tab and paste your frame there and press the "Translate"-button.
You can see encrypted data on the right side.
BR,
Mikko
Thanks for the info!
Thanks for the info!
Threre are some standard values in "System Title", "Block Cipher Key" and "Authentication Key". Should i keep them and only change Block Cipher Key? And what should i select at "Security"?
I tried it with only changing the Block Cipher Key and the result was the following:
1: 7E A0 77 CF 02 23 13 BB 45 E6 E7 00 DB 08 49 53 4B 69 74 55 0B CD 5F 20 00 00 0C B0 3C BB 27 4E 90 5F 09 74 9D 5C 31 36 CC B7 47 57 C5 FC 3A 35 7B AB 06 17 46 94 BB 5C 93 73 82 5F D7 76 77 E5 D9 21 92 17 B2 71 25 E8 CA B2 C0 1B 84 2E 75 6A C8 D0 71 85 FB 2D DF 66 31 89 EF 3E 8C 03 DE 2B B9 C1 68 B8 BF A7 D3 A4 CE F3 19 3F 83 21 E0 06 44 B4 A0 82 3C 92 A0 C0 7E
<!--Invalid data checksum.-->
<HDLC len="76" >
<TargetAddress Value="67" />
<SourceAddress Value="91" />
<!--Notification frame.-->
<FrameType Value="13" />
<PDU>
<GeneralGloCiphering>
<SystemTitle Value="49534B6974550BCD" />
<CipheredService Value="2000000CB03CBB274E905F09749D5C3136CCB74757C5FC3A357BAB06174694BB5C9373825FD77677E5D9219217B27125E8CAB2C01B842E756AC8D07185FB2DDF663189EF3E8C03DE2BB9C168B8BFA7D3A4CEF3193F8321E00644B4A0823C92" />
</GeneralGloCiphering>
</PDU>
</HDLC>
The "value" is equal to the original input from byte 24 to byte 118 and i cant find the encrypted data
Thanks,
Christoph
Hi Christoph,
Hi Christoph,
There is a new version available. Update to that and you should see the commented data is key is correct.
Because you are decrypting the data only "Block Cipher Key" matters.
BR,
Mikko
Hi!
Hi!
Now there are 6 new lines, which are always the same, no matter what Block Cipher Key i use. It doesn´t change and there is still no decrypted message
<!--
IDIS system title:
Manufacturer Code: ISK
Function type: Disconnector extension, Load Management extension, Multi Utility extension
Serial number: 72682445
-->
Best regards,
Christoph
Hi,
Hi,
Then your ciphering key is wrong. In the first post, you said that you are from Austria.
If you login to your power utility web portal you should see the ciphering key.
Can you see it there and verify that it's the same as what you have now?
BR,
Mikko
Hi,
Hi,
I got the key from my provider in a letter by post. May I send it to you via Email? Then you can check it if there is really a problem or if I am just doing it wrong...
If that is ok for you, please tell me your Email adress.
Christoph
Hi,
Hi,
I'll check this if you send it.
You can find my email address from here:
http://gurux.fi/AboutUs
BR,
Mikko
Hi!
Hi!
I sent it to your personal Email adress. Is this ok or should i use the general adress?
Christoph
Hi Christoph,
Hi Christoph,
I received it. I'll check it tomorrow morning.
BR,
Mikko
Hi Mikko,
Hi Mikko,
have you already checked the data?
BR
Christoph
Hi Christoph,
Hi Christoph,
Yes, I have but it failed. I don't know is the reason that the key is in some specific format and it's not hex string. Do we need to swap bytes, etc?
BR,
Mikko
Hi Mikko,
Hi Mikko,
i seriously cannot understand why, but i tried to read some more data packages today. They look the same and i did the same as last time, but now they work... One example:
7E A0 77 CF 02 23 13 BB 45 E6 E7 00 DB 08 49 53 4B 69 74 55 0B CD 5F 20 00 00 0D 0B 00 A6 6D E2 E6 7C 6F 06 23 06 1E 55 11 E7 27 E9 62 0A 52 63 B5 C7 88 C5 E3 FE 5C C0 54 38 B3 E6 D9 5C 45 08 8B 38 58 8A 11 C3 09 85 80 A8 43 04 A2 09 C3 27 86 3D 99 2F 71 55 12 0D E9 F2 21 20 29 DC C6 8C 76 4A A0 5E 5B 0C 31 E9 D4 E3 2A 22 4C 1B 53 71 8B 92 C5 DA 47 B9 38 69 7E
Thanks for your help!
Hi Christoph,
Hi Christoph,
I just try to decrypt this last message and it worked!
There is no CRC error anymore. I believe that meter firmware is updated.
Start GXDLMSDirector and Paste this data to Gurux DLMS Translator. Then press Translate btn.
Decrypted data is there.
BR,
Miko
Great! I can read the values
Great! I can read the values now!
One more question: Is there an API or algorithm for the decryption process on its own? My goal is to receive the serial data with an ESP8266 and send it to ioBroker via MQTT. But i have to decrypt the message either on the ESP8266 or on ioBroker to use the data.
(The pdu to xml function is not necessary, i can easily do this with scripts in ioBroker)
Thank you,
Christoph
Hey Christoph,
Hey Christoph,
glad to hear someone else in Austria is also struggling with the Smartmeters here ;)
I'm currently trying to get access to the optical interface and decryption key from "Wiener Netze" there once was the ability to enable the customer interface but it has been removed after I wrote them that the datapackets are not decryptable.
Cheers,
Tobias
Hi Tobias!
Hi Tobias!
Haha thats Austria... Beautiful country, but the bureaucracy... :D
I was fighting for the activation since November 2019 and got it working today after 100 calls, many friendly and helpful extern people like Mikko here and many lost nerves.
Unfortunately i can not help you, because i have a wired connection with the RJ12 connector. I think in Vienna you use the same model, but the interface is the optical port. In Carinthia the optical port is only for service by the provider. Maybe you can try to call them and annoy them until you get an appropriate answer. It is important that you tell them you mean the interface and not the web-portal. Always i mentioned "Kundenschnittstelle" they thought i mean the web-portal...
Christoph
HI Christoph,
HI Christoph,
Fastest way is if you can decrypt it on the ioBroker. If you do it on the ESP8266 you need to implement it with ANSI C. If you do it on the ioBroker you can use higher-level programming languages.
You can convert data to XML or use GXDLMSClient GetData Method. It can find the frames and returns data from the received frame.
BR,
Mikko
Hi Mikko,
Hi Mikko,
i am sorry, cryptography is not my best area. So i have some basic questions.
There are different types of AES decryption like AES-CBC, AES-ECD or AES-GCM. Which type do i have to use in order to decode my message?
And what are the additional inputs for the different types. For example, if i use AES-GCM i have to add an "IV" and a "GCM Tag". The IV should be the 8 byte of the system title and the 4 byte of the frame counter if I am correct. But where can i find the GCM Tag?
Sorry for the basic questions, but I expect that you know the answers, because you coded your program, which has to use these information.
Thanks for your assistance,
Christoph
Hi,
Hi,
You need to do it using AES-GCM. You can check everything from java implementation.
It's all there and it's in one class (GXSecure).
BR,
Mikko
Hi Mikko,
Hi Mikko,
unfortunately i was still unable to extract the algorithm. On your site https://www.gurux.fi/Gurux.DLMS.Secure you say, that one needs the authentication key too. What is this and where can i find it in my case?
And in the GXSecure class, i guess the correct method is "static byte[] decryptAesGcm". But in the description of it you say "return ENCRYPTED data". However, i would need the decrypted data.
BR,
Christoph Knapitsch
Hi,
Hi,
Only block cipher key is needed for decrypting. I updated this to the documentation.
You are not encrypting data, only decrypting.
This invalid information in return comment parameter is fixed.
BR,
Mikko
hi Christoph
hi Christoph
I have the same ISKRA AM550 from Wiener Netze but can't get out the energy data.
What i receive from the entergy counter via IR is like
7E A0 67 CF 02 23 13 FB F1 E6 E7 00 DB 08 49 53 4B 69 74 92 ED 66 4F 20 01 CD 52 D5 24 AF 4B 82 C1 F4 AE A4 A6 AA F7 4F 6D 82 EF B2 62 2A 5B D5 65 8A 22 FE 91 A9 F2 BD 16 5C 43 CC E1 D8 28 E8 21 97 04 6B 79 A4 58 DD AB 6E 20 CF D7 DB 64 8D 6F 6A F8 FD 97 94 F4 F8 48 8F FC 08 B5 C8 DF 93 7E
message which seems to be too short.
What baudrate, databits, stopbits and parity are you using to receive?
Do you have to send something to the energy counter to receive that message?
Regards from vienna
Stefan
Hey Steve,
Hey Stefan,
I had lots of emails with wiener netze about this... for a long time they hid the "customer key" in the webinterface and told me that the "kundenschnittstelle" is not supposed to be used yet.
now that they have unlocked it again and I will try to catch some data bits again and see if it works now.
The data I always got was "decode able" but not "decrypt able"
and you dont have to send anything the meter sends bursts of data every couple of seconds
9600 Data 8 Stop 1 Parity None
see this thread here:
http://www.gurux.fi/node/13801
thanks for your reply
thanks for your reply tofuSchnitzel!
Ok so i can receive the information and get some data. I also have the key from the web interface, but i am not able to decrypt. the message seems to be shorter than normal. there is a filling byte 00 missing between E6 E7 and DB byte.
for example i received:
7EA067CF022313FBF1E6E7DB0849534B697492ED664F200288BE6EBC8EA6430334C189E05E1D027FF5DFCEA68BB93F293B68E93C9A1CC96D3BA274F009C842606DFD94CE147154027E73D187CB6F899D194A932996CB71F86798FB7AE624C7D5CBF8D55F7E
it seems that there are also some bytes in the end missing....
Can you post a message from yours?
regards Stefan
Hi Mikko @Kurumi!
Hi Mikko @Kurumi!
Ok i got something working.... i used a raspberry pi with IR reader on the interal UART.
Then i used "Gurux.DLMS.Push.Listener.Example.python" to read a push message:
7E A0 67 CF 02 23 13 FB F1 E6 E7 00 DB 08 49 53 4B 69 74 92 ED 66 4F 20 00 02 C7 F2 3F 48 3C 95 59 79 AF 84 15 BD C7 21 DE 26 F5 3B 1F C1 E6 EE 5B CC 0C 0B 33 CE C4 ED 88 A6 DC 6A 04 D7 6D C0 8B 1D B2 F8 D1 99 68 FA CF AE E5 49 1A 7F CC 17 36 94 25 E6 CE B9 30 29 A7 02 13 E6 8B 8E 62 BF 23 0B DD E4 09 85 48 99 7E
Next step was to decrypt it with my key, so i used the python code you provided in another post:
from gurux_dlms.GXByteBuffer import GXByteBuffer
from gurux_dlms.GXDLMSTranslator import GXDLMSTranslator
from gurux_dlms.GXReplyData import GXReplyData
from gurux_dlms.secure.GXDLMSSecureClient import GXDLMSSecureClient
from gurux_dlms.TranslatorOutputType import TranslatorOutputType
reply = GXReplyData()
notify = GXReplyData()
data = "7EA067CF022313FBF1E6E700DB0849534B697492ED664F200002C7F3F6398766E2E1447$
cl = GXDLMSSecureClient(True, 0, 145)
cl.ciphering.authenticationKey = cl.ciphering.blockCipherKey = GXByteBuffer.hex$
dataAvail = cl.getData(GXByteBuffer.hexToBytes(data), reply, notify)
print(str(dataAvail))
if not dataAvail:
print("notify data length: " + str(len(notify.data)))
if len(notify.data) != 0:
print("notify.data: " + str(notify.data))
#Handle notify.
if not notify.isMoreData():
#Show received push message as XML.
t = GXDLMSTranslator()
cml = t.dataToXml(notify.data)
print("cml" + cml)
notify.clear()
Output was:
notify data length: 74
notify.data: 60 C5 F5 E9 95 BD 2A A7 B8 9F 32 5F 7E 22 80 0F 02 EB 9C 72 52 8E B9 27 73 B7 12 02 4E E8 2A D4 5D 76 EF 2B AB C1 73 1D F8 FA 04 60 9C 60 CD AA 5B 89 17 3D 36 16 AC BD 89 6F 03 1B BA C5 5B 70 07 49 6D FD 8C 6E 66 48 0F A9
Traceback (most recent call last):
File "decrypt.py", line 23, in <module>
cml = t.dataToXml(notify.data)
File "/home/pi/.local/lib/python2.7/site-packages/gurux_dlms/GXDLMSTranslator.py", line 1732, in dataToXml
_GXCommon.getData(None, data, di)
File "/home/pi/.local/lib/python2.7/site-packages/gurux_dlms/internal/_GXCommon.py", line 309, in getData
raise ValueError("Invalid data type.")
ValueError: Invalid data type.
This message seems to be ok, but with my received key from energy privoder this message is not decryptable.
So is the message unusable or is it the key?
Regards Stefan
From my email with wien
From my email with wien energy I surmise that they have no idea how this should work or if it even works. and after the first time I asked they just removed the customer key from the webportal... now that its back up maybe I ask them again...
Ah ok du warst das :D Ich hab
Ah ok du warst das :D Ich hab schon viele viele Male urgiert, dass die Kundenschnittstellen wieder aufgedreht werden. Jetzt kann man sie wieder aufdrehen, aber anscheinend sind die Schlüssel falsch?
ja ich nerve sie schon damit
ja ich nerve sie schon damit seit der schlüssel das erste mal abrufbar war... die antwort war dann immer nur... ist noch nicht "offiziell zur vewendung freigegeben"
ja irgendwas stimmt mit dem schlüssel oder wie sies verschlüsseln nicht...
ich nerv sie auch schon
ich nerv sie auch schon Monate, dass ich das endlich verwenden kann. werden immer wieder vertröstet.
Das erste Mal als ich angerufen haben, wusste der Support gar nicht, dass es die Kundenschnittstelle überhaupt gibt :D Hab sie dann auf ihre eigene Homepage verwiesen zum Nachlesen.
Will die Zählerdaten über den IR in die Homematic Anlage bekommen. der homematic zählersensor ist mist und funktioniert mit dem Zähler nicht. Was willst du damit machen?
ich würde gerne meinen zähler
ich würde gerne meinen zähler mit einem RPi auf dem Homeassitant läuft auslesen. dazu werde ich dann warscheinlich dieses modul anpassen müssen:
https://www.home-assistant.io/integrations/dsmr/
cool, ich hab home assistant
cool, ich hab home assistant ebenfalls auf dem rpi und die homematic ccu. ich spiele die daten in die ccu und hole sie dann mit dem home assistant ab.
also ähnliches problem ;-)
Hallo Leute - ich beiße mir
Hallo Leute - ich beiße mir auch die Zähne aus am entschlüsseln. Habe auch einen ISKRA AM550 von den WienerNetzen und den 256bit Key aus dem Webportal.
Wisst ihr schon, wie man das entschlüsseln kann?
Hier eine Message von meinem Zähler:
7e a0 67 cf 02 23 13 fb f1 e6 e7 00 db 08 49 53 4b 69 74 6c 83 b4 4f 20 00 03 b1 d9 16 c2 0d ea cb d1 33 48 b0 7a 7b 3a 85 0a c5 c1 ce 55 a7 0e a5 7a 15 c2 84 c6 ba 47 32 6e 2a 59 8f 32 76 b7 a4 a1 5c 03 93 c4 49 2c a8 3a 56 0b 3b 53 5d 15 8a 22 05 5f 89 a1 11 7c aa 91 89 5f cf 63 c5 05 b4 20 7b 16 a9 a3 f6 79 7e
Ich glaube der key den die WN
Ich glaube der key den die WN zur Verfügung stellen ist einfach falsch.
wenn du dir den GXDLMS Director runter lädst und dort unter tools DLMS Translator deinen Hex code eingibst dann sieht man zwar das die message korrekt formatiert ist aber ohne gültigen schlüssel lässt sich der CipheredService Value part nicht entschlüsseln.
Hi, da muss ich dir recht
Hi, da muss ich dir recht geben!
Ist auch meine Vermutung. Natürlich hab ich bei den Wiener Netzen schon urgiert und meine Infos hin geschickt ;-) Das dauert halt dann auch wieder bis da was kommt.
Ich habe leider kein Windows
Ich habe leider kein Windows-Device zur Verfügung um das auch zu probieren.
Welche decrypt Methode wird denn da verwendet? AES-128-ebc oder -CBC oder was anderes?
Wisst ihr wie sich der IV zusammensetzt bei -CBC? Ich vermute es fehlt eher das, als dass der key com Webportal falsch ist.
welcher teil ist denn der
welcher teil ist denn der ciphered value part?
CBC und du brauchst nur den
CBC und du brauchst nur den Block Cipher, keinen IV
wenn das die message ist:
7EA067CF022313FBF1E6E700DB0849534B697492ED664F2000040C7ABD12E155FB0BE0E8F53D6DC9361FA91E640F0648D8F132FF0AF7C09FE1CD8F1146D9017F80B7A7E17784A31CEE33D59AA84C02362891D7A26260821C7498B8EBDC31814F9434246C26FA45737E
dann ist das der ciphered value
2000040C7ABD12E155FB0BE0E8F53D6DC9361FA91E640F0648D8F132FF0AF7C09FE1CD8F1146D9017F80B7A7E17784A31CEE33D59AA84C02362891D7A26260821C7498B8EBDC31814F9434246C26FA
für die encryption brauchst du IV = System title + Framecounter, im fall oben 49534B697492ED66 + 76737894 glaub ich...
Danke steve_cz für das
Danke steve_cz für das Beispiel, doch da scheint was nicht zu stimmen:
1) bei deiner ciphered-value fehlt ein octet - es ist um eines zu kurz (oder um 15 zu lange)
2) woher nimmt man den framecounter?
3) eine "IV" braucht man nicht? "openssl enc -d" verlangt es bei aes-128-cbc aber, also nur "0000..." annehmen?
4) die IV müsste 32 lang sein, dein SystemTitle+FrameCounter ist aber kürzer. Mit 00 auffüllen rechts, links oder dazwischen?
Ich bin verwundert, dass der Beginn der ciphered value bei jedem paket gleich ist. Das ist bei deinem Beispiel "2000040C7A", also die ersten 5 Octets (ungeachtet Punkt 1)
Nachtrag: offenbar ist der IV
Nachtrag: offenbar ist der IV bei jedem Paket gleich - darauf deutet hin, dass jeder cipher-block am Anfang gleich ist und man annimmt, das im ersten Teil der entschlüsselten Nachricht immer das gleiche drinnen steht (z.b. ein frame header gefolgt von einem Datum).
Bleibt also noch zu klären:
-) beginnt der cipher-block wirklich schon bei "4f", also ein Byte zuvor?
-) wie den IV korrekt zusammensetzen?
Hi,
Hi,
I believe that your key is not correct. If I remember right meter firmware was updated in some point, but I don't know what is the correct version.
BR,
Mikko
also wenn ich ein push
also wenn ich ein push nachricht vom meter und meinen WN schlüssel in den DLMS Translator von Gurux DLMS Director reingebe dann erhalte ich zumindest die info:
IDIS system title:
Manufacturer Code: ISK
Function type: Disconnector extension, Load Management extension, Multi Utility extension
Serial number: 728xxxxx
das wird auch der grund sein warum immer ein "gleicher teil" dabei ist.
also wird der schlüssel auch iwie korrekt sein... allerdings entschlüsselt er nicht den ChipheredService teil - daher war auch die vermutung von Kurumi, dass der Zähler die Daten einfach nicht korrekt verschlüsselt und ein Firmware update braucht.
Habe den DLMS-Translator nun
Habe den DLMS-Translator nun zum Laufen gebracht. Sieht bei mir ähnlich aus.
Dennoch: der CipherText entschlüsselt nicht, und der Translator zeigt ein Oktet zu wenig an. Eventuell macht der SmartMeter als was falsch, oder der Translator?
Bist du mit WN in Kontakt wegen Firmware oder falschem Key?
Soll ich denen auch mal wieder schreiben?
Irgendwo habe ich mal gelesen, der Betreiber kann die Verschlüsselung auch deaktivieren. Schon danach gefragt?
same thing here...
same thing here...
ich hab WN schon geschrieben, dass die Datensätze mit dem Key nicht entschlüsselt werden können.
Wenn sich mehr Leute beschweren, ist das sicher nicht verkehrt ;-) Mich kennen sie auch schon von dem vielen hin und herschreiben. Ich hab sie über Monate gedrängt endlich die Kundenschnittstelle im Webportal wieder anzubieten....
Du könntest aber wegen der Firmware urgieren!
Ich hab mal irgendwo gelesen, dass WN die Verschlüsselung nicht deaktiviert, aber nicht danach gefragt. Bin eher davon ausgegangen, dass das eh funktioniert.
Ich habe von WienerNetze nun
Ich habe von WienerNetze nun folgende Antwort bekommen wegen Nachfrage nach Key/Firmware:
"nach Rückmeldung unserer Fachabteilung informieren wir Sie, dass die Bereitstellung des Schlüssels für die Schnittstelle erfolgreich durch die Wiener Netze erfolgt ist. Wir bedauern Ihnen mitteilen zu müssen, dass wir Ihnen in dieser Angelegenheit nicht weiter behilflich sein können und bitten Sie, sich an den Hersteller Ihres Gerätes zur Auslesung der Daten zu wenden."
Was nun?
Ich hab noch keine
Ich hab noch keine Rückmeldung bekommen.
Meine Frage an die WN war, wie ein Datensatz vom Zähler mit dem Key aus dem Webinterface entschlüsselt werden kann.
Ein Beispiel des Datensatzes haben sie bekommen und den Key. Mal sehen, ob da etwas kommt.
Thanks, hopefully they start
Thanks, hopefully they start to think about it in some point.
Please keep us updated on any new information.
In the meantime I answered WN yesterday that I see this to *their* responsibility to provide the correct key and correctly encrypted or unencrypted data.
In addition, I contacted digitalgridsolutions.at for further support on a possible firmware bug, message description and contact persons at WN.
Hi Mikko,
Hi Mikko,
do you remember from where you got the information about that firmware topic, and when approx?
Any minor little info piece could help us.
BR, Pocki
gute fragen...
gute fragen...
4F müsste die Länge sein = int 79, das würde hin kommen