Всероссийский сборник статей и публикаций института развития образования, повышения квалификации и переподготовки.

Горшков Максим Андреевич

Студент

ПРИМЕНЕНИЕ ХЕШ-ФУНКЦИЙ И ПОСТКВАНТОВЫХ ЦИФРОВЫХ ПОДПИСЕЙ В МОДУЛЕ КОНТРОЛЯ ЦЕЛОСТНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Аннотация:

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

Ключевые слова:

хеш-функция, контроль целостности, программное обеспечение, банковская информационная система, цифровая подпись, постквантовая криптография, ML-DSA, SLH-DSA, квантовые вычисления.

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

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

Квантовый компьютер работает с кубитами, а некоторые задачи решает иначе, чем классическая машина. Для безопасности особенно важны алгоритмы Шора и Гровера. Алгоритм Шора создает риск для RSA и части схем на эллиптических кривых. Алгоритм Гровера не отменяет хеш-функции, но уменьшает запас стойкости при переборе.

Ускорение перебора в квантовой модели можно записать так:

O(√N),

где O - оценка порядка сложности алгоритма, N - количество возможных вариантов, √N - квадратный корень из этого количества. Для контроля целостности это означает, что новые системы лучше проектировать с запасом длины хеша и поддержкой замены алгоритмов, например SHA-256, SHA-384 или SHA-512.

Хеш-функция как основа проверки

Криптографическая хеш-функция принимает данные произвольной длины и выдает значение фиксированной длины. В модуле контроля входом может быть исполняемый файл, библиотека, архив обновления, конфигурационный файл или контейнерный образ. Если в объекте изменится хотя бы один байт, корректная криптографическая хеш-функция должна выдать другое значение.

Для одного файла проверку можно записать так:

h_i = H(F_i),

где h_i - хеш-значение i-го файла, H - выбранная хеш-функция, F_i - i-й проверяемый файл, i - номер файла в контролируемом наборе. Например, F_i может быть платежным модулем, библиотекой авторизации или файлом настроек.

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

Манифест можно представить так:

M = {(path_i, h_i, v_i, c_i)},

где M - манифест контроля целостности, path_i - путь к i-му файлу, h_i - его хеш-значение, v_i - версия компонента, c_i - класс критичности объекта, i - номер записи. Класс критичности нужен для выбора реакции: изменение платежного модуля должно блокировать запуск, а изменение временного файла не должно попадать в эталонную базу.

Почему одного хеша недостаточно

Распространенная ошибка состоит в том, что файл с эталонными хешами считают полноценной защитой. На самом деле это защищает только от случайных изменений и простых сбоев. Если злоумышленник может заменить проверяемый файл и одновременно изменить список эталонов, модуль увидит совпадение. Формально проверка пройдет, хотя контроль уже потерян.

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

Создание подписи можно записать так:

s = Sign_sk(H(M)),

где s - цифровая подпись манифеста, Sign - операция создания подписи, sk - закрытый ключ подписанта, H(M) - хеш от манифеста M. Закрытый ключ должен находиться не на продуктивном сервере, а в доверенной среде выпуска релизов.

Проверка подписи выглядит так:

Verify_pk(H(M), s) = true,

где Verify - операция проверки подписи, pk - открытый ключ, H(M) - хеш манифеста, s - подпись, true - положительный результат проверки. На сервере эксплуатации достаточно хранить открытый ключ, но и его нужно защищать от подмены.

Постквантовые подписи в модуле

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

В качестве практических вариантов можно рассматривать ML-DSA и SLH-DSA, стандартизованные NIST. ML-DSA основан на решеточных задачах и подходит как основной вариант для подписи манифестов релизов, списков разрешенных хешей и политик контроля. Его ключи и подписи больше, чем у привычных схем на эллиптических кривых, но для манифестов это обычно не критично.

SLH-DSA является хеш-ориентированной подписью без состояния. Для контроля целостности это логично, потому что сама система уже опирается на хеширование. Такой вариант может применяться для особо важных и редко изменяемых данных: корневых политик, списков доверенных ключей или базовых манифестов. Его недостаток - более крупные подписи и меньшая скорость.

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

Практическая схема работы

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

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

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

Проверка на типовых сценариях

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

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

В результате хеш-функции остаются основой фиксации состояния программных компонентов, но в банковской системе их необходимо применять вместе с подписью эталонного манифеста. Квантовые вычисления не отменяют контроль целостности, но влияют на выбор подписи и запас криптографической стойкости. Наиболее обоснованной является архитектура, где хеши файлов защищаются подписанным манифестом, а алгоритм подписи выбирается с учетом постквантовых стандартов ML-DSA и SLH-DSA. Такой модуль позволяет обнаруживать подмену файлов, защищать эталонные значения от изменения и сохранять устойчивость для длительной эксплуатации банковской информационной системы.

Список используемых источников

1. Williams, C. P. Explorations in Quantum Computing. Second Edition. - London: Springer, 2011.

2. Chang, W.-L., Vasilakos, A. V. Fundamentals of Quantum Programming in IBM’s Quantum Computers. - Cham: Springer Nature Switzerland AG, 2021.

3. Хидари, Дж. Д. Квантовые вычисления: прикладной подход / пер. с англ. В. А. Яроцкого. - М.: ДМК Пресс, 2021. - 370 с.

4. Нильсен, М., Чанг, И. Квантовые вычисления и квантовая информация / пер. с англ. - М.: Мир, 2006. - 824 с.

5. National Institute of Standards and Technology. FIPS 204: Module-Lattice-Based Digital Signature Standard. - 2024.

6. National Institute of Standards and Technology. FIPS 205: Stateless Hash-Based Digital Signature Standard. - 2024.