I am trying to communicate with a DLMS compatible meter that uses HLS-5 protection (equivalent in GuruX library to DLMS_AUTHENTICATION_HIGH_GMAC) over GPRS. I'm using the C++ version of the GuruX library. When calling the AARQRequest() function to generate an AARQ frame, the entire application crashes when calling the EncryptBlock function from the GXCipher class, specifically at line 562 for this piece of code "r0 ^= Shift(AES[block->c3 >> 24], 8);".
I used the following reference: http://www.gurux.fi/Gurux.DLMS.Secure
The following is a code snippet of the DLMSSecureClient initialization and setup to use this level of authentication:
Client address: 0x01
Server address: 0x01
Password: "0000000000000000"
System title: "00000000"
Encryption key: "0000000000000000"
Authentication key: "0000000000000000"
my apologies for the delayed reply.
We're using GCC 5.5 for C++ compilation, with full C++11 compatibility, built on a CentOS 7 machine. The interface value is DLMS_INTERFACE_TYPE_WRAPPER, and we're using the latest version of the library.
We ran our tests on the C# version of the library and it's working perfectly with no crashes or errors, we're still facing problems with the C++ version on Linux.
We ran a debugging session on the culprit line to check the values that causes this crash, and inside the EncryptBlock function, the Working Key value inside m_WorkingKey generated by the library is 7754656, the GetRounds function returned 10 for 10 rounds, on line 562 of the GXCipher.cpp file the block->c3 >> 24 operation returns 0xffffffff87, a value that does not exist in the AES array (the Rijndael (AES) Encryption fast table) as the return value of AES[block->c3 >> 24] is null.
Even when compiling GuruX with the default compiler (GCC 4.8.5) and the default make file with the -std=c++11 flag for C++11 support, still the same result. Without the -std=c++11 flag it crashes as it cannot find C++11 functions such as to_string().
we do not use the default authentication and block cipher keys provided by the library, and I made sure that the authentication and block cipher keys provided in the first post were set correctly and not changed through the entire debug session.
Thanks from this info. I'll let you know as soon as we found anything.
One thing. Can you communicate with the meter at all or are you receiving data and then it crashes at the same place every time? How much data you are receiving when it crash (about)?
the crash occurs during the generation of the AAR request right after after the initial connection with the meter through GPRS before any data exchange take place, the following is the function trace to the crash:
AARQRequest() -> CGXAPDU::GenerateAarq() -> GenerateUserInformation() -> cipher->Encrypt() -> Init() -> ProcessBlock() -> EncryptBlock()
The crash always occurs at this statement inside the EncryptBlock() function: r0 ^= Shift(AES[block->c3 >> 24], 8); found at line 562, we use the latest library.
after taking a deeper look at the library, in particular at the CGXCipher.cpp file, it seems that the problem lies in the system itself. Our GCC compiler is a 64-bit one as well as the Linux distro itself, and from our research, it turns out that the essence of the problem is the data types. When debugging inside the CGXCipher.cpp file, the long unsigned values seemed to be the problem, since in a distro like Debian the size of such data type is 4 bytes, whereas in CentOS 7 it's 8, hence the wrong values and crashes we were receiving.
The crashes and wrong values occurred mostly by the shifting operations due to the wrong data type sizes, we tried to change some of the values, but we've never gotten a correct Association Frame yet.
Thanks from this info. We installed CentOS 7 last week and it worked without problems.
I'll ask to test this again. I'll give more results in the end of this week.
Authentication through HLS-5
Hi,
We have tested this using Windows and Linux without problems. What compiler you are using? What is value of the interface that you are using?
BR,
Mikko
Authentication through HLS-5
Greetings,
my apologies for the delayed reply.
We're using GCC 5.5 for C++ compilation, with full C++11 compatibility, built on a CentOS 7 machine. The interface value is DLMS_INTERFACE_TYPE_WRAPPER, and we're using the latest version of the library.
We ran our tests on the C# version of the library and it's working perfectly with no crashes or errors, we're still facing problems with the C++ version on Linux.
We ran a debugging session on the culprit line to check the values that causes this crash, and inside the EncryptBlock function, the Working Key value inside m_WorkingKey generated by the library is 7754656, the GetRounds function returned 10 for 10 rounds, on line 562 of the GXCipher.cpp file the block->c3 >> 24 operation returns 0xffffffff87, a value that does not exist in the AES array (the Rijndael (AES) Encryption fast table) as the return value of AES[block->c3 >> 24] is null.
Your advice will be much appreciated.
Thank you
Authentication through HLS-5
Hi,
We'll install CentOS 7 and try to make this happen. Have you made any changes for the make file?
Are you using default keys?
BR,
Mikko
Authentication through HLS-5
Greetings,
we made the following changes inside the library's make file to point to GCC 5.5, which we compiled on CentOS 7:
CC = /opt/gcc/bin/g++
CFLAGS = -I/opt/gcc/include -I/opt/gcc/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/include -I/opt/gcc/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/include-fixed -std=c++11 -O3 -Wall -fPIC
LINKER = /opt/gcc/bin/gcc-ar rvs
Even when compiling GuruX with the default compiler (GCC 4.8.5) and the default make file with the -std=c++11 flag for C++11 support, still the same result. Without the -std=c++11 flag it crashes as it cannot find C++11 functions such as to_string().
Best regards
Authentication through HLS-5
Hi,
I just verify that are you using default authentication and block cipher keys or have you changed them?
BR,
Mikko
Authentication through HLS-5
Greetings,
we do not use the default authentication and block cipher keys provided by the library, and I made sure that the authentication and block cipher keys provided in the first post were set correctly and not changed through the entire debug session.
Best regards
Authentication through HLS-5
Hi,
Thanks from this info. I'll let you know as soon as we found anything.
One thing. Can you communicate with the meter at all or are you receiving data and then it crashes at the same place every time? How much data you are receiving when it crash (about)?
BR,
Mikko
Authentication through HLS-5
Greetings,
the crash occurs during the generation of the AAR request right after after the initial connection with the meter through GPRS before any data exchange take place, the following is the function trace to the crash:
AARQRequest() -> CGXAPDU::GenerateAarq() -> GenerateUserInformation() -> cipher->Encrypt() -> Init() -> ProcessBlock() -> EncryptBlock()
The crash always occurs at this statement inside the EncryptBlock() function: r0 ^= Shift(AES[block->c3 >> 24], 8); found at line 562, we use the latest library.
thank you
Authentication through HLS-5
Greetings,
after taking a deeper look at the library, in particular at the CGXCipher.cpp file, it seems that the problem lies in the system itself. Our GCC compiler is a 64-bit one as well as the Linux distro itself, and from our research, it turns out that the essence of the problem is the data types. When debugging inside the CGXCipher.cpp file, the long unsigned values seemed to be the problem, since in a distro like Debian the size of such data type is 4 bytes, whereas in CentOS 7 it's 8, hence the wrong values and crashes we were receiving.
The crashes and wrong values occurred mostly by the shifting operations due to the wrong data type sizes, we tried to change some of the values, but we've never gotten a correct Association Frame yet.
Your advice is much appreciated in this regards.
Thank you.
Authentication through HLS-5
Hi,
Thanks from this info. We installed CentOS 7 last week and it worked without problems.
I'll ask to test this again. I'll give more results in the end of this week.
BR,
Mikko
Authentication through HLS-5
Hi,
We have changed ANSI C++ code. We are releasing a new version after tests at end of this month.
BR,
Mikko
Hi,
Hi,
There is a new version where GMAC is improved. It's taking less memory, etc.
Please, let me know if you have still problems.
BR,
Mikko