Kết quả pháp chứng phụ thuộc vào trạng thái thực tế của thiết bị và khóa, không chỉ tên cơ sở dữ liệu hay thuật toán.
Mã hóa đầu cuối và bảo vệ dữ liệu cục bộ là hai vấn đề liên quan nhưng khác nhau. Một tin nhắn được bảo vệ trên đường truyền mạng phải trở nên đọc được để hiển thị trên thiết bị. Kết quả kiểm tra pháp chứng phụ thuộc vào trạng thái thiết bị, loại quyền truy cập, phiên bản hệ điều hành và ứng dụng, cùng vị trí của khóa; không tên thuật toán nào tự nó quyết định kết quả.
Vì vậy, cả khẳng định “có tiếp cận vật lý là đọc được ngay mọi thứ” lẫn lời hứa “không bao giờ có thể trích xuất” đều cần được xem xét thận trọng.
Kiểm tra riêng bốn lớp bảo vệ
| Lớp | Nhiệm vụ chính | Giới hạn quan trọng |
|---|---|---|
| E2EE của tin nhắn | Bảo vệ nội dung giữa các thiết bị của người tham gia | Không bảo đảm tính an toàn của thiết bị và các bản sao cục bộ |
| Cách ly ứng dụng | Hạn chế ứng dụng thông thường truy cập dữ liệu của nhau | Quyền truy cập cấp cao hoặc lỗ hổng có thể thay đổi mô hình |
| Mã hóa tệp hoặc ổ đĩa | Bảo vệ dữ liệu lưu trữ trong những điều kiện cụ thể | Trạng thái khóa và khả năng truy cập khóa rất quan trọng |
| Mã hóa cơ sở dữ liệu trong ứng dụng | Thêm một ranh giới bảo vệ cho tệp cơ sở dữ liệu | Cách giữ và sử dụng khóa mang tính quyết định |
Tài liệu FBE của Android phân biệt vùng phụ thuộc thông tin xác thực của người dùng với vùng có thể truy cập trong Direct Boot. Chỉ câu “điện thoại đang khóa” không cho biết toàn bộ trạng thái của khóa; trước hay sau lần mở khóa đầu tiên kể từ khi khởi động cũng có thể quan trọng.
Tệp SQLite chứng minh điều gì?
SQLite là định dạng và công cụ lưu trữ, không phải nhãn tự nó chỉ ra sự có mặt hay vắng mặt của mọi biện pháp bảo vệ. Tệp có thể nằm trong vùng được hệ điều hành mã hóa hoặc được bảo vệ bằng một giải pháp riêng.
Ngoài ra, xóa một hàng không nhất thiết xóa mọi dấu vết của nó trong tất cả các tệp. Tài liệu SQLite giải thích cài đặt xóa an toàn và các giới hạn của bảng ảo. Các tệp phụ và bản sao lưu cũng phải được tính đến khi xem xét vòng đời dữ liệu. Điều này không có nghĩa là bảo đảm khôi phục được mọi tin nhắn đã xóa trên mọi điện thoại.
Không chạy lệnh bảo trì cơ sở dữ liệu trên dữ liệu thật khi chưa hiểu ứng dụng; sửa trực tiếp tệp của ứng dụng có thể làm hỏng dữ liệu hoặc thay đổi bằng chứng.
SQLCipher và Keystore là giải pháp, không phải chứng nhận miễn nhiễm
SQLCipher được thiết kế để mã hóa cơ sở dữ liệu một cách trong suốt, nhưng phải đọc đặc tả theo phiên bản. Trang thiết kế SQLCipher mô tả cấu trúc AES-CBC kèm xác thực; giới thiệu phiên bản 5 beta vào tháng 9 năm 2026 nêu việc chuyển sang AES-GCM. Vì vậy, gán một chế độ mã hóa cho tất cả phiên bản là không chính xác.
Android Keystore cũng có thể bảo vệ và kiểm soát việc dùng khóa, nhưng cần xác định ứng dụng thực sự sử dụng tính năng và cấp độ phần cứng nào. Tên StrongBox trong một bài viết không phải bằng chứng sản phẩm sử dụng nó. Hướng dẫn Keystore.
Ngay cả khóa không thể trích xuất cũng có thể được sử dụng qua các thao tác được phép trong một số điều kiện. “Không thể sao chép khóa” không phải cùng một khẳng định với “kẻ tấn công không thể giải mã bất kỳ dữ liệu nào”.
RAM và ratchet có vai trò gì?
Hạn chế thời gian tồn tại của khóa và văn bản nhạy cảm làm giảm số cơ hội bị lộ. Nhưng xóa một bộ đệm không chứng minh rằng không còn bản sao nào khác trong thư viện, bản xem trước hoặc quá trình hiển thị.
Phạm vi tác dụng của ratchet cũng khác nhau tùy loại khóa bị lộ và việc kẻ tấn công còn giữ quyền truy cập hay không. Không thể từ “khóa riêng cho từng tin nhắn” suy ra rằng một lần chụp bộ nhớ chỉ làm lộ tối đa một tin nhắn. Lưu lịch sử đọc được trên thiết bị là vấn đề khác với khóa truyền tải.
Điều gì chưa được xác nhận về Livara?
Mô hình đe dọa của Livara không bảo đảm bảo vệ thiết bị bị nhiễm mã độc hoặc đang mở khóa. Bài viết này không xác nhận độc lập rằng một phiên bản Livara cụ thể sử dụng SQLCipher, StrongBox, xóa sạch hoàn toàn RAM hay không có dữ liệu cuộc gọi cục bộ. Không nên gán những đặc tính này cho sản phẩm khi chưa có báo cáo thử nghiệm và bằng chứng triển khai.
Tương tự, gói khôi phục danh tính trong tài liệu bảo mật không giống bản sao lưu lịch sử. Kiểm tra mã băm APK trong Proof Lab có thể cho thấy tệp khớp với mã băm đáng tin cậy; kết quả đó không phải kiểm toán lưu trữ hay thử nghiệm chống pháp chứng.
Một tuyên bố pháp chứng đáng tin cậy cần thông tin gì?
Hãy yêu cầu mẫu thiết bị, phiên bản hệ điều hành và ứng dụng, trạng thái khóa, phương pháp và cấp độ truy cập, loại dữ liệu thu được và giới hạn thử nghiệm. Một công cụ thất bại trong một thử nghiệm không chứng minh mọi phương pháp đều bất khả thi; một thành công giới hạn cũng không cho phép khái quát cho tất cả người dùng.
Với người dùng thông thường, ưu tiên là cập nhật, khóa mạnh, giảm các bản sao nội dung đa phương tiện dư thừa và chăm sóc các phương thức khôi phục. Trong sự cố nghiêm trọng, hãy nhờ chuyên gia được ủy quyền trước khi thực hiện hành động làm thay đổi dữ liệu hoặc bằng chứng.
