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

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 с использованием российских криптографических стандартов.

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

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

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

ГОСТ 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.1.1 криптографический набор: Совокупность криптографических алгоритмов и параметров, используемых в протоколе DLMS.

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

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

Использование криптографического набора 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.

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

Типы симметричных ключей, используемых в протоколе DLMS, приведены в таблице 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.

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

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

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

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

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

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

При шифровании и имитозащите данных в протоколе 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₅ нулевому значению подразумевает отсутствие криптографической защиты и в данном документе не рассматривается.

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

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

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

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

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

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

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

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

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

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

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

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

При использовании криптографического набора 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, необходимые, соответственно, для генерации новой ключевой пары сервера, создания сервером запроса на сертификат и передачи созданного сертификата по направлению от клиента (или от доверенной третьей стороны) к серверу.

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

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

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

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

Алгоритмы шифрования и имитозащиты предназначены для защиты 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:

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

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

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

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

где 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 значение .

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

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

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

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

где ;

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

где ;

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

где , .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

где 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.

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

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

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

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

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

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

Используемые в процессе согласования ключа сеансовые и долговременные ключевые пары для согласования ключа, ключи подписи и проверки подписи должны соответствовать ГОСТ 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 бит.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для пересылки значений 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аутентификация 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.

Наличие строки 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-AE-qualifier.

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

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

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

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

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

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

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

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

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

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

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

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

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

Механизм аутентификации "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.

Механизм аутентификации "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 - Далее по тексту символ "\\" обозначает перенос числа на новую строку.

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

k = 43730c5cbccacf915ac292676f21e8bd\\

4ef75331d9405e5f1a61dc3130a65011₁₆

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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