Как и зачем переходить с SHA-1 на SHA-2 и почему это важно

Индустрия инфраструктуры открытых ключей (ИОК, англ. PKI — Public Key Infrastructure) рекомендует, чтобы любой объект инфраструктуры, использующий SHA-1, был переведён на более безопасный SHA-2. В этой статье описано, почему и как стоит это сделать.

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

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

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

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

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

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

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

Для чего используются хеши?

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

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

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

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

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

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

Атаки на хеши

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

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

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

Что в будущем?

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

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

Источники: • https://vc.ru/crypto/47132-algoritmy-heshirovaniya-prostoe-obyasnenie-slozhnogo; • https://www.kaspersky.ru/blog/the-wonders-of-hashing/3633/.

Введение в семейство SHA

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

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

Отличное обсуждение взлома SHA-1 и пример документации можно найти здесь.

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

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

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

Как проверить хеш в Windows 10

Любая настольная операционная система, будь то Windows 10, Linux или MacOS, имеет стандартные механизмы проверки хеш-сумм любых файлов на вашем диске.

Как узнать хеш в PowerShell

Для начала вам надо запустить PowerShell. Для этого можно нажать Win + X и выбрать PowerShell, либо нажать Win + R и ввести команду powershell.
В открывшемся синем окне вам надо ввести следующую команду: Get-FileHash F:\Test.txt. Вместо F:\Test.txt вам надо вставить путь к файлу. Обязательно указывайте его расширение.

PowerShell выдаст вам хеш-сумму вашего файла. По умолчанию Windows генерирует хеш SHA-265, но вы можете указать, что вам нужен хеш другого алгоритма. Для этого используйте следующие команды:

Get-FileHash F:\Test.txt -Algorithm MD5
Get-FileHash F:\Test.txt -Algorithm SHA1
Get-FileHash F:\Test.txt -Algorithm SHA256
Get-FileHash F:\Test.txt -Algorithm SHA384
Get-FileHash F:\Test.txt -Algorithm SHA512
Get-FileHash F:\Test.txt -Algorithm MACTripleDES
Get-FileHash F:\Test.txt -Algorithm RIPEMD160

Как проверить хеш-сумму через Командную строку

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

Нажмите Win + R и введите cmd.
В открывшемся окне Командной строки введите команду certutil -hashfile F:\Test.txt. Разумеется, вместо F:\Test.txt у вас должен быть свой путь к вашим файлам.

По умолчанию Командная строка выводит на экран хеш-сумму SHA1, но вы можете изменить это, указав системе, какой именно хеш вы хотите получить. Для этого используйте следующие команды:

certutil -hashfile F:\Test.txt MD5
certutil -hashfile F:\Test.txt MD4
certutil -hashfile F:\Test.txt MD2
certutil -hashfile F:\Test.txt SHA512
certutil -hashfile F:\Test.txt SHA384
certutil -hashfile F:\Test.txt SHA256
certutil -hashfile F:\Test.txt SHA1

Как проверить хеш через HasTab

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

Перейдите по ссылке и скачайте приложение HashTab.
Запустите установочный файл и следуйте указаниям мастера по установке. Примечание: для установки этой утилиты нужны права Администратора, либо пароль от учетной записи Администратора.
Найдите в Проводнике нужный вам файл, кликните по нему правой кнопкой мыши и выберите Свойства. Затем перейдите на вкладку Хеш-суммы файлов.
Здесь вы найдете имена алгоритмов и соответствующие хеш-значения. По умолчанию приложение отображает только CRC32, MD5 и SHA-1, но вы можете отобразить дополнительные суммы, если нажмете на Настройки и отметите алгоритмы, которые вам нужны.

Кроме того, HashTab позволяет легко сравнить хеш-суммы двух файлов. Для этого по первому файлу кликните правой кнопкой мыши, выберите Свойства, а затем откройте вкладку Хеш-суммы файлов. Нажмите Сравнить файл и укажите путь к второму файлу.

Хеш-сумма второго файла отобразится в поле Сравнение хеша, и, если суммы совпадают, возле иконки решетки будет зеленая галочка. Если не совпадают – красный крестик.

План перехода ИОК с SHA-1 на SHA-2

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

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

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

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

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

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

Когда контрольные суммы полезны

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

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

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

Модели перехода ИОК

Ниже перечислены сценарии для внедрения 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-2 и SHA-1, сертификаты конечных точек — SHA-2 и SHA-1.
Корень — SHA-2, выдающие ЦС — SHA-1, сертификаты конечных точек — SHA-1.
Корень — SHA-2, выдающие ЦС — SHA-2, сертификаты конечных точек — SHA-1.
Корень — SHA-2, выдающие ЦС — SHA-2 и SHA-1, сертификаты конечных точек — SHA-2 и SHA-1.

Также возможно существование выдающего центра сертификации, который переключается между 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 января 2022, поэтому вы должны сосредоточить свои усилия на серверах и приложениях с ещё не перешедшими на SHA-2 публичными цифровыми сертификатами. После решения этой проблемы можно начать смотреть на внутренние ИОК и доверенные стороны. Переход с SHA-1 на SHA-2 технически не сложен, но это массовое логистическое изменение с множеством последствий, которое требует продолжительного тестирования.

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

Что за «зверь» такой это хеширование?

Чтобы в головах читателей не образовался «винегрет», начнем со значения терминологий применительно к цифровым технологиям:

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

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

Коллизии

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

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

Технические параметры

Основополагающие характеристики протоколов хеширования выглядят следующим образом:

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

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

Требования

К эффективной во всех отношениях хэш-функции выдвигаются следующие требования:

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

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