FBI khôi phục tin nhắn Signal đã xóa từ dữ liệu thông báo trên iPhone

• Một trường hợp FBI khôi phục các tin nhắn Signal đã xóa bằng cách sử dụng cơ sở dữ liệu thông báo nội bộ của iPhone đã được công khai qua lời khai tại tòa
• Trên iPhone của bị cáo, nội dung thông báo Signal nhận được vẫn còn lưu trong bộ nhớ nội bộ ngay cả sau khi ứng dụng Signal đã bị xóa, và cài đặt xem trước thông báo đã bị tắt
• Do trạng thái bảo mật của iPhone (AFU, BFU) và cấu trúc bộ nhớ đệm cục bộ, một phần dữ liệu có thể vẫn tồn tại trong hệ thống nội bộ
• Có khả năng rằng ngay cả sau khi xóa ứng dụng, token thông báo đẩy không bị vô hiệu hóa ngay lập tức, nên máy chủ vẫn tiếp tục gửi thông báo và iPhone tiếp nhận chúng
• Vụ việc này cho thấy cấu trúc lưu giữ dữ liệu của ứng dụng nhắn tin mã hóa và hệ thống thông báo iOS đang nổi lên như một vấn đề cốt lõi của bảo mật quyền riêng tư

---

Trường hợp FBI khôi phục tin nhắn Signal đã xóa từ dữ liệu thông báo trên iPhone

• Một trường hợp FBI khôi phục các tin nhắn Signal đã xóa bằng cách sử dụng cơ sở dữ liệu thông báo nội bộ của iPhone đã được công bố
  • Theo bài đưa tin của 404 Media, việc này được hé lộ qua lời khai trong phiên tòa xét xử bị cáo liên quan đến một vụ pháo hoa và phá hoại tài sản tại cơ sở giam giữ ICE Prairieland ở Alvarado, Texas
  • Đặc vụ FBI Clark Wiethorn đã giải thích quy trình thu thập chứng cứ trước tòa

• Các tin nhắn được khôi phục từ dữ liệu thông báo

  • Trên iPhone của bị cáo Lynette Sharp, nội dung các tin nhắn nhận được vẫn còn trong kho lưu trữ thông báo nội bộ ngay cả sau khi ứng dụng Signal đã bị xóa
  • Theo phần tóm tắt chứng cứ tại tòa (Exhibit 158), “Signal đã bị xóa nhưng các thông báo nhận được vẫn được lưu trong bộ nhớ nội bộ thông qua kho lưu trữ thông báo nội bộ của Apple, và chỉ các tin nhắn nhận được mới được khôi phục”
  • Signal có cài đặt ẩn nội dung tin nhắn trong phần xem trước thông báo, nhưng có vẻ bị cáo đã tắt tùy chọn này
  • Cả Signal và Apple đều không đưa ra lập trường chính thức về cách dữ liệu thông báo được lưu trữ hay xử lý

• Cấu trúc lưu trữ nội bộ và bối cảnh kỹ thuật

  • Do thiếu thông tin kỹ thuật cụ thể về trạng thái chiếc iPhone của bị cáo, vẫn chưa rõ FBI đã khôi phục dữ liệu bằng cách nào
  • iPhone có nhiều trạng thái bảo mật như BFU (Before First Unlock) và AFU (After First Unlock), và quyền truy cập dữ liệu thay đổi tùy theo từng trạng thái
  • Khi thiết bị đang ở trạng thái đã mở khóa, hệ thống giả định người dùng đang trực tiếp thao tác nên phạm vi truy cập vào dữ liệu được bảo vệ sẽ được mở rộng
  • iOS quản lý nhiều trạng thái bảo mật khác nhau dựa trên cơ chế tin cậy, đồng thời lưu nhiều dữ liệu dưới dạng bộ nhớ đệm cục bộ để tăng tiện lợi cho người dùng

• Token thông báo đẩy và khả năng dữ liệu còn tồn tại

  • Ngay cả khi ứng dụng bị xóa, token dùng để gửi thông báo đẩy cũng không bị vô hiệu hóa ngay lập tức

    • Máy chủ không thể biết ứng dụng đã bị xóa hay chưa, nên vẫn có thể tiếp tục gửi push sau thông báo cuối cùng và iPhone có khả năng tiếp nhận rồi xử lý chúng ở cấp nội bộ
    • Apple gần đây đã thay đổi cách xác thực token thông báo đẩy trong iOS 26.4; chưa xác nhận có liên quan trực tiếp đến vụ việc này hay không, nhưng xét về thời điểm thì đây là chi tiết đáng chú ý

• Khả năng trích xuất dữ liệu và công cụ điều tra

  • Theo mô tả trong Exhibit 158, FBI đã khôi phục dữ liệu thông qua kho lưu trữ thông báo nội bộ của Apple, và có khả năng đây là thông tin được trích xuất từ bản sao lưu của thiết bị
  • Các cơ quan thực thi pháp luật sở hữu nhiều công cụ pháp y thương mại có thể trích xuất dữ liệu bằng cách khai thác lỗ hổng iOS, và FBI cũng có thể đã sử dụng những công cụ như vậy
  • 404 Media cũng công bố riêng báo cáo gốc của vụ việc này

• Ý nghĩa của vụ việc

  • Trường hợp này được chú ý như một ví dụ cho thấy chỉ xóa ứng dụng nhắn tin hoặc dùng mã hóa vẫn không đảm bảo dữ liệu được xóa hoàn toàn
  • Cấu trúc lưu giữ dữ liệu của hệ thống thông báo iOS và cách quản lý bảo mật của nó có thể trở thành trọng tâm trong các cuộc thảo luận về quyền riêng tư thời gian tới

[GN⁺]

Ý kiến trên Hacker News

• Nghĩ từ góc độ người dùng thì Signal có forward secrecy, nên tôi tưởng rằng sau khi nhận xong thì tin nhắn sẽ biến mất.
  Nhưng nếu không bật disappearing messages, các công cụ pháp chứng như Cellebrite vẫn có thể khôi phục. Mặc định tính năng này bị tắt.
  Ngay cả khi đã bật, nếu tin nhắn xuất hiện trong thông báo (notification) thì HĐH vẫn có thể lưu lại. Apple thực sự đã làm như vậy, và có tùy chọn để ngăn việc này nhưng mặc định cũng đang tắt.
  Xóa ứng dụng rồi mà tin nhắn vẫn còn trong HĐH. Cuối cùng, khi sự cân bằng giữa bảo mật và khả năng sử dụng bị phá vỡ, tôi cho rằng đây không phải lỗi của người dùng mà là vấn đề trong thiết kế hệ thống.
  Tôi đã tổng hợp các trường hợp liên quan trong bài viết của mình

  • Tôi nghĩ nếu bản sao lưu không được mã hóa thì mã hóa đầu cuối (E2EE) chỉ là ảo tưởng. Nếu bên kia không dùng ADP thì iMessage hay WhatsApp chỉ áp dụng mã hóa cho dữ liệu lưu trữ.
    WhatsApp trên Android cũng mặc định khuyến khích sao lưu không được mã hóa lên Google Drive.
    Tôi nghi ngờ Google, Apple và Meta đã tạo ra một kiểu thỏa thuận hậu PRISM kiểu “cho phép E2EE nhưng cấu hình mặc định vẫn có thể truy cập được”.
    Vì đa số người dùng giữ nguyên thiết lập mặc định nên kết cục là bảo mật bị vô hiệu hóa.
  • Dù Signal có an toàn đến đâu, hệ điều hành và hệ sinh thái mà nó chạy trên đó quá phức tạp, nên khó mà chắc chắn ta đang liên lạc thực sự an toàn.
    Metadata (ai liên lạc với ai, vào lúc nào) vẫn tiếp tục bị lộ.
  • Vì đa số người dùng không đổi cài đặt mặc định, mức độ bảo mật của ứng dụng thực chất là mặc định chính là mức độ bảo mật.
  • Việc Signal đưa nội dung tin nhắn dạng văn bản thuần vào thông báo còn nghiêm trọng hơn.
    Như bài này, dữ liệu nhạy cảm không nên được đưa vào thông báo, hoặc phải gửi dưới dạng payload đã mã hóa.
  • Nếu muốn một trình nhắn tin thực sự an toàn thì tôi khuyên dùng SimpleX. Whonix đã khuyến nghị nó, và Snowden cũng ủng hộ Whonix.
    Trang khuyến nghị Chat của Whonix

• Trong phần cài đặt Signal,
  nếu đổi Settings > Notifications > Notification Content > Show thành “Name Only” hoặc “No Name or Content”
  thì khi đưa màn hình cho người khác xem, tin nhắn nhạy cảm sẽ không bị lộ. Xét theo vụ việc lần này, thiết lập này còn có lợi ích bảo mật bổ sung.

  • Đây không phải cài đặt của HĐH mà là cài đặt bên trong ứng dụng Signal. Nếu chỉ đổi cài đặt thông báo của HĐH thì chỉ chặn hiển thị trên màn hình, còn lưu trữ nội bộ vẫn tiếp diễn.
  • Trên Android, mục này nằm ở Settings > Notifications > Messages > Show.
  • Thiết lập mặc định phải là thiết lập nhạy cảm nhất. Với ứng dụng bảo mật thì mặc định an toàn là điều bắt buộc.
  • Tính năng tóm tắt của Apple Intelligence cũng nên tắt đối với thông báo của các ứng dụng nhạy cảm.
  • Bật chế độ Lockdown có thể chặn cùng lúc nhiều lỗ hổng, bao gồm cả vấn đề này.

• Nếu cài đặt xem trước thông báo của Signal không bị tắt, hệ thống sẽ lưu nội dung tin nhắn vào cơ sở dữ liệu.
  Có thể xem bản ghi thông báo này trên macOS tại ~/Library/Group Containers/group.com.apple.usernoted/db2/db
  và dùng ứng dụng Crank để trích xuất bằng truy vấn SQL.

  • Trên Android, có thể xem lịch sử thông báo bằng ứng dụng như NotiStar.
    Nhưng hạ tầng thông báo tập trung như FCM(APNs) cũng có thể lưu dữ liệu ở giữa đường.
  • Trên Pixel, có thể xem một phần lịch sử ở Settings > Notifications > Manage > Notification History.
  • Với iPhone, nếu được thiết lập để hiện bản xem trước trên màn hình khóa thì nội dung thông báo sẽ được lưu ở dạng văn bản thuần.
    Mặc định là “xem trước khi mở khóa”, nhưng ngay cả trong trường hợp đó thì chưa rõ việc lưu trữ nội bộ có được mã hóa hay không.
    Cuối cùng, đây là vấn đề OPSEC do người dùng cấu hình sai, và tôi cho rằng mặc định của Signal là hợp lý.
  • Trên Android trước đây từng có một trang địa chỉ giao thức hiển thị mọi thông báo. Nó hữu ích nhưng giờ không còn được dùng nhiều.

• Tôi từng thắc mắc vì sao Signal cứ mỗi tháng lại hỏi bật thông báo. Dù đã từ chối nhưng nó vẫn lặp lại.

  • Theo các nhà phát triển Signal, mục đích là để ngăn trường hợp người dùng vô tình tắt đi, vì có rất nhiều câu hỏi liên quan đến độ tin cậy của thông báo. Tuy vậy, tần suất như vậy là hơi quá.
  • Nhưng phần lớn phần mềm đều ưu tiên lợi ích của nhà phát triển hay công ty hơn là ý chí của người dùng.
    Việc cứ tiếp tục khuyến khích dù người dùng không muốn giờ đã trở thành một mẫu UX rất phổ biến.
  • Nền tảng nhắn tin càng thành công khi người dùng phản hồi ngay, nên việc dẫn dắt người dùng bật thông báo là chiến lược tự nhiên.
  • Bản thân iOS cũng có cơ chế định kỳ hỏi lại nếu thông báo đang bị tắt.
  • Việc yêu cầu nhập định kỳ như mã PIN 2FA của WhatsApp cũng ở trong cùng một bối cảnh.

• Tôi nghĩ lời khai tại tòa mới là cách thật sự để kiểm chứng thực trạng bảo mật.
  Quan trọng không phải tranh luận lý thuyết mà là trong vụ việc thực tế, dữ liệu nào đã được khôi phục.

  • Tuy nhiên cũng có trường hợp chính phủ bỏ truy tố để tránh lộ phương thức tấn công mạng, nên không phải mọi thông tin đều được phơi bày.
  • Tòa án là nơi hiếm hoi mà các chi tiết kỹ thuật thực tế đôi khi được công khai.
  • Vụ Trivy / LiteLLM gần đây cũng là một vấn đề liên quan đến bảo mật, nhưng bản chất khác.
  • Tuy nhiên ở những quốc gia tham nhũng, kết quả tại tòa có thể không phản ánh thực tế. Có tồn tại parallel construction.

• Câu “bị cáo không bật cài đặt nên hệ thống đã lưu tin nhắn” thực chất đồng nghĩa với việc thiết lập mặc định của Apple có vấn đề.
  Đa số người dùng không đổi cài đặt, và Apple cũng biết điều đó.

  • Điều tệ hơn là, những cài đặt bảo mật mà người dùng đã rất vất vả mới đổi được lại bị khởi tạo lại mỗi khi cập nhật. Các cài đặt quyền riêng tư của Firefox cũng thường bị trả về như vậy.
    Dù không phải cố ý, chúng ta vẫn phải hành xử như thể đó là cố ý.
  • Nếu quan tâm đến bảo mật thì nhất định phải tắt xem trước trên màn hình khóa. Màn hình khóa là thứ ai cũng có thể nhìn thấy nên về mặc định không hề riêng tư.
  • Nếu truyền thông không viết rằng “bị cáo đã không đổi cài đặt” mà viết rằng “hệ thống Apple mặc định đã lưu dữ liệu”, thì nhận thức hẳn đã khác.
    Cuối cùng, trách nhiệm bị đẩy sang người dùng, còn công ty tạo ra hệ thống thì nấp sau cái tên vô danh là “hệ thống”.
  • Tôi từng tìm số liệu thống kê về khả năng thay đổi cài đặt của người dùng, và thấy rằng trình độ giáo dục máy tính rất thấp. Không chỉ là dạy gõ máy, mà cần cả năng lực số.

• Bài gốc: FBI Extracts Suspect’s Deleted Signal Messages Saved in iPhone Notification Database

  • Tuy nhiên đây là bài chỉ dành cho người đăng ký nên chi tiết bị hạn chế.

• Tôi thắc mắc vì sao Apple không xóa các bản ghi còn lại trong cơ sở dữ liệu thông báo ngay cả khi ứng dụng đã bị gỡ.
  Việc tiếp tục giữ nội dung thông báo cũ chính là mầm mống của sự cố bảo mật.

  • Khi kiểu vấn đề này bị phơi bày, nó rõ ràng đến mức khiến người ta nghĩ “sao đến giờ mới lộ ra?”. Có lẽ từ nay cấu trúc sẽ thay đổi.
  • Android sẽ xóa lịch sử thông báo khi gỡ ứng dụng, và nếu tắt rồi bật lại tính năng lịch sử thông báo thì dữ liệu cũ cũng bị xóa.
    Theo tài liệu chính thức của Android, dữ liệu chỉ được giữ trong một khoảng thời gian nhất định.
  • Nhưng nếu đã thực sự được ghi vào bộ nhớ flash thì ngay cả sau khi xóa vẫn có khả năng các block còn tồn tại.
    Do wear leveling, dữ liệu có thể còn tồn tại nhiều năm.
  • Hầu hết cơ sở dữ liệu (sqlite v.v.) dù xóa hàng thì dữ liệu thực trên đĩa cũng không bị xóa ngay.
    Điều tương tự cũng xảy ra ở cấp độ hệ thống tệp và SSD.

• Rốt cuộc đây là ví dụ cho thấy một đầu của E2E không phải là ứng dụng mà là chính chiếc điện thoại.
  Việc có thể đọc tin nhắn từ thông báo mà không hiện đã xem, như trên WhatsApp, có nghĩa là HĐH đang đóng vai trò MITM (người đứng giữa).

  • Tuy vậy, vì Signal tự tạo thông báo trực tiếp, nên cũng khó nói rằng chỉ riêng hành vi hiển thị một thông báo như echo "my_private_data" | notify-send đã là điều nguy hiểm.

• Thực ra vấn đề lưu dữ liệu thông báo kiểu này đã được biết đến từ lâu.
  Nó đã được đề cập trong RealityNet iOS Forensics References và
  bài viết của The Forensics Scooter từ trước rồi.