CRC phát hiện dữ liệu bị lỗi, vì sao không chứng minh dữ liệu đáng tin?

Một kết quả CRC khớp chỉ cho biết dữ liệu vượt qua phép kiểm tra tương ứng; nó không chứng minh dữ liệu đến từ người gửi đáng tin. CRC được dùng để phát hiện nhiều dạng sai hỏng do truyền hoặc lưu trữ. Khi có người cố ý sửa dữ liệu và tính lại mã kiểm tra, mục tiêu bảo vệ đã khác.

Phân biệt này quan trọng khi đọc thông báo “integrity check passed”. Cụm từ đó chỉ có ý nghĩa đầy đủ nếu biết cơ chế kiểm tra, phần dữ liệu được bao phủ và loại rủi ro mà hệ thống muốn ngăn chặn.

CRC tạo một giá trị kiểm tra từ chuỗi dữ liệu

RFC 3385 mô tả CRC như mã phát hiện lỗi được sử dụng rộng rãi trong truyền thông và ghi dữ liệu. Khả năng phát hiện phụ thuộc đa thức được chọn, mô hình lỗi và chiều dài dữ liệu; không thể suy ra mọi đặc tính chỉ từ tên CRC.

Có thể hình dung bên tạo dữ liệu tính một giá trị kiểm tra theo quy tắc đã thống nhất. Bên đọc thực hiện phép kiểm tra tương ứng và so sánh. Nếu kết quả không phù hợp, ít nhất một phần của dữ liệu hoặc thông tin kiểm tra không còn nhất quán.

Đó là cơ chế phát hiện, không phải lời giải tự động khôi phục chuỗi ban đầu. Nhận ra có vấn đề và biết chính xác mọi bit đúng phải là gì là hai năng lực khác nhau.

GZIP kiểm tra dữ liệu sau giải nén

RFC 1952 định nghĩa định dạng GZIP có trường CRC-32 trong phần cuối của mỗi member, tính từ dữ liệu chưa nén. Cấu trúc này giúp bên giải nén đối chiếu dữ liệu thu được với giá trị kiểm tra đi kèm.

Chi tiết “dữ liệu chưa nén” đáng chú ý: phải biết CRC đang áp dụng cho chuỗi nào, không đơn thuần tính trên bất kỳ byte nào của tệp rồi so với một số tìm thấy trong đó. Một tệp có cấu trúc còn chứa các trường khác phục vụ việc giải mã định dạng.

Vì vậy, khi điều tra báo lỗi, nên xác định phép kiểm tra thất bại ở bước nào. Trạng thái tải xuống thành công qua HTTP chưa đủ thay thế việc giải nén và xác minh nội dung của định dạng.

PNG cho thấy phạm vi kiểm tra có thể nằm ở từng khối

Đặc tả PNG phiên bản thứ ba của W3C tổ chức luồng dữ liệu thành các chunk. CRC của chunk bao phủ phần loại và dữ liệu chunk, không bao gồm trường độ dài. Đây là một ví dụ cụ thể về việc phạm vi kiểm tra cần được đọc đúng.

Đặc tả cũng nêu quy tắc khởi tạo, xử lý bit, bổ sung cuối và thứ tự lưu CRC. Dù hai định dạng cùng dùng một đa thức, cách triển khai vẫn phải tuân theo hợp đồng đầy đủ thay vì chỉ biết đó là “CRC 32 bit”.

Suy ra, khi hai thư viện trả kết quả khác nhau, không nên lập tức kết luận một bên hỏng. Trước hết cần đối chiếu biến thể thuật toán và chuỗi byte đầu vào. Chỉ một khác biệt trong cách chuẩn bị dữ liệu cũng có thể làm phép so sánh mất ý nghĩa.

Kẻ sửa dữ liệu có thể sửa cả mã kiểm tra

Phần an ninh của RFC 3385 nói rõ: những mã phát hiện lỗi được phân tích trong tài liệu không nhằm chống tấn công. Trong môi trường đối thủ sửa được dữ liệu, họ cũng có thể thay mã kiểm tra để phù hợp với dữ liệu mới.

Đây không phải việc CRC “hỏng”. Nó đang bị yêu cầu giải quyết một bài toán nằm ngoài mục tiêu. Một giá trị ngắn, tính công khai từ nội dung không tự tạo ra bằng chứng về danh tính bên tạo nội dung.

Cũng cần tránh tuyên bố CRC phát hiện mọi sai hỏng. Không gian kết quả hữu hạn không thể phân biệt mọi chuỗi dữ liệu có thể có. Các bảo đảm có ý nghĩa phải đi kèm biến thể mã và điều kiện lỗi cụ thể.

Xác thực thông điệp cần cơ chế phù hợp

RFC 2104 mô tả HMAC dùng hàm băm mật mã kết hợp với khóa bí mật dùng chung để xác thực thông điệp. Khóa là khác biệt căn bản so với một CRC công khai mà bất kỳ bên nào cũng tính được từ dữ liệu.

HMAC cũng không tự giải quyết việc ai giữ khóa, phân phối khóa ra sao hoặc phần mềm có kiểm tra đúng hay không. Nó cung cấp một cơ chế trong thiết kế bảo mật, không biến toàn bộ hệ thống thành đáng tin chỉ nhờ thêm một trường vào gói tin.

Bởi vậy, chọn CRC hay cơ chế xác thực nên bắt đầu từ rủi ro cần xử lý. Với lỗi ngẫu nhiên, một mã phát hiện lỗi phù hợp có giá trị rõ ràng. Với thay đổi có chủ đích, hệ thống phải có thiết kế xác thực tương ứng; việc CRC khớp không thay thế được bước ấy.

Nguồn và sơ đồ

Nguồn: RFC 3385; RFC 1952; W3C PNG; RFC 2104. Các RFC được dùng để giải thích cơ chế, không phải công bố sản phẩm mới.

Sơ đồ thanh ghi dịch CRC: Biezl/Wikimedia Commons, tác giả phát hành vào phạm vi công cộng trên toàn thế giới. Đây là ví dụ CRC bậc 4, không phải sơ đồ CRC-32 của GZIP hoặc PNG. Dùng đầy đủ sơ đồ trên nền sáng, không cắt.