help with General GLO Cipher

9 posts / 0 new
Last post
Swappage
help with General GLO Cipher

Hello everyone,
I'm writing a simple server to simulate a meter for experimenting with DLMS Protocol, now I have the following PDU:

00 01 00 01 00 01 00 21 DB 00 1E 30 00 00 00 02 19 FA BA 77 D2 DD 1B 65 06 28 25 58 06 2B 55 14 67 9F B7 BF 5F F7 AA E5 33

which according to the DLMS translator appears to be:

<GeneralGloCiphering>
<SystemTitle Value="" />
<CipheredService Value="300000000219FABA77D2DD1B6506282558062B5514679FB7BF5FF7AAE533" />
</GeneralGloCiphering>

I'd like to use GXDLMSSecureServer to decode this request, and reply accordingly, obviously as of now, my server doesn't understand the request and doesn't reply anything

Can anyone help me out with a little example on how to add GLO cipher to my server so that i can correctly decrypt the above request coming from the client?

thanks in advance for your kind reply.

kurumi
kurumi's picture
help with General GLO Cipher

Hi,

30 // Security level
00 //Security Suite
000002 //invocationCounter
19 //Data len
FABA77D2DD1B6506282558062B5514679FB7BF5FF7AAE533 //Crypted data

BR,

Mikko

________________________________________
Mikko Kurunsaari
Gurux Ltd
Hermiankatu 6-8 H 33720 TAMPERE, FINLAND
Phone: +358 3 265 1244
Home page: http://www.gurux.org

Swappage
Thanks for your help Mikko,

Thanks for your help Mikko,
how do i set up gurux .NET do decrypt it? i have the keys but i don't understand how to properly code a snipplet that does the job.

but also, considering suite 0 is AES-GCM-128, shoulòd the payload (encrypted data) be multiple of 128 bit in length?

Thanks in advance

kurumi
kurumi's picture
General GLO Cipher

Hi,

You can use ciphering like this:

GXDLMSSecureClient sc = new GXDLMSSecureClient();
sc.Ciphering.Security = Security.Encryption;
//Change sefault security. This is manufacturer depend info.
//sc.Ciphering.SystemTitle = ...;
//sc.Ciphering.AuthenticationKey = ...
sc.Ciphering.BlockCipherKey = ...

Everything else is handled automatically after parameters are correct.

BR,
Mikko

________________________________________
Mikko Kurunsaari
Gurux Ltd
Hermiankatu 6-8 H 33720 TAMPERE, FINLAND
Phone: +358 3 265 1244
Home page: http://www.gurux.org

Swappage
Hi Mikko, and thanks again

Hi Mikko, and thanks again for your kind reply and support.

I've tried doing as you suggested but unfortunately i cant get it to work.

I have some PDU logs here, maybe you can help me out with these informations, because it doesn't look normal to me.. and i don't understand.

I've redacted some sensitive values like LDN and PDR but the conversation is still consistent.

As you can see most of the conversation, including the association, happen in the clear, then i start receiving encrypted requests from the client

NOTE: I'm the server in this conversation

Thanks in advance for all your time and help

# AARQ and Reply happens in clear text
<- 00 01 00 10 00 01 00 1F 60 1D A1 09 06 07 60 85 74 05 08 01 01 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 1C 3E 3D FF FF
Connected.
-> 00 01 00 01 00 10 00 2B 61 29 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 BE 10 04 0E 08 00 06 5F 1F 04 00 00 1E 1D 04 00 00 07

#Client asks for PDR and reply
<- 00 01 00 10 00 01 00 0D C0 01 C1 00 01 00 00 60 01 0A FF 02 00
Client Read value from 0.0.96.1.10.255 attribute: 2.
-> 00 01 00 01 00 10 00 14 C4 01 C1 00 0A 0E 30 30 30 30 30 30 30 30 30 30 30 30 30 30 //Redacted for privacy reasons

#Clients asks for release and gets it
<- 00 01 00 10 00 01 00 05 62 03 80 01 1E
-> 00 01 00 01 00 10 00 05 63 03 80 01 00

#client associates again (again in plain unencrypted
<- 00 01 00 10 00 01 00 1F 60 1D A1 09 06 07 60 85 74 05 08 01 01 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 1C 3E 3D FF FF
Connected.
-> 00 01 00 01 00 10 00 2B 61 29 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 BE 10 04 0E 08 00 06 5F 1F 04 00 00 1E 1D 04 00 00 07

#Client asks for LDN and server replies accordingly
<- 00 01 00 10 00 01 00 0D C0 01 C1 00 01 00 00 2A 00 00 FF 02 00
Client Read value from 0.0.42.0.0.255 attribute: 2.
-> 00 01 00 01 00 10 00 16 C4 01 C1 00 09 10 41 41 41 41 30 31 32 33 34 35 36 37 38 39 3A 3B //Redacred for privacy reasons

#Client asks for for another parameter (Management Frame Counter) and gets the reply
<- 00 01 00 10 00 01 00 0D C0 01 C1 00 01 00 00 2B 01 01 FF 02 00
Client Read value from 0.0.43.1.1.255 attribute: 2.
-> 00 01 00 01 00 10 00 09 C4 01 C1 00 06 00 00 00 01

#Client asks for release and gets it (again)
<- 00 01 00 10 00 01 00 05 62 03 80 01 1E
-> 00 01 00 01 00 10 00 05 63 03 80 01 00

#Encrypted message from client (how to handle this?)
<- 00 01 00 01 00 01 00 21 DB 00 1E 30 00 00 00 02 19 FA BA 77 D2 DD 1B 65 06 28 25 58 06 2B 55 14 67 9F B7 BF 5F F7 AA E5 33

kurumi
kurumi's picture
General GLO Cipher

Hi,

Server will handle that automatically. You don't need to care from that. Just set correct parameters.

BR,

Mikko

________________________________________
Mikko Kurunsaari
Gurux Ltd
Hermiankatu 6-8 H 33720 TAMPERE, FINLAND
Phone: +358 3 265 1244
Home page: http://www.gurux.org

Swappage
Hi Mikko, the only parameter

Hi Mikko, the only parameter i was provided was the key, and the fact that i know it's using general GLO Ciphering.

Maybe there is something wrong with the code.

how can i check if my server is actually trying to decrypt the APDU? because it just hangs there without any information and i have no clue on what's going on.

EDIT: i think i know what's going on...
appearently the client doesn't seem to respect the standards.

Appearently the client, after the second release request, immediatelly sends a general glo ciphered payload, but without sending an AARQ for LN_WITH_CIPHERING, therefore my server doesn't know how to deal with the encrypted data.

Do you know if there is a workaround for this? like forcing the APDU to be threated as General GLO ciphered payload despite it not being annouced with a proper AARQ?

kurumi
kurumi's picture
General GLO Cipher

Hi,

You should receive two keys: authentication key and block cipher key. Both values are 16 bytes long.
If those keys are not the same for client and server strange data is generated.

You need to set Security to use LN_WITH_CIPHERING.
GXDLMSSecureClient sc = new GXDLMSSecureClient();
sc.Ciphering.Security = Security.Encryption;

BR,

Mikko

________________________________________
Mikko Kurunsaari
Gurux Ltd
Hermiankatu 6-8 H 33720 TAMPERE, FINLAND
Phone: +358 3 265 1244
Home page: http://www.gurux.org

Swappage
Hi, thanks for your kind

Hi, thanks for your kind reply and for keeping up with updating me

you are really helpful

Unfortunately i'm not the client in this case and i don't have any control over the client, i'm the server (meter) which replies to the client.

appearently the client is not sending me an AARQ with LN_WITH_CIPHERING

i feel like the vendor is not respecting the DLMS/COSEM standard at all at this point