Каково значение контрольных сумм MD5, если потенциально можно было бы манипулировать самим хэшем MD5?

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

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

Как контрольные суммы MD5 могут обеспечить какую-либо защиту от намеренно измененных файлов, если нет способа узнать, была ли скомпрометирована сама контрольная сумма?

Я слышал, что это позволяет [...] также обнаруживать любые вредоносные изменения.

Ну, тогда вы слышали неправильно. Контрольные суммы MD5 (или SHA или что-то еще) предоставляются (в частности, рядом со ссылками на скачивание ) только для проверки правильности загрузки. Единственное, что они хотят гарантировать, это то, что у вас тот же файл, что и на сервере. Ни больше ни меньше. Если сервер скомпрометирован, вы SOL. Это действительно так просто.

Решение, используемое некоторыми системами управления пакетами, такими как dpkg, заключается в подписывании хеша : используйте хеш в качестве входных данных для одного из алгоритмов подписывания открытого ключа. См. Http://www.pgpi.org/doc/pgpintro/#p12.

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

Ваше предположение верно. Хотя есть исключение. Если сервер, предоставляющий файл, и страница, на которой находится хеш, не управляются одним и тем же объектом. В этом случае разработчик программного обеспечения может захотеть сказать: «Эй, люди скачивают это с этого места, но верят только, если hash = xxxx». (Это может быть полезно для CDN в качестве примера). Я думаю, это было причиной, почему кто-то сделал это в первую очередь. Чем другие просто следовали, думая, как круто было бы показать хэш. Даже не думая, насколько это полезно, даже файл и хеш не находятся в одном месте.

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

Иногда контрольные суммы предоставляются надежно, а загрузка - нет. Так как MD5 сломан , контрольные суммы MD5 безопасности слабее, чем более безопасные контрольные суммы, но до того, как MD5 был сломан, надежно предоставленный MD5 (например, тот, который был подписан с PGP или GPG или Gatekeeper, или извлечен по HTTPS), который соответствовал MD5 загрузка была убедительным доказательством того, что полученная загрузка была доступной для сервера.

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

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

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

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

Выдержка из приведенной выше ссылки: «Приложение KeRanger было подписано с действующим сертификатом разработки приложений для Mac; следовательно, оно смогло обойти защиту Apple Gatekeeper». ... »С тех пор Apple аннулировала испорченный сертификат и обновила антивирусную сигнатуру XProtect, а Transmission Project удалил вредоносные программы установки со своего веб-сайта. Palo Alto Networks также обновила фильтрацию URL-адресов и предотвращение угроз, чтобы предотвратить воздействие KeRanger на системы. Технический анализ

Два инсталлятора Transmission, зараженные KeRanger, были подписаны законным сертификатом, выданным Apple. Разработчик перечислил этот сертификат турецкой компании с идентификатором Z7276PX673, который отличался от идентификатора разработчика, использовавшегося для подписи предыдущих версий установщика Transmission. В информации о подписи кода мы обнаружили, что эти установщики были созданы и подписаны утром 4 марта. "

Приложения 2016 года:

@ Cornstalks: Re. Ваш комментарий ниже: Неверно. Как в настоящее время отмечается в статье Википедии об атаках на столкновения, на которую вы ссылаетесь: «В 2007 году была обнаружена атака столкновения с выбранным префиксом на MD5», и «злоумышленник может выбрать два произвольно разных документа, а затем добавить различные вычисленные значения, которые в результате дают целое». документы, имеющие одинаковое значение хеш-функции. " Таким образом, даже если MD5 предоставляется безопасно и злоумышленник не может изменить его, злоумышленник все равно МОЖЕТ использовать атаку коллизии с выбранным префиксом с вредоносным ПО с выбранным префиксом, что означает, что MD5 НЕ безопасен для криптографических целей. Во многом это объясняется тем, что US-CERT заявил, что MD5 «следует считать криптографически взломанным и непригодным для дальнейшего использования».

Еще пара вещей: CRC32 - это контрольная сумма. MD5, SHA и т. Д. - это больше, чем контрольные суммы; они предназначены для надежных хэшей. Это означает, что они должны быть очень устойчивы к атакам столкновений. В отличие от контрольной суммы, защищенный хэш защищенного хэша защищает от атаки «человек посередине» (MITM), когда MITM находится между сервером и пользователем. Он не защищает от атаки, когда сам сервер подвергается риску. Чтобы защититься от этого, люди обычно полагаются на что-то вроде PGP, GPG, Gatekeeper и т. Д.

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

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

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

Возможное решение - использование подписанных файлов.

(Кстати: MD5 нигде небезопасен и не должен больше использоваться.)

Как контрольные суммы MD5 могут обеспечить какую-либо защиту от намеренно измененных файлов, если нет способа узнать, была ли скомпрометирована сама контрольная сумма?

Вы совершенно правы. Таким образом, цель состоит в том, чтобы сделать ваше «если» неправильным - если мы знаем, что безопасный криптографический хеш файла не скомпрометирован, то мы знаем, что файл также не скомпрометирован.

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

Если ваш веб-сайт использует HTTPS или вы подписываете хэш gpg, ваш файл также может быть (в основном) защищен от сетевых атак, таких как вредоносные точки доступа Wi-Fi, мошеннические выходные узлы Tor или NSA.

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

Если вы хотите «привязать» файл к чему-то внешнему, например, к автору, машине и т. Д., Его необходимо подписать , используя процесс типа PKI с сертификатами. Автор файла и т. Д. Может подписать файл своим закрытым ключом, и вы можете проверить подписи открытым ключом, который должен быть общедоступным, сам подписан ЦС и доверять вам и автору и быть загружаемым, предпочтительно из несколько мест.

Изменение файла сделает подпись недействительной, так что это также можно использовать для проверки целостности файла.

Хэши указывают, отличается ли ваша версия файла («загрузка») от версии сервера. Они не дают никаких гарантий подлинности файла.

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

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

Что мешает мистеру "A.Hacker" просто изменить файл, а затем подписать его своим личным ключом?

Чтобы проверить файл, вам нужно сравнить его хеш с тем, который вы получили, расшифровав соответствующую цифровую подпись. Если вы считаете, что файл принадлежит «IMAwesome», то вы расшифровывает хеш, используя его ключ, и хеш не соответствует файлу, поскольку хеш был зашифрован с использованием ключа A.Hacker.

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

Но как мы можем получить открытый ключ IMAwesome? Как мы можем гарантировать, что когда мы получили его / ее ключ, на самом деле ключ А.Хакера не обслуживался скомпрометированным сервером или атакой «человек посередине»? Именно здесь появляются цепочки сертификатов и доверенные корневые сертификаты, ни один из которых не является полностью безопасным [1] решением проблемы, и оба из них, вероятно, должны быть хорошо объяснены в Википедии и других вопросах, касающихся SO.

[1] После проверки корневые сертификаты, поставляемые с операционной системой Microsoft на моем рабочем ПК, включают сертификат правительства США. Любой человек , имеющий доступ к соответствующему секретному ключу от кашля NSA кашля поэтому может служить содержание в моем веб - браузер , который передает «есть висячий замок в адресной строке» проверки. Сколько людей на самом деле потрудится нажать на замок и посмотреть , какая пара ключей используется для «защиты» соединения?

Как контрольные суммы MD5 могут обеспечить какую-либо защиту от намеренно измененных файлов, если нет способа узнать, не была ли контрольная сумма также не скомпрометирована?

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

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

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

Недавно я обнаружил замечательное программное обеспечение для архивирования библиотек под названием ACE Audit manager, которое в основном представляет собой Java-приложение, предназначенное для отслеживания изменений в файловой системе. Он регистрирует изменения через изменения MD5. И он работает по принципу, аналогичному моему специальному процессу - сохранению контрольных сумм в базе данных - но он продвигается дальше, но создает контрольную сумму MD5 контрольных сумм MD5, известную как хеш-дерево или дерево Меркле .

Допустим, у вас есть 5 файлов в коллекции. Затем эти 5 файлов в диспетчере аудита ACE получат еще одну - назовем ее «родительской» - контрольную сумму, которая является хешем, сгенерированным из 5 контрольных сумм MD5 каждого файла. Таким образом, если кто-то вмешается только в один файл, хэш для файла изменится, как и хэш для всей «родительской» коллекции.

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

скорость

Часто люди обнаруживают, что гораздо быстрее (а) загрузить большой файл из ненадежной «соседней» сети доставки контента (CDN), зеркального сайта, торрент-пиров и т. Д., А также загрузить соответствующий файл короткой контрольной суммы (часто SHA256; устаревшее программное обеспечение). часто используется MD5) из нескольких надежных источников. Они считают, что это невыносимо медленно (б) загрузить весь большой файл напрямую из надежного источника.

Проверка

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

модификация

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

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

Как сказал ранее cpast, если надежная криптографическая контрольная сумма передается по доверенному соединению, она может обеспечить безопасность (которая получается из доверенного соединения).

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

«С точки зрения безопасности криптографические хеши, такие как MD5, позволяют аутентифицировать данные, полученные с небезопасных зеркал. Хеш MD5 должен быть подписан или получен из безопасного источника (страница HTTPS) организации, которой вы доверяете». - https://help.ubuntu.com/community/HowToMD5SUM

Криптографические контрольные суммы являются важной частью практических сигнатур с открытым ключом (как реализовано в GnuPG и другом OpenPGP-совместимом программном обеспечении). Подписи с открытым ключом имеют некоторые преимущества перед контрольными суммами.

Я слышал, что эта [контрольная сумма MD5] позволяет [...] также легко обнаруживать любые вредоносные изменения.

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

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

Вот пример из реального мира, который может прояснить все это. Следующий отрывок особенно важен по этому вопросу:

Для более старых выпусков архивированных CD были сгенерированы только контрольные суммы MD5 [...]. Для более новых выпусков используются более новые и криптографически более надежные алгоритмы контрольной суммы (SHA1, SHA256 и SHA512)