Khôi phục danh tính mật mã, đăng nhập lại vào tài khoản và khôi phục lịch sử trò chuyện là ba việc khác nhau. Theo tài liệu bảo mật của Livara, định dạng v7 được dùng để khôi phục danh tính mật mã; bản thân định dạng này không khôi phục lịch sử trò chuyện.
Cũng không nên mô tả kiến trúc này là “không có bất kỳ bản sao lưu đám mây nào”. Tài liệu hiện tại cho biết vật liệu danh tính được mã hóa trên thiết bị, sau đó tải lên dưới dạng bản sao lưu đã mã hóa. Điểm khác biệt quan trọng nằm giữa việc lưu khóa ở dạng đọc được trên máy chủ và lưu một bản sao đã mã hóa cần có khóa khôi phục mới mở được.
Ba cánh cửa không dùng chung một chìa khóa
| Thao tác | Mục đích | Vì sao chưa đủ? |
|---|---|---|
| Đăng nhập tài khoản | Chứng minh quyền truy cập vào tài khoản dịch vụ | Không nhất thiết cung cấp khóa giải mã các tin nhắn trước đây |
| Khôi phục danh tính | Lấy lại quyền truy cập vào vật liệu danh tính mật mã | Tự nó không chứng minh rằng mọi tin nhắn còn tồn tại hoặc có thể được khôi phục |
| Khôi phục lịch sử | Khôi phục các tin nhắn và tệp đính kèm cần thiết | Ngoài khóa, còn cần chính dữ liệu và phương thức khôi phục được hỗ trợ |
Sự phân biệt này giúp tránh một sai lầm tốn kém: xóa điện thoại cũ với suy nghĩ rằng chỉ cần biết mật khẩu đăng nhập là có thể khôi phục mọi cuộc trò chuyện.
Tài liệu v7 nói chính xác điều gì?
Trang bảo mật của Livara giải thích rằng các khóa P-256 dùng cho thỏa thuận khóa và ký, cùng giá trị khởi tạo ML-KEM, được mã hóa trên thiết bị bằng một khóa khôi phục ngẫu nhiên 256 bit. Trong mô tả định dạng v7, bộ thuật toán, kỷ nguyên danh tính và thế hệ cũng được xác thực. Đây là tài liệu của nhà cung cấp và tự nó không phải cuộc kiểm toán độc lập về cách triển khai.
Mô hình đe dọa của Livara xác định cụm từ khôi phục là cần thiết để mở bản sao lưu khóa. Không nên dựa vào mô tả này để đoán thuật toán chính xác chuyển cụm từ thành khóa hay giả định rằng mọi khóa đều được tái tạo trực tiếp. Các chi tiết thực tế cần được đối chiếu với phiên bản ứng dụng và hướng dẫn của chính phiên bản đó.
Vì sao hàm dẫn xuất không biến cụm từ yếu thành mạnh?
Độ dài đầu ra của một hàm không đồng nghĩa với mức độ khó đoán của đầu vào. RFC 5869 nêu rõ rằng HKDF tập trung entropy sẵn có nhưng không làm tăng entropy. Vì vậy, không thể khẳng định rằng bất kỳ cụm từ tùy chọn nào cũng tự động đạt độ an toàn đầy đủ 256 bit sau khi đi qua HKDF.
Không tự ý rút ngắn, viết lại hoặc thay cụm từ được tạo qua quy trình chính thức của ứng dụng bằng một câu dễ đoán. Không gửi cụm từ đó cho bất kỳ cá nhân, bot hỗ trợ hoặc biểu mẫu không rõ nguồn gốc nào.
Trước khi đổi hoặc xóa điện thoại
- Kiểm tra trong ứng dụng xem nội dung nào đã được sao lưu: danh tính, lịch sử hay cả hai bằng các phương thức riêng.
- Giữ cụm từ khôi phục ở nơi an toàn, độc lập với chính điện thoại đó; coi việc người khác truy cập được cụm từ là rủi ro nghiêm trọng.
- Đọc hướng dẫn khôi phục của phiên bản hiện tại. Chỉ thấy thông báo “Đăng nhập thành công” không có nghĩa là đã khôi phục đầy đủ.
- Nếu có phương thức kiểm thử khôi phục được hỗ trợ, hãy thử trước bằng dữ liệu không nhạy cảm và không xóa bản duy nhất hiện có.
- Sau khi chuyển, kiểm tra các cuộc trò chuyện và tệp cần thiết; rồi mới quyết định có ngừng sử dụng thiết bị cũ hay không.
Nếu tôi không có cụm từ khôi phục thì sao?
Nếu vẫn còn thiết bị được cấp quyền, chỉ kiểm tra các quy trình chính thức có sẵn ngay trong ứng dụng đó; không nên giả định có thể tạo bản sao lưu mới khi chưa kiểm tra phiên bản. Nếu mất cả thiết bị lẫn cụm từ, tài liệu của Livara không hứa hẹn khôi phục được khóa. Đừng coi bất kỳ dịch vụ “giải mã bảo đảm thành công” nào là cách vượt qua giới hạn này.
Hãy bắt đầu kế hoạch chuyển tài khoản bằng câu hỏi “Dữ liệu nào sẽ được khôi phục, bằng khóa nào và từ bản sao lưu nào?”, thay vì giả định rằng đăng nhập lại đồng nghĩa với lấy lại mọi cuộc trò chuyện.
