Смерть SHA-1 – так ли всё плохо?

На этой неделе IT-мир встретился с новостью из разряда “давно ожидаемых”: FIRST PRACTICAL SHA-1 COLLISION ATTACK ARRIVES. Новость шустро окрестили смертью SHA-1.

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

Затакт

SHA-1 вышел в 1995 году, однако в 1993 был опубликован его “предварительный” вариант – SHA-0. Встретиться с ним в дикой природе у вас шансов практически нет, но в нашем случае интересно то, что успешные атаки на SHA-0 были опубликованы уже в 1997 году – сотрудница Шаньдунского университета, Wang Xiao Yun, опубликовала работу, доказывающую наличие коллизий у данной хэш-функции. И уже в обсуждении этой работы возник первый вопрос про безопасность “усовершенствованного варианта” оной, SHA-1 – т.е. “какие потенциальные проблемы перешли в SHA-1 от SHA-0”?

Первый звонок

Первым широко о достижении реального успеха в части диф.криптоанализа SHA-1 сообщил многоопытный Брюс Шнейер, рассказав о работе той же команды из Wang XiaoYun, Ye HongBo и Yiqun Lisa Yin. Почему реального? Ведь попытки – и успешные – были и до этого?

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

Суть работы состояла в том, что удалось найти возможность создать коллизию с SHA-1, используя не 2⁸⁰ операций, а 2⁶⁹.

Безусловно, со стороны кажется, что что 2⁸⁰ операций, что 2⁶⁹ – огромные числа. Это так. Но это не отменяет факт того, что хэш-функция взломана – для поиска коллизий можно тратить меньше времени, чем должно быть с точки зрения ТЗ на разработку. Различие в 2048 раз достаточно серьёзно.

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

Уход от SHA-1 для подписи сертификатов CA

В конце 2013 года профильная организация CA Security Council, объединяющая крупнейшие Certification Authority, выпускает ~~фетву~~ публичное заявление о том, что грядущий 2014й год должен стать годом отказа от использования SHA-1. Незадолго до них Microsoft также публикует свой план последовательного отказа от SHA-1.

Ключевая логика проста – начиная с 1 января 2016 года для приложений, и с 1 января 2017 года для всех остальных применений (основное – SSL/TLS), сертификаты, подпись которых сформирована с использованием SHA-1, считаются не-доверенными.

Это очень важный момент в плане тонкостей и различий, на котором надо остановиться подробнее.

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

Так вот, отказ от SHA-1 для подписи сертификатов – это предупредительная мера, которая нужна именно для защиты от потенциально возможной в будущем атаки вида:

Мне сервер, к которому я подключаюсь, предъявляет сертификат, свидетельствующий о том, что это хороший сервер;
Сертификат проходит все базовые проверки;
Схожу-ка посмотрю на родительский сертификат – ведь адрес, куда сходить, есть в предъявленном мне сертификате;
Мне подсовывают фальшивый, но подпись сходится – я ошибочно думаю, что всё ОК и верю, что подключился к хорошему серверу;

Аналогичная штука возможна и для CRL’ов, и для OCSP-ответов, которые “плохой” сервер может заботливо “прикрепить” технологией OCSP Stapling.

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

Клиентская сторона

В сентябре 2014 года браузер Chrome 39й версии первым начинает сигнализировать о потенциальной проблеме – если он видит, что предъявляемый ему сертификат не-CA (“конечный”) подписан с использованием SHA-1, и имеет срок годности, заползающий на 2017й год, то он предупреждает клиента – мол, “с 1 января 2017 года этот сертификат станут отбивать клиентские системы – а у него срок годности далее этой даты – надо поменять”. Это не обозначает, что данная сессия небезопасна, это именно предупреждение.

В ноябре того же года 40й хром закручивает гайки – граница даты-предупреждения сдвигается на полгода, до июня 2016. 41й сдвигает дату ещё раньше – на 1 января 2016. Чтобы народ хоть как-то начал шевелиться и понимать, что кончившийся в 2016м году сертификат веб-сервера “просто продлить, перезапросив сертификат с теми же настройками, но новой датой”, не получится. Кроме того, если обнаруживается сертификат сервера, который продолжает быть валидным после 31 декабря 2016 года, и подписан с использованием SHA-1, то хром перестаёт рисовать иконку “защищённое соединение” и делает статус “affirmatively insecure”.

Ситуация на некоторое время затихает. Годы тикают. Что же теперь?

Что же случилось?

На сайте SHAttered.it представлены два PDF-документа, имеющие идентичный хэш SHA-1.

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

Оригинальная картинка с сайта shattered.io, показывающая, где именно в PDF-файле размещаются перебираемые битовые строки
(кликните для увеличения до 1222 px на 617 px)

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

Что же делать и чего бояться?

Нужно планомерно перестать использовать SHA-1 для проверки целостности как минимум “долгоживущих” данных – файлов, документов.

Что с поддержкой со стороны серверов и клиентов?

Все современные ОС отлично работают с хэш-функциями семейства SHA-2 – ну, как минимум с “главной тройкой” – SHA-256, SHA-384 и SHA-512. Были ещё SHA-448 и “половинка” от неё, SHA-224, но они по сути не используются.

Для устаревшей, но массово используемой XP SP3 есть патч – см. мою статью про настройку SSL/TLS в Windows, после которого проблем с поддержкой семейства SHA-2 также не остаётся.

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

Чего не бояться

В случае использования SHA-1 для, допустим, проверки целостности IPsec-данных, или сегментов TLS/SSL, угрозы нет. Потому что от предъявленной публике атаки, до возможности “сервер отправил ESP/AH-пакет, целостность которого проверяется SHA-1, а тут злоумышленник поймал его, съел, мгновенно сделал пакет с таким же SHA-1, только с другим содержанием, да притом не с каким попало, а со злонамеренным” – не просто далеко, а очень далеко. Сам объём доступных в этом сценарии злоумышленнику данных – очень мал. Места в пакете, аналогичного “невидимому изображению внутри PDF-файла”, по сути нет. Требования по времени – абсолютно несравнимы с “распределённая задача, машино-годы на GPU-ускорителях”.

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

Атаки же вида “враги запишут всю нашу TLS-сессию, а потом подберут ключи и расшифруют” – никак не зависят от используемого для проверки целостности алгоритма хэширования. Враги расшифруют, чтобы прочитать содержимое – им будет глубоко пофигу, что у каждого блока данных висит аппендикс для проверки целостности. Он хэш, в нём самих данных нет.

Древний и короткий CRC-16/32 до сих пор замечательно работает в роли алгоритма проверки “неповреждённости” у кадров данных – при том, что для подбора его нужно крохотное количество машинного времени, свою задачу “быстро отследить изменение содержимого” он решает.

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

Подождём следующую.