Приветствую уважаемую публику Хабра от лица условно анонимного представителя Компании «Актив», занимающейся производством небезызвестных средств аутентификации и электронной подписи. В этой статье хотелось бы рассказать об одном из менее известных направлений деятельности подразделения Рутокен, связанного с обеспечением киберфизической безопасности. В рамках данного направления компания уже не первый год производит встраиваемые в управляющее и управляемое оборудование устройства линейки Рутокен Модуль. Не так давно в эти устройства (а заодно в токены и смарт-карты Рутокен ЭЦП 3.0) добавилась поддержка протокола CRISP, и это отличный повод рассказать и о самом протоколе, и о принципах интеграции устройств Рутокен Модуль, и об организации процессов разработки в компании.

Рутокен Модуль: принципы интеграции

Устройства линейки Рутокен Модуль предназначены для обеспечения безопасности межмашинного взаимодействия (M2M), защиты автоматизированных систем управления технологическими процессами (АСУ ТП) и интернета вещей (IoT). В качестве интерфейсов для встраивания устройств могут использоваться шины USB, UART, USART или SPI.

В устройствах Рутокен Модуль исполняется та же операционная система, что и в токенах и смарт-картах Рутокен ЭЦП. Они имеют одинаковый APDU-интерфейс и поддерживаются похожим стеком middleware, на вершине которого как минимум оказывается реализация стандарта PKCS#11. PKCS#11 — гибкий интерфейс, позволяющий управлять подключенными устройствами, криптографическими ключами и сертификатами на них и выполнять криптографические операции шифрования, подписания, выработки производного ключа и т.п. Для удобства разработчиков поверх интерфейса PKCS#11 строятся дополнительные программные продукты, помогающие при помощи устройств Рутокен поддержать защищенное хранение и обмен данными с использованием стандартов прикладной криптографии, таких как Cades, XMLDSig, TLS. Для поддержки этих стандартов в арсенале Рутокен есть ряд механизмов, позволяющих использовать устройства через высокоуровневые интерфейсы, как opensource (криптографические библиотеки OpenSSL, BouncyCastle), так и проприетарные (например, веб-интерфейс Рутокен Плагин или родственный ему нативный интерфейс PKI-Core).

Нередко добавление новой функциональности в устройство требует реализации изменений на одном или нескольких уровнях middleware.  В случае поддержки протокола CRISP изменения затронули интерфейс APDU-команд, потребовали расширения стандартного интерфейса библиотеки PKCS#11, а также привели к разработке новых программных интерфейсов.

Для понимания причин таких обширных изменений придется немного углубиться в детали протокола CRISP.

Протокол CRISP

Описание протокола CRISP прошло путь от методических рекомендаций ТК26 МР 26.4.001-2019 "Протокол защищенного обмена для индустриальных систем (CRISP 1.0)" до рекомендаций по стандартизации Р 1323565.1.029-2019 "Информационная технология. Криптографическая защита информации. Протокол защищенного обмена для индустриальных систем".
В 2022 году вышло Изменение №1 к Р 1323565.1.029-2019, ранее опубликованное как МР 26.4.003-2021 "Криптографические наборы CS = 3 и CS = 4 для протокола защищенного обмена для индустриальных систем CRISP 1.0". Наконец, в 2024 году протокол CRISP был принят как стандарт ГОСТ Р 71252–2024 «Информационная технология. Криптографическая защита информации. Протокол защищенного обмена для индустриальных систем». Разработка протокола производилась компанией "ИнфоТеКС". Для ознакомления с протоколом можно воспользоваться следующими материалами:

• вебинар "Криптографический протокол CRISP. Что? Где? Когда?": infotecs.ru, youtube;

• презентация Ольги Шемякиной "Протокол защищенного обмена для индустриальных систем (CRISP 1.0)" на РусКрипто 2019: ruscrypto.ru.

Криптография в протоколе

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

Сообщения состоят из заголовка, полезной нагрузки и концевика.

В заголовке содержатся служебные поля:

• версия CRISP-протокола,

• идентификатор используемого криптонабора,

• порядковый номер сообщения,

• идентификатор базового ключа или признак, что идентификация базового ключа выполнена вне протокола.

Концевик содержит имитовставку сообщения.

Используемые криптонаборы предполагают подсчет имитовставки согласно ГОСТ Р 34.13—2015 блочным шифром "Магма" согласно ГОСТ Р 34.12—2015 (для криптонаборов CS=1, CS=2 MAC длиной 4 байта, для криптонаборов CS=3, CS=4 MAC длиной 8 байт) и шифрование блочным шифром "Магма" согласно ГОСТ Р 34.12—2015 в режиме гаммирования согласно ГОСТ Р 34.13—2015 (для криптонаборов CS=1, CS=3). При использовании криптонаборов CS=2, CS=4 шифрование не производится.

Ключи шифрования и имитовставки сообщений вырабатываются из базового ключа Key посредством конкатенации нескольких результатов работы псевдослучайной функции (PRF). В качестве PRF используется функция СMAC(Key, Data), где CMAC — функция выработки имитовставки блочным шифром "Магма".

Заслуживает внимания схема выработки производных ключей шифрования и имитовставки. Общий принцип построения схемы выработки производного ключа, использованной в протоколе CRISP, представлен в NIST 800-108, п. 4.1 — схема "KDF in Counter Mode".

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

где

• || — конкатенация,

• K_IN — базовый ключ,

• [x]₂ — бинарное представление числа x длиной r бит,

• L — длина выходного ключевого материала в битах,

• Label и Context — фиксированные данные.

Стандартом допускается, что одно или несколько полей из множества {Label, 0x00, Context, [L]₂} может не использоваться.

Применительно к CRISP данная схема выглядит так:

• в качестве PRF используется функция СMAC(Key, Data), реализованная с помощью блочного шифра "Магма" согласно ГОСТ Р 34.12—2015 в режиме вычисления имитовставки согласно ГОСТ Р 34.13—2015;

• Label принимает значения, в зависимости от криптонабора:

  • {'m', 'a', 'c', 'e', 'n', 'c', 0x06} для CS=1 и CS=3,

  • {'m', 'a', 'c', 'm', 'a', 'c', 0x06} для CS=2 и CS=4,

• разделяющий Label и Context байт 0x00 не используется,

• Context строится как конкатенация ContextBody, состоящего из 5 нулевых бит, 35 старших бит порядкового номера сообщения, имени отправителя сообщения, номера шифрнабора, и ContextBodyLength -- однобайтового бинарного представления длины ContextBody,

• L := 512 для CS=1 и CS=3, L := 256 для CS=2 и CS=4.

Для всех шифрнаборов:

Для шифрнаборов с шифрованием:

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

Управление потоком данных в протоколе

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

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

• Перед началом сессии приемо-передачи получатель устанавливает ожидаемые значения минимального и максимального номера окна в 0.

• Сообщения с номером меньше минимального номера окна не принимаются.

• При получении сообщения с номером, превышающим максимальный номер окна, номер сообщения становится максимальным номером окна — окно сдвигается.

• В рамках окна ведется учет номеров принятых сообщений.

• Сообщения, содержащие номер уже принятого сообщения, не принимаются.

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

• контроль версии протокола (версия должна поддерживаться получателем),

• контроль значения идентификатора ключа (получателю должно быть известно, какой ключ использовать для криптографических операций),

• контроль целостности сообщения криптографическими методами — проверку значения имитовставки.

Поддержка протокола CRISP продуктами Рутокен

Как уже упоминалось, изменения, вызванные добавлением поддержки протокола CRISP, затронули операционную систему устройств Рутокен (расширение функциональности и дополнение APDU-интерфейса), потребовали проектирования и реализации расширения интерфейса PKCS#11 и привели к разработке дополнительных программных модулей, реализующих логику протокола CRISP и использующих в качестве провайдера криптографии устройства Рутокен ЭЦП 3.0 или Рутокен Модуль через интерфейс PKCS#11.

Изменения в ОС Рутокен

За двадцатилетнюю историю операционная система устройств семейства Рутокен приобрела достаточно обширную функциональность. При проектировании функциональности ОС разработчики стараются предугадывать будущие потребности и для этого делают гибкие и расширяемые интерфейсы. Во многом благодаря этому изменения в ОС Рутокен оказались минимальны: ОС позволяет управлять криптографическими ключами, хранящимися на устройстве, и выполнять с их использованием криптографические операции. Единственное, что пришлось добавить, — это новый режим выработки производного ключа, в соответствии с описанным выше алгоритмом из спецификации протокола CRISP. В APDU-интерфейсе при этом новых APDU-команд не появилось, но для APDU-команды CHANGE REFERENCE DATA появился новый режим, задействующий добавленную функциональность.

Изменения в реализации интерфейса PKCS#11

Международная версия спецификации интерфейса PKCS#11 развивается организацией OASIS Open. Сам интерфейс PKCS#11 допускает его расширение: добавление новых типов, атрибутов объектов, криптографических механизмов.

Расширение интерфейса PKCS#11 в части поддержки отечественных криптографических алгоритмов и механизмов ведется рабочей группой 2.4 в составе ТК26. Авторству этой рабочей группы принадлежат МР 26.2.007-2017 "Расширение PKCS#11 для использования российских стандартов ГОСТ Р 34.10-2012 и ГОСТ Р 34-11-2012" (версия на английском доступна для скачивания) и еще не опубликованные, но уже поддерживаемые производителями смарт-карт МР "Расширение PKCS#11 для использования стандартов ГОСТ 34.12-2018 и ГОСТ 34.13-2018".

Расширением интерфейса PKCS#11 для поддержки механизмов, специфичных только для конкретных устройств, занимаются и организации-производители этих устройств, разрабатывающие реализацию интерфейса PKCS#11 под эти устройства. При поддержке протокола CRISP наша компания пошла этим путем. Мы разработали спецификацию расширения интерфейса "Расширение PKCS#11 для поддержки протокола CRISP". Расширением добавляются:

• Механизм выработки производного ключа CKM_VENDOR_KDF_CRISP_CMAC. Этот механизм позволяет выработать из базового ключа типа CKK_MAGMA либо производный ключ CKK_MAGMA, используемый для подсчета имитовставки, либо двойственный ключ CKK_MAGMA_TWIN_KEY, представляющий собой пару симметричных ключей, используемых для шифрования и подсчета имитовставки. Тип производного ключа зависит от указанных параметров механизма.

• Механизм аутентифицированного шифрования на двойственных ключах Магма в соответствии с протоколом CRISP CK_VENDOR_CRISP_AEAD_PARAMS.

Рутокен CRISP SDK

Изменений, внесенных в операционную систему Рутокен и в реализацию интерфейса PKCS#11, в принципе достаточно, чтобы утверждать, что протокол CRISP устройствами Рутокен поддерживается: существуют все необходимые криптографические механизмы для создания и обработки сообщений протокола CRISP и публичный интерфейс их использования. Но часто бывает, что интеграторами криптографических решений интерфейс PKCS#11 воспринимается слишком сложным, и предоставление одного этого интерфейса устанавливает достаточно высокий порог входа для интеграции. Для снижения порога входа наша компания разрабатывает высокоуровневые модули, оперирующие такими абстракциями, как сертификаты X.509, запросы на сертификат в формате PKCS#10, зашифрованные и подписанные сообщения в форматах CMS, CAdES и XAdES. С этой целью реализованы модули pki-core (документация, обзор), Рутокен Плагин (документация, опыт использования), модуль интеграции в OpenSSL (документация, опыт использования).

В качестве высокоуровневого интерфейса поддержки протокола CRISP был реализован Рутокен CRISP SDK, включающий в себя:

• модуль rtcrisp – реализацию некриптографической части протокола CRISP, к которой для обработки сообщений должен быть подключен криптографический модуль, реализующий управление криптографическими ключами и выполнение криптографических операций в соответствии с протоколом CRISP;

• модуль rtcrisp-crypto-rtpkcs11ecp – реализацию адаптера для подключения библиотеки rtPKCS11ECP в качестве криптографического модуля для rtcrisp.

Модуль rtcrisp разработан с применением объектно-ориентированного подхода и предоставляет интерфейс на языке C. Выделены сущности отправителя и получателя CRISP-сообщений. Объекты этих сущностей имеют внутреннее состояние, задаваемое при инициализации и частично изменяемое при использовании.

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

С использованием сущности получателя сообщений реализуется функция получения данных из CRISP-сообщения. Вызов этой функции изменяет внутреннее состояние окна полученных сообщений и также может привести к перегенерации ключей. При извлечении данных контролируется целостность сообщения и производится их расшифрование.
Кроме этого, определена функция, позволяющая извлечь служебные поля из CRISP сообщения без выполнения контроля целостности сообщения.
Ознакомиться с полной документацией Рутокен CRISP SDK можно по данной ссылке. В Рутокен SDK представлен пример использования модулей.

Модули Рутокен CRISP SDK в составе Рутокен SDK распространяются в виде бинарных компонент, собранных под платформы Windows x86/x64, Linux x86/x64, macOS x64+arm64. Эти платформы выбраны в демонстрационных целях. В то же время по запросу есть возможность собрать модули под целевую платформу, встраивающую Рутокен Модуль или Рутокен ЭЦП 3.0.

Контроль качества и cовместимость

Добавленная в ходе обеспечения поддержки протокола CRISP функциональность тестировалась на различных уровнях. Реализация изменений микропрограммы Рутокен покрывается автоматическими тестами, взаимодействующими с устройством на уровне APDU-команд; при реализация PKCS#11, аналогично, пополняется набор автоматических тестов, использующих устройство. Реализация Рутокен CRISP SDK покрывалась юнит-тестами (чему способствовала его модульная архитектура) и интеграционными тестами (тестирование всего стека ПО, включающее обращение к устройству).

Корректность реализации криптографических механизмов проверялась на контрольных примерах, содержащихся в рекомендациях по стандартизации. Для проверки корректности реализации самого протокола CRISP было выполнено кросс-тестирование с продуктом ИнфоТеКС ViPNet SIES. Опыт кросс-тестирования показал, что на основе Рутокен ЭЦП 3.0 или Рутокен Модуль с использованием Рутокен CRISP SDK может быть построен SIES-узел, совместимый с ViPNet SIES-узлами на базе ViPNet SIES Unit.

Заключение

Описанный процесс добавления поддержки протокола CRISP можно считать типичным для нашей компании. В развитии новой функциональности в устройствах Рутокен участвует большая группа специалистов: аналитиков, архитекторов, разработчиков программного обеспечения различных уровней, специалистов тестирования и менеджеров проектов, имеющих опыт в области компьютерной безопасности. Сравнительно новая линейка устройств Рутокен Модуль расширяет возможности использования результатов многих человеко-лет работы этих специалистов в решении задачи криптографической защиты обрабатываемых данных во встраиваемых системах. Поддержка протокола CRISP не предел; это скорее пример возможностей продукта и готовности его к адаптации под конкретные потребности интегратора и заказчика.