search

UtilitechAS / amsreader-firmware

ESP8266 and ESP32 compatible firmware to read, interpret and publish data to MQTT from smart electrical meters, both DLMS and DSMR is supported
Other
363 stars 69 forks source link

[v2.2.21] CGM decryption fails, if auth tag is present in the encrypted DLMS APDU, but no auth key is available #720

Closed GEAG closed 3 months ago

GEAG commented 5 months ago

Describe the bug

It has been found, that some DSO in Switzerland with L&G E450 SM do not only encrypt the DLMS APDU but also deliver the authentication tag appended to the encrypted APDU, while at the same time, do not provide to the customer the authentication key.

According to the encryption specification, authentication of the data issuer by an authentication tag is an optional security feature. What we have found very special is, that the DSO did not provide the customer the authentication key, even after the customer has asked the DSO multiple times for it. But the DSO delivers the authentication tag appended to the encrypted DLMS APDU with every telegram.

Our general recommendation for any DSO would be to:

  1. either provide the authentication key at least upon request by the customer if the DSO has append an authentication tag
  2. or, if they have decided, to only provide an encryption key to the customer, to not append the authentication tag at all

In both these case, GcmParser.cpp has been found to decrypt the encrypted DLMS APDU with no problem.

But in the special case that:

  1. the encrypted DLMS APDU is delivered by the SM CII (configured by the DSO) includes the appended authentication tag
  2. and the DSO does not provide the corresponding authentication key to its customer, the code in GcmParser.cpp ov v2.2.21 fails do decrypt that encrypted DLMS APDU and only tells "decryption failed" in the debug log.

In that combination when the DLMS APDU is encrypted as well as the authentication tag appended to it, the security byte at pos 13.dec in the header of the encrypted DLMS APDU (starts with 0xDB at pos 0.dec) is set to 0x30.

To Reproduce Steps to reproduce the behavior:

  1. Must have a DSO that has configured its SM to encrypt the data and append the authentication tag (security byte = 0x30).
  2. Do not configure the authentication key through the webUI (just the encryption key)
  3. Check the debug log

Expected behavior The decryption should also succeed, even if no authentication key is configured, just the correct decryption key.

Screenshots irrelevant

Hardware information:

Relevant firmware information:

Additional context

A reworked and tested source code of GcmParser.cpp v2.2.21 will be provided by GEAG under the same AGPL license as the original v2.2.21 code. Please consult the file appended to this issue.

GcmParser_cpp.txt

ArnieO commented 5 months ago

Thank you for the heads up and code, we will look into this.

gskjold commented 5 months ago

Thank you for the thorough feedback. As I read it, the following commit is sufficient to remedy this specific situation: https://github.com/UtilitechAS/amsreader-firmware/commit/e575ab755c540cec450b49ff1ba0e55bc2cbbea9