Инструменты разработчика · SHA хеш-калькулятор
SHA-1 Объяснение коллизий: что по-прежнему безопасно, а что необходимо перенести
· Почему это важно
ша-256 криптография безопасность
Сканер помечает SHA-1, и руководство спрашивает, насколько это срочно. В этом посте объясняется, что делает и не разрушает коллизионная атака, где SHA-1 все еще допускается и как планировать миграцию.
Сканер сообщает, что SHA-1 сломан, но почему сломан? Вопрос, который решает актуальность миграции
Сканер сетевой безопасности помечает SHA-1 в вашей инфраструктуре. Руководство спрашивает, насколько это срочно. Ответ полностью зависит от того, для чего вы используете SHA-1, и этот вопрос показывает, есть ли у вас проблема с соблюдением требований, активная проблема безопасности или просто устаревший артефакт, который необходимо каталогизировать. SHA-1 криптографически взломан — академические демонстрации доказали коллизии. Но «сломанный» означает разные вещи в зависимости от роли SHA-1 в вашей системе.
Криптографический хэш служит разным целям в разных контекстах. Иногда это контрольная сумма, защищающая от случайного повреждения. Иногда это обязательство, например опубликованная контрольная сумма загрузки, которая позволяет пользователям убедиться, что они получили именно тот файл, который предполагал издатель. Иногда это часть подписи или цепочки сертификатов, где злоумышленник, обладающий достаточным контролем, может создать два значимых документа, имеющих один и тот же хэш, и тем самым подделать аутентификацию. Серьезность коллизии SHA-1 критически зависит от того, какую из этих ролей SHA-1 выполняет в вашей системе.
Столкновение против прообраза: почему публично демонстрируемые атаки нацелены на коллизии и что это значит для существующего хеша
Атака коллизией создает два разных входа с одинаковым выходом. Злоумышленник не находит сообщение, хеш которого имеет заранее определенное значение — это будет атака по прообразу, и она остается неосуществимой для SHA-1. Вместо этого атака коллизией означает, что злоумышленник может создать два документа с одинаковым хеш-кодом. Если система использует хэш, чтобы доказать, что две вещи одинаковы, коллизия разрушит это доказательство. Злоумышленник должен обработать оба входных данных, что требует времени и вычислений, но в результате получаются две разные вещи, которые кажутся идентичными под хешем.
Атака с использованием прообраза будет означать, что злоумышленник может взять опубликованный хэш SHA-1 и найти соответствующие ему входные данные. Атаки SHA-1 работают иначе. Если у вас есть репозиторий дайджестов SHA-1 и вы беспокоитесь о том, действительно ли файл им соответствует, коллизионная атака не является угрозой. Угроза заключается в том, что кто-то, имеющий доступ к вашему репозиторию, может подделать другой файл в том же дайджесте. В большинстве случаев это также нереально без контроля самого процесса хеширования. Конкретная модель атаки имеет такое же значение, как и алгоритм.
Демонстрации 2017 — два разных файла с одинаковым SHA-1, качественно описанные, и последовавшая за этим работа с выбранным префиксом
Атака SHAttered от 2017 продемонстрировала практическую коллизию: два разных файла PDF с одним и тем же дайджестом SHA-1. Исследователи тщательно сконструировали оба файла, превратив их в действительные PDF-файлы при столкновении. Работа потребовала значительных вычислительных усилий и специального оборудования. Важно то, что это вообще было возможно: устойчивость к коллизиям, оправдывающая использование SHA-1 для обеспечения безопасности, исчезла. Атака доказала, что два семантически разных документа могут иметь общий дайджест, что ломает любую систему, которая доверяет дайджесту как доказательству личности.
Атака, последовавшая за 2020 и получившая название «SHA-1 is a Shambles», сделала следующий шаг: коллизии выбранных префиксов. Этот вариант означает, что злоумышленник может взять два произвольных документа, объединить к каждому разные суффиксы и создать коллизию. Это опасная атака на подписи и сертификаты. Злоумышленнику не обязательно начинать с нуля; они могут сталкиваться с двумя значимыми, разными документами. Это нарушает модель безопасности любой системы, которая подписывает дайджесты SHA-1. Злоумышленник может создать два документа, которые имеют одинаковый хеш-код и оба означают что-то разное.
Где SHA-1 неприемлемо — подписи, сертификаты и все, что злоумышленник может повлиять на обе стороны.
Это различие имеет значение, поскольку SHA-1 по-прежнему допустимо в некоторых ролях и абсолютно неприемлемо в других. В Git SHA-1 используется как адрес содержимого — имя для конкретного моментального снимка файлов. Git не использует SHA-1 для аутентификации; это схема именования. Злоумышленник теоретически может вычислить два разных состояния репозитория с одним и тем же идентификатором, но для этого потребуется контролировать весь процесс создания контента и распространять обе версии, прежде чем кто-либо это заметит. Для большинства команд такой уровень контроля со стороны злоумышленников не является моделью угрозы. Вот почему Git намеренно переходит на SHA-256, а не рассматривает это как чрезвычайную ситуацию.
В сценарии проверки загрузки через Интернет издатель публикует файл и его контрольную сумму SHA-1 на одном сервере. Злоумышленник, скомпрометировавший этот сервер, контролирует и файл, и контрольную сумму. Они могут загрузить файл и опубликовать его SHA-1, при этом коллизия не требуется. Если контрольная сумма размещена в другом месте — на защищенном VPN, напечатана в подписанном электронном письме, опубликована в другой инфраструктуре — тогда злоумышленнику придется столкнуться, и это становится невозможным. Контрольная сумма заслуживает доверия настолько же, насколько и ее канал. Вот почему для проверки загрузки требуется нечто большее, чем просто хэш.
Там, где это сохраняется с меньшим риском — идентификация контента в неконкурентных настройках и поэтапный переход Git на SHA-256.
Для подписей и сертификатов SHA-1 недопустимо. Сертификат цепочки из доверенного корня. Если центр сертификации подписывает два разных сертификата, используя один и тот же дайджест SHA-1, коллизионная атака позволяет злоумышленнику подделать любой из них. Это не теория: были задокументированы атаки на промежуточные центры сертификации. Любая схема подписи, основанная на SHA-1, потенциально может быть подделана злоумышленником, имеющим достаточные ресурсы. Каждый крупный поставщик браузеров и ОС объявил устаревшим SHA-1 в сертификатах. Новые сертификаты должны использовать SHA-256. Поставщики платформ высказались ясно, потому что угроза реальна и непосредственна.
NIST, орган по стандартизации США, установил четкие сроки. Начиная с 2024, SHA-1 не следует использовать для каких-либо новых приложений. Ожидается, что начиная с 2030 SHA-1 будет полностью удален из федеральных систем. Это не смутное осуждение; это конкретный мандат для государственных подрядчиков и сигнал для отрасли. Соблюдение графика NIST гарантирует, что ваши системы опередят кривую устаревания, а не будут суетиться после крайнего срока.
Свидетельства репозитория подтверждают прекращение поддержки SHA-1, а не непрочитанную дату публикации или прекращения использования NIST.
В исходных документах репозитория SHA-1 указано, что совместимость с устаревшими версиями и имена продемонстрировали работу по коллизиям, но он не содержит графика вывода из эксплуатации органа стандартов. Таким образом, в этом разделе исправлена структура, рассматривая устаревание как проблему инженерного инвентаря, а не цитируя непрочитанный номер публикации или дату соответствия.
Для сред, контролируемых политиками, обратитесь в орган, регулирующий такое развертывание, и запишите точный проверенный документ. Доказательства продукта здесь поддерживают более узкое действие: сохранить SHA-1 доступным для воспроизведения существующих значений, пометить его как непригодный для новых целей безопасности и вычислить замену SHA-256 везде, где окружающий протокол допускает миграцию.
Рабочий пример — контрольный список миграции, примененный к устаревшей странице проверки загрузки.
Путь миграции из SHA-1 обычно начинается с инвентаризации: где используется SHA-1? Сертификаты и подписи? Непосредственный приоритет. Репозитории Git и адресация контента? Средний приоритет, следуйте темпам миграции Git. Опубликованы контрольные суммы для загрузок? Зависит от модели доверия. Внутренние контрольные суммы для дедупликации или архивирования? Низкий приоритет, больше времени на планирование. Этап инвентаризации выявляет истинную поверхность и помогает вам расставить приоритеты на основе фактического риска, а не абстрактной срочности.
Для каждой роли миграция выглядит по-разному. Сертификаты немедленно обновятся до SHA-256. Репозитории Git постепенно добавляют ссылки на SHA-256, сохраняя при этом SHA-1 для обратной совместимости. Контрольные суммы загрузки начинают публиковаться как в SHA-1, так и в SHA-256, а затем, в конечном итоге, только в SHA-256. Устаревшие дайджесты SHA-1 в базе данных контрольных сумм можно проверить с помощью ToolAcre SHA хеш-калькулятора, а новые записи должны использовать SHA-256. Инструмент поддерживает обе стороны перехода, позволяя проверять старые хеши и создавать новые.
Вывод: SHA-1 для сравнения, SHA-256 для новой работы — ToolAcre SHA хеш-калькулятор включает SHA-1, поэтому устаревшие дайджесты можно проверять, а не в качестве одобрения.
Для большинства организаций миграция не означает «выключить SHA-1 завтра». Это «понимание того, где оно используется, определение приоритетов критически важных для безопасности ролей и составление многолетнего плана». Репозиторий Git с годами коммитов SHA-1 должен переходить постепенно, используя инструменты, которые справляются с обоими. Инфраструктура сертификатов уже должна быть перенесена. Опубликованные контрольные суммы должны соответствовать двойному алгоритму во время переходного периода. Постепенная миграция уменьшает количество критических изменений и дает системам время адаптироваться к новой реальности.
Хэш-калькулятор ToolAcre SHA обеспечивает обе стороны этого перехода. Вы можете проверить существующие дайджесты SHA-1 из ваших устаревших систем, чтобы убедиться, что файл им соответствует. Вы можете вычислить хэши SHA-256, чтобы начать публикацию пути миграции. Инструмент не претендует на безопасность SHA-1; он помечает его как сломанный и объясняет, почему. Но он позволяет вам работать с устаревшими хэшами, которые вам все еще необходимо поддерживать, пока вы строите мост к SHA-256 и планируете прекращение поддержки.