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

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

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

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

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.