Коллизия для SHA-1 за 100$ тыс

    image

    В начале года я рекомендовал обновить SSL/TLS сертификаты, имеющие подпись с алгоритмом SHA-1. Теперь это стало не просто рекомендацией, а предупреждением.

    Недавние новости показали — оценка того, что получение коллизии для SHA-1 будет вполне доступно для криминального мира уже к 2018 году, оказалась оптимистичной. Марк Стивенс, Пьер Карпмэн и Томас Пейрин (надеюсь они простят меня за такой перевод их имен) опубликовали статью и пресс-релиз, в которых призывают как можно скорее отказаться от SHA-1. Они показывают, что создание поддельной подписи, основанной на SHA-1 сейчас может стоить около 100$ тыс., что вполне по карману преступному миру, а не 700$ тыс., как рассчитывал на 2015 год известный криптограф Брюс Шнайер.

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

    Важно отметить, что исследователям удалось получить коллизию в функции внутренней компрессии алгоритма хэширования, так называемая freestart коллизия, когда вектор инициализации может выбираться произвольно. Поэтому, если быть корректным, то полученный результат — не коллизия в SHA-1. Вычисления заняли 10 дней и потребовали непрерывной работы 64 графических ядер. По расценкам Amazon EC2 это примерно 2000$. По расчетам экспертов, полная атака на SHA-1 потребует от 49 до 78 дней работы кластера из 512 графических ядер, что, несомненно, гораздо дороже и дольше, однако срок уже вполне разумный и в некоторых случаях такая атака может достичь целей, преследуемых злоумышленниками.

    С учетом того, что эксперты продемонстрировали метод, который напрямую не ведет к получению коллизии SHA-1 в произвольном случае, криптограф Брюс Шнайер заявил:
    Не паникуйте, а готовьтесь к будущей панике.

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

    Возможно уже в ближайшем времени на черном рынке появится услуга поиска коллизий SHA1, а поскольку спрос напрямую зависит от цены и сроков, это может встать на поток и все те, кто не уделил должного внимания безопасности, кто пользуется устаревшим ПО и так далее — окажутся под ударом.
    Поделиться публикацией

    Комментарии 42

      +1
      Хром давно уже, вроде, предупреждает об этом и грозится в будущих версиях вообще выбросить поддержку подписи SHA1.
        +3
          0
          Вы вот это почитайте. Там спецы из Symantec, Entrust, Microsoft, Trend Micro предлагают отодвинуть дэдлайн до которого еще будут выпускаться сертификаты с SHA-1.
            +13
            a very small number of very large enterprise customers have disclosed to us that they simply cannot complete this work before the issuance deadline.
            Классика.
            Вылет самолета задерживается, т.к. один из клиентов бизнес класса застрял в duty free.
          +4
          > появится услуга поиска коллизий SHA1
          идея для стартапа!
            +28
            Коллизия для SHA-1 за 10 дней


            Поэтому, если быть корректным, то полученный результат — не коллизия в SHA-1.


            Вот как с такими людьми быть, а?
              +2
              Исправил на: Коллизия для SHA-1 за 100$ тыс.

              Так более корректно?
                0
                "$100 тыс."

                «100 $ тыс.» пробел обязателен
                «100 тыс. $» тоже криво
              +1
              Если использовать ботнет с хорошими видеокарточками, то почему бы и нет? Но майнинг биткоинов, скорее всего, пока еще более выгоден.
                0
                Это печалька. Навскидку, sha-1 используется в git, websocket, майкрософтовских сертификатах формата x.509 :( Или уже нет?
                • НЛО прилетело и опубликовало эту надпись здесь
                    +5
                    Git использует SHA-1 не для безопасности, а для проверки целостности.

                    wiki
                    Revision control systems such as Git and Mercurial use SHA-1 not for security but for ensuring that the data has not changed due to accidental corruption. Linus Torvalds has said about Git:

                    «If you have disk corruption, if you have DRAM corruption, if you have any kind of problems at all, Git will notice them. It's not a question of if, it's a guarantee. You can have people who try to be malicious. They won't succeed.
                    [...]
                    Nobody has been able to break SHA-1, but the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, OK, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get.
                    [...]
                    I guarantee you, if you put your data in Git, you can trust the fact that five years later, after it was converted from your hard disk to DVD to whatever new technology and you copied it along, five years later you can verify that the data you get back out is the exact same data you put in.
                    [...]
                    One of the reasons I care is for the kernel, we had a break in on one of the BitKeeper sites where people tried to corrupt the kernel source code repositories.»

                    Nonetheless, without the second preimage resistance of SHA-1, signed commits and tags would no longer secure the state of the repository as they only sign the root of a Merkle tree.

                    en.wikipedia.org/wiki/SHA-1#Data_integrity

                    Более подробно здесь
                      +2
                      (Если SHA-1 используется для проверки целостности данных) = (скоро будет возможна, или уже возможна, подмена данных с получением того же хэша)
                        +5
                        Да, но при этом очень маловероятно, что эти данные будут являться корректным текстом. Почему-то все об этом забывают. А компилятор на мусор в исходниках будет вопить сразу :)
                          +1
                          Смысл в том, что можно сделать корректный текст и добавить воды до достижения коллизии. Например в комментариях.
                            0
                            Можно, но я оооочень сомневаюсь, что там будут строго текстовые символы :)

                            Думаю, как только появится пруф — то быстро сменят на sha256, например :)
                              +1
                              если пруф появится, то скорей всего будет уже поздно. А если онитак быстро могут сменить на SHA256 то почему бы не начать это делать прямо сейчас, пока не появились пруфы?
                                –1
                                Может, им места жалко. Длиннее хеш — больше места требуется, считать сложнее.
                              0
                              нет, никто не говорил о том, что данные, приводящие к колизии хеша, должны быть хоть как-то похожи на оригинальный текст. Там любой набор данных произвольного размера.
                                0
                                Поиск произвольной коллизии хэш-функции — шаг к решению задачи подмены данных так, чтобы они остались данными с сохранением оригинальной подписи.
                            +3
                            но зачем? Вы вики читали?
                            ensuring that the data has not changed due to accidental corruption
                              0
                              Как бы ограничение записи в репозиторий кем попало задача не самого git, а тех кто им пользуется. Нужно только убедиться, что новый объект не затрёт уже существующий при совпадении хэшей.
                              0
                              Линус сам себе противоречит, сначала говорит, что это не security feature, а потом, что хэш защищает от целенаправленных атак:
                              You can have people who try to be malicious. They won't succeed.
                              [...]
                              One of the reasons I care is for the kernel, we had a break in on one of the BitKeeper sites where people tried to corrupt the kernel source code repositories.
                            –8
                            А ведь все в курсе, что SHA-1 используется в качестве единственного алгоритма хэширования для Windows 7? Windows 8+ Понимает уже Sha-256. Таким образом, проверять целостность драйверов, основываясь на целостности подписи будет нельзя.
                            Учитывая, что валидная цифровая подпись разаработчика драйвера на черном рынке стоит порядка 20к$ волноваться пока рано, но…
                              +5
                              Вот это новости!
                              Sha256 поддерживается в сертификатах, начиная с XP SP3+
                              +5
                              Открытка Яндекс.Деньгам, которые до сих пор на SHA-1.
                                0
                                Так, а что делать счастливым пользователям StartSSL у которых корневой сертификат — SHA-1, а промежуточные — SHA-2?
                                  +1
                                  тут волноваться не надо. Потому что корневые сертификаты прописаны в ОС/браузеры, и не проверяются по отпечатку.
                                    0
                                    Они-то не проверяются, но нет ли риска, что кто-то создаст промежуточный сертификат и сертификат сайта якобы от StartSSL и, взломав сайт, подставит их вместо настоящих? Ну а там почти идеальный MiTM, если владельцы сайта заранее «гвоздями не прибили».
                                      +1
                                      Промежуточный сертификат будет подписан SHA-2.
                                      Если ваш браузер «увидит» в цепочке корневой сертификат, отличный от того, что хранится в доверенных корневых (или не подписанный другим доверенным корневым), то выдаст предупреждение.
                                      Еще раз: браузер не будет проверять подпись корневого УЦ, а просто проверит, есть ли он в списке доверенных.
                                        0
                                        Видимо я чего-то упорно недопонимаю, но кто мешает злоумышленнику создать промежуточный сертификат SHA-2 который якобы подписан тем самым корневым SHA-1? Браузер и система увидят отпечаток доверенного корневого и пропустят подделку. Как я это вижу.
                                          +1
                                          Возможно, я не понимаю вас. Поправьте, если не прав:
                                          — Вы создаете свой корневой УЦ, который имеет такую же подпись, как и один из доверенных (SHA-1).
                                          — Вы подписываете этим корневым УЦ сертификат (SHA-2).

                                          Если я правильно понял предлагаемую последовательность, то отвечаю: для корневого сертификата браузер и система доверяют открытому ключу, а не проверяют подпись. Подобрать закрытый ключ, зная открытый — задача отличная от нахождения коллизии в алгоритме хэширования.
                                            0
                                            Да, последовательность именно такая. Теперь понял, что зря нервничаю )
                                    0
                                    У них есть корневой сертификат с SHA-2: www.startssl.com/certs
                                      0
                                      Есть ли он в основных ОС, mozilla ca-certificates, jre? Если нет — то он пока нафиг никому не сдался. А intermediate ca с sha-2 уже есть у большинства нормальных ca.
                                        +1
                                        Mozilla добавила его в 2012 году: bugzilla.mozilla.org/show_bug.cgi?id=602750
                                        У Qualys SSL Test к нему нет замечаний.
                                          0
                                          Спасибо за информацию. Проверил, у меня он есть в списке.

                                          Удивился, т. к. rehashing был в 2010, а class 1 они подписывали старой цепочкой (от старого root ca с sha-1). Как сейчас — не знаю.
                                          0
                                          А в JRE они вообще есть?
                                            0
                                            В oracle jdk 8 не нашел. Кажется, раньше мы добавляли их root ca отдельно, но запамятовал, т. к. сейчас используем comodo, который есть из коробки. А наличие в openjdk зависит от политики дистрибутива, кто-то генерирует на основе mozilla ca-certificates, кто-то берёт cacerts по умолчанию.
                                              0
                                              По-моему их там никогда не было, вот и удивился.
                                          0
                                          Любопытно. Ждут нормального распространения этого сертификата по системам или просто забыли создать свежие промежуточные сертификаты?

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое