Должны ли данные полезной нагрузки UDP включать CRC?

16

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

Я реализовал проверку на своем конце, согласно спецификации, но я всегда задавался вопросом, было ли это необходимо. В конце концов, сам протокол UDP не несет 16-битный CRC? Поэтому, хотя UDP-пакеты могут быть потеряны или вышли из строя, у меня сложилось впечатление, что они не могут быть повреждены без их удаления сетевым оборудованием до того, как они достигнут процессов ОС. Или я пропускаю какой-то особый вариант использования?

Стоит добавить, что я работал в оборонной промышленности, которая, как я уверен, вы можете себе представить, любит быть сверхъестественной во всем, как это, поэтому мне интересно, был ли это случай «безопасности OCD». ..

Xenoprimate
источник
2
Если это в целях безопасности, а не только для предотвращения случайного повреждения, вам нужно использовать MAC, который является ключевым эквивалентом контрольной суммы.
CodesInChaos
1
Контрольная сумма UDP подходит только для данных, которые были введены в пакет UDP. Что на самом деле создает контрольную сумму? Что использует контрольную сумму? Используется ли он для обеспечения целостности перед созданием пакета UDP или, возможно, переносится вместе с пакетом, чтобы обеспечить его целостность при прохождении через другие системы? Без более широкого понимания компонентов вашей системы и того, как данные создаются, преобразуются и используются, я не уверен, что ваш вопрос отвечает.
Томас Оуэнс
@ThomasOwens Данные были отправлены с устройства-источника обратно на устройство-получатель. Нет среднего человека. Контрольная сумма была создана отправителем как последний шаг перед отправкой.
Ксенопримат

Ответы:

23

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

...обычно....

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

Во-вторых, с 16-битной контрольной суммой есть вероятность того, что абсолютно случайное сообщение с допустимой контрольной суммой будет иметь 65536 вероятностей. Когда этот предел погрешности слишком велик для вашего варианта использования (а в оборонной промышленности я мог бы представить несколько, где он есть), добавление еще одной контрольной суммы CRC-16 еще больше уменьшит ее. Но в этом случае вы можете рассмотреть возможность использования правильного дайджеста сообщений, такого как SHA-256 вместо CRC-16. Или пройти весь путь и использовать настоящую криптографическую подпись. Это защищает не только от случайной коррупции, но и от преднамеренной коррупции со стороны злоумышленника.

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

Philipp
источник
3
Почему криптографический ? Ограничения, используемые при разработке криптографических хэшей, не совпадают с теми, которые используются при разработке хэшей, используемых при передаче (например, ресурсоемкость является функцией криптографических хэшей и, следовательно, проблемой при передаче).
AProgrammer
1
@AProgrammer Я признаю, что выбор слов мог вводить в заблуждение. Я заменил его на «правильный дайджест сообщения». Функции дайджеста сообщений намного длиннее, что делает случайные коллизии настолько маловероятными, что их можно считать невозможными для практических целей.
Филипп
2
Он пытается обеспечить неизменность сообщений, но контрольная сумма, используемая в UDP, довольно слабая. Хотя вероятность случайного сообщения, имеющего действительную контрольную сумму, действительно равна 1 в 65536 для всех 16-разрядных контрольных сумм, более полезные меры включают обнаруживаемое количество перестановок битов, расположенных либо случайно, либо в пакете, и все контрольные суммы не выполняют одинаково в соответствии с этот показатель.
Бен Фойгт
1
@AProgrammer Криптографические хэши (MD5, SHA-1/2/3, ...) стремятся быть как можно дешевле, обеспечивая при этом такие защитные свойства, как устойчивость к столкновениям. Обычно они могут обрабатывать несколько сотен МБ в секунду, поэтому они не должны быть узким местом для чего-то меньшего, чем соединения Gbit. Они все еще медленнее, чем многие не криптографические, которые не должны быть устойчивыми к столкновениям. Только пароль хэши (PBKDF2, Bcrypt, Scrypt, Аргон, ...) стремиться быть дорогими , чтобы вычислить.
CodesInChaos
12

Однако UDP предоставляет контрольную сумму.

  1. Контрольная сумма UDP составляет всего 16 бит. Это означает 1 из 65536 вероятности того, что поврежденный пакет пройдет контрольную сумму.
  2. в UDP через IPv4 контрольная сумма является необязательной, поэтому теоретически отправитель может в конечном итоге отправить пакет без контрольной суммы.
  3. Контрольная сумма охватывает информацию об IP / порте, а также данные. Хотя это полезно при отбрасывании пакетов с поврежденными адресами, это означает, что, если пакет проходит через NAT, контрольная сумма должна быть пересчитана NAT.
  4. Контрольная сумма защищает данные только во время их перемещения в пакете UDP. Контрольная сумма уровня приложения может защитить данные от начала до конца, когда они проходят через более сложную систему.
  5. Контрольная сумма UDP очищает только то, что пакет был сгенерирован реализацией UDP. Это не говорит вам, что это произошло от вашего датчика. С другой стороны, контрольная сумма уровня приложения может помочь отклонить пакеты, которые являются действительными UDP, но получены из какого-то другого источника.

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

Существует вероятность того, что человек, разрабатывающий протокол, просто не знал, что UDP предоставил контрольные суммы, или что протокол на самом деле является небольшим вариантом протокола, разработанного для работы на носителе, который не предоставляет контрольные суммы.

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

Питер Грин
источник