Безопасность с Microsoft

Security, Identity and Access Management

Обновление для минимальной длины ключа RSA

Обновление для минимальной длины ключа RSA

  • Comments 4
  • Likes

Обновление для минимальной длины
ключа RSA

Уважаемые читатели, этим постом хотим привлечь ваше внимание к информации,
опубликованной по адресу http://technet.microsoft.com/ru-ru/security/advisory/2661254. Многие из вас, наверняка, уже не только
прочитали эту новость, но и предприняли необходимые действия.

Тем не менее, публикуем краткое напоминание на случай, если кто-то
пропустил данную информацию – ведь октябрь уже не за горой.

Речь идет о запрете использования ключей алгоритма RSA длиной меньше 1024 бит: после установки
обновления операционная система Microsoft Windows перестанет
доверять сертификатам, длина ключа которых меньше 1024 бит. Такие ключи теперь
считаются «слабыми» и не способны обеспечить современного уровня защищенности. Статья
предупреждает о возможных последствиях и предлагает информацию, позволяющую
пользователям заблаговременно оценить влияние данного обновления на развернутые
приложения и своевременно предпринять необходимые подготовительные меры. Данные
изменения относятся к сертификатам X.509 и не затрагивают RMS инфраструктуру, которая использует
сертификаты другого формата (XrML). Кстати сказать, в AD RMS не так давно тоже был проведен ряд улучшений в части используемой криптографии и возможная длина
RSA ключа увеличена с 1024 бит на 2048.

Ужесточение требований к длине ключа - это естественный процесс нашей
современной реальности. Вычислительные мощности год от года растут, а время, за
которое атакующий может вычислить ключ «в лоб» простым перебором, - сокращается.
Это отражается на длине ключей симметричных и несимметричных криптографических алгоритмов,
которая неуклонно увеличивалась на протяжении последних десятилетий. Косвенным
следствием этого процесса явилось также развитие новых разделов криптографии
(например, криптография эллиптических кривых), предъявляющих другие требования
к длине ключей.

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

  • Использовать AES для симметричного шифрования/дешифрования,
  • Симметричные ключи должны быть не менее 128 бит,
  • Использовать RSA для ассиметричного шифрования/дешифрования или цифровой подписи.
  • RSA ключи должны быть не менее 2048 бит,
  • Использовать SHA-256 или лучше при вычислении хешей или кода проверки подлинности (MAC),
  • Обеспечивать отзыв сертификатов,
  • Ограничивать время жизни симметричных и ассиметричных ключей, не использующих сертификаты,
  • Поддерживать криптографически стойкие версии проткола SSL/TLS,
  • Обоснованно выбирать время действия сертификатов,
  • При установлении TLS-соединений проверять атрибут Common Name/Subject Alternative Name на соответствие имени хоста, с которым
    планируется установить соединение.

Требования должны учитывать современные угрозы, регулярно обновляться, не
противоречить принятым стандартам и требованиям регуляторов. В России регулятором
в области криптографии является Федеральная Служба Безопасности РФ, а российские
криптографические стандарты ГОСТ Р 34.10-2001, ГОСТ Р 34.11-94, ГОСТ 28147-89
содержат описания алгоритмов формирования и проверки электронной цифровой
подписи,  вычисления хеш-функции и
симметричного шифрования.

Comments
  • <TrollMode=On>

    Вот из-за первых 5 требований SDL мы и имеем проблему под названием "Crypto Agility case" :(

    </TrollMode=Off>

  • Только к теме Crypto Agility эти требования не имею прямого отношения ;)

    "Never hardcode specific algorithms or implementations of those algorithms into your application."

    Неплохая статья по этой теме msdn.microsoft.com/.../ee321570.aspx

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

    Статья это, конечно, хорошо. Но вот только SDE их похоже не читают, а в лучшем случае руководствуются Microsoft SDL Process Guidance. Открываем этот документ (Version 5.2 page 26) и видим ровно то, что написал Андрей, священную мантру "SHA/RSA/AES". Ничего про "Never hardcore..." там нет ;)

  • Похоже директива </TrollMode=Off> не сработала :)

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

    Да, про это нужно говорить разработчикам, писать статьи и документы, включать в требования, процессы, методологии и курсы. И только так мы победим! :)

    А SDL – это большой шаг в правильном направлении.

    Возвращаясь к примерам (источник blogs.msdn.com/.../a-gritty-policy.aspx ):

    SHA512Cng sha = new SHA512Cng(); // not agile!

    HashAlgorithm hash = HashAlgorithm.Create(“SHA512”); // more agile

    HashAlgorithm hash = HashAlgorithm.Create(“MyApplication_PreferredHash”); // most agile, “MyApplication_PreferredHash” defined in config file

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment