Is it possible to implement End-to-End Encryption (E2E) within the meaning of "Greenbook 8.1 DLMS/COSEM Architecutre and Protocols" with gurux library?
We would need a possibility to have the following:
- API to seperately encrypt and decrypt COSEM objects as a seperate step before sending and after receiving data
- API to send and receive encrypted COSEM objects without decrypting them (broker functionality with only providing the connection handling and authentication)
So our goal is to separate processing the payload and doing the communication and authentication
- encrypt and decrypt only in HES (Process network)
- send and receive ecnrypted DLMS/COSEM-Objekte with sessionhandling und authentication (DMZ)
So e.g. GXDLMSSecureClient.read() should allow for paramter that are already encrypted DLMS/COSEM-Objects. The return values should also be encrypted.
The library should have a separate API to do the encryption/decryption part in a different process.
Hi Mikko,
in order to implement E2EE you do not need a specific meter - right?
It is just the separation of concerns. The API should provide a way to separate the process of doing the encryption/decryption of the payload in one process and sending/receiving with authentication in another process.
Is this feature already on a roadmap or do you currently not see the demand for this feature?
Could you also give me an approx. time range for implementing this feature?
Btw: I have to investigate whether and when I will be able to get samples which have Security Suite 0 or 1 built in.
You are right. We don't necessarily need the meter, BUT it makes testing easier and we can easily verify that everything is working as planned.
Our clients have not asked this yet, but we already try to implement new functionality little bit earlier.
I can't give approx time at the moment. I'll ask if there are meter manufacturers who are implementing or interested from this and are our clients interested from this.
We can add an example of security suite 0. Security Suite 1 is taking longer because we support that only in Java at the moment.
Hi Mikko,
I haven´t found anything related in the release notes. Do you already have any progress on the topic of having a separate API for encryption/decryption?
End-to-End Encryption (E2EE)
Hi Christoph,
We are supporting ciphering as described in the standard. You can start to use secured connection implementing GXDLMSSecureClient.
GXDLMSSecureClient cl = new GXDLMSSecureClient();
cl.Ciphering.Security = Security.Encryption;
cl.SystemTitle = ;
cl.BlockCipherKey = ;
cl.AuthenticationKey =;
BR,
Mikko
End-to-End Encryption (E2EE)
Hi Mikko,
thank you for your answer - I´ve seen that it is possible that the payloads are encrypted using the GXDLMSSecureClient.
I´d like to clarify our requirements.
We need to fulfill the requirements of the Austrian market https://oesterreichsenergie.at/sicherheitsanforderungen-fuer-smart-mete… - English requirements document under https://oesterreichsenergie.at/files/Downloads%20Netze/20150614%20E2E-S…
So our goal is to separate processing the payload and doing the communication and authentication
- encrypt and decrypt only in HES (Process network)
- send and receive ecnrypted DLMS/COSEM-Objekte with sessionhandling und authentication (DMZ)
So e.g. GXDLMSSecureClient.read() should allow for paramter that are already encrypted DLMS/COSEM-Objects. The return values should also be encrypted.
The library should have a separate API to do the encryption/decryption part in a different process.
Best regards
Christoph
End-to-End Encryption (E2EE)
Hi Christoph,
I'll read the doc and let you know on next week is this possible.
BR,
Mikko
End-to-End Encryption (E2EE)
Hi Mikko,
do you have any news on this topic?
Best regards
Christoph
End-to-End Encryption (E2EE)
Hi,
I'll give more info on this latest tomorrow. We are checking few things first.
BR,
Mikko
End-to-End Encryption (E2EE)
Hi Christoph,
I checked this and this is possible to implement. Do you know any meter that is implementing this?
BR,
Mikko
End-to-End Encryption (E2EE)
Hi Mikko,
in order to implement E2EE you do not need a specific meter - right?
It is just the separation of concerns. The API should provide a way to separate the process of doing the encryption/decryption of the payload in one process and sending/receiving with authentication in another process.
Is this feature already on a roadmap or do you currently not see the demand for this feature?
Could you also give me an approx. time range for implementing this feature?
Btw: I have to investigate whether and when I will be able to get samples which have Security Suite 0 or 1 built in.
Best regards
Christoph
End-to-End Encryption (E2EE)
Hi Christoph,
You are right. We don't necessarily need the meter, BUT it makes testing easier and we can easily verify that everything is working as planned.
Our clients have not asked this yet, but we already try to implement new functionality little bit earlier.
I can't give approx time at the moment. I'll ask if there are meter manufacturers who are implementing or interested from this and are our clients interested from this.
We can add an example of security suite 0. Security Suite 1 is taking longer because we support that only in Java at the moment.
BR,
Mikko
End-to-End Encryption (E2EE)
Hi Mikko,
I haven´t found anything related in the release notes. Do you already have any progress on the topic of having a separate API for encryption/decryption?
Is there a way to accelerate the implementation?
Best regards
Christoph
End-to-End Encryption (E2EE)
Hi Christoph,
Our clients have not asked this yet and we have added support for other things. I can't give any schedule at the moment,
BR,
Mikko