Tải trọng dữ liệu UDP có nên bao gồm CRC không?


16

Đối với một công ty tôi từng làm việc, tôi đã phải triển khai một bộ thu ổ cắm chủ yếu lấy dữ liệu ở dạng UDP qua kết nối cục bộ từ một số phần cứng cảm biến chuyên dụng. Dữ liệu được đề cập là một gói UDP được định dạng tốt, nhưng thật thú vị, tải trọng dữ liệu luôn kết thúc bằng tổng kiểm tra CRC16 được hình thành bằng cách sử dụng phần còn lại của dữ liệu.

Tôi đã thực hiện kiểm tra vào cuối của tôi, theo thông số kỹ thuật, nhưng tôi luôn tự hỏi nếu điều này là cần thiết. Rốt cuộc, bản thân giao thức UDP có mang CRC 16 bit không? Do đó, mặc dù các gói UDP có thể bị mất hoặc không theo thứ tự, tôi có cảm tưởng rằng chúng không thể bị hỏng mà không bị phần cứng mạng loại bỏ trước khi chúng tiếp cận các quy trình của HĐH. Hoặc có một số trường hợp sử dụng đặc biệt tôi đang thiếu?

Thật đáng để nói thêm rằng tôi đã làm việc trong ngành công nghiệp quốc phòng, điều mà tôi chắc chắn bạn có thể tưởng tượng, thích siêu rõ ràng về mọi thứ như thế này, vì vậy tôi tự hỏi liệu đó có phải chỉ là một trường hợp "bảo mật OCD" hay không. ..


2
Nếu đó là vì mục đích bảo mật, không chỉ là ngăn ngừa tham nhũng vô tình, bạn cần sử dụng MAC, tương đương với khóa của tổng kiểm tra.
CodeInChaos

1
Tổng kiểm tra UDP chỉ tốt cho dữ liệu được đưa vào gói UDP. Điều gì thực sự tạo ra tổng kiểm tra? Những gì sử dụng tổng kiểm tra? Được sử dụng để đảm bảo tính toàn vẹn trước khi gói UDP được tạo hoặc có thể được mang theo cùng với gói để đảm bảo rằng nó duy trì tính toàn vẹn khi nó chảy qua các hệ thống khác? Nếu không có sự hiểu biết rộng hơn về các thành phần trong hệ thống của bạn và cách dữ liệu được tạo, biến đổi và sử dụng, tôi không chắc chắn rằng câu hỏi của bạn có thể trả lời được.
Thomas Owens

@ThomasOwens Dữ liệu được gửi từ thiết bị gốc trở lại phần cứng nhận. Không có đàn ông trung lưu. Tổng kiểm tra được tạo bởi người khởi tạo như là bước cuối cùng trước khi gửi.
Xenoprimate

Câu trả lời:


23

Giao thức UDP không đảm bảo rằng thông điệp được phân phối theo thứ hoặc giao tại tất cả, nhưng nó đảm bảo rằng những thông điệp mà làm được giao đầy đủ và không thay đổi bằng cách tự động bao gồm một checksum 16-bit. Điều đó có nghĩa là việc thêm một tổng kiểm tra 16 bit khác trên lớp ứng dụng thường là dự phòng.

...thông thường....

Đầu tiên, với IPv4 (không phải IPv6), tổng kiểm tra là tùy chọn . Điều đó có nghĩa là bạn có thể đang sử dụng một cấu hình kỳ lạ không thực hiện việc tạo và xác nhận tổng kiểm tra (nhưng trong trường hợp đó, bạn nên sửa ngăn xếp mạng của mình thay vì xử lý lỗi này trên lớp ứng dụng).

Thứ hai, với tổng kiểm tra 16 bit, có một khả năng trong 65536 có một thông báo hoàn toàn ngẫu nhiên xảy ra để có một tổng kiểm tra hợp lệ. Khi biên độ sai số này quá lớn đối với trường hợp sử dụng của bạn (và trong ngành công nghiệp quốc phòng, tôi có thể tưởng tượng một vài nơi nó xảy ra), việc thêm một tổng kiểm tra CRC-16 sẽ làm giảm thêm. Nhưng trong trường hợp đó, bạn có thể cân nhắc sử dụng thông báo tiêu hóa phù hợp như SHA-256 thay vì CRC-16. Hoặc đi tất cả các cách và sử dụng một chữ ký mật mã thực sự. Điều này bảo vệ không chỉ chống lại tham nhũng ngẫu nhiên mà còn tham nhũng có chủ ý của một kẻ tấn công.

Thứ ba, tùy thuộc vào nơi dữ liệu đến và nơi nó đến, nó có thể bị hỏng trước hoặc sau khi được gửi qua mạng. Trong trường hợp đó, tổng kiểm tra bổ sung bên trong tin nhắn có thể bảo vệ tính toàn vẹn của tin nhắn hơn là chỉ giữa hai máy chủ mạng.


3
Tại sao mật mã ? Các ràng buộc được sử dụng trong thiết kế băm mật mã không giống như các ràng buộc được sử dụng trong thiết kế hàm băm được sử dụng trong truyền (ví dụ, sử dụng nhiều tài nguyên là một tính năng cho băm mật mã và vấn đề truyền tải).
AProgrammer

1
@AProgrammer Tôi thừa nhận rằng việc lựa chọn từ ngữ có thể đã gây hiểu nhầm. Tôi đã thay thế nó bằng "thông báo thích hợp". Các chức năng tiêu hóa tin nhắn dài hơn rất nhiều, khiến các va chạm vô tình trở nên khó có thể giả định là không thể cho các mục đích thực tế.
Philipp

2
cố gắng đảm bảo rằng các tin nhắn không thay đổi, nhưng tổng kiểm tra được sử dụng trong UDP khá yếu. Mặc dù khả năng một tin nhắn ngẫu nhiên có tổng kiểm tra hợp lệ thực sự là 1 trên 65536 cho tất cả các tổng kiểm tra 16 bit, các biện pháp hữu ích hơn liên quan đến số lần lật bit có thể phát hiện được sắp xếp ngẫu nhiên hoặc theo đợt và tất cả các tổng kiểm tra không thực hiện như nhau theo số liệu này.
Ben Voigt

1
@AProgrammer Băm mật mã (MD5, SHA-1/2/3, ...) nhằm mục đích rẻ nhất có thể trong khi vẫn đảm bảo các đặc tính bảo mật như chống va chạm. Thông thường, họ có thể xử lý vài trăm MB mỗi giây, vì vậy họ không nên là nút cổ chai cho mọi thứ ít hơn kết nối Gbit. Chúng vẫn chậm hơn so với nhiều loại không mật mã không cần phải chống va chạm. Chỉ băm mật khẩu (PBKDF2, bcrypt, scrypt, Argon, ...) nhằm mục đích tốn kém để tính toán.
CodeInChaos

12

UDP không cung cấp tổng kiểm tra, tuy nhiên.

  1. Tổng kiểm tra UDP chỉ có 16 bit. Điều đó có nghĩa là cơ hội 1 trong 65536 của một gói bị hỏng đi qua tổng kiểm tra.
  2. trong UDP qua IPv4, tổng kiểm tra là tùy chọn, do đó về mặt lý thuyết, người gửi có thể gửi một gói mà không cần kiểm tra.
  3. Tổng kiểm tra bao gồm thông tin IP / cổng cũng như dữ liệu. Mặc dù điều này rất hữu ích trong việc loại bỏ các gói có địa chỉ bị hỏng, điều đó có nghĩa là nếu gói đó đi qua NAT thì tổng kiểm tra phải được NAT tính toán lại.
  4. Tổng kiểm tra chỉ bảo vệ dữ liệu trong khi nó đang di chuyển trong gói UDP. Kiểm tra mức ứng dụng có thể bảo vệ dữ liệu từ đầu đến cuối khi nó đi qua một hệ thống phức tạp hơn.
  5. Tổng kiểm tra UDP rõ ràng chỉ cho bạn biết rằng gói được tạo bởi việc triển khai UDP. Nó không cho bạn biết rằng nó đến từ cảm biến của bạn. Mặt khác, tổng kiểm tra mức ứng dụng có thể giúp từ chối các gói là UDP hợp lệ nhưng đến từ một số nguồn khác.

Vì vậy, tôi có thể thấy những lý do chính đáng cho việc không tin tưởng vào tổng kiểm tra UDP nhưng cũng không tin vào tổng kiểm tra UDP và sau đó thực hiện một tổng kiểm tra yếu tương tự ở cấp ứng dụng có vẻ lạ.

Có khả năng người bỏ qua giao thức chỉ đơn giản là không biết rằng UDP cung cấp tổng kiểm tra hoặc giao thức đó thực sự là một biến thể nhỏ của một giao thức được thiết kế để chạy trên một phương tiện không cung cấp tổng kiểm tra.

PS vì bài đăng này được gắn thẻ bảo mật, hãy lưu ý rằng tổng kiểm tra được đề cập được thiết kế để bảo vệ chống lại những thay đổi vô ý. Bảo vệ chống sửa đổi hoặc giả mạo có chủ ý yêu cầu cả việc sử dụng các hàm băm mật mã có khả năng chống lại sự va chạm / tiền đề có chủ ý và sử dụng một số cơ chế (ví dụ: chữ ký được sử dụng khóa công khai) để xác minh bản băm chưa được sửa đổi.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.