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

Статья
05/24/2024

Используйте эти сведения в качестве ссылки при разработке продуктов для использования одинаковых 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.

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

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

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

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

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

Режим шифрования с обратной связью по выходу (OFB)
Режим шифрования с обратной связью по шифру (CFB)
Счетчик (центр)
Что-либо еще не указано в предыдущем списке "рекомендуемые"

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

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

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

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

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

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

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

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

RSA

RSA можно использовать для шифрования, обмена ключами и подписей.
Алгоритм шифрования RSA должен использовать режимы OAEP или RSA-PSS.
Существующий код должен использовать PKCS #1 версии 1.5 для обеспечения совместимости.
Не рекомендуется использовать заполнение null.
Рекомендуется не менее 2048-разрядной длины ключа, но мы рекомендуем поддерживать длину ключа 3072-разрядной версии.

ECDSA и ECDH

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

Целочисленный алгоритм Диффи-Хеллмана

Длина >ключа = 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

Используйте RandomNumberGenerator.

PowerShell

Используйте Get-SecureRandom (PowerShell).

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

Приложения Магазина Windows могут использовать CryptographicBuffer.GenerateRandom или CryptographicBuffer.GenerateRandomNumber .

Linux/macOS

Устройство /dev/urandom предоставляет криптографически надежный источник случайных данных, как и системный getrandom(2) вызов.

Не рекомендуется

Небезопасные функции, связанные со случайным поколением чисел: rand, System.Random (.NET), GetTickCount, GetTickCount64 и Get-Random (командлет PowerShell).
Использование алгоритма двойного многоточия случайного числа ("DUAL_EC_DRBG") не допускается.

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

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

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

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

Машинный код

Примитивы шифрования. Если выпуск находится в Windows, используйте CNG, если это возможно.
Проверка сигнатуры кода. WinVerifyTrust — это поддерживаемый API для проверки сигнатур кода на платформах Windows.
Проверка сертификата (как используется в проверке ограниченного сертификата для подписывания кода или SSL/TLS/DTLS): API CAPI2; например, CertGetCertificateChain и CertVerifyCertificateChainPolicy.

Управляемый код (.NET)

Примитивы шифрования: используйте API, определенный в пространстве имен System.Security.Cryptography .
Используйте последнюю версию .NET.

Функции производных ключей

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

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

NIST SP 800-108 (редакция 1): рекомендация по производению ключей с помощью псевдорандомных функций. В частности, функция формирования ключа в режиме счетчика с 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 бит не рекомендуется.

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