Máy chủ ứng dụng nhắn tin bị xâm nhập không nhất thiết có nghĩa là mọi tin nhắn đều bị đọc. Kết quả phụ thuộc vào dữ liệu được lưu, vị trí các khóa và mức độ truy cập của kẻ tấn công. Ngay cả khi nội dung trò chuyện được mã hóa đầu cuối đúng cách, thông tin tài khoản, thời điểm, tư cách thành viên nhóm và tuyến chuyển tin vẫn có thể nhạy cảm.
Để đánh giá sự cố, trước tiên hãy hỏi kẻ tấn công đã có được gì: một bản sao cơ sở dữ liệu, khóa hạ tầng, máy chủ đang hoạt động hay hệ thống phát hành phần mềm? Các tình huống này không có cùng hậu quả.
Cơ sở dữ liệu bị đánh cắp khác với máy chủ bị kiểm soát
Kẻ tấn công chỉ có một bản sao cơ sở dữ liệu cũ bị giới hạn trong những dữ liệu đã được ghi lại ở đó. Kiểm soát dịch vụ đang hoạt động có thể cho phép ghi lại dữ liệu mới, đánh cắp phiên, thay đổi phản hồi hoặc tìm cách thay thế khóa của người liên hệ. Truy cập chuỗi phát hành phần mềm là một rủi ro khác: mã độc trên điểm cuối có thể thấy văn bản trước khi mã hóa hoặc sau khi giải mã.
Vì vậy, tuyên bố «cơ sở dữ liệu không chứa khóa của nội dung tin nhắn» là quan trọng, nhưng không trả lời đầy đủ cho mọi kiểu xâm nhập.
So sánh năm mô hình kiến trúc
Đây là các mô hình mang tính giải thích, không phải bảng xếp hạng năm sản phẩm. Một dịch vụ có thể dùng nhiều mô hình cho những tính năng khác nhau.
| Mô hình | Dữ liệu có thể truy cập từ cơ sở dữ liệu | Ranh giới quan trọng |
|---|---|---|
| Tin nhắn và mật khẩu ở dạng rõ | Nội dung và thông tin xác thực có thể được đọc trực tiếp | Thiếu bảo vệ phù hợp cho cả hai loại dữ liệu |
| Mật khẩu được băm, tin nhắn ở dạng rõ | Nội dung có thể đọc được; có thể kiểm tra các mật khẩu phỏng đoán | Chất lượng lưu trữ mật khẩu không bảo vệ nội dung trò chuyện |
| Nội dung được mã hóa bằng khóa máy chủ | Bản mã; việc đọc phụ thuộc vào khả năng truy cập khóa | Việc thực sự tách khóa khỏi dữ liệu rất quan trọng |
| Trò chuyện E2EE có bản sao lưu mà nhà cung cấp truy cập được | Trò chuyện trực tiếp có thể được bảo vệ, nhưng bản sao lịch sử có đường lộ dữ liệu riêng | Cần xem xét chính sách và khóa của bản sao lưu |
| Trò chuyện E2EE với khôi phục được mã hóa và khóa độc lập | Bản mã và dữ liệu vận hành; bảo vệ nội dung phụ thuộc vào thiết kế và bảo vệ khóa | Thiết bị, cụm từ khôi phục và xác thực người liên hệ vẫn quan trọng |
Mã hóa ổ đĩa máy chủ hữu ích khi chỉ riêng ổ đĩa vật lý bị đánh cắp. Khi kẻ tấn công cũng nắm dịch vụ đang hoạt động hoặc khóa giải mã, không nên mặc định có cùng mức bảo vệ. Với E2EE, mục tiêu là dịch vụ trung gian không có khóa cần thiết để đọc nội dung được bảo vệ.
Siêu dữ liệu cho thấy điều gì?
Siêu dữ liệu có thể cho biết tài khoản nào đã liên lạc với nhau, hoạt động khi nào, thuộc nhóm nào và đã truyền bao nhiêu dữ liệu. Những thông tin này không phải nội dung tin nhắn, nhưng có giá trị để hiểu mạng lưới liên lạc hoặc mô hình hoạt động.
Trang bảo mật Livara mô tả rõ việc lưu trữ và xử lý dữ liệu vận hành, gồm định tuyến, thành viên, thời điểm, kích thước bản mã và trạng thái chuyển tin. Không nên hiểu tính bí mật của nội dung riêng tư là ẩn danh hoàn toàn hoặc máy chủ không có bất kỳ dữ liệu nào.
SRP không loại bỏ nguy cơ đoán mật khẩu từ dữ liệu tài khoản
SRP là phương pháp chứng minh việc biết mật khẩu mà không trực tiếp gửi chính mật khẩu đó. Máy chủ vẫn lưu dữ liệu xác minh, hay verifier. Phần bảo mật của RFC 5054 giải thích rằng việc đánh cắp verifier có thể tạo điều kiện cho tấn công từ điển để đoán mật khẩu.
Do đó, «mật khẩu không được gửi qua mạng» khác với «không tồn tại dữ liệu liên quan đến mật khẩu để đánh cắp». Vẫn cần mật khẩu mạnh và riêng biệt, bảo vệ thiết bị và phản ứng phù hợp khi có sự cố. SRP cũng không thay thế mã hóa nội dung hoặc bảo vệ phiên đăng nhập.
Livara công bố những ranh giới nào?
Tài liệu bảo mật Livara mô tả LVR1 cho tin nhắn trực tiếp và LGS1 cho các nhóm được bảo vệ. Việc bảo vệ nhóm phụ thuộc vào trạng thái thực tế của nhóm; nhóm cũ không tương thích không được gắn nhãn E2EE. Kênh công khai nằm ngoài ranh giới bí mật này.
Cũng tài liệu đó mô tả khôi phục v7 là gói danh tính được mã hóa và bảo vệ trước khi tải lên. Quy trình này khôi phục danh tính mật mã, không phải lịch sử trò chuyện. Cụm từ khôi phục hoặc thiết bị chứa khóa bị lộ là tình huống khác với việc chỉ đánh cắp cơ sở dữ liệu.
Đây là các mô tả sản phẩm đã được công bố, không phải kết quả kiểm toán độc lập của bài viết này. Chỉ việc nêu tên AES hoặc ML-KEM cũng không chứng minh rằng quản lý khóa và triển khai ứng dụng là đúng.
Nên hỏi gì khi có thông báo sự cố?
- Khoảng thời gian nào và những hệ thống nào bị ảnh hưởng? Cụm từ mơ hồ «thông tin người dùng» là chưa đủ.
- Kẻ tấn công truy cập được văn bản rõ, tệp, khóa, verifier, phiên đăng nhập hay chỉ bản mã?
- Kẻ tấn công có thể thay đổi dịch vụ hoặc phần mềm cung cấp cho người dùng không?
- Cần thực hiện những bước nào qua kênh chính thức: đăng xuất các phiên, đổi mật khẩu, cập nhật hay kiểm tra danh tính người liên hệ?
- Khuyến nghị khôi phục có thể làm mất lịch sử cục bộ không? Hãy đọc các giới hạn trước khi gỡ ứng dụng.
Không dùng liên kết trong tin nhắn ẩn danh để «xác minh tài khoản ngay lập tức». Hãy tự mở thông báo qua địa chỉ chính thức. Mô hình đe dọa của Livara hữu ích để hiểu các ranh giới chung; phạm vi của một sự cố thực tế phải được xác định bằng bằng chứng của chính sự cố đó.
