Phạm vi lộ dữ liệu phụ thuộc vào loại khóa và thời gian kẻ tấn công có quyền truy cập; ratchet không bảo đảm rằng chỉ một tin nhắn gặp rủi ro.
Mã hóa mạnh cũng cần được thực thi đúng trên thiết bị. Lỗ hổng trong hệ điều hành, cách triển khai mật mã hoặc phần cứng có thể mở đường đến dữ liệu nhạy cảm; nhưng việc có nghiên cứu về tấn công bộ xử lý không có nghĩa là mọi điện thoại hay ứng dụng nhắn tin đều có thể bị xâm nhập bằng cùng phương pháp đó.
Câu hỏi hữu ích là: kẻ tấn công có quyền truy cập nào, có thể thấy khóa hoặc văn bản nào, và quyền truy cập đó chỉ tạm thời hay vẫn tiếp diễn? Câu trả lời quan trọng hơn tên thuật toán.
Kênh kề khác với đọc bộ nhớ như thế nào?
Khi đọc trực tiếp bộ nhớ, kẻ tấn công có thể đọc được một phần không gian bộ nhớ của tiến trình hoặc thiết bị. Trong tấn công kênh kề, thông tin được suy ra từ các dấu hiệu như thời gian thực thi thao tác hoặc hoạt động của bộ nhớ đệm. Hai cách này không nhất thiết có cùng điều kiện tiên quyết hoặc kết quả.
Nghiên cứu gốc về FLUSH+RELOAD khảo sát hoạt động của bộ nhớ đệm và các trang bộ nhớ dùng chung trong một môi trường thử nghiệm cụ thể, đồng thời chứng minh việc trích xuất khóa từ một phiên bản GnuPG. Kết quả này không phải là thử nghiệm bảo mật Livara hay bằng chứng rằng mọi bộ xử lý điện thoại đều dễ bị tấn công.
| Loại quyền truy cập | Câu hỏi cần đặt ra để đánh giá |
|---|---|
| Chạy ứng dụng thông thường trên cùng thiết bị | Cơ chế cách ly tiến trình và điều kiện tiên quyết của cuộc tấn công có cho phép quan sát không? |
| Quyền truy cập cấp cao vào hệ điều hành | Kẻ tấn công có thể tiếp cận dữ liệu hoặc thao tác khóa nào? |
| Tiếp cận vật lý hoặc trong phòng thí nghiệm | Trạng thái khóa, mẫu phần cứng và cơ chế bảo vệ khóa là gì? |
| Quyền truy cập liên tục vào ứng dụng | Kẻ tấn công có thể tiếp tục thu thập văn bản hoặc khóa mới không? |
Cụm từ chung chung “hack RAM” không phải là lời giải thích kỹ thuật đầy đủ nếu thiếu các chi tiết này.
Keystore và phần cứng an toàn giúp được gì?
Android Keystore có thể hạn chế việc sử dụng khóa và thực hiện thao tác có hỗ trợ phần cứng trên thiết bị phù hợp. Trong thiết kế này, khóa không thể trích xuất không đồng nghĩa với việc kẻ tấn công không thể sử dụng nó: trong một số điều kiện, ứng dụng bị nhiễm có thể lạm dụng thao tác khóa được phép, ngay cả khi không lấy được các byte của khóa ra ngoài. Xem hướng dẫn Android Keystore.
Không phải mọi khóa và thuật toán đều tự động được đặt trong phần cứng an toàn. Cần xác định loại khóa, khả năng hỗ trợ của thiết bị và cách ứng dụng sử dụng nó. Chỉ nói “khóa nằm trên thiết bị” không chứng minh được vị trí hoặc mức độ bảo vệ của khóa.
Một khóa bị lộ có chỉ làm lộ một tin nhắn không?
Đôi khi việc lộ một khóa tin nhắn độc lập chỉ có phạm vi hạn chế. Nhưng nếu kẻ tấn công lấy được khóa chuỗi, trạng thái phiên, khóa danh tính, lịch sử có thể đọc hoặc nhiều bộ đệm, kết quả sẽ khác. Vì vậy, khi chưa xác định dữ liệu bị lộ, không thể nói rằng “tối đa một tin nhắn” gặp rủi ro.
Việc đổi khóa cho mỗi tin nhắn cũng không nhất thiết cắt đứt quyền truy cập của kẻ tấn công. Nếu các khóa tiếp theo được suy ra từ trạng thái mà kẻ tấn công nắm giữ, hoặc chúng vẫn hiện diện trên thiết bị, chúng có thể tiếp cận cả những tin nhắn sau. Bảo vệ quá khứ và khôi phục an toàn trong tương lai là hai đặc tính riêng biệt, với những giả định cụ thể.
Ratchet và xóa bộ nhớ có giới hạn gì?
Ratchet có thể biến đổi khóa trong suốt cuộc trò chuyện. Khôi phục sau khi bị lộ đòi hỏi đưa vào thông tin mới mà kẻ tấn công không thể tiếp cận; chỉ gửi một tin nhắn không chứng minh rằng điều kiện này đã được đáp ứng. Đặc tả Double Ratchet giải thích cả việc khôi phục lẫn rủi ro truy cập dai dẳng và khôi phục dữ liệu đã xóa.
Rút ngắn thời gian tồn tại của dữ liệu nhạy cảm và xóa bộ đệm là hữu ích, nhưng không suy ra được một bảo đảm chung rằng mọi bản sao trong RAM đều đã bị xóa. Cần xem xét thư viện, ngôn ngữ lập trình và các đường xử lý hiển thị.
Có thể nói gì về Livara?
Trang bảo mật Livara mô tả cấu trúc lai và sự biến đổi khóa trong LVR1. Bài viết này không phải thử nghiệm kênh kề, kiểm toán bộ nhớ hay xác nhận rằng tất cả khóa đều sử dụng Keystore. Đặc biệt, tài liệu công khai về mô hình đe dọa không bảo đảm bảo vệ thiết bị đã bị nhiễm.
Vì vậy, không nên gán cho sản phẩm lời hứa “vô hiệu hóa xâm nhập phần cứng bằng tin nhắn tiếp theo” hoặc “lộ tối đa một tin nhắn”, trừ khi có bằng chứng cụ thể cho đúng phiên bản và tình huống đó.
Quyết định thực tế cho người dùng
Hãy cập nhật hệ điều hành và ứng dụng, chọn thiết bị còn được hỗ trợ bảo mật, tránh cài đặt từ nguồn không đáng tin và cấp quyền dư thừa, đồng thời sử dụng khóa thiết bị phù hợp. Nếu nghi ngờ có xâm nhập nghiêm trọng, đổi ứng dụng nhắn tin hoặc gửi tin nhắn mới không thay thế được việc điều tra và làm sạch thiết bị.
Khi đọc một tuyên bố bảo mật, hãy yêu cầu bốn điều: phiên bản được thử nghiệm, quyền truy cập của kẻ tấn công, dữ liệu bị lộ và giới hạn của kết quả. Chỉ tên bộ xử lý hoặc tiêu chuẩn mật mã không trả lời được bốn câu hỏi này.
