Поделиться через

Рекомендации по криптографии Microsoft SDL

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

Разработчики на платформах, отличных от Windows, могут воспользоваться этими рекомендациями. Хотя имена API и библиотеки могут отличаться, рекомендации по выбору алгоритма, длине ключа и защите данных похожи на разные платформы.

Рекомендации по протоколу безопасности, алгоритму и длине ключа

Версии TLS/SSL

Продукты и службы должны использовать криптографически безопасные версии TLS/SSL:

  • Протокол TLS 1.3 должен быть включен

  • Протокол TLS 1.2 можно включить для улучшения совместимости со старыми клиентами.

  • Tls 1.1, TLS 1.0, SSL 3 и SSL 2 должны быть отключены

Симметричные блочные шифры, режимы шифров и векторы инициализации

Блокировать шифры

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

  • Требуется расширенный стандарт шифрования (AES).

  • При использовании шифрования необходимо заменить все остальные блочные шифры, включая 3DES (Triple DES/TDEA) и RC4.

Для алгоритмов шифрования симметричного блока рекомендуется поддерживать 256-разрядные ключи, но разрешать до 128-разрядных. Единственный алгоритм блочного шифрования, рекомендуемый для нового кода, это AES (AES-128, AES-192 и AES-256 — все они приемлемы), при этом следует отметить, что AES-192 не хватает оптимизации на некоторых процессорах.

Режимы шифров

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

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

Некоторые другие режимы шифров, такие как те, которые следуют, имеют недостатки реализации, которые делают их более вероятными для неправильного использования. В частности, необходимо избежать режима работы электронной кодовой книги (ECB). Повторное использование того же вектора инициализации (IV) с блочных шифров в "режимах потоковой передачи шифров", таких как CTR, может привести к обнаружению зашифрованных данных. Рекомендуется использовать дополнительные проверки безопасности, если используется любой из следующих режимов:

  • Режим обратной связи по выходу (OFB)

  • Обратная связь с шифрами (CFB)

  • Счетчик (CTR)

  • Что-либо другое, не указанное выше в приведенном выше списке "рекомендуемые"

Векторы инициализации (IV)

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

Векторы инициализации никогда не следует повторно использовать при выполнении нескольких операций шифрования. Повторное использование может выявить сведения о зашифрованных данных, особенно при использовании режимов потоковой передачи, таких как обратная связь вывода (OFB) или счетчик (CTR).

рекомендации по AES-GCM и AES-CCM

AES-GCM (режим галуа или счетчика) и AES-CCM (счетчик с CBC-MAC) широко используются режимы шифрования, прошедшие проверку подлинности. Они объединяют конфиденциальность и защиту целостности, что делает их полезными для безопасного взаимодействия. Однако их хрупкость лежит в неиспользование повторного использования. Если один и тот же вектор инициализации используется дважды, он может привести к катастрофическим последствиям.

Рекомендуется следовать руководствам, описанным в NIST SP 800-38D, Рекомендации по режимам блочного шифрования: режим Галоа/счетчика (GCM) и GMAC, уделяя особое внимание разделам 8.1, 8.2 и 8.3 в отношении требований к уникальности для ключа и nonce/IV.

Другим вариантом будет создание уникальных ключей AES-GCM/CCM для каждого зашифрованного сообщения, что позволяет эффективно ограничить максимальное количество вызовов до 1. Этот подход рекомендуется для шифрования данных, находящихся в состоянии покоя, где использование счётчика или обеспечение возможности отслеживания максимального количества вызовов для заданного ключа будет нецелесообразным.

Для шифрования неактивных данных также можно использовать AES-CBC с кодом проверки подлинности сообщений (MAC) в качестве альтернативы с помощью схемы Encrypt-then-MAC, что гарантирует использование отдельных ключей для шифрования и MAC.

Проверка целостности

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

Если вы не можете использовать алгоритм шифрования, прошедший проверку подлинности, с связанными данными (AEAD), например AES-GCM, можно было бы проверить целостность с помощью кода проверки подлинности сообщений (MAC) с помощью схемы Encrypt-then-MAC, убедившись, что для шифрования и MAC используются отдельные ключи.

Использование отдельного ключа для шифрования и для MAC является важным. Если невозможно сохранить два ключа, допустимая альтернатива состоит в том, чтобы наследовать два ключа из основного ключа с помощью подходящей функции извлечения ключей (KDF), одной для целей шифрования и одной для MAC. Дополнительные сведения см. в разделе [SP 800-108 ред. 1, рекомендация по производению ключей с помощью псевдорандомных функций | CSRC (nist.gov)](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf).

Асимметричные алгоритмы, длины ключей и режимы заполнения

RSA

  • RSA можно использовать для транспорта ключей, обмена ключами и подписей.

  • Шифрование RSA должно использовать режимы заполнения OAEP или RSA-PSS.

  • Существующий код может использовать режим заполнения PKCS #1 v1.5 для подписания.

  • Использование PKCS#1 версии 1.5 для шифрования запрещено.

  • Не рекомендуется использовать нулевое заполнение.

  • 2048-разрядная длина ключа является минимальной, но мы рекомендуем поддерживать длину ключа 3072-разрядной.

ECDSA и ECDH

  • Обмен ключами на основе ECDH и подписи на основе ECDSA должны использовать одну из трех утвержденных NIST кривых (P-256, P-384 или P521).

  • Поддержка P-256 должна считаться минимальной, но рекомендуется поддерживать P-384.

ML-DSA

  • Необходимо использовать стандарт FIPS 204. Не используйте версии в проекте стандарта.

  • Рекомендуется использовать ML-DSA в сочетании с классическим алгоритмом подписи (т. е. ECDSA или RSA). Использование сочетаний, определенных IETF (проект) или другими стандартами, предпочтительнее для взаимодействия.

  • Для ML-DSA допустимый гибридный (составной) механизм заключается в том, чтобы подписать одни и те же данные как с помощью классического метода, так и ML-DSA, и проверить оба (если любая проверка завершается ошибкой, то проверка считается неуспешной).

ML-KEM

  • Необходимо использовать стандарт FIPS 203. Не используйте версии в проекте стандарта.

  • Рекомендуется использовать комбинатор или гибридную криптосистему, сочетающую ML-KEM и классический алгоритм KEM (т. е. ECDH). Использование сочетаний, определенных IETF (проект) или другими стандартами, предпочтительнее для взаимодействия.

SLH-DSA

  • Должен использовать стандарт FIPS 205. Не используйте версии в проекте стандарта.

  • Разрешены все наборы параметров SLH-DSA, но рекомендуемый набор параметров будет зависеть от варианта использования.

  • Нет известного различия между версиями SHA-2 и SHAKE (SHA-3)

LMS и XMSS

  • Поддержка LMS или XMSS безопасна для проверки подписи.

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

Целочисленный Diffie-Hellman

  • Хотя Integer Diffie-Hellman (DH) одобрен для обмена ключами, он не является самым эффективным по современным стандартам. Вместо этого настоятельно рекомендуется использовать ECDH.
  • Длина >ключа = 2048 бит рекомендуется
  • Параметры группы должны быть хорошо известной именованной группой (например, RFC 7919), или создаваться доверенным участником и проходить проверку подлинности перед использованием.

Время существования ключа

  • Определите криптопериод для всех ключей.

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

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

Генераторы случайных чисел

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

CNG

  • Используйте BCryptGenRandom с флагом BCRYPT_USE_SYSTEM_PREFERRED_RNG.

Win32/64

  • Устаревший код может использовать RtlGenRandom в режиме ядра.

  • Новый код должен использовать BCryptGenRandom или CryptGenRandom.

  • Также рекомендуется использовать функцию C Rand_s(), которая в Windows вызывает CryptGenRandom.

  • Rand_s() является безопасной и производительной заменой для Rand().

  • Rand() не должен использоваться для каких-либо криптографических приложений.

.NET

PowerShell

Приложения Магазина Windows

Поддерживаемые платформой Windows библиотеки шифрования

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

Любое решение относительно использования платформенной и неплатформенной криптовалюты должно соответствовать следующим требованиям:

  • Библиотека должна быть поддерживаемой текущей версией без известных уязвимостей безопасности.

  • Должны поддерживаться последние протоколы безопасности, алгоритмы и длины ключей.

  • (Необязательно) Библиотека должна поддерживать более старые протоколы и алгоритмы безопасности только для обратной совместимости.

Нативный код

  • Примитивы криптографии: Если релиз должен работать на Windows, используйте CNG, если возможно.

  • Проверка подписи кода: WinVerifyTrust — это поддерживаемый API для проверки подписей кода на платформах Windows.

  • Проверка сертификатов (как используется в проверке ограниченного сертификата для подписывания кода или TLS/DTLS): API CAPI2; например , CertGetCertificateChain и CertVerifyCertificateChainPolicy.

Функции генерации ключей

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

Следующие стандарты указывают функции KDF, рекомендуемые для использования:

  • NIST SP 800-108 (редакция 1): рекомендация по производению ключей с помощью псевдорандомных функций. В частности, KDF в режиме счетчика с HMAC в качестве псевдорандомной функции

  • NIST SP 800-56A (редакция 3): рекомендация по схемам установления парных ключей с использованием криптографии на основе дискретного логарифма.

Чтобы получить ключи от существующих ключей, используйте API BCryptKeyDerivation с одним из алгоритмов:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM

  • BCRYPT_SP80056A_CONCAT_ALGORITHM

Чтобы получить ключи из общего секрета (выходные данные соглашения ключа), используйте API BCryptDeriveKey с одним из следующих алгоритмов:

  • BCRYPT_KDF_SP80056A_CONCAT

  • BCRYPT_KDF_HMAC

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

Продукты, использующие TLS или DTLS, должны полностью проверить сертификаты X.509 сущностей, к которым они подключаются. Этот процесс включает проверку следующих частей сертификата:

  • Доменное имя.

  • Срок действия (как даты начала, так и окончания срока действия).

  • Состояние отзыва.

  • Использование (например, "Проверка подлинности сервера" для серверов, "Проверка подлинности клиента" для клиентов).

  • Цепочка доверия. Сертификаты должны быть связаны с корневым центром сертификации (ЦС), доверенным платформой или явно настроенным администратором.

Если какой-либо из этих тестов проверки не пройдет, продукт должен прервать подключение с объектом.

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

Функции хэша шифрования

Продукты должны использовать семейство хэш-алгоритмов SHA-2 (SHA-256, SHA-384 и SHA-512). Запрещается усечение криптографических хэшей для целей безопасности до длины менее 128 бит. Хотя использование SHA-256 является минимальным, рекомендуется поддерживать SHA-384.

Хэш-алгоритмы MAC/HMAC/с ключом

Код проверки подлинности сообщения (MAC) — это часть информации, присоединенной к сообщению, которая позволяет получателю проверить подлинность отправителя и целостность сообщения с помощью секретного ключа.

Использование MAC на основе хэша (HMAC) или блочного шифрования на основе MAC рекомендуется, если для использования также рекомендуется использовать все базовые хэш-алгоритмы или симметричные алгоритмы шифрования; В настоящее время это включает функции HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 и HMAC-SHA512). Хотя использование HMAC-SHA256 является минимальным, рекомендуется поддерживать HMAC-SHA384.

Усечение HMACs до уровня менее 128 бит не рекомендуется.

Рекомендации по проектированию и эксплуатации

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

    • При каждом продлении сертификата необходимо обновить его с помощью нового ключа (повторного доступа).

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

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

  • Не сообщайте о сбоях криптографической операции конечным пользователям. При возврате ошибки удаленному вызывающему объекту (например, веб-клиенту или клиенту в сценарии клиентского сервера) используйте только универсальное сообщение об ошибке.

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

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

    • Новый протокол, который в первую очередь ориентирован на безопасность (например, протокол проверки подлинности или авторизации)

    • Новый протокол, использующий криптографию в новом или нестандартном способе. Ниже приведены примеры рекомендаций.

      • Будет ли продукт, реализующий протокол, вызывать какие-либо API-интерфейсы или методы шифрования в рамках реализации протокола?

      • Зависит ли протокол от любого другого протокола, используемого для проверки подлинности или авторизации?

      • Определяет ли протокол форматы хранения для криптографических элементов, таких как ключи?

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

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