Comments 8
Жаль, что очень здравая идея в унификации обмена сообщениями рискует превратится в очередную принудиловку со стороны регуляторов, которая не несет никакой реальной пользы, кроме финансового благополучия "тех, кто в теме".
Лучше напишите про Рутокен Модуль или это аналог ViPNet SIES и тоже на STM32?
Добрый день! Спасибо за внимательное чтение статьи;) Рутокен Модуль -- это практически аналог Рутокен ЭЦП 3.0, но с более удобными для промышленного встраивания транспортными и физическими интерфейсами. На зоопарк можно взглянуть здесь: https://www.rutoken.ru/products/all/rutoken-module/#models
Могу поделиться отношением к факту стандартизации протокола со стороны разработчика/интегратора СКЗИ (возможно, конечно, мое мнение не учитывает всех деталей): здорово, стандартизован еще один криптографический протокол обмена данными; теперь вместо изобретения своей криптовундервафли, требующей обоснования безопасности, можно выбирать из большего набора готовых, стандартизованных протоколов, и этим облегчить взаимодействие с регулятором при сертификации/контроле встраивания решения.
Возможно я сильно саркастически написал, из-за чего вы не поняли мой комментарий, а восприняли его сразу в штыки. Я не против принятия принятие нового стандарта криптографической защиты сообщений (да и как я могу, если и сам, хотя и давно, приложил руку к началу его разработки). И я согласен с вами, что проще взять готовый и одобренный регуляторами, чем изобретать собственный велосипед.
Но в данном случае, готовый велосипед очень хорошо подходит для того, для чего и был создан (шифрование, подпись и т.д.), чтобы никакой хакер из недружественных стран не взломал защиту. Но не во всех системах это требуется или не на всех этапах, а сам велосипед хоть и хороший, но очень уникальный, из-за чего не совместимый больше ни с чем.
Поэтому разработчики систем будут вынуждены брать свой родной одобренный протокол по ГОСТ, но это будет только своя локальная разработка, которая больше никуда не пойдет, и это вместо того, чтобы взять какой нибудь международный протокол и только добавить в него Российские алгоритмы (как это было сделано с OpenSSL, PKCS#11 и т.д.) было изобретено вот это вот все. Или может быть я ошибаюсь, и у этого ГОСТ есть международный аналог по формату сообщений?
восприняли его сразу в штыки
И в мыслях не было;)
Или может быть я ошибаюсь, и у этого ГОСТ есть международный аналог по формату сообщений?
Насколько мне известно, нет.
Поэтому разработчики систем будут вынуждены брать свой родной одобренный протокол по ГОСТ, но это будет только своя локальная разработка
К счастью, протокол достаточно легковесный.
взять какой нибудь международный протокол и только добавить в него
Российские алгоритмы (как это было сделано с OpenSSL, PKCS#11 и т.д.)
Беглый обзор показывает, что в сфере IoT как раз с этим достаточно неплохо (https://www.itsec.ru/articles/podhody-k-kriptograficheskoj-zashchite-kommunikacij-v-iot-i-m2m, https://www.comnews.ru/content/231724/2024-02-26/2024-w09/1008/rosstandart-utverdil-pervyy-otechestvennyy-kriptoprotokol-urovne-standarta): LoRaWAN RU, NB-Fi, OpenUNB, OpenRAN.
Какой международный протокол закрывает ту же нишу, что и CRISP - передачу в том числе небольших сообщений с минимальным оверхедом?
Я сейчас не припоминаю его международных общераспространенных аналогов. Хотя и не исключаю, что они есть.
Есть как минимум один стандартизированный формат сообщений для SCADA системы с поддержкой криптографической подписи, целостности и шифрования как на фиксированных симметричных, заранее распределяемых ключах (как CRISP), так и на асимметричных алгоритмах.
Сейчас я уже не помню на память номера международных стандартов, но по моему что-то из электроэнергетики.
Я уже плохо помню предысторию создания CRISP, но, вроде, альтернативные на тот момент варианты там рассматривались - и были признаны неподходящими по тем или иным причинам. Например - из-за размера оверхеда.
Не исключаю варианта, что сейчас он выбран именно из-за наличия отечественных решений.
Плюс криптонаборы 3 и 4 (точнее, расширение на них) позволяет адресовать защищенное сообщение группе.
Не припоминаю, была ли такая возможность у тех международных протоколов, которые я тогда смотрел.
Но это было достаточно давно, и контекст CRISP (и SIES, особенно Core) мной изрядно подзабыт.
Протокол защищенного обмена для индустриальных систем CRISP: поддержка в устройствах Рутокен