Xóa một người khỏi nhóm được mã hóa phải ngăn họ nhận những bí mật cần cho các tin nhắn được bảo vệ trong tương lai. Chỉ đổi danh sách thành viên không đạt được điều đó nếu những người gửi còn lại tiếp tục dùng vật liệu khóa mà cựu thành viên đã biết.
Quá trình chuyển đổi cũng không diễn ra tức thời trên toàn bộ một mạng thiếu ổn định. Thiết kế nhóm an toàn phải xác định một tin nhắn thuộc trạng thái thành viên nào và người gửi làm gì trước khi xử lý việc xóa thành viên.
Tin nhắn quá khứ và tương lai là hai vấn đề khác nhau
Cựu thành viên có thể giữ lại tin nhắn, tệp và khóa đã nhận khi còn được phép. Việc xóa không thể khiến người đó quên lịch sử hay xóa ảnh chụp màn hình của họ.
Mục tiêu có thể đạt được là loại họ khỏi trạng thái mật mã mới sau khi việc xóa có hiệu lực. Tương tự, thêm một người đặt ra câu hỏi riêng: họ có được truy cập lịch sử cũ không? Các sản phẩm và giao thức dùng thuật ngữ như bí mật chuyển tiếp trong những ngữ cảnh khác nhau, nên mô tả thẳng quy tắc truy cập dự kiến thường rõ hơn một nhãn mơ hồ.
Vì sao nhóm dùng khóa người gửi cần trạng thái mới
Trong thiết kế khóa người gửi, mỗi người tham gia có thể mã hóa tin nhắn nhóm thông thường bằng một chuỗi chia sẻ với những người nhận được phép. Điều này có thể tránh phải mã hóa riêng toàn bộ nội dung cho từng người nhận mỗi lần gửi.
Sau khi bị xóa, cựu thành viên vẫn có thể giữ chuỗi cũ. Vì vậy, những người gửi còn lại cần trạng thái thay thế không được phân phối cho người bị loại, và các máy khách cần thống nhất ngữ cảnh thành viên để sử dụng nó. Luân chuyển phải bao phủ những người gửi và thiết bị liên quan; đổi một cờ phía máy chủ là chưa đủ.
Giao thức cụ thể rất quan trọng. MLS, được quy định trong RFC 9420, xử lý việc xóa bằng một thay đổi epoch đã được cam kết, cung cấp entropy mới cho các thành viên còn lại. Đây là ví dụ về chuyển trạng thái được định nghĩa rõ, không phải khẳng định Livara triển khai MLS.
Livara công bố gì về LGS1
Trang bảo mật của Livara mô tả mỗi người gửi có một chuỗi người gửi được ký, với khóa người gửi được phân phối qua các phiên LVR1 từng cặp. Trang này nói rằng khóa người gửi mới được tạo và phân phối khi thành viên thay đổi.
Điều đó hỗ trợ một khẳng định về thiết kế đổi khóa đã công bố. Nó không xác lập thời gian “thu hồi tức thời” đã đo đạc, cũng không chứng minh mọi tình huống tranh chấp, thiết bị ngoại tuyến và lần thử lại đều được xử lý đúng. Những điều đó cần phân tích triển khai và kiểm thử.
Kiểm soát thành viên phía máy chủ và loại trừ bằng mật mã cũng có nhiệm vụ khác nhau. Dịch vụ có thể từ chối chuyển phát hoặc truy cập, còn mã hóa phải ngăn bên bị loại mở bản sao bản mã về sau mà họ có được nếu không có những bí mật mới.
Kế hoạch kiểm thử xóa thành viên hữu ích
Trong nhóm kiểm thử được cho phép, hãy kiểm tra các tình huống sau bằng tin nhắn không nhạy cảm:
| Tình huống | Câu hỏi cần giải quyết |
|---|---|
| Xóa thành viên khi tất cả đang trực tuyến | Tin nhắn nào là tin đầu tiên thuộc trạng thái thành viên mới? |
| Một người gửi còn lại đang ngoại tuyến | Họ có phải làm mới thành viên và khóa trước khi gửi lại không? |
| Thành viên bị xóa kết nối lại sau đó | Họ có lấy được các đợt phân phối khóa người gửi mới hay chỉ nội dung cũ đã được phép? |
| Nhiều thành viên thay đổi cùng lúc | Tất cả thiết bị còn lại có hội tụ về cùng trạng thái không? |
| Một tin nhắn cũ được thử gửi lại | Epoch gốc có được giữ thay vì bị gắn nhầm là nội dung mới không? |
Kiểm thử chỉ qua giao diện có thể xác nhận hành vi nhìn thấy, nhưng một mình nó không chứng minh được loại trừ bằng mật mã. Đánh giá nghiêm ngặt phải xem thiết bị kiểm thử bị loại có thể lấy được những khóa và bản mã nào.
Điều quản trị viên nên nhớ
Xóa những người tham gia không cần thiết, xem lại thành viên còn lại và tránh gửi tài liệu nhạy cảm mới cho đến khi ứng dụng xử lý xong thay đổi. Nếu một người tham gia hiện tại cố ý chuyển tiếp nội dung, việc đổi khóa nhóm không thể ngăn tiết lộ đó.
Với nhu cầu có độ nhạy cảm cao, hãy hỏi nhà cung cấp về ý nghĩa chính xác của việc xóa, hành vi thu hồi thiết bị và bằng chứng kiểm thử. Cam kết quan trọng là ranh giới được xác định rõ cho tin nhắn tương lai, không phải khẳng định thiếu căn cứ rằng nút xóa phá hủy mọi bản sao trong quá khứ.
