falbar Все, что нужно знать о переходе от SHA-1 к SHA-2

Все, что нужно знать о переходе от SHA-1 к SHA-2

23 октября 2018 Перевод 153 0

Индустрией PKI (инфрастуктуры открытых ключей) рекомендовано, чтобы для каждого элемента с SHA-1 осуществлялся переход на SHA-2, который считается более безопасным. Ниже рассказаны причины такого требования и алгоритм действий для его выполнения.

Реклама

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

Во многих девайсах и приложениях, в которых используются электронные сертификаты, уже начали появляться предупреждения и ошибки, а некоторые из этих вещей и просто могут прекратить работу. Это происходит, если используется SHA-1 хеширование (или более старое). Скоро так будет со всеми устройствами и приложениями. Почему же этот переход принудителен? Потому что стало известно, что SHA-1 имеет криптографические недостатки, из-за чего больше не может осуществлять надежную защиту.

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

Что такое хеш?

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

Сервисы центра сертификации (ЦС) инфраструктуры открытых ключей (ИОК) используют криптографические хеши для подтверждения идентификации и запросов от цифровых сертификатов. С помощью этой же технологии они подтверждают (например, используя подпись) цифровые сертификаты и списки аннулированных сертификатов, которые назначаются другими доверенными сторонами (например, компьютеры, софт, пользователи и т. д.). Если криптографический хеш, который используется службами ИОК, нельзя считать достаточно сильным (т. е. таким, который нельзя взломать), то доверенные стороны не могут положиться на действительность цифровых сертификатов и другого контента, подписанного ЦС. Именно надежность хеша создает доверие во всей системе ИОК.

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

Атаки, совершаемые на хеши

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

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

Надежность криптографического хеша равна его фиксированной битовой длине минус единица. Таким образом, надежный 128-битовый хеш имеет 127 битов (2^127) эффективной защиты, если при этом нет других уязвимостей. Как только кто-то разработает математический алгоритм, позволяющий взломать хеш за время, которое меньше значения его надежности, хеш считается ослабленным. В большинстве случаев все общепринятые хеши со временем ослаблялись, так как совершенствовалась способность криптографических атак сокращать эффективную битовую длину хеша. Чем больше сокращается эффективная битовая длина хеша, тем менее защищенным и ценным становится хеш. Как только можно посчитать, что кто-то может взломать хеш за разумное количество времени и с некоторым количеством ресурсов (чаще всего они все еще измеряются от сотен тысяч до миллионов долларов), хеш является взломанным. Больше им пользоваться нельзя. Взломанные хеши могут использоваться вредоносным ПО и хакерами, которые выдают их за правильное ПО с цифровой подписью. Хороший пример - вредоносное ПО Flame. Вкратце: слабые хеши тоже могут сыграть важную роль, но их использовать не стоит.

Введение в SHA

SHA-1 было разработано Агентством Национальной Безопасности Соединенных Штатов Америки (NSA). В 1995 году SHA-1 хеширование было признано федеральным стандартом Национальным институтом стандартов и технологий США. Криптографические стандарты, устанавливаемые этим институтом, чаще всего заслуживают доверие большей части мира. В большинстве случаев их использование обязательно на всех компьютерах, которые занимаются важной деятельностью, связанной с правительством США или с армией. SHA-1 сменило ранее ослабленные криптографические хеши, такие как MD-5.

Со временем, после нескольких криптографических атак, эффективная битовая длина SHA-1 стала сокращаться. После этого Агентство Национальной Безопасности и Национальный институт стандартов и технологий разработали SHA-2. В 2002 году SHA-2 хеширование стало новым рекомендованным стандартом. Это произошло гораздо раньше того момента, когда SHA-1 можно было считать взломанным. В феврале 2017 года была раскрыта атака столкновения, из-за которой SHA-1 больше нельзя было использовать для криптографической защиты, осуществляемой при помощи электронных подписей.

Отличную дискуссию о взломе SHA-1 и примеры документов можно увидеть по ссылке.

Семейство SHA-2

SHA-2 является криптографическим стандартом хеширования, которое на данный момент должно использоваться всеми ПО и техническими средствами по крайней мере в течение ближайших лет. Чаще всего этот стандарт имеет название семейства хешей SHA-2, так как оно содержит много хеш-функций разных размеров: 224, 256, 384, 512 битов. Когда кто-то говорит, что использует SHA-2 хеширование, нельзя определить длину хешей. Самая популярная длина составляет 256 битов. Несмотря на то что SHA-2 обладает несколькими математическими характеристиками, которые также имеет SHA-1, и уже было обнаружено немного незначительных уязвимостей, в криптографической среде оно все равно считается надежным (по крайней мере на ближайшее будущее). Конечно, оно гораздо лучше SHA-1. Все сертификаты, подтвержденные SHA-1, и приложения и хард, использующий SHA-1, должны быть переведены на SHA-2.

Осуществление депрекации SHA-1

Все крупные вендоры веб-браузеров, такие как Microsoft, Mozilla, Apple, Google, и другие доверенные стороны стали требовать (и делали это в течение нескольких лет), чтобы все клиенты, службы и продукты, на данный момент использующие SHA-1, перешли на SHA-2. Время, за которое должен осуществляться переход, было различным в зависимости от поставщика. Например, многих вендоров заботили только TLS-сертификаты (т. е. веб-сервера). Один из них, Microsoft Corporation, сейчас волнуется только о том, чтобы SHA-1 использовался на цифровых сертификатах от «публичного» ЦС. Однако стоит ожидать, что вскоре все вендоры в обязательном порядке будут требовать перехода на SHA-2 для всех приложений и устройств и всех криптографических хеш-функций, если они еще не начали это делать. В настоящий момент все браузеры выдают сообщение об ошибке, если на веб-сайте обнаруживается цифровой сертификат SHA-1. Некоторые из них разрешают проигнорировать ошибку и при желании перейти на сайт, который защищается SHA-1. В скором времени все крупные вендоры браузеров наверняка запретят переходить на сайты с SHA-1-защитой.

К сожалению, переход от SHA-1 к SHA-2 в большинстве случаев серверов является односторонней операцией. Например, как только вы переведете сертификат своего сервера с SHA-1 на SHA-2, клиенты, которые не понимают сертификаты SHA-2, скорее всего, будут получать предупреждения или ошибки, приложение может просто не работать. Переход на SHA-2 - рискованный шаг для приложений и устройств, которые не поддерживают это хеширование.

План перехода инфраструктуры открытых ключей от SHA-1 к SHA-2

Каждая компания с внутренней ИОК, которая еще не использует SHA-2, в какой-то момент времени будет вынуждена создать ИОК с SHA-2 или перейти с SHA-1 на SHA-2 на существующей ИОК. План перехода к SHA-2 включает в себя:

  1. Обучение членов команды, которые участвуют в деле, о том, что такое SHA-2 и почему его использование обязательно. Эта статья будет хорошим началом;
  2. Инвентаризация всех приложений и устройств, в которых используются критические хеши и цифровые сертификаты;
  3. Определение того, какие приложения или устройства, в которых используются критические хеши, могут поддерживать SHA-2. Также нужно определить подходящую битовую длину. Для приложений или устройств, которые не поддерживают данный тип хеширования, нужно понять, в чем может состоять причина. Чаще всего для этого нужно связаться с вендором и провести тестирование;
  4. Определение компонентов ИОК, которые можно перевести на SHA-2;
  5. Создать план перехода для конвертации компонентов на SHA-1 в SHA-2, включая потребляющих клиентов и компоненты ИОК. Также нужно разработать резервный план на случай критической ошибки;
  6. Проведение тестирования PoC (проверка обоснованности концепции);
  7. Принятие риска управления и решения об осуществлении миграции или отказе от нее;
  8. Внедрение плана перехода в среду производства;
  9. Тестирование, получение фидбека.

Самая трудная часть всех проектов по переходу к SHA-2 - определение устройств и приложений, совместимых с SHA-2. Если потребляющие устройства не понимают SHA-2, можно ожидать появление сообщения об ошибке (оно вряд ли будет сформулировано как «не понимаю SHA-2») или неудачу в работе. Можно ожидать такую ошибку: «Не распознан сертификат», «Затруднения с соединением», «Невозможно осуществить соединение», «Проблемы с сертификатом», «Сертификат, не прошедший проверку».

Думайте о своей миссии по определению того, что будет работать, как о небольшом проекте по проблеме 2000 года. Начните с инвентаризации всех уникальных устройств, ОС и приложений, которые должны будут понимать SHA-2. Затем соберите команду людей, которые должны будут провести тестирование и понять, работает ли SHA-2. До этого можно положиться на сведения, полученные от вендоров. Однако до того момента, когда вы осуществите тестирование при помощи сертификатов SHA-2, вы не будете знать наверняка.

Обновление приложений и устройств - необычная задача, и на ее выполнение может уйти гораздо больше времени, чем вы предполагаете. Даже сейчас я вижу большое количество устройств и приложений, которые работают на устаревших версиях OpenSSL. Они должны были быть обновлены после Heartbleed, но таких действий не последовало. Не забывайте, что обновление также требует формального пользовательского тестирования и принятия.

Если вы имеете внутреннюю ИОК, ее нужно тоже подготовить для внедрения SHA-2. Иногда для этого нужно обновить ЦС, получить новые сертификаты ЦС или установить новую ИОК. По многим причинам я рекомендую именно последний шаг. Новая ИОК - возможность начать все заново, избавиться от старых ошибок.

Модели миграции ИОК

Ниже перечислены возможные случая внедрения SHA-2 в компоненты ИОК. Для этих примеров я принял ИОК из двух уровней (оффлайн-корень, онлайн-ЦС), каждый из которых может либо стать новым компонентом ИОК, либо оказаться перенесенным в новое хеширование:

  • Два дерева ИОК: одно - SHA-1, второе - SHA-2;
  • В остальных вариантах используется единственное дерево;
  • Целое дерево ИОК: от корня до крайних точек - SHA-1;
  • Целое дерево ИОК: от корня до крайних точек - SHA-2;
  • Корень - SHA-1, ЦС - SHA-2, сертификаты крайних точек - SHA-2;
  • Корень - SHA-1, ЦС - SHA-2, сертификаты крайних точек - SHA-1;
  • Корень - SHA-1, ЦС - и SHA-1, и SHA-2, сертификаты крайних точек - и SHA-1, и SHA-2;
  • Корень - SHA-2, ЦС - SHA-1, сертификаты крайних точек - SHA-1;
  • Корень - SHA-2, ЦС - SHA-2, сертификаты крайних точек - SHA-1;
  • Корень - SHA-2, ЦС - и SHA-1, и SHA-2, сертификаты крайних точек - и SHA-1, и SHA-2.

Возможен также случай, в котором ЦС переходит между SHA-1 и SHA-2 по необходимости. Однако он, скорее всего, вызовет беспорядок в сервисах ИОК, да и в целом не рекомендуется к использованию. Если такое возможно, для облегчения процесса перехода можно применять параллельные ИОК (одна - SHA-1, вторая - SHA-2), а после тестирования начинать переход устройств и приложений.

Сертификат ЦС в корне ЦС необязательно переводить на SHA-2, даже если он все еще относится к SHA-1. Всех программ, проверяющих вещи на предмет использования устаревшего SHA-1, заботит все, что идет после собственного сертификата ЦС в корне (по крайней мере так будет в ближайшее будущее). И все же на вашем месте я бы перенес вообще все, включая собственный сертификат ЦС в корне, на SHA-2. Тогда я бы мог сказать, что моя ИОК использует хеширование SHA-2, поэтому в дальнейшем мне больше не пришлось бы менять SHA-1.

Публичные ЦС уже перешли с SHA-1 на SHA-2 для всяких сертификатов, которые действительны после 1 января 2017 года. Нужно сосредоточить свои усилия на серверах и приложениях с публичными цифровыми сертификатами, которые еще не осуществили переход. После того как эта проблема будет решена, взгляните на свою внутреннюю ИОК и доверенных клиентов. Переход от SHA-1 к SHA-2 не является сложным технически. Это глобальная логистическая перемена с большим количеством последствий, а также нужно проводить тестирование.

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

SHA-3 уже существует. Стоит ли использовать это хеширование?

Несмотря на то что в SHA-2 не было найдено никаких глобальных криптографических уязвимостей, считается, что этот метод хеширования алгоритмически связан с SHA-1. Многие эксперты полагают, что жизненный цикл SHA-2 будет похож на SHA-1. Уже в августе 2015 года Национальный институт стандартов и технологий США одобрил замещающий стандарт криптографического хеш-алгоритма, который называется SHA-3. SHA-3 имеет отличные от SHA-1 и SHA-2 математические свойства. Именно поэтому этот тип хеширования должен быть устойчив к криптографическим атакам больше, чем SHA-2.

К сожалению, все, кто думает о том, чтобы повременить с переходом на SHA-2 и мигрировать сразу на SHA-3, будут разочарованы. Широкое принятие SHA-3 произойдет еще нескоро, а вот SHA-2 требуется уже сейчас. Если бы вы перешли на SHA-3 сейчас, большинство, если не все, ваших приложений и устройств, опирающихся на криптографию, наверняка выдадут ошибку, не в силах распознать цифровой сертификат.

Итак, если вы еще не перешли на SHA-2, займитесь этим сейчас же. А вот когда SHA-2 начнет ослабевать, мы все можем мигрировать на SHA-3.

Реклама
Комментариев еще не оставлено
no_avatar