AES-GCM có thể bảo vệ tính bí mật của tin nhắn và phát hiện thay đổi trái phép. Tự nó không cho người nhận biết liệu một tin nhắn vốn hợp lệ đã được xử lý trước đó hay chưa.
Ba yêu cầu rất dễ bị nhầm lẫn: cặp khóa/nonce duy nhất khi mã hóa, xác thực tin nhắn cùng ngữ cảnh của nó, và xử lý phát lại ở cấp giao thức. HKDF có thể giúp dẫn xuất khóa, nhưng không tự động đáp ứng cả ba.
Tái sử dụng nonce và phát lại là hai sự kiện khác nhau
| Sự kiện | Điều xảy ra | Biện pháp bảo vệ cần thiết |
|---|---|---|
| Tái sử dụng nonce khi mã hóa | Các bản rõ khác nhau được mã hóa bằng cùng khóa GCM và nonce | Chiến lược cấp phát khóa/nonce đáng tin cậy |
| Sửa đổi trái phép | Bản mã hoặc ngữ cảnh được xác thực bị thay đổi | Giải mã có xác thực và từ chối khi xác thực thất bại |
| Phát lại | Một tin nhắn mã hóa từng hợp lệ được gửi đến lần nữa | Trạng thái và quy tắc ứng dụng nhận biết bản trùng hoặc tin nhắn lỗi thời |
| Đảo thứ tự | Các tin nhắn hợp lệ đến theo thứ tự khác | Thứ tự do giao thức quy định và xử lý ngoài thứ tự trong giới hạn |
Bản mã bị phát lại vẫn có thể mang thẻ xác thực hợp lệ. Không có gì bị thay đổi. Vì vậy, nói rằng mọi bản trùng tự động thất bại khi xác thực AES-GCM là không đúng. RFC 5116 phân biệt rõ giao diện AEAD với các dịch vụ chống phát lại.
Vì sao cặp khóa và nonce không được lặp lại
Nonce của GCM không cần bí mật, nhưng phải đáp ứng yêu cầu về tính duy nhất của cơ chế dưới một khóa nhất định. Nonce 96 bit, tức 12 byte, thường được dùng; chọn độ dài đó không bảo đảm tạo nonce đúng cách.
Dùng lại cùng khóa và nonce cho các bản rõ khác nhau sẽ tái sử dụng dòng khóa mã hóa, làm lộ mối quan hệ giữa các bản rõ. Điều đó cũng có thể phá vỡ tính xác thực và cho phép giả mạo. Tác động rất nghiêm trọng, nhưng không nên mô tả là tự động làm lộ mọi khóa cũ hay mọi tin nhắn trong tài khoản. Phạm vi bị ảnh hưởng phụ thuộc vào khóa được tái sử dụng và giao thức.
NIST SP 800-38D định nghĩa GCM và các yêu cầu của nó. Triển khai phải tuân theo giới hạn số lần gọi và quy tắc tạo nonce áp dụng, không dựa vào quy tắc đơn giản kiểu “an toàn cho đến chừng này tin nhắn”.
HKDF đóng góp điều gì
HKDF, được quy định trong RFC 5869, dẫn xuất vật liệu khóa từ vật liệu bí mật đầu vào qua các giai đoạn trích xuất và mở rộng. Giao thức có thể dùng nhãn ngữ cảnh và đầu vào riêng biệt để tách các khóa phục vụ những mục đích khác nhau.
HKDF có tính xác định. Nếu máy khách bị sự cố hoặc bị khôi phục lùi lặp lại cùng trạng thái và đầu vào, nó có thể dẫn xuất lại cùng đầu ra. Vì vậy, thêm HKDF vào thiết kế không làm cho việc tái sử dụng nonce trở nên bất khả thi.
Khóa riêng cho từng tin nhắn có thể giảm lượng nội dung được bảo vệ bằng bất kỳ một khóa nào, nhưng việc cập nhật trạng thái an toàn, tách khóa và xóa khóa vẫn quan trọng. Cùng giá trị nonce dưới các khóa thực sự khác nhau không phải lỗi giống như lặp lại một cặp khóa/nonce; giao thức phải bảo đảm rằng các khóa thực sự khác nhau.
Chống phát lại thuộc trách nhiệm của giao thức
Người nhận có thể theo dõi mã định danh tin nhắn, vị trí trong chuỗi, kỷ nguyên phiên hoặc khóa ratchet đã dùng. Các trường liên quan phải được xác thực để kẻ tấn công không thể gắn nhãn tin nhắn cũ thành tin nhắn mới.
Sau đó, ứng dụng phải quyết định bản trùng có ý nghĩa gì. Hiển thị một bong bóng trò chuyện trùng là bất tiện; thực hiện cùng hành động hai lần có thể nghiêm trọng hơn. Thử lại qua mạng là bình thường, nên thường cần xử lý lũy đẳng bên cạnh các kiểm tra mật mã.
Đừng yêu cầu mọi tin nhắn hợp lệ phải đến đúng thứ tự tuyệt đối trừ khi giao thức quy định hành vi đó. Máy khách di động thường xuyên kết nối lại, thử lại và nhận tin nhắn chậm. Xử lý an toàn phân biệt tin nhắn đến muộn hợp lệ với tin nhắn đã được dùng hoặc thuộc ngữ cảnh sai.
Cần kiểm thử gì trước khi tuyên bố có bảo vệ
- Khởi động lại sau khi cấp phát nonce nhưng trước khi ghi nhận việc gửi: việc cấp phát có thể lặp lại không?
- Khôi phục ảnh chụp trạng thái cũ hơn: khóa, bộ đếm hoặc bản ghi chống phát lại có thể bị quay lùi không?
- Gửi đồng thời từ hai tiến trình xử lý hoặc thiết bị: các miền khóa/nonce của chúng có được tách biệt không?
- Gửi đến cùng một tin nhắn hợp lệ hai lần: hành động của ứng dụng có chỉ được thực hiện một lần không?
- Thay đổi mã định danh phiên hoặc phần đầu: ngữ cảnh có được ràng buộc bằng mật mã không?
- Gửi đến các tin nhắn hợp lệ ngoài thứ tự: độ trễ được hỗ trợ có được xử lý mà không chấp nhận trạng thái lỗi thời không?
API giải mã có xác thực chỉ nên trả bản rõ cho ứng dụng khi xác minh thành công. Đây là yêu cầu về giao diện; không phải khẳng định rằng không triển khai nào từng tính toán một bộ đệm bản rõ tạm thời ở bên trong.
Đọc chính xác các tuyên bố của Livara
Tài liệu bảo mật của Livara nêu AES-256-GCM, chuỗi cho từng tin nhắn và ngữ cảnh LVR1/LGS1. Những thành phần mật mã cơ bản đó không tự chứng minh việc khôi phục sau sự cố, cấp phát nonce hay từ chối phát lại là đúng. Các tuyên bố như vậy cần chi tiết giao thức gắn với phiên bản và bằng chứng kiểm thử.
Thiết kế vững chắc phân công rõ từng nhiệm vụ: dẫn xuất khóa tạo ra các khóa dự định, AEAD xác thực nội dung và ngữ cảnh, còn logic giao thức có trạng thái quyết định liệu một tin nhắn hợp lệ có thể được chấp nhận lúc này hay không.
