Яке значення контрольних сум 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 від впливу на системи. Технічний аналіз

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

Додаток 2016 року:

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

Ще кілька речей: CRC32 - контрольна сума. MD5, SHA тощо - це більше, ніж контрольні суми; вони призначені для безпечних хешей. Це означає, що вони повинні бути дуже стійкими до атак зіткнення. На відміну від контрольної суми, надійно переданий захищений хеш захищає від атаки "людина-в-середині" (MITM), коли MITM знаходиться між сервером і користувачем. Він не захищає від атаки, коли сам сервер порушений. Для захисту від цього люди зазвичай покладаються на щось на зразок PGP, GPG, Gatekeeper тощо.

Це точна причина, коли розміщені контрольні суми часто містять застереження із твердженням: "Це не може захистити від зловмисної модифікації файлу". Отже, коротка відповідь - "вони не можуть забезпечити будь-якого захисту від навмисно зміненого файлу" (хоча, якщо сторінка доставлена ​​через HTTPS, сама HTTPS захищає від модифікації; якщо файл не доставляється через HTTPS, але контрольну суму є, то це може допомогти деяким, але це не звичайний випадок). Хто б вам не сказав, що контрольні суми, розміщені на веб-сторінках, використовуються для виявлення шкідливих модифікацій, був помилковим, оскільки це не роль, яку вони можуть виконувати; все, що вони роблять, - це захист від випадкової корупції та лінивої зловмисної корупції (якщо хтось не намагається перехопити сторінку, яка дає вам контрольну суму).

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

Це справді проблема. Показати контрольні суми на тому самому сайті, що і файл для завантаження, не є безпечним. Людина, яка може змінити файл, також може змінити контрольну суму. Контрольну суму слід показувати через повністю розділену систему, але це навряд чи можливо, адже як безпечно повідомити користувача, де можна знайти контрольну суму.

Можливе рішення - використання підписаних файлів.

(BTW: MD5 небезпечний ніде і більше не повинен використовуватися.)

Як контрольні суми MD5 можуть забезпечити захист від навмисно змінених файлів, якщо немає можливості знати, чи була порушена сама контрольна сума?

Ви абсолютно правильні. Метою було б зробити помилку "якщо" - якщо ми знаємо, що захищений криптографічний хеш файлу не порушений, то ми знаємо, що файл також не є компрометованим.

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

Якщо ваш веб-сайт використовує HTTPS або ви підписуєте хеш- gpgфайл, ваш файл також може бути (в основному) захищений від зловмисників мережі, як-от шкідливі точки доступу до Wi-Fi, вихідні вузли вихідних тор або 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 секунд скріпкою для паперу.

швидкість

Часто люди вважають, що набагато швидше (a) завантажити великий файл з якоїсь недовіреної "сусідньої" мережі доставки вмісту (CDN), з дзеркального сайту, торрент-однолітків тощо, а також завантажити відповідний короткий файл контрольної суми (часто SHA256; старіше програмне забезпечення часто використовується MD5) з кількох надійних джерел. Вони вважають нестерпно повільним завантаження всього великого файлу безпосередньо з надійного джерела.

перевірка

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

модифікація

Ви маєте рацію, що коли Mallory зловмисно змінює великий файл, який сидить на якомусь веб-сайті для завантаження, Mallory також може зловмисно здійснити зловмисну ​​контрольну суму цього файлу на тому самому веб-сайті завантаження, щоб shasum (або md5sum) працював на цьому зловмисному файлі контрольної суми здається, підтверджує великий файл. Але цей файл контрольної суми не є єдиним, який завантажувач повинен використовувати для перевірки.

Коли завантажувач порівняє цей зловмисний файл контрольної суми з файлами контрольної суми, завантаженими з надійних джерел, якщо оригінальна контрольна сума проскочить навіть один раз, тоді завантажувач побачить, що все не підтверджується, і знатиме, що щось пішло не так.

Як раніше говорив cpast, якщо хороша криптографічна контрольна сума передається через надійне з'єднання, вона може забезпечити безпеку (яка походить від надійного з'єднання).

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

"З точки зору безпеки, криптографічні хеші, такі як MD5, дозволяють аутентифікувати дані, отримані з незахищених дзеркал. Хеш MD5 повинен бути підписаний або надходити з захищеного джерела (сторінки HTTPS) організації, якій ви довіряєте." - https://help.ubuntu.com/community/HowToMD5SUM

Криптографічні контрольні суми є важливою частиною практичного підпису на відкритому ключі (як це реалізовано в GnuPG та іншому сумісному OpenPGP програмному забезпеченні). Підписи на відкритому ключі мають деякі переваги перед контрольними сумами.

Я чув, що ця [контрольна сума MD5] дозволяє [...] також легко виявити будь-які шкідливі зміни.

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

Однак, якщо джерело не надає підпис хешу і надійний спосіб його перевірити , ви маєте рацію, захист від навмисно змінених файлів не надається , але хеш все ще корисний як контрольна сума проти випадкових корупція .

Ось приклад із реального світу, який може прояснити всю справу. Наступний уривок особливо важливий з цього приводу:

Для старих архівованих випусків CD генеруються лише контрольні суми MD5 [...] Для новіших випусків використовуються новіші та криптографічно сильніші алгоритми контрольної суми (SHA1, SHA256 та SHA512).