[AlexRayne 7]

Кто нить уже видел спецификацию DLMS для DataNotificationConfirmation ? 4й СПОДЭС уже на неё ссылается. Поделитесь подробностями?

 

[Andrei Kharitonov 0]

У какого то китайского товарища выложены некоторые выдержки, в которых можно получить инфу по этой ссылке:
https://hjk.life/posts/dlms-green-1/

Судя по всему, вышла 9ая версия зеленой книги (dlms ua 1000-2 ed. 9). В которой и описывается confirm сервис.
Если кто то заимеет эту книжку, буду благодарен за ссылку на ресурс.

P.s Китайцу писал на личную почту, он не ответил.

[AlexRayne 7]

DLMS для DataNotificationConfirmation - описывается в 10й версии GB. Так что китаец неактуален

[Andrei Kharitonov 0]

Прикладываю скрин у китайца, все таки про подтверждение там есть. даже можно примерно прикинуть содержание подтверждения

[AlexRayne 7]

Да, древний ДЛМС тоже так рисует табличку, но вот там нет этого:

 

Цитата

В [14] версии 10 определён новый сервис Data-notification-confirm (выделено жёлтым)
XDLMS-APDU ::= CHOICE
{
-- standardised xDLMS pdus used in DLMS/COSEM
-- data-notification
data-notification [15] IMPLICIT Data-Notification,

data-notification-confirm [16] IMPLICIT Data-Notification-Confirm,

...

Data-Notification ::= SEQUENCE
{
long-invoke-id-and-priority Long-Invoke-Id-And-Priority,
date-time OCTET STRING,
notification-body Notification-Body
}

Data-Notification-Confirm ::= SEQUENCE {

long-invoke-id-and-priority Long-Invoke-Id-And-Priority,

date-time OCTET STRING

}

 

[Lj_ 0]

Всем доброго дня! Подскажите пожалуйста: по какому алгоритму генерируется псевдослучайная последовательность при авторизации с уровнем доступа Конфигурирование? Пытаюсь подключиться к счетчику Меркурий 234.

[AlexRayne 7]

7 часов назад, Lj_ сказал:

псевдослучайная последовательность при авторизации с уровнем доступа Конфигурирование

о чем речь? о challenge? челешж - просто случайные байты. я их рандомом делаю

 

[Lj_ 0]

Да, речь о челендже. Не совсем разобрался: как в ПУ передается пароль 16 двоек?

[AlexRayne 7]

а в чем проблема? А СПОДЭС то читали? там описан механизм обмена челенжами. Что непонятно, приводите ситуацию на байтах

челенж может быть любого размера по идее, помещающийся в ПДУ 

 

[Lj_ 0]

В 22.09.2023 в 21:21, AlexRayne сказал:

а в чем проблема? А СПОДЭС то читали? там описан механизм обмена челенжами. Что непонятно, приводите ситуацию на байтах

челенж может быть любого размера по идее, помещающийся в ПДУ 

 

 

СПОДЭС читал, но, вероятно, не очень внимательно, раз не удалось понять процедуру аутентификации в режиме Конфигуратор

 

Вот трассировка сообщений при установке соединения:

Tx= 7E A0 08 0271 61 53 8C D2 7E
Rx=  7E A0 1F 61 02 71 73 16 31 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 01 53 3B 7E

-------
Tx= 7E A0 08 0271 61 93 80 14 7E
Rx=  7E A0 1F 61 02 71 73 16 31 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 01 53 3B 7E

-------
Tx= 7E A04D027161106545E6E600603EA1090607608574050801018A0207808B0760857405080202AC128010 11A51A13AA5CFC59BB1B43A2D7AD8AAC BE10040E01000000065F1F0400001FFFFFFF BD 31 7E

Вот тут, как я понимаю, 11A51A13AA5CFC59BB1B43A2D7AD8AAC - псевдослучайная последовательность байт со стороны клиента
Rx=  7E A0 59 61 02 71 30 33 BB E6 E7 00 61 4A A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 0E 88 02 07 80 89 07 60 85 74 05 08 02 02 AA 12 80 10 B8 DC EE F7 FB FD FE FF FF 7F 3F 9F CF E7 73 B9 BE 10 04 0E 08 00 06 5F 1F 04 00 00 18 1D 00 FA 00 07 15 08 7E

Псевдослучайная последовательность со стороны ПУ: B8 DC EE F7 FB FD FE FF FF 7F 3F 9F CF E7 73 B9

------

Запрос информации об ассоциации №1, тоже не совсем разобрался зачем нужен.
Tx= 7E A02C0271613282EDE6E600C301C1000F0000280000FF010109103925A6A44551A9B6A496D415EDBA67E0 3F 83 7E
Rx=  7E A0 25 61 02 71 52 E4 99 E6 E7 00 C7 01 C1 00 01 00 09 10 64 C7 E1 E5 24 B1 14 A7 50 CC 18 3D 82 4A E0 00 14 5D 7E

 

Если псевдослучайная последовательность - просто результат случайной генерации, то зачем нужен пароль 2222222222222222 ?

[AlexRayne 7]

Цитата

10.3.3 

1.1.1 Высокий уровень безопасности- доступ к прибору учета осуществляется через процедуру аутентификации доступа основанную на алгоритме, при котором пароль не передается. Данный алгоритм состоит из четырех этапов:

- Этап 1: Клиент генерирует псевдослучайную последовательность байт, так называемый «запрос» CtoS (ClientToServer). Затем СtoS передается в кадре AARQ ПУ.

- Этап 2: ПУ генерирует псевдослучайную последовательность байт, так называемый «запрос» StoC (ServerToClient). Затем StoC передается в кадре AARE клиенту.

            Если последовательности CtoS и StoC идентичны, то клиент должен принудительно завершить процедуру аутентификации с отрицательным результатом и не устанавливать соединение.

- Этап 3: Клиент обрабатывает StoC и дополнительную информацию в соответствии с правилами механизма аутентификации высокого уровня безопасности и отправляет результат ПУ. ПУ проверяет, является ли f(StoC) результатом правильной обработки, и - если это так - он принимает аутентификацию клиента;

- Этап 4: ПУ обрабатывает CtoS и дополнительную информацию в соответствии с правилами механизма аутентификации высокого уровня безопасности и отправляет результат клиенту. Клиент проверяет, является ли f(CtoS) результатом правильной обработки, и - если это так - он принимает аутентификацию ПУ;

-          Формально после этапа 2 устанавливается соединение между клиентом и ПУ, однако клиенту разрешен доступ только к методу 1 объекта 0.0.40.0.0.255, ИК: 15.

-          Результаты обработки f(StoC) и f(CtoS) передаются при помощи метода 1 объекта 0.0.40.0.0.255 ИК: 15. Если оба этапа пройдены успешно, то между клиентом и ПУ устанавливается соединение, в противном случае - соединение не устанавливается.

Это выдержка из СПОДЭС. если не имеете этого документа, советую найти.

чуть ниже там есть примеры установления соединения:
 

Цитата

Отправитель	Трафик HDLC	Комментарий
Клиент	7E A008 0221 41 93 50B4 7E	Команда SNRM
Сервер	7E A008 41 0221 73 2EE9 7E	Подтверждение UA
Клиент	7E A043 0221 41 10 0D84 E6E600 60 36 A109060760857405080101 8A020780 8B 0760857405080202 AC128010  4B35366956616759 0000000000000000 BE10040E01000000 065F1F 040000101C FFFF 218Е 7E	I-кадр AARQ с челленджем CtoS «K56iVagY», дополненным нулями
Сервер	7E A051 41 0221 73 2EA9 E6E700 61 42 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 0E 88 02 07 80 89 07 60 85 74 05 08 02 05 AA 12 80 10 50 36 77 52 4A 32 31 46 00 00 00 00 00 00 00 00 BE 10 04 0E 08 00 06 5F 1F 04 00 00 50 1F 01 F4 00 07 A0Е4 7E	I-кадр AARE с челленджем StoC «P6wRJ21F», дополненным нулями
Клиент	7E A02C 0221 41 74 2DC7 E6E600 C301C1 000F 0000280001FF 01 09 11 10 00000001 1A52FE7D D3E72748973C1E28 EFB4 7E	Action-request-normal 000F 0.0.40.0.1.255 01 f(StoC) 10 00000001 1A52 FE7D D3E727 48973C1E28
Сервер	7E A02C 41 0221 75 2CC7 E6E700 C701C1 000F 0000280001FF 01 09 11 1001234567FE1466AF B3DBCD4F93 89E2B7 EFB7 7E	Action-responce-normal 000F 0.0.40.0.1.255 01  f(CtoS) 100123 4567FE1466AF B3DBCD4F93 89E2B7

 

9 часов назад, Lj_ сказал:

Tx= 7E A04D027161106545E6E600603EA1090607608574050801018A0207808B0760857405080202AC128010 11A51A13AA5CFC59BB1B43A2D7AD8AAC BE10040E01000000065F1F0400001FFFFFFF BD 31 7E

Вот тут, как я понимаю, 11A51A13AA5CFC59BB1B43A2D7AD8AAC - псевдослучайная последовательность байт со стороны клиента
Rx=  7E A0 59 61 02 71 30 33 BB E6 E7 00 61 4A A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 0E 88 02 07 80 89 07 60 85 74 05 08 02 02 AA 12 80 10 B8 DC EE F7 FB FD FE FF FF 7F 3F 9F CF E7 73 B9 BE 10 04 0E 08 00 06 5F 1F 04 00 00 18 1D 00 FA 00 07 15 08 7E

вот расшифровка пакета:

Цитата

<HDLC len="4C" >
<!-- Logical address:1, Physical address:56 -->
<TargetAddress Value="B8" />
<SourceAddress Value="30" />
<FrameType Value="10" />
<!-- AARQ frame. -->
<PDU>
<AssociationRequest>
  <ApplicationContextName Value="LN" />
  <SenderACSERequirements Value="1" />
  <MechanismName Value="High" />
  <CallingAuthentication Value="11A51A13AA5CFC59BB1B43A2D7AD8AAC" />
  <InitiateRequest>
    <ProposedDlmsVersionNumber Value="06" />
    <ProposedConformance>
      <ConformanceBit Name="BlockTransferWithGetOrRead" />
      <ConformanceBit Name="BlockTransferWithSetOrWrite" />
      <ConformanceBit Name="BlockTransferWithAction" />
      <ConformanceBit Name="MultipleReferences" />
      <ConformanceBit Name="InformationReport" />
      <ConformanceBit Name="DataNotification" />
      <ConformanceBit Name="Access" />
      <ConformanceBit Name="ParameterizedAccess" />
      <ConformanceBit Name="Get" />
      <ConformanceBit Name="Set" />
      <ConformanceBit Name="SelectiveAccess" />
      <ConformanceBit Name="EventNotification" />
      <ConformanceBit Name="Action" />
    </ProposedConformance>
    <ProposedMaxPduSize Value="FFFF" />
  </InitiateRequest>
</AssociationRequest>
</PDU>
</HDLC>
 

9 часов назад, Lj_ сказал:

Запрос информации об ассоциации №1, тоже не совсем разобрался зачем нужен.
Tx= 7E A02C0271613282EDE6E600C301C1000F0000280000FF010109103925A6A44551A9B6A496D415EDBA67E0 3F 83 7E

расшифровка:
 

Цитата

<HDLC len="2B" >
<!-- Logical address:1, Physical address:56 -->
<TargetAddress Value="B8" />
<SourceAddress Value="30" />
<FrameType Value="32" />
<!-- I frame: Sending=True,N(R)=1,N(S)=1 -->
<PDU>
<ActionRequest>
  <ActionRequestNormal>
    <!-- Priority: High, ServiceClass: Confirmed, ID: 1 -->
    <InvokeIdAndPriority Value="C1" />
    <MethodDescriptor>
      <!-- AssociationLogicalName -->
      <ClassId Value="000F" />
      <!-- 0.0.40.0.0.255 -->
      <InstanceId Value="0000280000FF" />
      <MethodId Value="01" />
    </MethodDescriptor>
    <MethodInvocationParameters>
      <OctetString Value="3925A6A44551A9B6A496D415EDBA67E0" />
    </MethodInvocationParameters>
  </ActionRequestNormal>
</ActionRequest>
</PDU>
</HDLC>
 

 

 

[AlexRayne 7]

9 часов назад, Lj_ сказал:

то зачем нужен пароль 2222222222222222 ?

паролем шифруются/дешифруются челенжи.
алгоритм шифрования выбирается в AARQ согласно 
 

Цитата

9.4.2.2.4  Cryptographic algorithm ID-s
Cryptographic algorithm IDs identify the algorithm for which a derived secret symmetrical key will be
used. See 9.2.3.4.6.5.
Cryptographic algorithms are identified by the following general object identifier value:
COSEM_Cryptographic_Algorithm_Id ::= {joint-iso-ccitt(2) country(16) country-name(756) identified-organization(5) DLMS-UA(8) cryptographic-algorithms (3) algorithm_id(x)}

The values of the algorithm_id-s are shown in Table 76. See also Table 18.
Table 76 – Cryptographic algorithm ID-s
COSEM_cryptographic_algorithm_name_aes-gcm-128 ::=  algorithm_id(0)
COSEM_cryptographic_algorithm_name_aes-gcm-256 ::=  algorithm_id(1)
COSEM_cryptographic_algorithm_name_aes-wrap-128 ::=  algorithm_id(2)
COSEM_cryptographic_algorithm_name_aes-wrap-256 ::=  algorithm_id(3

в ваших AARQ такого элемента нет, потому используется видимо алгоритм 0 - aes-128

[maksim1750 0]

Добрый день!

Подскажите пожалуйста, на каком ресурсе можно скачать или купить указанные стандарты:

• DLMS UA 1000-1 ed. 14 Technical Report
• DLMS UA 1000-2 Ed. 10 Technical Report?

Заранее спасибо.

[AlexRayne 7]

купить подписку ежегодную у ДЛМС-консорциума. Если они вобще захотят иметь дело с вами. 
если найдете и поделитесь - все будут рады.

[Curator 0]

Искал библиотеку сподэс для arduino, шлюз сподэс to mqtt хотел получить. И ничего не нарыл. Но зато очень много реализаций DLMS под те же Arduino и ESP. сподэс это не DLMS? Наши счётчики по DLMS работать не будут?