reading “Security setup”.certificates

Forum Rules

Before commenting read Forum rules

Don't comment the topic if you have a new question.

You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.

By Chris_Zhu_1986 , 11 March, 2023
Forums
DLMSDirector

Hi,
I have a problem with reading “Security setup”.certificates by gurux.
According to the description of the Blue Book,The octet-strings that hold the serial_number, issuer, subject, and subject_alt_name shall include the tag, length and value (TLV) of the corresponding field of the Certificate.
But the gurux seems does not include the TLV ，when I read certificate from meter,it shows unreadable character ，below is an eaxmple from CTT and also the data from meter.

----------------------------------------CTT EAXMPLE:--------------------------------------------
<Structure Qty="0006" >
<Enum Value="02" /> // certificate_entity = 2, certification authority
<Enum Value="03" /> // certificate-type = 3, other,
// this Root-CA Certificate
<OctetString Value="0202009C" // Serial number
<OctetString Value="303F310B3009060355040613024348311E301C060355040A0C15444C4D532055534552204153534F43494154494F4E3110300E06035504030C07526F6F745F4341" /> // issuer
<OctetString Value="303F310B3009060355040613024348311E301C060355040A0C15444C4D532055534552204153534F43494154494F4E3110300E06035504030C07526F6F745F4341" /> // subject, same as issuer,
// Root-CA Certificate self-signed
<OctetString Value="" /> //subject_alt_name

-----------------------------------DATA FROM METER:-------------------------------------------
1: 7E A0 A7 03 02 23 92 E0 83 E6 E7 00 C4 01 C1 00 01 01 02 06 16 02 16 03 09 04 02 02 00 9C 09 41 30 3F 31 0B 30 09 06 03 55 04 06 13 02 43 48 31 1E 30 1C 06 03 55 04 0A 0C 15 44 4C 4D 53 20 55 53 45 52 20 41 53 53 4F 43 49 41 54 18 00 00 31 10 30 0E 06 03 55 04 03 0C 07 52 6F 6F 74 5F 43 41 09 41 30 3F 31 0B 30 09 06 03 55 04 06 13 02 43 48 31 1E 30 1C 06 03 55 04 0A 0C 15 44 4C 4D 53 20 55 53 45 52 20 41 53 53 4F 43 49 41 54 18 00 00 31 10 30 0E 06 03 55 04 03 0C 07 52 6F 6F 74 5F 43 41 09 00 77 8A 7E
<HDLC len="A6" >
<TargetAddress Value="1" />
<!-- Logical address:1, Physical address:17 -->
<SourceAddress Value="91" />
<FrameType Value="92" />
<PDU>
<GetResponse>
<GetResponseNormal>
<!-- Priority: High, ServiceClass: Confirmed, Invoke ID: 1 -->
<InvokeIdAndPriority Value="C1" />
<Result>
<Data>
<Array Qty="01" >
<Structure Qty="06" >
<Enum Value="02" />
<Enum Value="03" />
<!-- 2:02:00 -->
<OctetString Value="0202009C" />
<OctetString Value="303F310B3009060355040613024348311E301C060355040A0C15444C4D532055534552204153534F434941541800003110300E06035504030C07526F6F745F4341" />
<OctetString Value="303F310B3009060355040613024348311E301C060355040A0C15444C4D532055534552204153534F434941541800003110300E06035504030C07526F6F745F4341" />
<OctetString Value="" />
</Structure>
</Array>
</Data>
</Result>
</GetResponseNormal>
</GetResponse>
</PDU>
</HDLC>

Kurumi

3 years 2 months ago

Hi,

If you compare the public key certificates you see the difference:

CTT example:
303F310B3009060355040613024348311E301C060355040A0C15444C4D532055534552204153534F43494154494F4E3110300E06035504030C07526F6F745F4341

Certificate from the meter:
303F310B3009060355040613024348311E301C060355040A0C15444C4D532055534552204153534F434941541800003110300E06035504030C07526F6F745F4341

Check those bytes:

DLMS USER ASSOCIATION
0C 15 44 4C 4D 53 20 55 53 45 52 20 41 53 53 4F 43 49 41 54 49 4F 4E

DLMS USER ASSOCIAT[Invalid chars]
0C 15 44 4C 4D 53 20 55 53 45 52 20 41 53 53 4F 43 49 41 54 18 00 00

That invalid char causes that C# can't show the string correctly.

BR,
Mikko

oh! thanks for your reply！ I correct the bytes,but GURUX still show unreadable character,you can also see the serial number shows"33685660" but the real value is 0x009C which is 156 in decimal format,gurux seems take all bytes (02 02 00 9c)in to calculation :
BlockCipher key: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
Authentication Key:D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF
1: 7E A0 A7 03 02 23 FC 98 09 E6 E7 00 C4 01 C1 00 01 01 02 06 16 02 16 03 09 04 02 02 00 9C 09 41 30 3F 31 0B 30 09 06 03 55 04 06 13 02 43 48 31 1E 30 1C 06 03 55 04 0A 0C 15 44 4C 4D 53 20 55 53 45 52 20 41 53 53 4F 43 49 41 54 49 4F 4E 31 10 30 0E 06 03 55 04 03 0C 07 52 6F 6F 74 5F 43 41 09 41 30 3F 31 0B 30 09 06 03 55 04 06 13 02 43 48 31 1E 30 1C 06 03 55 04 0A 0C 15 44 4C 4D 53 20 55 53 45 52 20 41 53 53 4F 43 49 41 54 49 4F 4E 31 10 30 0E 06 03 55 04 03 0C 07 52 6F 6F 74 5F 43 41 09 00 D9 82 7E
<HDLC len="A6" >
<TargetAddress Value="1" />
<!-- Logical address:1, Physical address:17 -->
<SourceAddress Value="91" />
<FrameType Value="FC" />
<PDU>
<GetResponse>
<GetResponseNormal>
<!-- Priority: High, ServiceClass: Confirmed, Invoke ID: 1 -->
<InvokeIdAndPriority Value="C1" />
<Result>
<Data>
<Array Qty="01" >
<Structure Qty="06" >
<Enum Value="02" />
<Enum Value="03" />
<!-- 2:02:00 -->
<OctetString Value="0202009C" />
<OctetString Value="303F310B3009060355040613024348311E301C060355040A0C15444C4D532055534552204153534F43494154494F4E3110300E06035504030C07526F6F745F4341" />
<OctetString Value="303F310B3009060355040613024348311E301C060355040A0C15444C4D532055534552204153534F43494154494F4E3110300E06035504030C07526F6F745F4341" />
<OctetString Value="" />
</Structure>
</Array>
</Data>
</Result>
</GetResponseNormal>
</GetResponse>
</PDU>
</HDLC>

Image

Kurumi

3 years 2 months ago

Hi,

I have asked this from the DLMS UA because we have meters that are returning plain data without Type-Length-Value. It might be that we have to handle both cases.

I'll keep you posted.

BR,
Mikko

Kurumi

3 years 2 months ago

Hi,

This is fixed for the version 9.0.2303.2001. Update to the latest version from GXDLMSDirector.

BR,
Mikko