Tính linh hoạt mật mã là khả năng chuyển một giao thức từ bộ thuật toán mật mã này sang bộ khác mà không đánh mất cam kết bảo mật rõ ràng. Trong nhắn tin, điều đó không chỉ là thêm tên một thuật toán mới. Ứng dụng khách cũ, người nhận ngoại tuyến, tin nhắn đã lưu và thiết bị được liên kết đều phải hoạt động theo cách có thể dự đoán trong quá trình chuyển đổi.
RFC 7696 của IETF mô tả tính linh hoạt thuật toán như một bài toán chuyển đổi liên quan đến mã định danh, cách triển khai và thay đổi vận hành. Số phiên bản giúp nhận biết thứ đang được sử dụng; bản thân nó không làm cho quá trình chuyển đổi trở nên an toàn.
Ba loại phiên bản dễ nhầm lẫn
Một ứng dụng nhắn tin có thể có phiên bản ứng dụng, phiên bản giao thức truyền tin và mã định danh bộ thuật toán mật mã. Chúng trả lời những câu hỏi khác nhau:
| Mã định danh | Cho người đánh giá biết điều gì | Không chứng minh điều gì |
|---|---|---|
| Bản phát hành ứng dụng | Bản dựng phần mềm nào được cài đặt | Rằng mọi cuộc trò chuyện đều dùng giao thức mới nhất |
| Phiên bản giao thức | Định dạng tin nhắn và quy tắc trạng thái nào được áp dụng | Rằng cách triển khai tuân thủ đúng những quy tắc đó |
| Mã định danh thuật toán hoặc bộ thuật toán | Những thành phần mật mã nào được chọn | Rằng quá trình thương lượng không thể bị hạ cấp |
Ghi chú phát hành cần nêu rõ mối quan hệ này. “Đã triển khai mã hóa mới” là cách nói mơ hồ nếu chỉ các cuộc trò chuyện mới tạo sử dụng nó, hoặc nếu ứng dụng khách cũ trên thiết bị liên kết khiến hệ thống quay về phương án trước đó.
Một quá trình chuyển đổi an toàn phải xác định điều gì
Hãy bắt đầu bằng tình huống cụ thể: Alice cập nhật hôm nay; Bob vẫn ngoại tuyến trên chiếc điện thoại cũ hơn. Alice gửi tin nhắn rồi thêm một thiết bị thứ hai. Mỗi thiết bị nên chấp nhận, lưu trữ và hiển thị những gì?
Một thiết kế có thể thẩm định phải trả lời ít nhất những câu hỏi sau:
- Mỗi bên biết được các phiên bản mà bên kia hỗ trợ bằng cách nào?
- Phiên bản được chọn có được xác thực như một phần của phiên làm việc không?
- Điều gì xảy ra khi hai bên không có phiên bản chấp nhận được nào chung?
- Một máy chủ chuyển tiếp độc hại có thể loại bỏ thông tin về khả năng hỗ trợ và khiến hệ thống dùng chế độ yếu hơn không?
- Tin nhắn cũ còn đọc được không, và những khóa cũ nào vẫn cần thiết?
- Khôi phục bản sao lưu có làm sống lại trạng thái giao thức lỗi thời không?
- Khi nào các thuật toán đã bị khuyến cáo ngừng dùng sẽ bị vô hiệu hóa thay vì chỉ bị khuyên tránh dùng?
Một lỗi hiển thị rõ thường an toàn hơn việc âm thầm chuyển sang chế độ mà người dùng không chủ định sử dụng. Tuy nhiên, hành vi cụ thể khi lỗi và khi khôi phục phải được ghi lại để mọi người không tìm cách vượt qua vấn đề bằng cách chuyển sang kênh không được bảo vệ.
Ma trận kiểm thử nâng cấp thực tế
Một bản nâng cấp bảo mật cần nhiều hơn một cuộc trò chuyện thành công giữa hai bản cài đặt mới. Hãy kiểm thử các trường hợp sau bằng dữ liệu không nhạy cảm:
| Kiểm thử | Bằng chứng cần ghi lại |
|---|---|
| Ứng dụng khách mới gửi tới ứng dụng khách cũ | Giao thức được chọn hoặc kết quả không tương thích rõ ràng |
| Người nhận ngoại tuyến trong lúc nâng cấp | Hành vi chuyển phát và giải mã sau khi kết nối lại |
| Thiết bị liên kết cũ quay lại | Thiết bị có thể đọc, gửi hoặc ép dùng một chế độ ngoài dự kiến hay không |
| Nhóm thêm thành viên không tương thích | Chính sách nhóm rõ ràng và trạng thái người dùng nhìn thấy được |
| Khôi phục bản sao lưu sau khi ngừng hỗ trợ | Trạng thái không được hỗ trợ bị từ chối hay được chuyển đổi |
| Siêu dữ liệu phiên bản bị sửa trái phép | Lỗi xác thực thay vì hạ cấp mà không bị nhận ra |
Đây là các tiêu chí đánh giá, không phải tuyên bố rằng một sản phẩm cụ thể đã vượt qua các bài kiểm thử. Hãy giữ lại mã định danh bản dựng và kết quả quan sát để có thể phân biệt lỗi hồi quy về sau với thay đổi trong tài liệu.
Cách hiểu tên giao thức của Livara
Livara dùng tên LVR1 cho trò chuyện trực tiếp và LGS1 cho nhóm riêng tư trong tài liệu bảo mật. Các tên này phân biệt phạm vi trách nhiệm; không nên xem chúng là bằng chứng về việc tiêu chuẩn hóa hoặc kiểm toán độc lập. Trang này cũng thảo luận về hành vi của ứng dụng khách hoặc nhóm không thể đáp ứng điều kiện tiên quyết của chế độ mã hóa.
Bằng chứng hữu ích tiếp theo sẽ là đặc tả có phiên bản, các vectơ kiểm thử, quy tắc tương thích và kết quả đánh giá gắn với một bản phát hành cụ thể. Proof Lab nêu rõ phạm vi nhỏ hơn của phần minh họa. Thử các thành phần mật mã cơ bản trong trình duyệt không đồng nghĩa với kiểm thử mọi lộ trình chuyển đổi trong ứng dụng.
Người dùng nên làm gì trong quá trình nâng cấp mã hóa
Luôn cập nhật các ứng dụng khách còn được hỗ trợ, đọc thông báo bảo mật về khả năng tương thích thiết bị và chú ý khi các chỉ báo danh tính hoặc trạng thái mã hóa thay đổi. Đừng cho rằng biểu tượng ứng dụng mới có nghĩa mọi nhóm và bản sao lưu cũ đều nhận được cơ chế bảo vệ mới. Nếu sản phẩm không thể giải thích dữ liệu nào đã thay đổi cách bảo vệ, hãy hỏi trước khi chia sẻ tài liệu nhạy cảm.
Tính linh hoạt mật mã tốt giúp thay đổi có thể được kiểm tra. Nó xác định điều gì đã thay đổi, các bên thống nhất về thay đổi đó như thế nào, điều gì có thể xảy ra sai sót và khi nào cơ chế cũ không còn được chấp nhận.
