Bản sao đĩa, quyền kiểm soát máy chủ đang hoạt động và quyền truy cập điện thoại là ba tình huống khác nhau; một bảo đảm chung không đủ cho cả ba.
Nếu máy chủ của một ứng dụng nhắn tin bị chiếm, câu trả lời chính xác cho “những gì sẽ bị lộ?” phụ thuộc vào dữ liệu được lưu, vị trí của khóa và kiểu truy cập mà kẻ tấn công có. Lấy được bản sao đĩa không giống với kiểm soát trực tiếp dịch vụ đang hoạt động và đường phân phối ứng dụng.
Bài viết này xem xét một tình huống giả định dựa trên tài liệu công khai của Livara. Bài viết không khẳng định vị trí các trung tâm dữ liệu của Livara, việc đã xảy ra thu giữ, hay bảo đảm dịch vụ hoạt động khi internet bị gián đoạn. Mã hóa nội dung, tính sẵn sàng của mạng và bảo mật hạ tầng là những vấn đề riêng biệt.
Trước hết, xác định kiểu truy cập
Bản sao máy chủ được lưu: kẻ tấn công có quyền truy cập các tệp, cơ sở dữ liệu hoặc bản sao lưu có trong bản sao đó. Nếu nội dung riêng tư đã được mã hóa đúng cách trên thiết bị và máy chủ không nắm khóa giải mã, chỉ sở hữu bản sao này không làm lộ văn bản cuộc trò chuyện.
Kiểm soát chủ động dịch vụ: ngoài việc đọc dữ liệu hiện có, kẻ tấn công có thể chặn một số yêu cầu, trả về dữ liệu cũ hoặc thay đổi hành vi của các thành phần do mình kiểm soát. Việc kiểm tra danh tính người liên lạc, kiểm soát phiên bản và tính toàn vẹn của ứng dụng khách trở nên quan trọng hơn trong tình huống này.
Đồng thời truy cập thiết bị: điện thoại đã mở khóa, phần mềm độc hại hoặc bản sao đọc được ở chỗ một thành viên cuộc trò chuyện có thể làm lộ nội dung theo một con đường hoàn toàn khác. Mô hình đe dọa của Livara cũng không bảo đảm bảo vệ thiết bị đã mở khóa hoặc bị nhiễm mã độc.
Theo tài liệu Livara, máy chủ nhìn thấy dữ liệu nào?
Trang bảo mật Livara, mang nhãn phiên bản 0.1.68, phân biệt nội dung trò chuyện trực tiếp theo LVR1 và nhóm riêng tư tương thích theo LGS1 với thông tin vận hành. Trang này cũng nêu rõ rằng các nhóm cũ không tương thích vẫn nằm ngoài E2EE; vì vậy cần kiểm tra trạng thái của chính cuộc trò chuyện đó.
| Loại dữ liệu | Ranh giới được mô tả và hậu quả có thể xảy ra |
|---|---|
| Văn bản và tệp đính kèm của cuộc trò chuyện được bảo vệ | Máy chủ giữ bản mã hóa; muốn đọc cần có khóa phù hợp |
| Siêu dữ liệu liên lạc | Dịch vụ có thể truy cập thông tin như các bên, thời gian, kích thước và trạng thái chuyển phát |
| Tư cách thành viên nhóm | Thuộc thông tin và quyền hạn vận hành của máy chủ |
| Kênh công khai | Nội dung công khai và máy chủ có thể đọc được |
| Gói khôi phục danh tính v7 | Được mã hóa trước khi tải lên và cần một bí mật khôi phục riêng |
| Chế độ ghi tùy chọn trên máy chủ | Dấu REC phân biệt chế độ này với E2EE; không nên mặc định có tính riêng tư đầu cuối |
Tài liệu nhắc đến mã LSS1 để bảo vệ siêu dữ liệu, nhưng mã này chưa được nối vào quy trình gửi tin nhắn thông thường. Tên một giao thức xuất hiện trong dự án không chứng minh giao thức đó hoạt động trong mọi liên lạc.
Bảng này mô tả tuyên bố của sản phẩm, không phải kết quả thử nghiệm thu giữ thực tế hay kiểm toán độc lập mọi bản sao cơ sở dữ liệu.
Siêu dữ liệu có thể quan trọng đến mức nào?
Thông tin về liên hệ giữa con người, thời điểm và tư cách thành viên nhóm có thể nhạy cảm ngay cả khi không có văn bản tin nhắn. Tuy nhiên, câu “toàn bộ đồ thị liên lạc sẽ bị lộ mãi mãi” không chính xác nếu chưa biết thời hạn lưu giữ, phạm vi nhật ký và bản dữ liệu đã bị lấy.
Để đánh giá thực tế, cần hỏi những trường nào được thu thập, chúng được giữ bao lâu và có thể truy cập những bản sao lưu nào. Chỉ mã hóa nội dung không quyết định chính sách lưu giữ dữ liệu. Cũng không thể từ kiến trúc của một ứng dụng nhắn tin suy ra rằng mọi ứng dụng đều nhất thiết giữ cùng loại siêu dữ liệu.
Kiểm soát máy chủ gây rủi ro gì cho tin nhắn tương lai?
Trong đánh giá bảo mật, cần kiểm thử riêng việc sửa danh sách thành viên, cung cấp khóa danh tính khác, ngăn cập nhật và phân phối ứng dụng khách độc hại. Tác động của từng hành vi phụ thuộc vào xác thực phía ứng dụng khách, cách hiển thị thay đổi và việc xác minh danh tính.
Không thể nói rằng mọi máy chủ bị chiếm chắc chắn đều thêm được thành viên ẩn nếu chưa kiểm thử cách triển khai; cũng không thể nói quyền kiểm soát chủ động máy chủ không có tác động nào. Với cuộc trò chuyện nhạy cảm, cần kiểm tra những thay đổi bất ngờ về danh tính hoặc thành viên. So sánh dấu vân tay khóa với người liên lạc qua một kênh độc lập đáng tin cậy cung cấp nhiều thông tin hơn việc chỉ tin vào tên hiển thị.
Nếu kẻ tấn công thay đổi mã chạy trên thiết bị, chúng có thể thấy văn bản trước khi mã hóa. Vì vậy, bảo mật quá trình phân phối và cập nhật ứng dụng là một phần của tình huống này, không phải vấn đề nằm ngoài mật mã học.
Tính hậu lượng tử bổ sung điều gì?
Tiêu chuẩn NIST FIPS 203 cho ML-KEM giúp thiết lập bí mật chung. Sử dụng đúng trong một tổ hợp lai có thể giảm nguy cơ của một số cuộc tấn công tương lai vào trao đổi khóa. Đặc tính này không thay thế bảo mật thiết bị, giới hạn lưu giữ siêu dữ liệu hay kiểm soát truy cập máy chủ.
Proof Lab cũng chỉ trình diễn một số thao tác P-256, HKDF và AES-GCM cục bộ và coi tổ hợp đầy đủ LVR1/LGS1 nằm ngoài thử nghiệm đó. Kết quả thành công không bảo đảm toàn bộ sản phẩm chống chịu được việc hạ tầng bị chiếm.
Làm gì khi đánh giá hoặc khi có sự cố thực tế?
- Ghi nhận kiểu truy cập và thông tin đã xác nhận; đừng coi tin đồn gián đoạn là sự cố bảo mật chắc chắn.
- Kiểm tra phiên bản ứng dụng và trạng thái mã hóa của chính cuộc trò chuyện đó.
- Kiểm tra thay đổi danh tính, thành viên nhóm và phiên không rõ qua kênh chính thức.
- Không giao bí mật khôi phục, mật khẩu hoặc nội dung riêng tư cho người lạ để “kiểm tra bảo mật”.
- Khi có rủi ro nghiêm trọng hoặc vấn đề pháp lý, hãy tìm chuyên gia phù hợp và không thực hiện hành động không thể đảo ngược chỉ dựa trên một bài viết.
Kết luận đáng tin cậy phải nêu rõ dữ liệu nào được bảo vệ, ở phiên bản nào và trước kiểu truy cập nào. Câu “dù máy chủ bị thu giữ thì cũng không có gì xảy ra” không thay thế được câu trả lời đó.
