"Р 1323565.1.032-2020. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических механизмов для реализации обмена данными по протоколу DLMS" (утв. и введены в действие Приказом Росстандарта от 27.10.2020 N 941-ст)

Главная // Актуальные документы // Приказ

СПРАВКА

Источник публикации

М.: Стандартинформ, 2020

Примечание к документу

Документ введен в действие с 01.04.2021.

Название документа

"Р 1323565.1.032-2020. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических механизмов для реализации обмена данными по протоколу DLMS"

(утв. и введены в действие Приказом Росстандарта от 27.10.2020 N 941-ст)

Содержание

Р 1323565.1.032-2020. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических механизмов для реализации обмена данными по протоколу DLMS

3 Термины, определения и обозначения

3.1 Термины и определения

3.2 Обозначения

4 Криптографические наборы

5 Ключи

5.1 Симметричные ключи

5.2 Асимметричные ключи

6 Вспомогательные величины

6.1 Байт управления безопасностью

6.2 Идентификатор стороны

6.3 Счетчик вызовов

6.4 Сертификат открытого ключа

7 Описание алгоритмов

7.1 Шифрование и имитозащита

7.2 Передача ключа

7.3 Защита с помощью электронной цифровой подписи

7.4 Согласование ключа

7.5 Механизмы аутентификации HLS

Приложение А. Контрольные примеры

Библиография

Утверждены и введены в действие

Приказом Федерального

агентства по техническому

регулированию и метрологии

от 27 октября 2020 г. N 941-ст

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ

ИСПОЛЬЗОВАНИЕ РОССИЙСКИХ КРИПТОГРАФИЧЕСКИХ МЕХАНИЗМОВ

ДЛЯ РЕАЛИЗАЦИИ ОБМЕНА ДАННЫМИ ПО ПРОТОКОЛУ DLMS

Information technology. Cryptographic data security.

Usage of Russian cryptographic mechanisms to implement

data exchange in the DLMS protocol

Р 1323565.1.032-2020

ОКС 35.040

Дата введения

1 апреля 2021 года

Предисловие

1 РАЗРАБОТАНЫ Открытым акционерным обществом "Информационные технологии и коммуникационные системы" (ОАО "ИнфоТеКС")

2 ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 26 "Криптографическая защита информации"

3 УТВЕРЖДЕНЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 27 октября 2020 г. N 941-ст

4 ВВЕДЕНЫ ВПЕРВЫЕ

Правила применения настоящих рекомендаций установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящим рекомендациям публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящих рекомендаций соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

В настоящих рекомендациях определяется порядок использования российских криптографических алгоритмов в протоколе DLMS, предназначенном для защищенного взаимодействия между системами сбора данных и измерительными устройствами. Протокол DLMS может быть использован для обеспечения конфиденциальности и целостности данных, а также для аутентификации источника данных. Протокол DLMS специфицируется в DLMS/COSEM Architecture and Protocols [1] и COSEM Interface Classes and OBIS Object Identification System [2].

Необходимость разработки настоящих рекомендаций вызвана потребностью в обеспечении совместимости реализаций протокола DLMS с использованием российских криптографических стандартов.

Примечание - Настоящие рекомендации дополнены приложением А.

1 Область применения

Протокол DLMS рекомендуется применять при обмене данными между системами сбора данных и измерительными устройствами. Обмен данными основан на модели клиент/сервер, где системы сбора данных играют роль клиента, а измерительные устройства играют роль сервера.

2 Нормативные ссылки

В настоящих рекомендациях использованы нормативные ссылки на следующие стандарты:

ГОСТ 34.10-2018 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи

ГОСТ 34.11-2018 Информационная технология. Криптографическая защита информации. Функция хэширования

ГОСТ 34.12-2018 Информационная технология. Криптографическая защита информации. Блочные шифры

ГОСТ 34.13-2018 Информационная технология. Криптографическая защита информации. Режимы работы блочных шифров

Р 50.1.113-2016 Информационная технология. Криптографическая защита информации. Криптографические алгоритмы, сопутствующие применению алгоритмов электронной цифровой подписи и функции хэширования

Р 1323565.1.017-2018 Информационная технология. Криптографическая защита информации. Криптографические алгоритмы, сопутствующие применению алгоритмов блочного шифрования

Р 1323565.1.023-2018 Информационная технология. Криптографическая защита информации. Использование алгоритмов ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012 в сертификате, списке аннулированных сертификатов (CRL) и запросе на сертификат PKCS#10 инфраструктуры открытых ключей X.509

Р 1323565.1.024-2019 Информационная технология. Криптографическая защита информации. Параметры эллиптических кривых для криптографических алгоритмов и протоколов

Примечание - При пользовании настоящими рекомендациями целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящих рекомендаций в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

3 Термины, определения и обозначения

3.1 Термины и определения

В настоящих рекомендациях применен следующий термин с соответствующим определением:

3.1.1 криптографический набор: Совокупность криптографических алгоритмов и параметров, используемых в протоколе DLMS.

3.2 Обозначения

В настоящих рекомендациях использованы следующие обозначения:

V*	-	множество всех двоичных строк конечной длины, включая пустую строку;
\|x\|	-	длина (число компонент) строки (если x - пустая строка, то \|x\| = 0);
V_s	-	множество всех двоичных строк длины s, где s - целое неотрицательное число; нумерация подстрок и компонент строки осуществляется справа налево, начиная с нуля;
x\|\|y	-	конкатенация двоичных строк x, , то есть строка из V_\|x\|+\|y\|, в которой подстрока с большими номерами компонент из V_\|x\| совпадает со строкой x, а подстрока с меньшими номерами компонент из V_\|y_\| совпадает со строкой y;
0^s	-	двоичная строка, состоящая из s нулей;
Z_s	-	кольцо вычетов по модулю s;
	-	отображение, ставящее в соответствие строке z_m_-1\|\|...\|\|z₁\|\|z₀, m >= s строку z_s_-1\|\|...\|\|z₁\|\|z₀, , i = 0, 1 ..., m - 1;
	-	отображение, ставящее в соответствие строке z_m_-1\|\|...\|\|z₁\|\|z₀, m >= s строку z_m_-1\|\|...\|\|z_m_-_s₊₁\|\|z_m_-_s, , i = 0, 1 ..., m - 1;
	-	биективное отображение, сопоставляющее элементу кольца его двоичное представление, то есть для любого элемента , представленного в виде z = z₀ + 2·z₁ + ... + 2^s^-1·z_s_-1, где , i = 0, 1 ..., s - 1, выполнено равенство Vec_s(z) = z_s_-1\|\|...\|\|z₁\|\|z₀;
	-	отображение, обратное к отображению Vec_s, то есть ;
E	-	группа точек эллиптической кривой, задаваемая набором параметров id-tc26-gost-3410-2012-256-paramSetB "1.2.643.7.1.2.1.1.2.", определенным в Р 1323565.1.024-2019;
p	-	характеристика простого поля, над которым определяется эллиптическая кривая E;
m	-	порядок группы точек эллиптической кривой E;
q	-	порядок циклической подгруппы группы точек эллиптической кривой E;
	-	нулевая точка эллиптической кривой E;
P	-	точка эллиптической кривой E, являющаяся порождающим элементом циклической подгруппы порядка q, задаваемая набором параметров id-tc26-gost-3410-2012-256-paramSetB "1.2.643.7.1.2.1.1.2.", определенным в Р 1323565.1.024-2019;
	-	отображение, сопоставляющее точке эллиптической кривой E двоичное представление первой координаты этой точки в форме Вейерштрасса, то есть для любой точки , представленной в форме Вейерштрасса Q = (x_Q, y_Q), где , выполнено равенство ;
	-	отображение, сопоставляющее точке эллиптической кривой E двоичное представление второй координаты этой точки в форме Вейерштрасса, то есть для любой точки , представленной в форме Вейерштрасса Q = (x_Q, y_Q), где , выполнено равенство ;
HASH₂₅₆(M)	-	алгоритм вычисления хэш-функции с длиной хэш-кода 256 бит от данных M, определенный в ГОСТ 34.11-2018;
KDFTREE(K,label,seed,R)	-	алгоритм диверсификации ключа KDF_TREE_GOSTR3411_2012_256, определенный в Р 50.1.113-2016, где K - ключ диверсификации, label, seed - параметры, задаваемые протоколом, ;
KUZN_CMAC(K,M)	-	алгоритм шифрования ГОСТ 34.12-2018 ("Кузнечик") в режиме выработки имитовставки согласно ГОСТ 34.13-2018, где K - ключ, M - данные. Значение входного параметра режима выработки имитовставки s = 96;
KUZN_CTR(K,IV,P)	-	алгоритм зашифрования ГОСТ 34.12-2018 ("Кузнечик") в режиме работы, аналогичном режиму гаммирования согласно ГОСТ 34.13-2018, где K - ключ, IV - синхропосылка, P - открытые данные, с теми отличиями, что и начальное значение счетчика режима гаммирования вычисляется как CTR₁ = IV\|\|0³². Значение входного параметра режима гаммирования s = 128;
KUZN_KEXP(K,K_M,K_E,IV)	-	алгоритм экспорта ключа, аналогичный алгоритму экспорта ключа KExp15, определенному в Р 1323565.1.017-2018, на основе алгоритма шифрования ГОСТ 34.12-2018 ("Кузнечик"), где K - передаваемый ключ, K_M - мастер-ключ имитозащиты, K_E - мастер-ключ шифрования, IV - синхропосылка, с теми отличиями, что и начальное значение счетчика режима гаммирования вычисляется как CTR₁ = IV\|\|0³²;
KUZN_KIMP(ExpK,K_M,K_E,IV)	-	алгоритм импорта ключа, аналогичный алгоритму импорта ключа KImp15, определенному в Р 1323565.1.017-2018, на основе алгоритма шифрования ГОСТ 34.12-2018 ("Кузнечик"), где ExpK - экспортное представление передаваемого ключа, K_M - мастер-ключ имитозащиты, K_E - мастер-ключ шифрования, IV - синхропосылка, с теми отличиями, что и начальное значение счетчика режима гаммирования вычисляется как CTR₁ = IV\|\|0³²;
SIGN₂₅₆(d, M)	-	алгоритм формирования цифровой подписи согласно ГОСТ 34.10-2018 на основе эллиптической кривой E, где d - ключ подписи, M - подписываемые данные;
VKO₂₅₆(d,Q,UKM)	-	алгоритм выработки ключа обмена VKO_GOST3410_2012_256, определенный в Р 50.1.113-2016, на основе эллиптической кривой E, где d - закрытый ключ вычисляющей стороны, Q - открытый ключ противоположной стороны, UKM - число (в формульных обозначениях Р 50.1.113-2016 вместо открытого ключа Q используется соответствующий ему закрытый ключ);
A-Associate	-	сервис ACSE, использующийся при установлении AA;
AA	-	Application Association: ассоциация приложений;
AARE	-	A-Associate Response: APDU, использующийся ACSE и предназначенный для осуществления ответа при использовании сервиса A-Associate;
AARQ	-	A-Associate Request: APDU, использующийся ACSE и предназначенный для осуществления запроса при использовании сервиса A-Associate;
ACSE	-	Association Control Service Element: элемент службы управления ассоциациями;
APDU	-	Application layer Protocol Data Unit: блок данных протокола уровня приложений;
COSEM	-	Companion Specification for Energy Metering: сопутствующая спецификация для учета электроэнергии;
DLMS	-	Device Language Message Specification: спецификация языка сообщений между устройствами;
HLS	-	High Level Security: высокий уровень безопасности;
xDLMS APDU	-	Extended DLMS APDU: APDU, использующийся xDLMS ASE;
xDLMS ASE	-	Extended DLMS Application Service Element: элемент службы приложений расширенной DLMS;
xDLMS InitiateRequest APDU	-	xDLMS APDU, применяющийся при установлении AA;
Data protection	-	объект COSEM, применяющийся при защите данных COSEM;
Security setup	-	объект COSEM, содержащий информацию об используемом криптографическом наборе и применяемой политике безопасности;
general-ciphering	-	способ защиты xDLMS APDU: шифрование общего вида;
general-signing	-	способ защиты xDLMS APDU: подпись общего вида;
general-ded-ciphering	-	способ защиты xDLMS APDU: специализированное шифрование общего вида;
general-glo-ciphering	-	способ защиты xDLMS APDU: глобальное шифрование общего вида;
service-specific dedicated ciphering	-	способ защиты xDLMS APDU: специализированное шифрование, зависящее от сервиса;
service-specific global ciphering	-	способ защиты xDLMS APDU: глобальное шифрование, зависящее от сервиса;
change_HLS_secret	-	метод объекта ассоциации COSEM, описанный в [2] и предназначенный для изменения значения общего секрета двух сторон при использовании механизмов аутентификации HLS (аутентификации высокого уровня безопасности);
key_agreement	-	метод объекта Security setup, описанный в [2] и предназначенный для пересылки сеансового открытого ключа и сопутствующей информации при согласовании ключа;
key_transfer	-	метод объекта Security setup, описанный в [2] и предназначенный для пересылки передаваемого ключа и сопутствующей информации при передаче ключа;
generate_key_pair	-	метод объекта Security setup, описанный в [2] и предназначенный для генерации ключевой пары сервера;
generate_certificate_request	-	метод объекта Security setup, описанный в [2] и предназначенный для создания сервером запроса на сертификат открытого ключа;
import_certificate	-	метод объекта Security setup, описанный в [2] и предназначенный для пересылки сертификата открытого ключа по направлению к серверу;
export_certificate	-	метод объекта Security setup, описанный в [2] и предназначенный для пересылки сертификата открытого ключа по направлению от сервера;
remove_certificate	-	метод объекта Security setup, описанный в [2] и предназначенный для удаления сертификата открытого ключа, хранящегося на сервере;
reply_to_HLS_authentication	-	метод объекта ассоциации COSEM, описанный в [2] и предназначенный для пересылки ответа на запрос при использовании механизмов аутентификации HLS (аутентификации высокого уровня безопасности).

4 Криптографические наборы

В настоящих рекомендациях специфицируется два криптографических набора для использования в протоколе DLMS. Описание криптографических наборов приведено в таблице 1.

Таблица 1

Описание криптографических наборов

Параметры и алгоритмы криптографического набора	Криптографический набор 8	Криптографический набор 9
Идентификатор криптографического набора (Security Suite Id)	8	9
Название криптографического набора (Security Suite name)	KUZN-CTR-CMAC	VKO-256-GOST34102018-256-KUZN-CTR-CMAC-GOST34112018-256
Шифрование и имитозащита (Authenticated encryption)	Блочный шифр ГОСТ 34.12-2018 ("Кузнечик") в режимах CTR <*> и CMAC, согласно ГОСТ 34.13-2018	Блочный шифр ГОСТ 34.12-2018 ("Кузнечик") в режимах CTR <*> и CMAC, согласно ГОСТ 34.13-2018
Электронная цифровая подпись (Digital signature)	-	ГОСТ 34.10-2018 с длиной закрытого ключа 256 бит, с использованием эллиптической кривой, задаваемой набором параметров id-tc26-gost-3410-2012-256-paramSetB "1.2.643.7.1.2.1.1.2.", определенным в Р 1323565.1.024-2019
Согласование ключа (Key agreement)	-	Алгоритмы согласования, основанные на VKO_GOSTR3410_2012_256, определенном в Р 50.1.113-2016, с использованием эллиптической кривой, задаваемой набором параметров id-tc26-gost-3410-2012-256-paramSetB "1.2.643.7.1.2.1.1.2.", определенным в Р 1323565.1.024-2019
Хэш-функция (Hash)	-	ГОСТ 34.11-2018 с длиной хэш-кода 256 бит
Передача ключа (Key transport)	KExp15, KImp15 <**>, определенные в Р 1323565.1.017-2018, на основе блочного шифра ГОСТ 34.12-2018 ("Кузнечик")	KExp15, Klmp15 <**>, определенные в Р 1323565.1.017-2018, на основе блочного шифра ГОСТ 34.12-2018 ("Кузнечик")
<> Используемый в криптографических наборах 8 и 9 режим шифрования аналогичен режиму гаммирования согласно ГОСТ 34.13-2018 с теми отличиями, что длина используемой синхропосылки IV равна 96 бит и начальное значение счетчика режима гаммирования вычисляется как CTR₁ = IV\|\|0³². <> Используемые в криптографических наборах 8 и 9 алгоритмы экспорта и импорта ключа аналогичны алгоритмам KExp15, KImp15, определенным в Р 1323565.1.017-2018, на основе блочного шифра ГОСТ 34.12-2018 ("Кузнечик"), с теми отличиями, что длина используемой синхропосылки IV равна 96 бит и начальное значение счетчика режима гаммирования вычисляется как CTR*₁ = IV\|\|0³².

Использование криптографического набора 8 позволяет осуществлять:

- шифрование и имитозащиту данных (см. 7.1);

- передачу ключа (см. 7.2).

Использование криптографического набора 9 позволяет осуществлять:

- шифрование и имитозащиту данных (см. 7.1);

- передачу ключа (см. 7.2);

- защиту данных с помощью электронной цифровой подписи (см. 7.3);

- согласование ключа (см. 7.4).

При использовании в процессе установления AA механизмов аутентификации HLS (см. 7.5) допускается применение:

- механизма аутентификации "HLS CMAC" для согласования криптографического набора 8;

- механизмов аутентификации "HLS GOST34112018-256" и "HLS GOST34102018-256" для согласования криптографического набора 9.

5 Ключи

5.1 Симметричные ключи

При использовании криптографических наборов 8 и 9 под симметричным ключом (ключом шифрования и имитозащиты) понимается ключевая информация длины 512 бит, представляющая собой конкатенацию двух независимых криптографических ключей: ключа для шифрования и ключа для имитозащиты. В дальнейшем, с целью сохранения сложившейся в протоколе DLMS терминологии, такая ключевая информация называется ключом.

Типы симметричных ключей, используемых в протоколе DLMS, приведены в таблице 2.

Таблица 2

Типы симметричных ключей

Тип ключа	Описание	Способ распределения ключа	Применение
Мастер-ключ шифрования и имитозащиты (Key Encryption Key, KEK)	Мастер-ключ, использующийся при передаче (см. 7.2): - (новых) мастер-ключей шифрования и имитозащиты; - глобальных ключей шифрования и имитозащиты при адресной рассылке; - глобальных ключей шифрования и имитозащиты при широковещательной рассылке; - сеансовых ключей шифрования и имитозащиты	По выделенному каналу (описание находится за рамками данного документа)	Передача ключа посредством: - метода key_transfer; - xDLMS APDU, защищенного способом general-ciphering
		Передача ключа (см. 7.2)
		Согласование ключа с применением каждой из взаимодействующих сторон сеансовых ключевых пар согласования ключа (см. 7.4.1)
Глобальный ключ шифрования и имитозащиты при адресной рассылке (Global unicast encryption key, GUEK)	Ключ шифрования и имитозащиты, использующийся при адресной рассылке для защиты (см. 7.1): - xDLMS APDU; - данных COSEM. Ключ шифрования и имитозащиты при вычислении ответа на запрос в механизме аутентификации "HLS CMAC" (см. 7.5)	Передача ключа (см. 7.2)	Защита: - xDLMS APDU способами service-specific global ciphering, general-glociphering, general-ciphering; - данных COSEM с применением объекта Data protection
		Согласование ключа с применением каждой из взаимодействующих сторон сеансовых ключевых пар согласования ключа (см. 7.4.1)
Глобальный ключ шифрования и имитозащиты при широковещательной рассылке (Global broadcast encryption key, GBEK)	Ключ шифрования и имитозащиты, использующийся при широковещательной рассылке для защиты (см. 7.1): - xDLMS APDU; - данных COSEM	Передача ключа (см. 7.2)
Специализированный ключ шифрования и имитозащиты (Dedicated key)	Ключ шифрования и имитозащиты, действующий в течение одной установленной AA и использующийся для защиты xDLMS APDU (см. 7.1)	Пересылка ключа в xDLMS InitiateRequest APDU	Защита: - xDLMS APDU способами service-specific dedicated ciphering, general-ded-ciphering
Сеансовый ключ шифрования и имитозащиты (Ephemeral encryption key)	Ключ шифрования и имитозащиты, действующий в течение одного обмена данными и использующийся для защиты (см. 7.1): - xDLMS APDU; - данных COSEM	Передача ключа (см. 7.2)	Защита: - xDLMS APDU способом general-ciphering; - данных COSEM с применением объекта Data protection
		Согласование ключа: - с применением одной из взаимодействующих сторон сеансовой ключевой пары согласования ключа и другой из сторон долговременной ключевой пары согласования ключа (см. 7.4.2); - с применением каждой из взаимодействующих сторон долговременных ключевых пар согласования ключа (см. 7.4.3)

5.2 Асимметричные ключи

При использовании криптографического набора 9 под асимметричными ключами понимаются ключи, соответствующие ГОСТ 34.10-2018 и эллиптической кривой, задаваемой набором параметров id-tc26-gost-3410-2012-256-paramSetB "1.2.643.7.1.2.1.1.2.", определенным в Р 1323565.1.024-2019.

Типы асимметричных ключей, используемых в протоколе DLMS, приведены в таблице 3.

Таблица 3

Типы асимметричных ключей

Тип ключа	Описание
Ключи подписи и проверки подписи (Digital signature key pair)	Ключи подписи и проверки подписи под - xDLMS APDU (см. 7.3); - данными COSEM (см. 7.3); - сеансовым открытым ключом для согласования ключа (см. 7.4.1, 7.4.2); - сертификатами открытых ключей; - ответом на запрос в механизме аутентификации "HLS GOST34102018-256" (см. 7.5)
Сеансовая ключевая пара для согласования ключа (Ephemeral key agreement key pair)	Сеансовая ключевая пара - у обеих сторон в схеме согласования ключа с применением каждой из взаимодействующих сторон сеансовых ключевых пар согласования ключа (см. 7.4.1); - у одной из сторон в схеме согласования ключа с применением одной из взаимодействующих сторон сеансовой ключевой пары согласования ключа и другой из сторон долговременной ключевой пары согласования ключа (см. 7.4.2)
Долговременная ключевая пара для согласования ключа (Static key agreement key pair)	Долговременная ключевая пара - у обеих сторон в схеме согласования ключа с применением каждой из взаимодействующих сторон долговременных ключевых пар согласования ключа (см. 7.4.3); - у одной из сторон в схеме согласования ключа типа с применением одной из взаимодействующих сторон сеансовой ключевой пары согласования ключа и другой из сторон долговременной ключевой пары согласования ключа (согласно см. 7.4.2)

Возможны следующие варианты распределения ключа проверки подписи и открытого ключа долговременной ключевой пары для согласования ключа:

- путем внесения сертификатов этих ключей в устройство в процессе его изготовления;

- путем передачи сертификатов этих ключей по выделенному каналу (описание находится за рамками данного документа);

- путем использования методов объекта Security Setup, предназначенных для распределения сертификатов этих ключей (см. 6.4).

Ключ проверки подписи дополнительно может быть распределен в процессе выполнения механизма аутентификации "HLS GOST34102018-256" (см. 7.5) путем пересылки сертификата этого ключа в AARQ или AARE.

Распределение открытого ключа сеансовой ключевой пары осуществляется путем пересылки этого ключа в процессе выполнения алгоритма согласования ключа (см. 7.4.1, 7.4.2).

6 Вспомогательные величины

6.1 Байт управления безопасностью

При шифровании и имитозащите данных в протоколе DLMS используется величина под названием байт управления безопасностью (Security Control byte, SC). Байт управления безопасностью SC имеет длину 8 бит и представляется в виде:

где строка SC₃||...||SC₀ = Vec₄(N), где N - идентификатор криптографического набора;

бит SC₄ является индикатором применения имитозащиты (0 - не применяется, 1 - применяется);

бит SC₅ является индикатором применения шифрования (0 - данные не шифруются, 1 - данные шифруются);

бит SC₆ является индикатором вида рассылки (0 - адресная, 1 - широковещательная);

бит SC₇ является индикатором применения сжатия данных (в криптографических наборах 8 и 9 сжатие данных не используется и бит SC₇ всегда принимает нулевое значение).

Случай одновременного равенства битов SC₄ и SC₅ нулевому значению подразумевает отсутствие криптографической защиты и в данном документе не рассматривается.

6.2 Идентификатор стороны

Все стороны, использующие протокол DLMS, имеют уникальные имена, называемые идентификаторами сторон (system title). Идентификатор стороны должен иметь длину 64 бита и быть уникальным среди множества всех идентификаторов. Для идентификаторов сторон не требуется обеспечения конфиденциальности.

Некоторые криптографические алгоритмы, описанные в разделе 7, требуют предварительного распределения идентификаторов сторон. Возможны следующие варианты распределения идентификаторов:

- в процессе доверенной регистрации устройства;

- в процессе установления AA между взаимодействующими сторонами;

- путем записи атрибута client_system_title (идентификатор клиента) и чтения атрибута server_system_title (идентификатор сервера) объекта Security setup.

6.3 Счетчик вызовов

Каждой паре: отправитель, ключ шифрования и имитозащиты - ставится в соответствие величина

, имеющая длину 32 бита и представляющая собой счетчик вызовов операций зашифрования и/или вычисления имитовставки, выполняемых заданным отправителем на заданном ключе.

Перед первой операцией зашифрования и/или вычисления имитовставки на заданном ключе заданный отправитель инициализирует значение IC нулем:

IC = Vec₃₂(0).

При выполнении зашифрования и/или вычисления имитовставки на заданном ключе заданный отправитель использует текущее значение IC и затем увеличивает его на единицу, полагая равным величине Vec₃₂(Int₃₂(IC) + 1). В случае, когда исходное значение IC равно Vec₃₂(2³² - 1), выполнение операции зашифрования и/или вычисления имитовставки считается невозможным, возвращается ошибка и увеличения значения счетчика IC не происходит. Последующий порядок обработки данной ситуации определяется конкретным исполнением протокола DLMS. В частности, стороны могут инициировать процедуру смены используемого ключа.

Каждой тройке: отправитель, получатель, ключ шифрования и имитозащиты - ставится в соответствие величина, принимающая значения из

и представляющая собой минимально допустимое значение счетчика IC, которое заданный получатель ожидает получить от заданного отправителя при необходимости расшифрования и/или проверки имитовставки на заданном ключе.

Перед первой операцией расшифрования и/или проверки имитовставки для данных, защищенных заданным отправителем на заданном ключе, заданный получатель инициализирует минимально допустимое значение счетчика IC нулем.

При выполнении расшифрования и/или проверки имитовставки для данных, защищенных заданным отправителем на заданном ключе, заданный получатель проверяет, что для входящего значения IC справедливо, что Int₃₂(IC) меньше 2³² - 1, но не меньше минимально допустимого значения счетчика. В случае отрицательного результата проверки выполнение операций расшифрования и/или проверки имитовставки считается невозможным и возвращается ошибка. Последующий порядок обработки данной ситуации определяется конкретным исполнением протокола DLMS. В случае положительного результата проверки (и положительного результата проверки имитовставки, в случае ее присутствия) минимально допустимое значение счетчика устанавливается равным Int₃₂(IC) + 1.

Для мастер-ключа шифрования и имитозащиты порядок инициализации, изменения и проверки значений соответствующего счетчика аналогичен порядку, описанному выше, с тем отличием, что вместо операций зашифрования и/или вычисления имитовставки (расшифрования и/или проверки имитовставки) рассматривается операция вычисления экспортного представления ключа (вычисления исходного ключа из его экспортного представления).

6.4 Сертификат открытого ключа

При использовании криптографического набора 9 возможно применение сертификатов открытых ключей.

Сертификат открытого ключа должен содержать либо ключ проверки подписи, либо открытый ключ долговременной ключевой пары для согласования ключа. Сертификаты открытых ключей могут применяться для доверенной передачи:

- ключа проверки подписи при защите данных с помощью электронной цифровой подписи (см. 7.3);

- ключей проверки подписи и открытых ключей долговременных ключевых пар для согласования ключа при выполнении согласования ключа (согласно 7.4);

- ключей проверки подписи при выполнении механизма аутентификации "HLS GOST34102018-256" (см. 7.5).

Сертификаты открытых ключей должны иметь формат X.509 версии 3. Ключ, содержащийся в сертификате, должен соответствовать ГОСТ 34.10-2018 и эллиптической кривой, задаваемой набором параметров id-tc26-gost-3410-2012-256-paramSetB "1.2.643.7.1.2.1.1.2.", определенным в Р 1323565.1.024-2019. Каждый сертификат должен быть подписан с использованием алгоритма ГОСТ 34.10-2018 на эллиптической кривой, задаваемой набором параметров id-tc26-gost-3410-2012-256-paramSetB "1.2.643.7.1.2.1.1.2.", определенным в Р 1323565.1.024-2019. Использование алгоритма ГОСТ 34.10-2018 в сертификате формата X.509 версии 3 должно выполняться в соответствии с Р 1323565.1.023-2018.

Управление сертификатами может осуществляться с применением методов объекта Security Setup, в частности:

- для передачи сертификата по направлению от клиента (или от доверенной третьей стороны) к серверу может использоваться метод import_certificate;

- для передачи сертификата по направлению от сервера к клиенту (или к доверенной третьей стороне) может использоваться метод export_certificate;

- для удаления сертификата, хранящегося на сервере, может использоваться метод remove_certificate;

- для замены сертификата сервера могут использоваться методы generate_key_pair, generate_certificate_request и import_certificate, необходимые, соответственно, для генерации новой ключевой пары сервера, создания сервером запроса на сертификат и передачи созданного сертификата по направлению от клиента (или от доверенной третьей стороны) к серверу.

Описание инфраструктуры открытых ключей, предназначенной для управления сертификатами открытых ключей, находится за рамками данного документа.

7 Описание алгоритмов

В данном разделе описываются криптографические алгоритмы, предназначенные для применения в протоколе DLMS при использовании криптографических наборов 8 и/или 9. Возможные значения аргументов функций в представленных алгоритмах ограничены допустимостью их использования в качестве входных параметров преобразований.

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

Если для некоторого алгоритма заявляется возможность его применения для защиты xDLMS APDU и данных COSEM, то рассматривается только вариант защиты xDLMS APDU. Защита данных COSEM, то есть атрибутов, параметров метода и возвращаемых значений, осуществляется посредством использования объекта Data protection и применения защиты к APDU, выполняющим роль транспорта при работе с этим объектом.

7.1 Шифрование и имитозащита

Алгоритмы шифрования и имитозащиты предназначены для защиты xDLMS APDU и данных COSEM. Протокол DLMS предполагает наличие алгоритмов шифрования и имитозащиты. Приведенные в данном пункте алгоритмы шифрования и имитозащиты применяются при использовании криптографических наборов 8 и 9.

На вход алгоритму зашифрования и вычисления имитовставки поступают:

- ключ шифрования и имитозащиты

- ассоциированные данные

- открытый текст

- идентификатор отправителя

- байт управления безопасностью

Тип ключа шифрования и имитозащиты K_EM определяется используемым способом защиты xDLMS APDU:

- general-ciphering,

- general-ded-ciphering,

- general-glo-ciphering,

- service-specific dedicated ciphering,

- service-specific global ciphering.

В случае применения способа защиты general-ciphering ключ K_EM должен иметь один из следующих типов:

- глобальный ключ шифрования и имитозащиты при адресной рассылке;

- глобальный ключ шифрования и имитозащиты при широковещательной рассылке;

- сеансовый ключ шифрования и имитозащиты.

В случае применения способов защиты general-glo-ciphering и service-specific global ciphering ключ K_EM должен иметь один из следующих типов:

- глобальный ключ шифрования и имитозащиты при адресной рассылке;

- глобальный ключ шифрования и имитозащиты при широковещательной рассылке.

В случае применения способов защиты general-ded-ciphering и service-specific dedicated ciphering ключ K_EM должен являться специализированным ключом шифрования и имитозащиты.

Структура ассоциированных данных AAD и открытого текста Plaintext определяется значением байта управления безопасности SC:

- в случае SC₅ = 0, SC₄ = 1:

AAD = SC||AF||Unprotected_APDU,

- в случае SC₅ = 1, SC_A = 0:

Plaintext = Unprotected_APDU,

- в случае SC₅ = 1, SC₄ = 0:

AAD = SC||AF,

Plaintext = Unprotected_APDU,

где

- защищаемый xDLMS APDU,

- дополнительно защищаемые данные, определяемые используемым способом защиты xDLMS APDU.

В случае применения способа защиты general-ciphering значение AF должно иметь вид

AF = transaction-id||originator-system-title||

recipient-system-title||date-time||other-information,

где transaction-id - значение параметра transaction-id (идентификатор транзакции) xDLMS APDU, защищенного способом general-ciphering;

originator-system-title - значение параметра originator-system-title (идентификатор отправителя) xDLMS APDU, защищенного способом general-ciphering;

recipient-system-title - значение параметра recipient-system-title (идентификатор получателя) xDLMS APDU, защищенного способом general-ciphering;

date-time - значение параметра date-time (дата и время отправления) xDLMS APDU, защищенного способом general-ciphering;

other-information - значение параметра other-information (прочая информация) xDLMS APDU, защищенного способом general-ciphering.

В случае применения способов защиты general-ded-ciphering, general-glo-ciphering, service-specific dedicated ciphering, service-specific global ciphering значение

Для осуществления зашифрования и вычисления имитовставки формируется значение синхропосылки

IV_EM = originator-system-title||IC_EM,

где

- значение счетчика вызовов, уникальное для каждой операции зашифрования и/или вычисления имитовставки, выполняемой стороной с идентификатором originator-system-title с использованием ключа K_EM. Порядок инициализации, изменения и проверки значений счетчика вызовов описан в 6.3.

Дальнейшие вычисления определяются значениями бит SC₅, SC₄:

- при SC₅ = 0, SC₄ = 1 вычисляется

где

;

- при SC₅ = 1, SC₄ = 0 вычисляется

где

;

- при SC₅ = 1, SC₄ = 1 вычисляются

где

Выходными значениями алгоритмов зашифрования и вычисления имитовставки являются Ciphertext и/или AuthTag, полученные на предыдущем шаге.

7.2 Передача ключа

Алгоритм передачи ключа предназначен для передачи ключа шифрования и имитозащиты по направлению от одной стороны к другой. Приведенный в данном пункте алгоритм передачи ключа применяется при использовании криптографических наборов 8 и 9.

Пошаговое описание алгоритма передачи ключа шифрования и имитозащиты

от стороны U к стороне V приведено в таблице 4.

Таблица 4

Передача ключа от стороны U к стороне V

Сторона U	Пересылаемые значения	Сторона V
Вычисляет синхропосылку длины 96 бит:
Вычисляет мастер-ключ шифрования длины 256 бит:
Вычисляет мастер-ключ имитозащиты длины 256 бит:
Вычисляет экспортное представление передаваемого ключа, имеющее длину 640 бит: ExpKey = KUZN_KEXP

		Проверяет, что для значения счетчика IC_KEK справедливо, что Int₃₂(IC_KEK) меньше 2³² - 1, но не меньше минимально допустимого значения счетчика. В случае отрицательного результата проверки возвращает ошибку и досрочно завершает процесс передачи ключа
		Вычисляет синхропосылку длины 96 бит:
		Вычисляет мастер-ключ шифрования длины 256 бит:
		Вычисляет мастер-ключ имитозащиты длины 256 бит:
		Вычисляет передаваемый ключ длины 512 бит: Key = KUZN_KIMP (в случае отрицательного результата проверки имитовставки возвращает ошибку и досрочно завершает процесс передачи ключа)

Для возможности выполнения алгоритма передачи ключа:

- сторона U и сторона V должны иметь общий мастер-ключ шифрования и имитозащиты

;

- сторона V должна предварительно получить значение идентификатора стороны U:

Передаваемый ключ Key должен иметь один из следующих типов:

- мастер-ключ шифрования и имитозащиты,

- глобальный ключ шифрования и имитозащиты при адресной рассылке,

- глобальный ключ шифрования и имитозащиты при широковещательной рассылке,

- сеансовый ключ шифрования и имитозащиты.

При вычислении синхропосылки

сторона U использует значение счетчика вызовов

, уникальное для каждой операции передачи ключа, выполняемой стороной U с использованием ключа K_KEK. Порядок инициализации, изменения и проверки значений счетчика IC_KEK аналогичен порядку, описанному в 6.3, с тем отличием, что вместо операций зашифрования и/или вычисления имитовставки (расшифрования и/или проверки имитовставки) рассматривается операция вычисления экспортного представления ключа (вычисления исходного ключа из его экспортного представления).

Способы обработки сбоев и ошибок в процессе передачи ключа определяются конкретным исполнением протокола DLMS.

При передаче мастер-ключа шифрования и имитозащиты, глобального ключа шифрования и имитозащиты при адресной рассылке или глобального ключа шифрования и имитозащиты при широковещательной рассылке в качестве стороны U выступает клиент, а в качестве стороны V - сервер. В этом случае для пересылки значений IC_KEK, ExpKey используется метод key_transfer, для чего устанавливаются следующие значения его параметров:

- тип передаваемого ключа

где 0 - глобальный ключ шифрования и имитозащиты при адресной рассылке, 1 - глобальный ключ шифрования и имитозащиты при широковещательной рассылке, 3 - мастер-ключ шифрования и имитозащиты;

- экспортное представление ключа и сопутствующая информация:

key_wrapped = IC_KEK||ExpKey.

При передаче сеансового ключа шифрования и имитозащиты в качестве одной из взаимодействующих сторон U или V выступает клиент, в качестве другой стороны - сервер. В этом случае для пересылки значений IC_KEK, ExpKey используется xDLMS APDU, защищенный способом general-ciphering, для чего устанавливаются следующие значения его параметров:

- тип мастер-ключа:

key-info.wrapped-key.kek-id = 0,

где 0 - мастер-ключ шифрования и имитозащиты;

- экспортное представление ключа и сопутствующая информация:

key-info.wrapped-key.key-ciphered-data = IC_KEK||ExpKey.

Пересылаемый xDLMS APDU шифруется и/или имитозащищается с использованием передаваемого ключа Key.

Следует отметить, что процесс передачи специализированного ключа шифрования и имитозащиты отличается от описанного в таблице 4. Данный ключ передается без вычисления его экспортного представления путем пересылки в xDLMS InitiateRequest APDU, который в обязательном порядке шифруется и имитозащищается на глобальном ключе шифрования и имитозащиты при адресной рассылке.

7.3 Защита с помощью электронной цифровой подписи

Алгоритм защиты с помощью электронной цифровой подписи предназначен для защиты xDLMS APDU и данных COSEM. Приведенный в данном пункте алгоритм защиты с помощью электронной цифровой подписи применяется при использовании криптографического набора 9.

На вход алгоритму вычисления электронной цифровой подписи поступают:

- ключ подписи

- дополнительно защищаемые данные

- защищаемые данные

Дополнительно защищаемые данные AF и защищаемые данные Content определяются способом защиты xDLMS APDU general-signing.

Значение Content должно иметь вид

Content = Unprotected_APDU,

где

- защищаемый xDLMS APDU.

Значение AF должно иметь вид

AF = transaction-id||originator-system-title||

recipient-system-title||date-time||other-information,

где transaction-id - значение параметра transaction-id (идентификатор транзакции) xDLMS APDU, защищенного способом general-signing;

originator-system-title - значение параметра originator-system-title (идентификатор отправителя) xDLMS APDU, защищенного способом general-signing;

recipient-system-title - значение параметра recipient-system-title (идентификатор получателя) xDLMS APDU, защищенного способом general-signing;

date-time - значение параметра date-time (дата и время отправления) xDLMS APDU, защищенного способом general-signing;

other-information - значение параметра other-information (прочая информация) xDLMS APDU, защищенного способом general-signing.

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

Ключи подписи и проверки подписи, используемые при защите данных с помощью электронной цифровой подписи, должны удовлетворять ГОСТ 34.10-2018 и эллиптической кривой, задаваемой набором параметров id-tc26-gost-3410-2012-256-paramSetB "1.2.643.7.1.2.1.1.2.", определенным в Р 1323565.1.024-2019.

7.4 Согласование ключа

Алгоритмы согласования ключа предназначены для согласования ключа шифрования и имитозащиты между двумя сторонами. Приведенные в данном пункте алгоритмы согласования ключа применяются при использовании криптографического набора 9.

Рассматриваются три алгоритма согласования ключа:

- с применением каждой из взаимодействующих сторон сеансовых ключевых пар согласования ключа (см. 7.4.1);

- с применением одной из взаимодействующих сторон сеансовой ключевой пары согласования ключа и другой из сторон долговременной ключевой пары согласования ключа (см. 7.4.2);

- с применением каждой из взаимодействующих сторон долговременных ключевых пар согласования ключа (см. 7.4.3).

В таблице 5 приведены основные свойства каждого из перечисленных алгоритмов согласования ключа, а также алгоритма передачи ключа, описанного в 7.2.

Таблица 5

Алгоритмы распределения ключа шифрования и имитозащиты

Свойства алгоритма	Согласование ключа на сеансовых ключах (см. 7.4.1)	Согласование ключа на сеансовом и долговременном ключе (см. 7.4.2)	Согласование ключа на долговременных ключах (см. 7.4.3)	Передача ключа (см. 7.2)
Криптографические наборы, поддерживающие алгоритм	9	9	9	8,9
Возможные типы распределяемого ключа	- мастер-ключ шифрования и имитозащиты; - глобальный ключ шифрования и имитозащиты при адресной рассылке	- сеансовый ключ шифрования и имитозащиты	- сеансовый ключ шифрования и имитозащиты	- мастер-ключ шифрования и имитозащиты; - глобальный ключ шифрования и имитозащиты при адресной рассылке; - глобальный ключ шифрования и имитозащиты при широковещательной рассылке; - сеансовый ключ шифрования и имитозащиты
Используемые в процессе вычислений ключи	У каждой из сторон должны быть: - ключи подписи и проверки подписи; - сеансовая ключевая пара согласования ключа	У одной стороны должны быть: - ключи подписи и проверки подписи; - сеансовая ключевая пара согласования ключа У другой стороны должна быть: - долговременная ключевая пара согласования ключа	У каждой из сторон должна быть: - долговременная ключевая пара согласования ключа	У каждой из сторон должен быть: - мастер-ключ шифрования и имитозащиты
Тип взаимодействия (первым указывается инициатор)	- клиент-сервер	- клиент-сервер; - сервер-клиент; - доверенная третья сторона-сервер; - сервер-доверенная третья сторона	- клиент-сервер; - сервер-клиент; - доверенная третья сторона-сервер; - сервер-доверенная третья сторона	- клиент-сервер; - сервер-клиент (только при передаче сеансового ключа шифрования и имитозащиты)

Используемые в процессе согласования ключа сеансовые и долговременные ключевые пары для согласования ключа, ключи подписи и проверки подписи должны соответствовать ГОСТ 34.10-2018 и эллиптической кривой, задаваемой набором параметров id-tc26-gost-3410-2012-256-paramSetB "1.2.643.7.1.2.1.1.2.", определенным в Р 1323565.1.024-2019.

Для возможности выполнения алгоритма согласования ключа между сторонами U и V:

- сторона V должна предварительно получить значение идентификатора стороны U:

;

- сторона U должна предварительно получить значение идентификатора стороны V:

В процессе согласования ключа стороны используют величину AlgorithmID, определяющую криптографические алгоритмы, для которых предназначен согласуемый ключ. Возможные значения AlgorithmID приведены в таблице 6. При подаче величины AlgorithmID на вход криптографическим алгоритмам необходимо использовать ее закодированное значение длиной 56 бит.

Таблица 6

Значения AlgorithmID

Криптографические алгоритмы, для которых предназначен согласуемый ключ	Идентификатор криптографического алгоритма COSEM (COSEM cryptographic algorithm ID)	Закодированное значение (в виде шестнадцатеричной строки)
Алгоритмы шифрования и имитозащиты KUZN_CTR и KUZN_CMAC (выбирается в случае согласования глобального ключа шифрования и имитозащиты при адресной рассылке или сеансового ключа шифрования и имитозащиты)	2.16.756.5.8.3.4	60857406080304
Алгоритмы экспорта и импорта ключа KUZN_KEXP и KUZN_KIMP (выбирается в случае согласования мастер-ключа шифрования и имитозащиты)	2.16.756.5.8.3.5	60857406080305

Способы обработки сбоев и ошибок в процессе согласования ключа определяются конкретным исполнением протокола DLMS.

7.4.1 Согласование ключа с применением каждой из взаимодействующих сторон сеансовых ключевых пар согласования ключа

Алгоритм согласования ключа между сторонами U и V с применением каждой из взаимодействующих сторон сеансовых ключевых пар согласования ключа приведен в таблице 8. В качестве стороны U выступает клиент, в качестве стороны V - сервер.

Для возможности выполнения алгоритма согласования ключа с применением каждой из взаимодействующих сторон сеансовых ключевых пар согласования ключа:

- сторона U должна иметь собственные долговременные ключи подписи и проверки подписи:

соответственно, где

;

- сторона V должна иметь собственные долговременные ключи подписи и проверки подписи:

соответственно, где

;

- стороны должны предварительно обменяться ключами

доверенным образом (например, с помощью использования сертификатов).

Согласуемый ключ

должен иметь один из следующих типов:

- мастер-ключ шифрования и имитозащиты,

- глобальный ключ шифрования и имитозащиты при адресной рассылке.

В процессе согласования ключа стороны используют величину key_id, определяющую тип согласуемого ключа. Возможные значения key_id приведены в таблице 7. Конкретное значение key_id определяется стороной U перед выполнением алгоритма согласования ключа. При подаче величины key_id на вход криптографическим алгоритмам необходимо использовать ее закодированное значение длиной 16 бит.

Таблица 7

Значения key_id

Тип согласуемого ключа	Значение	Закодированное значение (в виде шестнадцатеричной строки)
Глобальный ключ шифрования и имитозащиты при адресной рассылке	0	1600
Мастер-ключ шифрования и имитозащиты	3	1603

Таблица 8

Согласование ключа с применением каждой из взаимодействующих

сторон сеансовых ключевых пар согласования ключа

Сторона U	Пересылаемые значения	Сторона V
Генерирует сеансовую ключевую пару согласования ключа , где - закрытый ключ, - открытый ключ, для чего: случайным образом выбирает значение и вычисляет точку эллиптической кривой

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

Проверяет, что и . В случае отрицательного результата проверки возвращает ошибку и досрочно завершает процесс согласования ключа
Вычисляет значение P_VU длины 256 бит:
Вычисляет значение T_VU длины 768 бит:
Вычисляет значение K_VU длины 512 бит и значение M_VU длины 256 бит:
Вычисляет цифровую подпись sign_U длины 512 бит:
Вычисляет значение tag_U длины 96 бит:

		Проверяет цифровую подпись sign_U с использованием . В случае отрицательного результата проверки возвращает ошибку и досрочно завершает процесс согласования ключа
		Вычисляет значение P_UV длины 256 бит:
		Вычисляет значение T_UV длины 768 бит:
		Вычисляет значение K_UV длины 512 бит и значение M_UV длины 256 бит:
		Проверяет равенство . В случае отрицательного результата проверки возвращает ошибку и досрочно завершает процесс согласования ключа
		Вычисляет цифровую подпись sign_V длины 512 бит:
		Вычисляет значение tag_V длины 96 бит:
		Уничтожает ключ M_UV и устанавливает значение Key длины 512 бит:

Проверяет цифровую подпись sign_V с использованием . В случае отрицательного результата проверки возвращает ошибку и досрочно завершает процесс согласования ключа
Проверяет равенство В случае отрицательного результата проверки возвращает ошибку и досрочно завершает процесс согласования ключа
Уничтожает ключ M_VU и устанавливает значение Key длины 512 бит:

Для пересылки значений key_id,

используется метод key_agreement, для чего устанавливаются следующие значения его параметров:

- тип согласуемого ключа:

- сеансовый открытый ключ и сопутствующая информация:

Для пересылки значения

используется метод key_agreement, для чего устанавливаются следующие значения его параметров:

- тип согласуемого ключа:

- сеансовый открытый ключ и сопутствующая информация:

Для пересылки значений sign_U, tag_U используется метод key_agreement_confirmation, описанный в 7.4.1.1, для чего устанавливаются следующие значения его параметров:

тип согласуемого ключа:

информация для подтверждения согласуемого ключа и взаимодействующих сторон:

key_confirmation_data = sign_U||tag_U.

Для пересылки значений sign_V, tag_V используется метод key_agreement_confirmation, описанный в 7.4.1.1, для чего устанавливаются следующие значения его параметров:

- тип согласуемого ключа:

- информация для подтверждения согласуемого ключа и взаимодействующих сторон:

key_confirmation_data = sign_V||tag_V.

7.4.1.1 Описание метода подтверждения ключа и взаимодействующих сторон

Для возможности подтверждения согласуемого ключа и взаимодействующих сторон вводится дополнительный метод key_agreement_confirmation объекта Security Setup. Описание метода в соответствии с обозначениями, принятыми в [2], приведено ниже.

key_agreement_confirmation (data)

data::= array key_agreement_confirmation_data

key_agreement_confirmation_data::= structure

{

key_id: enum:

(0) global unicast encryption key,

(3) master key (KEK)

key_confirmation_data: octet-string

}

Метод key_agreement_confirmation имеет один входной параметр data. Значение data представляет собой массив, состоящий из структур, каждая из которых содержит два элемента:

- тип согласуемого ключа key_id, который может принимать значение 0 в случае согласования глобального ключа шифрования и имитозащиты при адресной рассылке, и значение 3 в случае согласования мастер-ключа шифрования и имитозащиты;

- информацию для подтверждения согласуемого ключа и взаимодействующих сторон key_confirmation_data, которая должна содержать значения подписи и имитовставки, вычисленные с использованием сеансовых ключевых пар согласования ключа, идентификаторов сторон и долговременного ключа подписи.

7.4.2 Согласование ключа с применением одной из взаимодействующих сторон сеансовой ключевой пары согласования ключа и другой из сторон долговременной ключевой пары согласования ключа

Алгоритм согласования ключа между сторонами U и V с применением одной из взаимодействующих сторон сеансовой ключевой пары согласования ключа и другой из сторон долговременной ключевой пары согласования ключа приведен в таблице 9. В качестве одной из взаимодействующих сторон U или V выступает клиент (или доверенная третья сторона), в качестве другой стороны - сервер.

Для возможности выполнения алгоритма согласования ключа с применением одной из взаимодействующих сторон сеансовой ключевой пары согласования ключа и другой из сторон долговременной ключевой пары согласования ключа:

- сторона U должна иметь собственные долговременные ключи подписи и проверки подписи:

соответственно, где

;

- сторона V должна иметь собственную долговременную ключевую пару согласования ключа

, где

- закрытый ключ,

- открытый ключ и

;

- сторона V должна предварительно получить ключ

доверенным образом (например, с помощью использования сертификата);

- сторона U должна предварительно получить ключ

доверенным образом (например, с помощью использования сертификата).

Таблица 9

Согласование ключа с применением одной из взаимодействующих

сторон сеансовой ключевой пары согласования ключа и другой

из сторон долговременной ключевой пары согласования ключа

Сторона U	Пересылаемые значения	Сторона V
Генерирует случайное значение . В случае r_U = 0¹²⁸ устанавливает
Генерирует сеансовую ключевую пару согласования ключа (, ), где - закрытый ключ, - открытый ключ, для чего: случайным образом выбирает значение и вычисляет точку эллиптической кривой
Вычисляет значение P_VU длины 256 бит:
Вычисляет значение T_VU длины 768 бит:
Вычисляет значение K_VU длины 512 бит и значение M_VU длины 256 бит:
Вычисляет цифровую подпись sign_U длины 512 бит:
Вычисляет значение tag_U длины 96 бит:
Уничтожает ключ M_VU и устанавливает значение Key длины 512 бит:

		Проверяет, что и . В случае отрицательного результата проверки возвращает ошибку и досрочно завершает процесс согласования ключа
		Проверяет цифровую подпись sign_U с использованием . В случае отрицательного результата проверки возвращает ошибку и досрочно завершает процесс согласования ключа
		Вычисляет значение P_UV длины 256 бит:
		Вычисляет значение T_UV длины 768 бит:
		Вычисляет значение K_UV длины 512 бит и значение M_UV длины 256 бит:
		Проверяет равенство . В случае отрицательного результата проверки возвращает ошибку и досрочно завершает процесс согласования ключа
		Уничтожает ключ M_UV и устанавливает значение Key длины 512 бит:

Согласуемый ключ

должен являться сеансовым ключом шифрования и имитозащиты.

Для пересылки значений r_U,

, sign_U, tag_U используется xDLMS APDU, защищенный способом general-ciphering, для чего устанавливаются следующие значения его параметров:

- идентификатор транзакции:

transaction-id = r_U;

- идентификатор схемы согласования ключа:

key-info.agreed-key.key-parameters = 01 (в шестнадцатеричном виде);

- дополнительная информация для согласования ключа:

Одновременно с передачей перечисленных значений, необходимых для возможности вычисления ключа Key стороной V, в этом же xDLMS APDU передается содержательная часть сообщения, зашифрованная и/или имитозащищенная с использованием согласуемого ключа Key.

- сторона U устанавливает значение поля date-time (дата и время) xDLMS APDU, защищенного способом general-ciphering, равным значению времени отправки этого xDLMS APDU;

- сторона U в обязательном порядке выполняет имитозащиту xDLMS APDU;

- сторона V при получении xDLMS APDU проверяет имитовставку для xDLMS APDU и сверяет значение поля date-time с текущим значением времени; на основании этих проверок сторона V принимает решение о необходимости приема полученного xDLMS APDU.

Описание конкретного механизма защиты от повторов при передаче xDLMS APDU, защищенного на согласуемом сеансовом симметричном ключе, находится за рамками данного документа.

7.4.3 Согласование ключа с применением каждой из взаимодействующих сторон долговременных ключевых пар согласования ключа

Алгоритм согласования ключа между сторонами U и V с применением каждой из взаимодействующих сторон долговременных ключевых пар согласования ключа приведен в таблице 10. В качестве одной из взаимодействующих сторон U или V выступает клиент (или доверенная третья сторона), в качестве другой стороны - сервер.

Таблица 10

Согласование ключа с применением каждой из взаимодействующих

сторон долговременных ключевых пар согласования ключа

Сторона U	Пересылаемые значения	Сторона V
Генерирует случайное значение . В случае r_U = 0¹²⁸ устанавливает
Вычисляет значение P_VU длины 256 бит:
Вычисляет значение T_VU длины 768 бит:
Вычисляет значение K_VU длины 512 бит и значение M_VU длины 256 бит:
Вычисляет значение tag_U длины 96 бит:
Уничтожает ключ M_VU и устанавливает значение Key длины 512 бит:

		Вычисляет значение P_UV длины 256 бит:
		Вычисляет значение T_UV длины 768 бит:
		Вычисляет значение K_UV длины 512 бит и значение M_UV длины 256 бит:
		Проверяет равенство . В случае отрицательного результата проверки возвращает ошибку и досрочно завершает процесс согласования ключа
		Уничтожает ключ M_UV и устанавливает значение Key длины 512 бит:

Для возможности выполнения алгоритма согласования ключа с применением каждой из взаимодействующих сторон долговременных ключевых пар согласования ключа:

- сторона U должна иметь собственную долговременную ключевую пару согласования ключа (

), где

- закрытый ключ,

- открытый ключ и

;

- сторона V должна иметь собственную долговременную ключевую пару согласования ключа (

), где

- закрытый ключ,

- открытый ключ и

;

- стороны U и V должны предварительно обменяться ключами

доверенным образом (например, с помощью использования сертификатов).

Согласуемый ключ

должен являться сеансовым ключом шифрования и имитозащиты.

Для пересылки значений r_U, tag_U используется xDLMS APDU, защищенный способом general-ciphering, для чего устанавливаются следующие значения его параметров:

- идентификатор транзакции:

transaction-id = r_U;

- идентификатор схемы согласования ключа:

key-info.agreed-key.key-parameters = 02

(в шестнадцатеричном виде);

- дополнительная информация для согласования ключа:

key-info.agreed-key.key-ciphered-data = tag_U.

В случае необходимости обеспечения защиты от повторов при передаче xDLMS APDU, защищенного на согласуемом сеансовом симметричном ключе, взаимодействующие стороны должны предусмотреть использование дополнительного механизма защиты. Такой механизм, к примеру, может базироваться на использовании меток времени и содержать этапы, приведенные в 7.4.2. Описание конкретного механизма защиты от повторов при передаче xDLMS APDU, защищенного на согласуемом сеансовом симметричном ключе, находится за рамками данного документа.

При реализации протокола DLMS в информационной системе, в которой актуальна угроза получения злоумышленником закрытого долговременного ключа, использование алгоритма согласования ключа с применением каждой из взаимодействующих сторон долговременных ключевых пар согласования ключа запрещается.

7.5 Механизмы аутентификации HLS

Аутентификация HLS (аутентификация высокого уровня безопасности) может осуществляться при установлении AA между клиентом и сервером.

В основе аутентификации HLS лежит схема из четырех этапов:

- этап 1: клиент отправляет серверу запрос, основу которого составляет случайное значение, сгенерированное клиентом;

- этап 2: сервер отправляет клиенту запрос, основу которого составляет случайное значение, сгенерированное сервером;

- этап 3: клиент вычисляет ответ на запрос сервера, обрабатывая этот запрос с применением криптографических алгоритмов и секретного значения, и отправляет полученный ответ серверу; сервер проверяет ответ клиента;

- этап 4: сервер вычисляет ответ на запрос клиента, обрабатывая этот запрос с применением криптографических алгоритмов и секретного значения, и отправляет полученный ответ клиенту; клиент проверяет ответ сервера.

Рассматриваются три механизма аутентификации HLS:

- механизм "HLS CMAC" на основе алгоритма вычисления имитовставки (см. 7.5.1);

- механизм "HLS GOST34112018-256" на основе алгоритма вычисления хэш-функции (см. 7.5.2);

- механизм "HLS GOST34102018-256" на основе алгоритма вычисления электронной цифровой подписи (см. 7.5.3).

Допускается применение:

- механизма аутентификации "HLS CMAC" для согласования криптографического набора 8;

- механизмов аутентификации "HLS GOST34112018-256" и "HLS GOST34102018-256" для согласования криптографического набора 9.

Идентификаторы описываемых механизмов аутентификации HLS приведены в таблице 11. Содержимое запросов и ответов для каждого из описываемых механизмов аутентификации HLS приведено в таблице 12.

Таблица 11

Идентификаторы механизмов аутентификации HLS

Механизм аутентификации HLS	Идентификатор механизма (mechanism_id)	Полный идентификатор механизма аутентификации COSEM (COSEM authentication mechanism name)
"HLS CMAC"	mechanism_id(8)	2.16.756.5.8.2.8
"HLS GOST34112018-256"	mechanism_id(9)	2.16.756.5.8.2.9
"HLS GOST34102018-256"	mechanism_id(10)	2.16.756.5.8.2.10

Таблица 12

Содержимое запросов и ответов

для механизмов аутентификации HLS

Механизм аутентификации HLS	Этап 1: запрос от клиента к серверу	Этап 2: запрос от сервера к клиенту	Этап 3: ответ от клиента к серверу	Этап 4: ответ от сервера к клиенту
mechanism_d(8) "HLS CMAC"	- случайная двоичная строка CtoS длины 64 - 512; - идентификатор клиента system-title-C длины 64 бит	- случайная двоичная строка StoC длины 64 - 512 бит; - идентификатор сервера system-title-S длины 64 бит
mechanism_id(9) "HLS GOST34112018-256"
mechanism_id(10) "HLS GOST34102018-256"	- случайная двоичная строка CtoS длины 256 - 512 бит; - идентификатор клиента system-title-C длины 64 бит; - сертификат ключа проверки подписи клиента (опционально)	- случайная двоичная строка StoC длины 256 - 512 бит; - идентификатор сервера system-title-S длины 64 бит; - сертификат ключа проверки подписи сервера (опционально)

Наличие строки CtoS и идентификатора system-title-C среди данных, передаваемых на этапе 1, а также строки StoC и идентификатора system-title-S среди данных, передаваемых на этапе 2, является обязательным для всех трех механизмов. В случае отсутствия этих значений среди передаваемых данных возвращается ошибка и AA не устанавливается.

Точные значения длин CtoS и StoC определяются конкретным исполнением протокола DLMS. При получении значения StoC на этапе 2 клиент должен проверить, что это значение не равно значению CtoS. В случае равенства значений StoC и CtoS возвращается ошибка и AA не устанавливается.

При получении значения system-title-C на этапе 1 сервер должен проверить, что это значение не равно значению system-title-S. Аналогично, при получении значения system-title-S на этапе 2 клиент должен проверить, что это значение не равно значению system-title-C. В случае равенства значений system-title-C и system-title-S возвращается ошибка и AA не устанавливается.

Если стороны предварительно участвовали в процессе доверенной регистрации устройств с распределением идентификаторов (см. 6.2), то при получении идентификатора на этапе 1 и этапе 2 необходимо проверить его наличие среди идентификаторов, распределенных в процессе доверенной регистрации устройств. В случае, если полученный идентификатор отсутствует среди идентификаторов, распределенных в процессе доверенной регистрации устройств, возвращается ошибка и AA не устанавливается.

Для пересылки данных на этапе 1 используется AARQ, для чего устанавливаются следующие значения его параметров:

- значение запроса клиента:

calling-authentication-value = CtoS;

- идентификатор клиента:

calling-AP-title = system-title-C;

- уточняющие данные клиента (опционально): сертификат ключа проверки подписи клиента размещается в calling-AE-qualifier.

Перечисленные значения параметров пересылаются в незащищенном виде.

Для пересылки данных на этапе 2 используется AARE, для чего устанавливаются следующие значения его параметров:

- значение запроса сервера:

responding-authentication-value = StoC;

- идентификатор сервера:

responding-AP-title = system-title-S;

- уточняющие данные сервера (опционально): сертификат ключа проверки подписи сервера размещается в responding-AE-qualifier.

Перечисленные значения параметров пересылаются в незащищенном виде.

Для пересылки данных на этапе 3 и этапе 4 используется метод reply_to_HLS_authentication, для чего значение его параметра data устанавливается равным значению ответа на запрос. APDU, используемые в качестве транспорта для выполнения метода reply_to_HLS_authentication, при необходимости могут быть дополнительно зашифрованы и/или имитозащищены.

Аутентификация в каждом из трех механизмов считается успешной только в случае положительного результата всех проверок, осуществляемых клиентом и сервером и отсутствия сбоев и ошибок в процессе аутентификации. В случае успешной аутентификации устанавливается AA. Способы обработки сбоев и ошибок в процессе аутентификации HLS определяются конкретным исполнением протокола DLMS.

7.5.1 Механизм аутентификации HLS CMAC

Механизм аутентификации "HLS CMAC" может использоваться для согласования криптографического набора 8.

В качестве секрета, применяющегося при вычислении и проверке ответа в механизме аутентификации "HLS CMAC", используется глобальный ключ шифрования и имитозащиты при адресной рассылке

, известный только клиенту с идентификатором system-title-C и серверу с идентификатором system-title-S. Проверка ответа осуществляется путем вычисления значения имитовставки для идентичного набора данных и сравнения полученного и вычисленного значений имитовставки (предварительно должна быть выполнена проверка счетчика вызовов). В случае неравенства значений возвращается ошибка и AA не устанавливается.

Значения синхропосылок, использующихся при вычислении и проверке ответов в механизме аутентификации "HLS CMAC", имеют следующий вид:

где

- значение счетчика вызовов, уникальное для каждой операции зашифрования и/или вычисления имитовставки, выполняемой клиентом (сервером) с использованием ключа K_EM. Порядок инициализации, изменения и проверки значений счетчика вызовов описан в 6.3.

Байт управления безопасностью SC, использующийся при вычислении и проверке ответов в механизме аутентификации "HLS CMAC", должен принимать следующее значение:

SC = 0 || 0 || 0 || 1 || Vec₄(8).

7.5.2 Механизм аутентификации HLS GOST34112018-256

Механизм аутентификации "HLS GOST34112018-256" может использоваться для согласования криптографического набора 9.

В качестве секрета, применяющегося при вычислении и проверке ответа в механизме аутентификации "HLS GOST34112018-256", используется значение

, известное только клиенту с идентификатором system-title-C и серверу с идентификатором system-title-S. Проверка ответа осуществляется путем вычисления значения хэш-функции для идентичного набора данных и сравнения полученного и вычисленного значений хэш-функции. В случае неравенства значений возвращается ошибка и AA не устанавливается.

Минимальная длина значения HLS_Secret, при использовании в механизме "HLS GOST34112018-256", должна составлять 128 бит. Начальные значения HLS_Secret устанавливаются на устройствах в процессе их изготовления. В дальнейшем возможно изменение значений HLS_Secret при помощи метода change_HLS_secret.

7.5.3 Механизм аутентификации HLS GOST34102018-256

Механизм аутентификации "HLS GOST34102018-256" может использоваться для согласования криптографического набора 9.

Используемые в механизме аутентификации "HLS GOST34102018-256" ключи подписи и проверки подписи должны соответствовать ГОСТ 34.10-2018 и эллиптической кривой, задаваемой набором параметров id-tc26-gost-3410-2012-256-paramSetB "1.2.643.7.1.2.1.1.2.", определенным в Р 1323565.1.024-2019.

В качестве секрета, применяющегося при вычислении ответа в механизме аутентификации "HLS GOST34102018-256" на этапе 3 (на этапе 4), используется ключ подписи клиента

(ключ подписи сервера

). Проверка ответа осуществляется путем проверки полученного значения подписи с помощью соответствующего ключа проверки подписи (предварительно должна быть выполнена проверка самого ключа проверки подписи путем проверки соответствующего сертификата или цепочки сертификатов). В случае отрицательного результата хотя бы одной из проверок возвращается ошибка и AA не устанавливается.

Наличие сертификата ключа проверки подписи среди данных, передаваемых на этапе 1 и этапе 2 в механизме "HLS GOST34102018-256", является опциональным. При этом:

- если сертификат присутствует среди передаваемых данных, принимающая сторона должна использовать для проверки подписи этот сертификат;

- если сертификат не присутствует среди передаваемых данных, но был известен принимающей стороне, принимающая сторона должна использовать для проверки подписи имеющийся сертификат;

- если сертификат не присутствует среди передаваемых данных и не был известен принимающей стороне, возвращается ошибка и AA не устанавливается.

Приложение А

(справочное)

КОНТРОЛЬНЫЕ ПРИМЕРЫ

Приводимые ниже значения рекомендуется использовать только для проверки корректной работы конкретной реализации алгоритмов, описанных в настоящих рекомендациях.

Все числовые значения приведены в шестнадцатеричной системе счисления.

В данном приложении двоичные строки из V*, длина которых кратна 4, записываются в шестнадцатеричном виде, а символ конкатенации ("||") опускается. То есть строка

будет представлена в виде a_r_-1, a_r_-2 ... a₀, где

, i = 0,1, .... r - 1. Соответствие между двоичными строками длины 4 и шестнадцатеричными строками длины 1 задается естественным образом (таблица А.1).

Преобразование, ставящее в соответствие двоичной строке длины 4r шестнадцатеричную строку длины r, и соответствующее обратное преобразование для простоты записи опускается.

Таблица А.1

Соответствие между двоичными и шестнадцатеричными строками

0000	0
0001	1
0010	2
0011	3
0100	4
0101	5
0110	6
0111	7
1000	8
1001	9
1010	a
1011	b
1100	c
1101	d
1110	e
1111	f

Примечание 1 - Далее по тексту символ "\\" обозначает перенос числа на новую строку.

Примечание 2 - Во всех контрольных примерах, использующих функцию подписи SIGN₂₅₆, значение числа

, применяющегося при формировании подписи согласно ГОСТ 34.10-2018, является фиксированным и задается как

k = 43730c5cbccacf915ac292676f21e8bd\\

4ef75331d9405e5f1a61dc3130a65011₁₆

А.1 Шифрование и имитозащита

Общие входные значения:

А.1.1 Случай SC₅ = 0, SC₄ = 1

Входные значения:

Промежуточные значения:

Выходные значения:

А.1.2 Случай SC₅ = 1, SC₄ = 0

Входные значения:

Промежуточные значения:

Выходные значения:

А.1.3 Случай SC₅ = 1, SC₄ = 1

Входные значения:

Промежуточные значения:

Выходные значения:

А.2 Передача ключа

А.2.1 Вычисление экспортного представления ключа

Входные значения:

Промежуточные значения:

Выходные значения:

А.3 Защита данных с помощью электронной цифровой подписи

Входные значения:

Промежуточные значения:

Выходные значения:

А.4 Согласование ключа

А.4.1 Согласование ключа с применением каждой из взаимодействующих сторон сеансовых ключевых пар согласования ключа

Входные значения:

Промежуточные значения:

Выходные значения:

А.4.2 Согласование ключа с применением одной из взаимодействующих сторон сеансовой ключевой пары согласования ключа и другой из сторон долговременной ключевой пары согласования ключа

Входные значения:

Промежуточные значения:

Выходные значения:

А.5 Механизмы аутентификации HLS

А.5.1 HLS CMAC

Входные значения:

Промежуточные значения:

Выходные значения:

А.5.2 HLS GOST34112018-256

Входные значения:

Промежуточные значения:

Выходные значения:

А.5.3 HLS GOST34102018-256

Входные значения:

Промежуточные значения:

Выходные значения:

БИБЛИОГРАФИЯ

[1]	DLMS/COSEM Architecture and Protocols, Edition 8.0.
[2]	COSEM Interface Classes and OBIS Object Identification System, Edition 12.0.

УДК 681.3.06:006.354	ОКС 35.040
Ключевые слова: криптографические протоколы, шифрование, аутентификация, ключ, имитозащита