Haruskah muatan data UDP termasuk CRC?

Untuk perusahaan tempat saya bekerja, saya harus mengimplementasikan penerima soket yang sebagian besar mengambil data dalam bentuk UDP melalui koneksi lokal dari beberapa perangkat keras sensor khusus. Data yang dimaksud adalah paket UDP yang dibentuk dengan baik, tetapi yang menarik, data payload selalu berakhir dengan sebuah CRC16 checksum yang dibentuk menggunakan sisa data.

Saya menerapkan cek pada akhir saya, sesuai spesifikasi, tapi saya selalu bertanya-tanya apakah ini perlu. Lagi pula, bukankah protokol UDP itu sendiri membawa CRC 16-bit? Oleh karena itu, meskipun paket UDP dapat hilang atau rusak, saya mendapat kesan bahwa mereka tidak dapat rusak tanpa dibuang oleh perangkat keras jaringan sebelum mereka mencapai proses OS. Atau ada beberapa kasus penggunaan khusus yang saya lewatkan?

Perlu ditambahkan bahwa saya bekerja di industri pertahanan, yang saya yakin Anda bisa bayangkan, suka bersikap sangat eksplisit tentang hal-hal seperti ini, jadi saya bertanya-tanya apakah itu hanya kasus "OCD keamanan". ..

security networking data-integrity

— Xenoprimate
sumber

Jika ini untuk tujuan keamanan, bukan hanya tentang mencegah korupsi tidak disengaja, Anda perlu menggunakan MAC, yang setara dengan checksum.

— CodesInChaos

Checksum UDP hanya baik untuk data yang disuntikkan ke paket UDP. Apa yang sebenarnya menciptakan checksum? Apa yang menggunakan checksum? Apakah ini digunakan untuk memastikan integritas sebelum paket UDP dibuat atau mungkin dibawa bersama dengan paket untuk memastikan bahwa ia mempertahankan integritas ketika mengalir melalui sistem lain? Tanpa pemahaman yang lebih luas tentang komponen sistem Anda dan bagaimana data dibuat, diubah, dan digunakan, saya tidak yakin bahwa pertanyaan Anda dapat dijawab.

— Thomas Owens

@ThomasOwens Data dikirim dari perangkat yang berasal back-to-back ke perangkat keras penerima. Tidak ada perantara. Checksum dibuat oleh originator sebagai langkah terakhir sebelum mengirim.

— Xenoprimate

Jawaban:

Protokol UDP tidak menjamin bahwa pesan yang disampaikan dalam rangka atau disampaikan sama sekali, tapi itu tidak menjamin bahwa pesan-pesan yang tidak bisa dikirim secara lengkap dan tidak berubah dengan secara otomatis termasuk checksum 16-bit. Itu berarti menambahkan checksum 16-bit lain pada lapisan aplikasi biasanya berlebihan.

...biasanya....

Pertama, dengan IPv4 (bukan IPv6), checksum adalah opsional . Itu berarti Anda mungkin menggunakan konfigurasi eksotis yang tidak melakukan pembuatan dan validasi checksum (tetapi dalam hal ini Anda harus memperbaiki tumpukan jaringan Anda alih-alih juri-mencurangi ini pada lapisan aplikasi).

Kedua, dengan checksum 16bit, ada peluang 65536 bahwa ada pesan acak yang kebetulan memiliki checksum yang valid. Ketika margin kesalahan ini terlalu besar untuk kasus penggunaan Anda (dan dalam industri pertahanan saya bisa membayangkan beberapa di mana itu berada), menambahkan checksum CRC-16 lain akan semakin menguranginya. Tetapi dalam hal ini Anda mungkin mempertimbangkan untuk menggunakan intisari pesan yang tepat seperti SHA-256, bukan CRC-16. Atau lanjutkan dan gunakan tanda tangan kriptografi nyata. Ini melindungi tidak hanya terhadap korupsi acak tetapi juga korupsi yang disengaja oleh penyerang.

Ketiga, tergantung dari mana data berasal dan ke mana data itu pergi, mungkin rusak sebelum atau setelah dikirim melalui jaringan. Dalam hal itu checksum tambahan di dalam pesan mungkin melindungi integritas pesan lebih dari sekadar antara dua host jaringan.

— Philipp
sumber

Mengapa kriptografis ? Kendala yang digunakan dalam merancang hash kriptografi tidak sama dengan yang digunakan dalam mendesain hash yang digunakan dalam transmisi (misalnya, menjadi sumber daya intensif adalah fitur untuk hash kriptografi dan dan masalah dalam transmisi).

— Pemrogram

@Programmer Saya akui bahwa pilihan kata mungkin menyesatkan. Saya menggantinya dengan "intisari pesan yang tepat". Fungsi message digest jauh lebih lama, membuat tabrakan tidak sengaja jadi tidak mungkin sehingga mereka bisa dianggap mustahil untuk tujuan praktis.

— Philipp

Ia berusaha untuk memastikan bahwa pesan tidak berubah, tetapi checksum yang digunakan dalam UDP agak lemah. Sementara kemungkinan pesan acak memiliki checksum yang valid memang 1 dalam 65536 untuk semua checksum 16-bit, langkah-langkah yang lebih berguna melibatkan jumlah bit yang terdeteksi diatur baik secara acak atau dalam sebuah ledakan, dan semua checksum tidak melakukan sama sesuai dengan metrik ini.

— Ben Voigt

@AProgrammer Kriptografi Cryptographic (MD5, SHA-1/2/3, ...) bertujuan semurah mungkin sambil memastikan properti keamanan seperti resistensi tabrakan. Biasanya mereka dapat memproses beberapa ratus MB per detik, sehingga mereka seharusnya tidak menjadi hambatan untuk apa pun yang kurang dari koneksi Gbit. Mereka masih lebih lambat daripada banyak yang non kriptografi yang tidak perlu resistensi tabrakan. Hanya hash kata sandi (PBKDF2, bcrypt, scrypt, Argon, ...) yang bertujuan menjadi mahal untuk dihitung.

— CodesInChaos

Namun, UDP memang menyediakan checksum.

Checksum UDP hanya 16 bit. Itu berarti peluang 1 dari 65536 paket korup melewati checksum.
dalam UDP melalui IPv4, checksum adalah opsional, sehingga pengirim secara teoritis dapat mengirim paket tanpa checksum.
Checksum mencakup informasi IP / port serta data. Meskipun ini berguna untuk menjatuhkan paket dengan alamat yang rusak, itu berarti bahwa jika paket melewati NAT, checksum harus dihitung ulang oleh NAT.
Checksum hanya melindungi data saat bepergian dalam paket UDP. Checkum level aplikasi dapat melindungi data ujung ke ujung saat melewati sistem yang lebih kompleks.
Checksum UDP clealy hanya memberi tahu Anda bahwa paket dihasilkan oleh implementasi UDP. Itu tidak memberi tahu Anda bahwa itu berasal dari sensor Anda. Sebaliknya, checksum level aplikasi dapat membantu menolak paket yang valid UDP tetapi berasal dari beberapa sumber lain.

Jadi saya dapat melihat alasan yang sah untuk tidak mempercayai checksum UDP tetapi sama-sama tidak mempercayai checksum UDP dan kemudian mengimplementasikan checksum yang sama lemahnya pada level aplikasi tampaknya aneh.

Ada kemungkinan bahwa orang yang memilih protokol itu tidak tahu bahwa UDP menyediakan checksum atau bahwa protokol tersebut sebenarnya merupakan varian sedikit dari yang dirancang untuk dijalankan pada media yang tidak menyediakan checksum.

PS karena pos ini ditandai keamanan, ketahuilah bahwa checksum yang dimaksud dirancang untuk melindungi terhadap perubahan yang tidak disengaja. Melindungi dari modifikasi atau spoofing yang disengaja membutuhkan penggunaan fungsi hash kriptografi yang tahan terhadap tabrakan / preimage yang disengaja dan penggunaan beberapa mekanisme (misalnya tanda tangan yang dibuat menggunakan kunci publik) untuk memverifikasi hash itu sendiri belum dimodifikasi.

— Peter Green
sumber