Чи повинні корисні навантаження даних UDP включати CRC?

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

Я здійснив перевірку на своєму кінці відповідно до специфікації, але завжди цікавився, чи потрібно це. Зрештою, невже сам протокол UDP не містить 16-бітної CRC? Тому, хоча пакети UDP можуть бути втрачені або вийшли з ладу, у мене було враження, що вони не можуть бути пошкоджені, не відкинувшись мережевим обладнанням, перш ніж вони дістануться до процесів ОС. Або є якісь спеціальні випадки використання, які я пропускаю?

Варто додати, що я працював у галузі оборони, яка, як я впевнений, ви можете собі уявити, любить бути надто очевидним щодо всього подібного, тому мені цікаво, чи це був просто випадок "OCD безпеки". ..

security networking data-integrity

— Ксенопримат
джерело

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

— CodesInChaos

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

— Thomas Owens

@ThomasOwens Дані надсилалися від пристрою, що створює джерело, до обладнання, що приймає. Ні середніх. Контрольну суму створив оригінатор як останній крок перед надсиланням.

— Xenoprimate

Відповіді:

Протокол UDP не гарантує доставку повідомлень в порядку або доставляються на всіх, але гарантує , що ті повідомлення , які дійсно доставляються є повними і незмінними, автоматично включаючи 16-бітну контрольну суму. Це означає, що додавання ще 16-бітної контрольної суми до рівня додатків зазвичай є зайвим.

...зазвичай....

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

По-друге, з 16-бітовою контрольною сумою є шанс на 65536, що випадкове повідомлення має дійсну контрольну суму. Коли ця похибка занадто велика для ваших випадків використання (а в оборонній промисловості я можу уявити собі декілька, де вона є), додавання ще однієї контрольної суми CRC-16 ще більше зменшить її. Але в цьому випадку ви можете розглянути можливість використання правильного дайджеста повідомлень типу SHA-256 замість CRC-16. Або пройти весь шлях і використовувати справжній криптографічний підпис. Це захищає не тільки від випадкової корупції, але й навмисної корупції зловмисником.

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

— Філіп
джерело

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

— AProgrammer

@AProgrammer Я визнаю, що вибір слів міг бути оманливим. Я замінив його "правильним дайджестом повідомлень". Функції передачі повідомлень набагато довші, що робить випадкові зіткнення настільки малоймовірними, що їх можна вважати неможливими для практичних цілей.

— Філіп

Він намагається переконатися, що повідомлення не змінюються, але контрольна сума, що використовується в UDP, є досить слабкою. Хоча шанс випадкового повідомлення, що має дійсну контрольну суму, дійсно становить 1 на 65536 для всіх 16-бітових контрольних сум, більш корисні заходи передбачають виявлення кількості бітових переворотів, розташованих як випадковим чином, так і під час зйомки, і всі контрольні суми не працюють однаково відповідно до ця метрика.

— Бен Войгт

@AProgrammer Криптографічні хеші (MD5, SHA-1/2/3, ...) мають на меті бути максимально дешевими, забезпечуючи такі властивості безпеки, як стійкість до зіткнення. Зазвичай вони можуть обробляти кілька сотень МБ в секунду, тому вони не повинні бути вузьким місцем менше ніж Gbit-з'єднання. Вони все ще повільніше, ніж у багатьох не криптографічних, яким не потрібно стійкості до зіткнення. Тільки пароль хеші (PBKDF2, Bcrypt, Scrypt, Аргон, ...) прагнути бути дорогими , щоб обчислити.

— CodesInChaos

Однак UDP забезпечує контрольну суму.

Контрольна сума UDP становить лише 16 біт. Це означає, що 1 на 65536 шанс корумпованого пакету пройти контрольну суму.
в UDP через IPv4 контрольна сума необов'язкова, тому відправник теоретично може в кінцевому підсумку відправити пакет без контрольної суми.
Контрольна сума охоплює інформацію про IP / порт, а також дані. Хоча це корисно для викидання пакетів з пошкодженими адресами, це означає, що якщо пакет проходить через NAT, контрольна сума повинна бути перерахована NAT.
Контрольна сума захищає дані лише під час подорожі в пакеті UDP. Контрольна сума на рівні додатків може захищати дані від кінця до кінця, коли вони проходять через більш складну систему.
Чиста контрольна сума UDP говорить вам лише про те, що пакет був створений реалізацією UDP. Це не говорить вам про те, що він походить від вашого датчика. З іншого боку, контрольна сума рівня додатків може допомогти відхилити пакети, які є дійсними UDP, але прийшли з іншого джерела.

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

Існує ймовірність, що особа, яка розробляє протокол, просто не знала, що UDP надає контрольні суми, або що протокол насправді є незначним варіантом, призначеного для запуску на носій, який не забезпечує контрольні суми.

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

— Пітер Грін
джерело