Czy ładunki danych UDP powinny zawierać CRC?

W firmie, w której kiedyś pracowałem, musiałem zaimplementować odbiornik gniazdowy, który przeważnie pobierał dane w postaci UDP przez połączenie lokalne z jakiegoś specjalistycznego sprzętu czujnikowego. Dane, o których mowa, były dobrze uformowanym pakietem UDP, ale co ciekawe, ładunek danych zawsze kończył się sumą kontrolną CRC16 utworzoną przy użyciu reszty danych.

Zaimplementowałem kontrolę po mojej stronie, zgodnie ze specyfikacją, ale zawsze zastanawiałem się, czy to było konieczne. W końcu, czy sam protokół UDP nie zawiera 16-bitowego CRC? Dlatego chociaż pakiety UDP mogą zostać utracone lub przestarzałe, miałem wrażenie, że nie można ich uszkodzić bez odrzucenia przez sprzęt sieciowy, zanim dotrą do procesów systemu operacyjnego. A może brakuje mi jakiegoś specjalnego przypadku użycia?

Warto dodać, że pracowałem w przemyśle obronnym, który, jak jestem pewien, można sobie wyobrazić, lubi być bardzo precyzyjny w takich sprawach, więc zastanawiam się, czy to był tylko przypadek „bezpieczeństwa OCD”. ..

security networking data-integrity

— Xenoprimate
źródło

Jeśli służy to celom bezpieczeństwa, a nie tylko zapobieganiu przypadkowemu uszkodzeniu, musisz użyć MAC, który jest kluczowym odpowiednikiem sumy kontrolnej.

— CodesInChaos

Suma kontrolna UDP jest dobra tylko dla danych, które zostały wstrzyknięte do pakietu UDP. Co tak naprawdę tworzy sumę kontrolną? Do czego służy suma kontrolna? Czy służy on do zapewnienia integralności przed utworzeniem pakietu UDP, czy może jest przenoszony wraz z pakietem, aby zapewnić jego integralność podczas przepływu przez inne systemy? Bez szerszego zrozumienia składników systemu i tego, jak dane są tworzone, przetwarzane i wykorzystywane, nie jestem pewien, czy na twoje pytanie można odpowiedzieć.

— Thomas Owens

@ThomasOwens Dane zostały wysłane z urządzenia źródłowego tyłem do siebie do sprzętu odbierającego. Żadnych środkowych mężczyzn. Suma kontrolna została utworzona przez nadawcę jako ostatni krok przed wysłaniem.

— Xenoprimate,

Odpowiedzi:

Protokół UDP nie gwarantuje, że wiadomości są dostarczane na zamówienie lub dostarczane w ogóle, ale to nie gwarantuje, że te komunikaty, które mają dostać dostarczane są kompletne i niezmienione przez automatyczne tym kontrolną 16-bitowego. Oznacza to, że dodanie kolejnej 16-bitowej sumy kontrolnej na warstwie aplikacji jest zwykle zbędne.

...zazwyczaj....

Po pierwsze, w przypadku IPv4 (nie IPv6) suma kontrolna jest opcjonalna . Oznacza to, że korzystasz z egzotycznej konfiguracji, która nie generuje i nie sprawdza sumy kontrolnej (ale w takim przypadku powinieneś raczej naprawić stos sieciowy zamiast sędziować to na warstwie aplikacji).

Po drugie, z 16-bitową sumą kontrolną istnieje szansa na 65536, że przypadkowa wiadomość ma prawidłową sumę kontrolną. Kiedy ten margines błędu jest zbyt duży dla twojego przypadku użycia (a w przemyśle obronnym mógłbym sobie wyobrazić kilka tam, gdzie jest), dodanie kolejnej sumy kontrolnej CRC-16 jeszcze bardziej ją zmniejszy. Ale w takim przypadku możesz rozważyć użycie odpowiedniego skrótu wiadomości, takiego jak SHA-256 zamiast CRC-16. Lub przejdź całą drogę i użyj prawdziwego podpisu kryptograficznego. Chroni to nie tylko przed przypadkowym uszkodzeniem, ale także umyślnym uszkodzeniem przez atakującego.

Po trzecie, w zależności od tego, skąd dane pochodzą i dokąd trafiają, mogą zostać uszkodzone przed lub po wysłaniu przez sieć. W takim przypadku dodatkowa suma kontrolna w komunikacie może chronić integralność wiadomości bardziej niż tylko między dwoma hostami sieciowymi.

— Philipp
źródło

Dlaczego kryptograficzny ? Ograniczenia stosowane przy projektowaniu skrótów kryptograficznych nie są takie same jak te stosowane przy projektowaniu skrótu używanego w transmisji (na przykład bycie intensywnym zasobem jest cechą skrótów kryptograficznych i problem z transmisją).

— AProgrammer

@AProgrammer Przyznaję, że wybór słów mógł wprowadzać w błąd. Zamieniłem go na „właściwe podsumowanie wiadomości”. Funkcje podsumowania wiadomości są znacznie dłuższe, co sprawia, że przypadkowe kolizje są tak mało prawdopodobne, że można je założyć jako niemożliwe ze względów praktycznych.

— Philipp

To stara , aby upewnić się, że wiadomości są niezmienione, ale suma kontrolna używana w UDP jest raczej słaby. Podczas gdy szansa, że losowy komunikat będzie miał prawidłową sumę kontrolną, faktycznie wynosi 1 na 65536 dla wszystkich 16-bitowych sum kontrolnych, bardziej przydatne miary obejmują wykrywalną liczbę odwróconych bitów rozmieszczonych losowo lub w serii, a wszystkie sumy kontrolne nie działają jednakowo zgodnie z ta metryka.

— Ben Voigt,

@AProgrammer Skrypty kryptograficzne (MD5, SHA-1/2/3, ...) starają się być tak tanie, jak to możliwe, zapewniając jednocześnie właściwości bezpieczeństwa, takie jak odporność na kolizje. Zazwyczaj mogą przetwarzać kilkaset MB na sekundę, więc nie powinny stanowić wąskiego gardła w przypadku mniej niż połączeń Gbit. Są nadal wolniejsze niż wiele niekryptograficznych, które nie muszą być odporne na zderzenia. Tylko hasło hashe (PBKDF2, bcrypt, scrypt, Argon ...) mają być drogie, aby obliczyć.

— CodesInChaos

UDP zapewnia jednak sumę kontrolną.

Suma kontrolna UDP wynosi tylko 16 bitów. Oznacza to szansę 1 na 65536, że uszkodzony pakiet przejdzie sumę kontrolną.
w UDP przez IPv4 suma kontrolna jest opcjonalna, więc teoretycznie nadawca może teoretycznie wysłać pakiet bez sumy kontrolnej.
Suma kontrolna obejmuje informacje o adresie IP / porcie, a także dane. Chociaż jest to przydatne w usuwaniu pakietów z uszkodzonymi adresami, oznacza to, że jeśli pakiet przechodzi przez NAT, suma kontrolna musi zostać ponownie obliczona przez NAT.
Suma kontrolna chroni dane tylko podczas podróży w pakiecie UDP. Suma kontrolna na poziomie aplikacji może chronić dane od końca do końca, gdy przechodzi przez bardziej złożony system.
Suma kontrolna UDP wyraźnie mówi tylko, że pakiet został wygenerowany przez implementację UDP. Nie mówi ci, że pochodzi z twojego czujnika. Z drugiej strony suma kontrolna na poziomie aplikacji może pomóc w odrzuceniu pakietów, które są poprawne UDP, ale pochodzą z innego źródła.

Widzę więc uzasadnione powody, by nie ufać sumie kontrolnej UDP, ale równie nie ufać sumie kontrolnej UDP, a następnie implementować podobnie słabą sumę kontrolną na poziomie aplikacji wydaje się dziwne.

Istnieje możliwość, że osoba opracowująca protokół po prostu nie wiedziała, że UDP zapewnia sumy kontrolne lub że protokół jest w rzeczywistości niewielkim wariantem takiego, który jest przeznaczony do pracy na nośniku, który nie zapewnia sum kontrolnych.

PS, ponieważ ten post jest oznaczony jako bezpieczeństwo, pamiętaj, że sumy kontrolne mają na celu ochronę przed przypadkowymi zmianami. Ochrona przed celową modyfikacją lub fałszowaniem wymaga zarówno użycia funkcji skrótu kryptograficznego, które są odporne na celowe zderzenia / preimages, jak i użycia niektórych mechanizmów (np. Podpisów wykonanych za pomocą klucza publicznego) w celu sprawdzenia, że same skróty nie zostały zmodyfikowane.

— Peter Green
źródło