Криптоалгоритмы

На этой странице собрана сводная информация о криптографических механизмах Stronghold:

• какие алгоритмы используются для TLS;
• как шифруются данные в хранилище;
• как HSM дополняет встроенное шифрование;
• какие алгоритмы доступны в PKI;
• какие алгоритмы доступны в Transit.

Краткая сводка

ГОСТ-алгоритмы

Stronghold поддерживает сценарии, где требуется использование ГОСТ-криптографии:

• в TLS поддерживается TLS 1.3 с проверкой сертификатов на ключах ГОСТ 34.10, а также с использованием ГОСТ-шифрования Магма и Кузнечик;
• механизм PKI поддерживает выпуск сертификатов с ключами ГОСТ 34.10;
• механизм Transit поддерживает подпись с помощью асимметричных ключей ГОСТ 34.10, а также шифрование с помощью симметричных алгоритмов ГОСТ 34.12 (Магма, Кузнечик) и ГОСТ 28147-89;
• при использовании Managed Keys и HSM, поддерживающих ГОСТ-криптографию, сохраняется возможность работы не только с RSA, но и с ключами и сертификатами на базе поддерживаемых ГОСТ-алгоритмов.

TLS: версии, наборы шифров и проверка сертификатов

TLS для API Stronghold настраивается в секции listener "tcp" через параметры Standalone-конфигурации.

Поддерживаемые версии TLS

Параметры tls_min_version и tls_max_version поддерживают значения:

• tls10;
• tls11;
• tls12;
• tls13.

Для production-сред рекомендуется использовать только TLS 1.2 и TLS 1.3.

Поддерживаемые наборы шифров

Параметр tls_cipher_suites позволяет явно задать список шифров для TLS 1.2 и более ранних версий.

Важно учитывать:

• tls_cipher_suites не влияет на TLS 1.3; для TLS 1.3 наборы шифров определяются реализацией Go TLS;
• имена допустимых шифров соответствуют списку из Go crypto/tls;
• если указать только наборы шифров, запрещённые спецификацией HTTP/2, CLI и другие клиенты на базе net/http могут работать некорректно.

Практический подход:

• ограничить tls_min_version значением tls12;
• задавать tls_cipher_suites только при наличии требований ИБ или совместимости;
• после изменения набора шифров проверять работу CLI, UI и балансировщиков.

Проверка сертификатов

Stronghold поддерживает несколько уровней проверки TLS-сертификатов:

• tls_cert_file и tls_key_file задают серверный сертификат и приватный ключ;
• в tls_cert_file можно передать полную цепочку PEM, где сертификат узла должен идти первым;
• tls_require_and_verify_client_cert = true включает обязательную проверку клиентских сертификатов;
• tls_client_ca_file задаёт CA-файл, по которому Stronghold проверяет клиентские сертификаты;
• tls_disable_client_certs = true полностью отключает проверку клиентских сертификатов.

В средах, где используется ГОСТ-криптография, Stronghold поддерживает TLS 1.3 с проверкой сертификатов ГОСТ 34.10, а также TLS-шифрование на алгоритмах Магма и Кузнечик.

Шифрование хранилища

Stronghold защищает данные в хранилище встроенным криптографическим барьером на основе AES-256-GCM.

Это означает:

• для шифрования данных в хранилище используется AES-GCM с 256-битным ключом;
• барьер обеспечивает не только конфиденциальность, но и контроль целостности данных;
• для каждой записи используется отдельный nonce; стандартный размер GCM nonce составляет 96 бит (12 байт);
• Stronghold поддерживает ротацию ключей барьера, поэтому новые записи могут шифроваться новым ключом без потери доступа к ранее сохранённым данным.

Шифрование барьером работает поверх выбранного storage backend-а. Поэтому независимо от того, используется raft, filesystem, etcd или postgresql, в физическое хранилище записываются уже зашифрованные значения Stronghold.

Важно различать:

• криптографическую защиту данных Stronghold, которую обеспечивает барьер AES-256-GCM;
• операционные процедуры резервного копирования storage backend-а, которые остаются зоной ответственности администратора.

Дополнительное шифрование через HSM

Поддержка HSM не заменяет встроенный барьер AES-256-GCM, а дополняет его.

В типовом сценарии:

• данные в storage backend-е продолжают защищаться барьером Stronghold;
• root key и операции распечатывания могут быть защищены через seal "pkcs11" и внешний HSM;
• для части критичных внутренних данных может использоваться дополнительное шифрование через seal wrap.

Таким образом, Stronghold использует несколько уровней защиты:

1. встроенное шифрование хранилища через AES-256-GCM;
2. защиту root key и auto-unseal через HSM;
3. при необходимости дополнительную seal wrap-обёртку для наиболее чувствительных значений.

Если HSM или внешний ключевой провайдер поддерживает ГОСТ-криптографию, этот подход сохраняется и для сценариев с ГОСТ-ключами: внешний модуль защищает ключевой материал, а Stronghold продолжает использовать его в PKI, Transit и связанных криптографических операциях.

Подробнее:

• Поддержка HSM
• Двойное шифрование

Алгоритмы в PKI

Механизм секретов PKI отвечает за выпуск и подпись сертификатов X.509.

При настройке ролей и генерации ключей доступны следующие типы ключей:

• rsa;
• ec;
• ed25519;
• gost3410;

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

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

• для rsa: 2048, 3072, 4096;
• для ec: 224, 256, 384, 521;
• для ed25519 параметр key_bits не используется;
• для ГОСТ-параметров тип ключа уже определяет соответствующий набор параметров.

Для алгоритма подписи параметр signature_bits поддерживает:

• 256 для SHA-2-256;
• 384 для SHA-2-384;
• 512 для SHA-2-512.

Если signature_bits не задан, Stronghold подбирает значение автоматически:

• для RSA используется SHA-2-256;
• для NIST P-Curves выбирается хеш, соответствующий размеру кривой.

Практически это означает, что PKI в Stronghold покрывает типовые корпоративные сценарии с RSA и EC, современные сценарии с Ed25519, а также инфраструктуры, где требуется использование поддерживаемых ГОСТ-алгоритмов.

В частности, PKI поддерживает выпуск сертификатов с ключами ГОСТ 34.10, включая поддерживаемые наборы параметров 256 и 512 бит.

Подробнее о настройке PKI см. раздел Механизм секретов PKI.

Алгоритмы в Transit

Transit предоставляет криптографические операции как сервис: шифрование, дешифрование, подпись, проверку подписи, HMAC, хеширование и операции с data keys.

Основные типы ключей Transit

Симметричные алгоритмы шифрования:

• aes128-gcm96;
• aes256-gcm96 - значение по умолчанию;
• chacha20-poly1305;
• gost28147;
• gost341264;
• gost3412128.

Асимметричные алгоритмы подписи и, для части случаев, шифрования:

• ecdsa-p256;
• ecdsa-p384;
• ecdsa-p521;
• ed25519;
• rsa-2048;
• rsa-3072;
• rsa-4096;
• gost3410.

Специализированные типы:

• hmac для HMAC-операций;
• managed_key для операций через внешний managed key, если он предварительно настроен.

Тип managed_key не является отдельным алгоритмом шифрования: в этом режиме Transit использует заранее настроенный внешний ключевой источник.

Если managed_key указывает на HSM или другой внешний провайдер с поддержкой ГОСТ-криптографии, Transit может использовать и внешние ГОСТ-ключи.

Какие операции доступны

• aes128-gcm96, aes256-gcm96, chacha20-poly1305 и поддерживаемые симметричные GOST-типы подходят для encrypt / decrypt;
• RSA подходит для encrypt / decrypt, а также sign / verify;
• ECDSA, Ed25519 и поддерживаемые асимметричные GOST-типы используются для sign / verify;
• все типы ключей могут использоваться в HMAC-сценариях через отдельный HMAC-ключ, который Transit ведёт вместе с основным ключом;
• тип hmac предназначен только для HMAC-операций.

Для ГОСТ-сценариев это означает:

• gost3410-* используется для операций sign / verify;
• gost3412128 и gost341264 соответствуют симметричным алгоритмам ГОСТ 34.12 (Кузнечик и Магма);
• gost28147 покрывает сценарии с ГОСТ 28147-89.

Для RSA в Transit используются:

• OAEP для шифрования и дешифрования;
• PSS для подписи и проверки подписи;
• PKCS#1 v1.5 для подписи и проверки подписи.

Для симметричных ключей поддерживаются производные ключи, а для некоторых типов - конвергентное шифрование. Для AES-GCM Stronghold рекомендует регулярную ротацию ключей в зависимости от нагрузки.

Подробнее о возможностях Transit см. раздел Механизм секретов Transit.

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

• Для публичного и межсервисного API устанавливайте tls_min_version = "tls12" или выше.
• Не ограничивайте tls_cipher_suites без явной причины: это может неожиданно повлиять на совместимость клиентов.
• Рассматривайте HSM как дополнительный уровень защиты, а не как замену встроенному шифрованию Stronghold.
• Для PKI заранее стандартизируйте допустимые типы ключей и длины ключей на уровне ролей.
• Для Transit определяйте допустимые типы ключей отдельно по сценариям: симметричное шифрование, подпись, HMAC, BYOK, managed keys.