Bộ nhớ đệm nội bộ, thư viện ảnh và RAM là ba ranh giới khác nhau; xóa một bản sao không chứng minh rằng tất cả đã bị xóa.
Mã hóa đầu cuối bảo vệ đường truyền ảnh; sau khi ảnh được mở, độ an toàn của bản có thể xem còn phụ thuộc thiết bị và cách ứng dụng lưu trữ. Nhưng không phải mọi tệp tạm trên Android đều công khai, và không phải mọi ảnh lưu trong bộ nhớ đệm đều tự động vào thư viện ảnh.
Để xem xét rủi ro, thay vì dùng cụm mơ hồ “rò rỉ từ bộ nhớ đệm”, hãy tách ba nơi: vùng lưu trữ riêng của ứng dụng, vùng dùng chung như thư viện ảnh và bộ nhớ đang hoạt động của tiến trình, tức RAM. Mỗi nơi có quyền truy cập và vòng đời khác nhau.
Ảnh đã giải mã có thể còn lại ở đâu?
| Vị trí | Công dụng thường gặp | Lưu ý bảo mật |
|---|---|---|
| Bộ nhớ đệm nội bộ riêng của ứng dụng | Hiển thị lại ảnh nhanh chóng | Các ứng dụng thông thường khác không nên truy cập tự do được |
| Thư viện ảnh hoặc vùng dùng chung | Lưu, chỉnh sửa hoặc chia sẻ ảnh | Ứng dụng có quyền và dịch vụ sao lưu có thể truy cập |
| RAM và bộ nhớ của thành phần hiển thị | Xử lý ảnh trong lúc sử dụng | Tính tạm thời không có nghĩa là miễn nhiễm khi thiết bị nhiễm mã độc |
| Bản xuất hoặc bản xem trước | Mở tệp bằng ứng dụng khác | Có thể có vòng đời xóa độc lập |
Tài liệu lưu trữ của Android phân biệt vùng dành riêng cho ứng dụng với vùng dùng chung. Vì vậy, câu “mọi tệp bộ nhớ đệm đều được MediaStore lập chỉ mục” là không đúng; đường dẫn lưu trữ, API được sử dụng và quyền truy cập mới là yếu tố quyết định.
Bộ nhớ đệm nội bộ được bảo vệ ra sao?
Android cách ly vùng nội bộ dành riêng cho ứng dụng khỏi các ứng dụng thông thường khác. Hướng dẫn chính thức khuyến nghị chính vùng này cho dữ liệu nhạy cảm tạm thời. Ứng dụng hoặc hệ thống có thể xóa tệp bộ nhớ đệm trước khi gỡ ứng dụng, nhưng nhà phát triển không nên chỉ trông chờ vào tình trạng thiết bị thiếu dung lượng để dọn dẹp. Hướng dẫn về tệp dành riêng cho ứng dụng.
Sự bảo vệ này không đồng nghĩa với “không ai có thể trích xuất tệp”. Quyền truy cập của kẻ tấn công vào điện thoại bị khóa, điện thoại đã mở khóa, hệ điều hành có lỗ hổng hoặc thiết bị có quyền root không giống nhau. Một tuyên bố pháp chứng đáng tin phải xác định mẫu thiết bị, phiên bản hệ thống, trạng thái khóa và loại quyền truy cập của kẻ tấn công.
Vì sao lưu trong RAM không bảo đảm xóa hoàn toàn?
Tránh ghi bản chưa mã hóa xuống đĩa có thể giảm số bản sao tồn tại lâu dài. Dọn sạch bộ đệm nhạy cảm cũng có thể là một phần của thiết kế phòng vệ. Tuy nhiên, không thể tuyên bố khả năng khôi phục bằng không chỉ bằng cách nhắc đến “ghi số không vào RAM”.
Trong khi xử lý, ảnh có thể được sao chép vào nhiều bộ đệm, thư viện hoặc thành phần hiển thị. Xóa một bộ đệm tự nó không chứng minh mọi bản sao đều đã bị xóa. Ngay cả khi không tạo tệp tồn tại lâu dài, mã độc có quyền truy cập dữ liệu lúc hiển thị vẫn có thể sao chép chúng. Mã hóa và quản lý bộ nhớ bổ trợ cho nhau, không thay thế nhau.
Người dùng có thể làm gì?
- Kiểm tra việc lưu vào thư viện ảnh riêng với tải xuống tự động. Nhận nội dung đa phương tiện để hiển thị trong ứng dụng không nhất thiết là lưu vào thư viện ảnh.
- Kiểm soát sao lưu ảnh. Một ảnh đã xuất có thể lên đám mây độc lập với cuộc trò chuyện.
- Xem lại quyền ảnh và tệp của ứng dụng khác. Đừng nhầm quyền cần cho một công việc cụ thể với quyền truy cập thường xuyên vào bộ sưu tập ảnh.
- Thử bằng một ảnh kiểm tra. Xem bản nào còn trong thư viện ảnh hoặc ứng dụng khác sau khi nhận, mở, lưu và xóa.
- Kiểm tra cách khôi phục trước khi xóa dữ liệu ứng dụng. “Xóa bộ nhớ đệm”, “xóa bộ nhớ lưu trữ” và đăng xuất có tác động khác nhau; lựa chọn thứ hai có thể xóa khóa hoặc dữ liệu cục bộ cần thiết.
Thử với ảnh không nhạy cảm là hữu ích, nhưng việc không có tệp trong thư viện ảnh không chứng minh rằng thiết bị không còn dấu vết nào.
Nhà phát triển nên thử nghiệm việc dọn dẹp như thế nào?
Việc kiểm tra cần bao quát toàn bộ đường đi của nội dung đa phương tiện: nhận, giải mã, hiển thị, chia sẻ, đóng màn hình, đăng xuất và đăng nhập lại. Hoạt động tải xuống hoặc tạo bản xem trước đang chạy phải phối hợp với chính sách đăng xuất; nếu không, một tệp mới có thể được ghi sau khi dọn dẹp. Đây là tình huống có thể kiểm thử, không phải tuyên bố đã được chứng minh về mọi ứng dụng nhắn tin.
Hãy thử trên một phiên bản cụ thể và ghi lại vị trí tệp cùng kết quả từng bước. Khuyến nghị bảo mật của Android nhấn mạnh việc giảm thiểu quyền truy cập và giữ dữ liệu nhạy cảm ở vị trí phù hợp.
Thảo luận này nói gì về Livara?
Mô hình mối đe dọa của Livara không bảo đảm bảo vệ trên thiết bị nhiễm mã độc hoặc đã mở khóa. Chỉ tài liệu về mã hóa truyền tải không phải bằng chứng cho tuyên bố “không còn bản chưa mã hóa nào trong bộ nhớ đệm”. Tuyên bố đó cần kiểm tra một phiên bản ứng dụng cụ thể và các đường xử lý nội dung đa phương tiện.
Kết luận: hãy biết vị trí và số lượng bản sao ảnh. Giảm bản sao thừa, khóa thiết bị phù hợp và cập nhật đều quan trọng; lời hứa “không thể khôi phục” khi thiếu thử nghiệm và mô hình mối đe dọa không phải tiêu chí đáng tin.
