Несколько дней назад сотрудники компании Google и Центра математики и информатики в Амстердаме представили первый алгоритм генерации коллизий для SHA-1. За десять лет существования SHA-1 не было известно ни об одном практическом способе генерировать документы с таким же хешем SHA-1 и цифровой подписью, как в другом документе, но теперь такая возможность появилась.
Хеш-функция SHA-1 используется повсеместно, поэтому известие о генерации документов с идентичным хешей вызвало естественную обеспокоенность у пользователей. В том числе у пользователей системы управления версиями Git, в которой тоже используются хеши SHA-1. Развёрнутый ответ на эти опасения дал Линус Торвальс. Если вкратце, то бояться нечего.
Линус считает, что ничего критически важного эта атака на поиск коллизий не сделает. По его словам, есть большая разница между использованием криптографического хеша для цифровых подписей в системах шифрования и для генерации «идентификации контента» в системе вроде Git.
В первом случае хеш — это некое заявление доверия. Хеш выступает как источник доверия, который фундаментально защищает вас от людей, которых вы не можете проверить иными способами.
Напротив, в проектах вроде Git хеш не используется для «доверия». Здесь доверие распространяется на людей, а не на хеши, говорит Линус. В проектах вроде Git хеши SHA-1 используются совершенно для другой, технической цели — просто чтобы избежать случайных конфликтов и как действительно хороший способ обнаружения ошибок. Это просто инструмент, который помогает быстро выявить искажённые данные. Речь не о безопасности данных, а о техническом удобстве дедубликации и выявления ошибок. Другие системы контроля версий часто используют для выявления ошибок методы вроде CRC.
Линус признаёт, что SHA-1 используется в Git также для подписи веток, так что в этом смысле он тоже является частью сети доверия, поэтому появление атаки на поиск коллизий действительно имеет негативные последствия для Git.
Но в реальности нужно иметь в виду, что этой конкретной атаки очень легко избежать по нескольким причинам.
Во-первых, в этой атаке злоумышленник не может просто создать документ с заданным хешем. Ему нужно создавать сразу два документа, поскольку атака проводится по идентичному префиксу.
Во-вторых, разработчики атаки на поиск коллизий SHA-1 опубликовали научную статью и выложили инструменты, чтобы распознать признаки атаки. Можно очень легко распознать документы, в которых есть этот префикс, пригодный для генерации второго документа с идентичным хешем.
То есть на практике, если внедрить соответствующие меры защиты против документов с этим префиксом, атака будет неосуществима. Кстати, такая защита уже реализована в Gmail и GSuite. Детектор уязвимых документов работает в открытом доступе на сайте shattered.io. Библиотека для обнаружения коллизий sha1collisiondetection опубликована на Github.
Когда все данные лежат в открытом доступе, то реальная атака практически невозможна. Авторы научной работы приводят пример атаки на документы PDF с идентичным префиксом. Эта атака успешна, потому что сам префикс «закрыт» внутри документа, как блоб. Если же у нас открытые исходники в репозитории, то это совсем другое дело. Вряд ли можно сделать такой префикс из исходного кода (только из блоба). Другими словами, для создания идентичного префикса и последующей генерации веток кода с одинаковыми хешами SHA-1 придётся внедрить в код некие случайные данные, что сразу же будет замечено. Линус говорит, что есть места, куда можно спрятать данные, но git fsck уже вылавливает такие фокусы.
Линус Торвальдс признаёт, что реальным опасением может быть только отслеживание документов PDF средствами Git. Здесь можно порекомендовать использовать инструменты для обнаружения признаков атаки, указанные выше. Такие патчи уже созданы для хостингов github.com и kernel.org, скоро они станут активными, так что здесь нечего волноваться.
Ну и кроме всего прочего, Git в будущем уйдёт от использования SHA-1, сказал Линус, есть план, чтобы никому даже не пришлось конвертировать свои репозитории. Но как уже понятно, это не такая уж критическая вещь, чтобы спешить с ней.
Кстати, упомянутая Торвальсом проблема отслеживания PDF-документов с идентичными хешами SHA-1 уже проявила себя в системе контроля версий Apache SVN, которая применяется в репозитории WebKit и других крупных проектах. В пятницу вечером на информационном сайте атаки на поиск коллизий SHA-1 появилась новая информация относительно действия атаки на систему контроля версий SVN. Там указано, что PDF-файлы с одинаковыми хешами SHA-1 уже ломают репозитории SVN.
Оказалось, что если залить два разных файла с одинаковыми хешами, то система контроля версий не справляется с багом. Кто-то залил такие файлы в репозиторий WebKit, после чего он сглючил и прекратил приём новых коммитов.
Вот эти два файла PDF с одинаковыми хешами:
$ls -l sha*.pdf
-rw-r--r--@ 1 amichal staff 422435 Feb 23 10:01 shattered-1.pdf
-rw-r--r--@ 1 amichal staff 422435 Feb 23 10:14 shattered-2.pdf
$shasum -a 1 sha*.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdfАвтор: alizar
