Рекомендации по шифрованию Microsoft SDL

  • Статья

Введение

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

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

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

Версии SSL/TLS

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

  • Необходимо включить протокол TLS 1.2.

  • Протоколы TLS 1.1 и TLS 1.0 должны быть включены только для обратной совместимости

  • SSL 3 и SSL 2 должны быть отключены по умолчанию

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

Блочные шифры

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

  • для нового кода требуется алгоритм AES;

  • для обеспечения обратной совместимости с существующим кодом приемлем алгоритм 3DES с тремя ключами;

  • все другие алгоритмы блочного шифрования, в том числе RC2, DES, 3DES с двумя ключами, DESX и Skipjack, необходимо использовать только для расшифровки старых данных и заменяться при шифровании.

Для алгоритмов симметричного блочного шифрования рекомендуется минимальная длина ключа 128 бит. Для нового кода рекомендуется использовать только алгоритм блочного шифрования AES (применяются все AES-128, AES-192 и AES-256, что означает, что AES-192 не имеет оптимизации для некоторых процессоров). Алгоритм 3DES с тремя ключами допустим, если он уже используется в имеющемся коде. Рекомендуется перейти на использование AES. DES, DESX, RC2 и Skipjack больше не считаются безопасными. Эти алгоритмы должны использоваться, только чтобы расшифровывать имеющиеся данные для обеспечения обратной совместимости, после чего данные необходимо повторно зашифровать с помощью рекомендуемого алгоритма блочного шифрования.

Режимы шифрования

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

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

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

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

  • Режим шифрования с обратной связью по шифру (CFB)

  • Счетчик (центр)

  • Счетчик с CBC-MAC (CCM)

  • Режим Галуа/счетчик (GCM)

  • Что-то еще не в списке "Рекомендуемые" выше

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

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

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

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

RSA

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

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

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

  • Ключи >= рекомендуется использовать ключи = 2048 бит

ECDSA

  • Рекомендуется использовать ECDSA >= с 256-разрядными ключами

  • Сигнатуры на основе ECDSA должны использовать одну из трех утвержденных NIST-кривых (P-256, P-384 или P521).

ECDH

  • Рекомендуется использовать ECDH >= с 256-разрядными ключами

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

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

  • Рекомендуемая длина ключа >= 2048 бит

  • Параметры группы должны быть хорошо известными именованными группами (например, RFC 7919) или созданы доверенной стороной и прошли проверку подлинности перед использованием

Время жизни ключа

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

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

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

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

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

CNG

  • Использование BCryptGenRandom с флагом BCRYPT_USE_SYSTEM_PREFERRED_RNG

CAPI

  • Для создания случайных значений используйте CryptGenRandom.

Win32/64

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

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

  • Функция C Rand_s() также рекомендуется (которая в Windows вызывает CryptGenRandom)

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

  • Для кода режима ядра рекомендуется использовать функцию SystemPrng.

.NET

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

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

  • К небезопасным функциям, связанным с генерацией случайных чисел, относятся: rand,System.Random (.NET), GetTickCount и GetTickCount64

  • Не рекомендуется использовать алгоритм случайных чисел с двойной эллиптической кривой ("DUAL_EC_DRBG") алгоритма.

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

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

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

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

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

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

Машинный код

  • Примитивы шифрования: если ваш выпуск работает в Windows или Windows Phone, используйте CNG, если это возможно. В противном случае используйте интерфейс CryptoAPI (также называемый CAPI, который поддерживается в качестве устаревшего компонента в Windows из Windows Vista).

  • SSL/TLS/DTLS. WinINet,WinHTTP,Schannel,IXMLHTTPRequest2 или IXMLHTTPRequest3.

    • Приложения WinHTTP должны строиться с параметром WinHttpSetOption для поддержки TLS 1.2

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

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

Управляемый код

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

  • Установите последнюю версию .NET Framework. Как минимум это должна быть платформа .NET Framework версии 4.6. Если требуется более старая версия, убедитесь, что в окне "SchUseStrongCrypto" установлен флажок "Включить TLS 1.2 для рассматриваемого приложения".

  • Проверка сертификата. Используйте интерфейсы API, определенные в пространстве имен System.Security.Cryptography.X509Certificates.

  • SSL/TLS/DTLS. Используйте интерфейсы API, определенные в пространстве имен System.Net (например, HttpWebRequest).

Функции формирования ключа

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

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

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

  • Директива NIST SP 800-56A (редакция 2). Рекомендации для схем установки парных ключей с использованием дискретного логарифмического шифрования. В частности, рекомендуется использовать "функцию одноэтапного формирования ключей" в разделе 5.8.1.

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

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM

  • BCRYPT_SP80056A_CONCAT_ALGORITHM

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

  • BCRYPT_KDF_SP80056A_CONCAT

  • BCRYPT_KDF_HMAC

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

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

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

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

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

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

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

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

Клиенты, которые доверяют "самозаверяющим" сертификатам (например, почтовый клиент, подключающийся к серверу Exchange в конфигурации по умолчанию), могут пропускать проверку сертификатов. Однако самозаверяющие сертификаты, по сути, не передают доверия, поддерживают отзыв или продление срока действия ключей. Доверять самозаверяющим сертификатам следует только в том случае, если они получены из другого доверенного источника (например, доверенной сущности, предоставляющей сертификат через транспорт с проверкой подлинности и являющийся целостно-защищенным).

Криптографические хэш-функции

Продукты должны использовать семейство алгоритмов хэширования SHA-2 (SHA256, SHA384 и SHA512). Усечение криптографических хэшей менее 128 бит в целях безопасности не допускается.

Алгоритмы хэширования MAC/HMAC/ключевые

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

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

Не рекомендуется усечение хэш-функции HMAC менее 128 бит.

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

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

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

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

  • Не используйте симметричные потоковые шифры, такие как RC4. Вместо них продукты должны использовать блочные шифры, в частности алгоритм AES с длиной ключа не менее 128 бит.

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

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

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

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

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

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

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

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

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

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

Шифрование конфиденциальных данных до хранилища

DPAPI/DPAPI-NG

Данные, которые необходимо сохранить при перезагрузке системы:

  • CryptProtectData

  • CryptUnprotectData

  • NCryptProtectSecret (Windows 8 CNG DPAPI)

Данные, которые не нужно сохранять при перезагрузке системы:

  • CryptProtectMemory

  • CryptUnprotectMemory

Данные, которые должны быть сохранены и доступны нескольким учетным записям домена и компьютерам:

SQL Server TDE

Для защиты конфиденциальных данных можно использовать прозрачное шифрование данных (TDE) сервера SQL Server.

Следует использовать ключ шифрования базы данных TDE (DEK), который соответствует требованиям алгоритма шифрования SDL и стойкости ключа. В настоящее время рекомендуется использовать только AES_128, AES_192 и AES_256; TRIPLE_DES_3KEY не рекомендуется.

Существует ряд важных вопросов, касающихся использования SQL TDE, о которых следует помнить.

Управление учетными данными

Используйте API диспетчера учетных данных Windows или Microsoft Azure KeyVault, чтобы защитить пароли и учетные данные.

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

Используйте классы в пространствах имен Windows.Security.Cryptography и Windows.Security.Cryptography.DataProtection для защиты секретов и конфиденциальных данных.

  • ProtectAsync

  • ProtectStreamAsync

  • UnprotectAsync

  • UnprotectStreamAsync

Используйте классы в пространстве имен Windows.Security.Credentials для защиты паролей и учетных данных.

.NET

Данные, которые необходимо сохранить при перезагрузке системы:

  • ProtectedData.Protect

  • ProtectedData.Unprotect

Данные, которые не нужно сохранять при перезагрузке системы:

  • ProtectedMemory.Protect

  • ProtectedMemory.Unprotect

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

либо RSAProtectedConfigurationProvider, либо DPAPIProtectedConfigurationProvider для защиты конфигурации с помощью либо шифрования RSA, либо DPAPI соответственно.

RSAProtectedConfigurationProvider можно использовать на нескольких компьютерах в кластере. См. статью Шифрование сведений о конфигурации с помощью функции защищенной конфигурации.