1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • FBI가 iPhone의 내부 알림 데이터베이스를 이용해 삭제된 Signal 메시지를 복구한 사례가 법정 증언을 통해 공개됨
  • 피고인의 iPhone에서 Signal 앱 삭제 후에도 수신 알림 내용이 내부 저장소에 남아 있었으며, 알림 미리보기 설정이 비활성화된 상태였음
  • iPhone의 보안 상태(AFU, BFU)로컬 캐시 구조로 인해 일부 데이터가 시스템 내부에 잔존할 수 있음
  • 앱 삭제 후에도 푸시 알림 토큰이 즉시 무효화되지 않아, 서버가 계속 알림을 전송하고 iPhone이 이를 수신했을 가능성이 제기됨
  • 이 사건은 암호화 메시징 앱과 iOS 알림 시스템의 데이터 보존 구조가 프라이버시 보안의 핵심 쟁점으로 떠오르고 있음을 보여줌

iPhone 알림 데이터로 삭제된 Signal 메시지를 복구한 FBI 사례

  • FBI가 iPhone의 내부 알림 데이터베이스를 이용해 삭제된 Signal 메시지를 복구한 사례가 공개됨
    • 404 Media 보도에 따르면, 텍사스 Alvarado의 ICE Prairieland 구금시설에서 폭죽 및 기물 파손 사건에 연루된 피고인 재판 중 증언으로 드러남
    • FBI 요원 Clark Wiethorn이 법정에서 증거 수집 과정을 설명함
  • 알림 데이터에서 복구된 메시지

    • 피고인 Lynette Sharp의 iPhone에서 Signal 앱이 삭제된 이후에도 수신된 메시지 내용이 내부 알림 저장소에 남아 있었음
    • 법정 증거 요약(Exhibit 158)에 따르면, “Signal은 삭제되었지만 Apple의 내부 알림 저장소를 통해 수신 알림이 내부 메모리에 보존되어 있었고, 오직 수신 메시지만 복구됨”
    • Signal에는 알림 미리보기에서 메시지 내용을 숨기는 설정이 있으나, 피고인은 이를 비활성화한 상태였던 것으로 나타남
    • Signal과 Apple 모두 알림 데이터의 저장 방식이나 처리 과정에 대한 공식 입장을 내놓지 않음
  • 내부 저장 구조와 기술적 배경

    • 피고인의 iPhone 상태에 대한 구체적 기술 정보가 부족해 FBI가 어떤 방식으로 데이터를 복구했는지는 명확하지 않음
    • iPhone에는 BFU(Before First Unlock), AFU(After First Unlock) 등 여러 보안 상태가 존재하며, 각 상태에 따라 데이터 접근 권한이 달라짐
    • 기기가 잠금 해제된 상태에서는 시스템이 사용자가 직접 조작 중이라고 가정해 보호된 데이터 접근 범위가 확대됨
    • iOS는 다양한 보안 상태를 신뢰 기반으로 관리하며, 사용자 편의를 위해 로컬에 많은 데이터를 캐시 형태로 저장
  • 푸시 알림 토큰과 데이터 잔존 가능성

    • 앱이 삭제되더라도 푸시 알림 전송에 사용되는 토큰이 즉시 무효화되지 않음

      • 서버는 앱 삭제 여부를 인지하지 못하므로, 마지막 알림 이후에도 계속 푸시를 보낼 수 있으며 iPhone이 이를 수신해 내부적으로 처리할 가능성 존재
      • Apple은 최근 iOS 26.4에서 푸시 알림 토큰 검증 방식을 변경했으며, 이번 사건과의 직접적 연관성은 확인되지 않았으나 시점상 주목됨
  • 데이터 추출 가능성 및 수사 도구

    • Exhibit 158의 설명에 따르면, FBI는 Apple의 내부 알림 저장소를 통해 데이터를 복구했으며, 이는 기기 백업에서 추출된 정보일 가능성이 있음
    • 법 집행 기관은 iOS 취약점을 이용해 데이터를 추출하는 상용 포렌식 도구를 다수 보유하고 있으며, FBI가 이를 활용했을 가능성도 있음
    • 404 Media는 이 사건의 원문 보고서를 별도로 공개함
  • 사건의 의미

    • 이 사례는 메시징 앱 삭제나 암호화만으로는 완전한 데이터 삭제가 보장되지 않음을 보여주는 사례로 주목됨
    • iOS 알림 시스템의 데이터 보존 구조와 보안 관리 방식이 향후 프라이버시 논의의 핵심 쟁점으로 부상할 가능성 있음
Hacker News 의견들
  • 사용자 입장에서 생각해보면, Signal은 forward secrecy가 있어서 메시지를 받은 뒤엔 사라지는 줄 알았음
    하지만 disappearing messages를 켜지 않으면 Cellebrite 같은 포렌식 도구가 복원할 수 있음. 기본값이 꺼져 있음
    켰다고 해도 알림(notification)에 메시지가 포함되어 OS가 저장할 수 있음. Apple이 실제로 그렇게 했고, 이를 막는 옵션이 있지만 역시 기본값은 꺼져 있음
    앱을 삭제해도 OS에 메시지가 남음. 결국 보안과 사용성의 균형이 무너질 때, 이건 사용자 탓이 아니라 시스템 설계 문제라고 생각함
    관련 사례를 내 글에 정리했음

    • 백업이 암호화되지 않는 한 종단 간 암호화(E2EE) 는 허상이라고 생각함. 상대방이 ADP를 안 쓰면 iMessage나 WhatsApp은 단순 저장 암호화만 적용됨
      Android의 WhatsApp도 기본적으로 Google Drive에 암호화되지 않은 백업을 권장함
      Google, Apple, Meta가 PRISM 후속 협약처럼 “E2EE를 허용하되 기본 설정으로 접근 가능하게” 만든 게 아닌가 의심됨
      대부분 사용자가 기본 설정을 그대로 쓰기 때문에 결국 보안이 무력화됨
    • Signal이 아무리 안전하다고 해도, 그 위에서 돌아가는 운영체제와 생태계가 너무 복잡해서 실제로 안전한 통신을 하고 있는지 확신하기 어려움
      메타데이터(누가 언제 누구와 통신했는지)도 여전히 노출됨
    • 대부분 사용자는 기본 설정을 바꾸지 않기 때문에, 앱의 보안 수준은 기본값이 곧 보안 수준
    • Signal이 알림에 메시지를 평문으로 넣는 건 더 심각함.
      이 글처럼, 민감한 데이터는 알림에 포함하지 않거나 암호화된 페이로드로 전송해야 함
    • 정말 안전한 메신저를 원한다면 SimpleX를 쓰라고 권함. Whonix가 추천했고, Snowden도 Whonix를 지지함
      Whonix Chat 추천 페이지
  • Signal 설정에서
    Settings > Notifications > Notification Content > Show: “Name Only” 혹은 “No Name or Content”로 바꿔두면
    화면을 보여줄 때 민감한 메시지가 노출되지 않음. 이번 사건을 보면 이 설정이 보안상 추가 이점이 있음

    • 이건 OS 설정이 아니라 Signal 앱 내부 설정임. OS 알림 설정만 바꾸면 화면 표시만 막을 뿐, 내부 저장은 계속됨
    • Android에서는 Settings > Notifications > Messages > Show 메뉴에 있음
    • 기본값이 가장 민감한 설정이어야 함. 보안 앱이라면 안전한 기본값이 필수임
    • Apple Intelligence 요약 기능도 민감한 앱 알림에는 꺼두는 게 좋음
    • Lockdown 모드를 켜면 이런 문제를 포함해 여러 취약점을 함께 막을 수 있음
  • Signal의 알림 미리보기 설정이 꺼져 있지 않으면, 시스템이 메시지 내용을 데이터베이스에 저장함
    이 알림 기록을 macOS에서는 ~/Library/Group Containers/group.com.apple.usernoted/db2/db에서 볼 수 있음
    Crank 앱을 이용하면 SQL 쿼리로 추출 가능함

    • Android에서는 NotiStar 같은 앱으로 알림 기록을 볼 수 있음.
      하지만 FCM(APNs) 같은 중앙화된 알림 인프라가 중간에서 데이터를 저장할 수 있음
    • Pixel에서는 Settings > Notifications > Manage > Notification History에서 일부 기록을 볼 수 있음
    • iPhone의 경우, 잠금화면에서 미리보기가 보이도록 설정되어 있으면 알림 내용이 평문으로 저장
      기본 설정은 “잠금 해제 시 미리보기”인데, 이 경우에도 내부 저장이 암호화되는지는 불분명함
      결국 이건 사용자 설정 실수로 인한 OPSEC 문제이며, Signal의 기본값은 적절했다고 봄
    • Android에서는 예전엔 모든 알림을 보여주는 프로토콜 주소 페이지가 있었음. 유용했지만 지금은 잘 쓰지 않음
  • Signal이 매달 알림을 켜라고 계속 묻는 이유가 궁금했음. 거절했는데도 반복됨

    • Signal 개발자에 따르면, 알림 신뢰성 관련 문의가 많아서 사용자가 실수로 꺼둔 걸 방지하려는 목적임. 다만 빈도는 과한 편임
    • 하지만 대부분 소프트웨어가 사용자의 의사보다 개발자나 회사의 이익을 우선함.
      사용자가 원치 않아도 계속 권유하는 건 이제 흔한 UX 패턴임
    • 메시징 플랫폼은 사용자가 즉시 응답할수록 성공적이기 때문에, 알림을 켜도록 유도하는 건 자연스러운 전략임
    • iOS 자체가 알림을 꺼두면 주기적으로 다시 확인하라고 묻는 구조이기도 함
    • WhatsApp의 2FA PIN처럼, 주기적으로 입력을 요구하는 것도 비슷한 맥락임
  • 실제 법정 증언이야말로 보안 실태를 검증하는 진짜 방법이라고 생각함
    이론적 논쟁보다 실제 사건에서 어떤 데이터가 복원되는지가 중요함

    • 다만 정부가 사이버 수단 노출을 피하기 위해 기소를 포기하는 경우도 있어, 모든 정보가 드러나는 건 아님
    • 법정은 드물게나마 실제 기술 세부사항이 공개되는 자리임
    • 최근 Trivy / LiteLLM 사건도 보안 관련 이슈였지만 성격이 달랐음
    • 그러나 부패한 국가에서는 법정 결과가 현실을 반영하지 않을 수도 있음. 병행 구성(parallel construction) 이 존재함
  • “피고가 설정을 켜지 않아 시스템이 메시지를 저장했다”는 문장은 사실상 Apple의 기본 설정이 문제
    대부분 사용자는 설정을 바꾸지 않으며, Apple도 이를 알고 있음

    • 더 나쁜 건, 사용자가 어렵게 바꾼 보안 설정이 업데이트 때마다 초기화된다는 점임. Firefox의 프라이버시 설정도 자주 이런 식으로 되돌아감
      의도적이지 않다고 해도, 우리는 의도된 것처럼 행동해야 함
    • 보안을 신경 쓴다면 잠금화면 미리보기는 반드시 꺼야 함. 잠금화면은 누구나 볼 수 있으므로 기본적으로 비공개가 아님
    • 언론이 “피고가 설정을 안 바꿨다”고 쓰는 대신, “Apple 시스템이 기본적으로 데이터를 저장했다”고 썼다면 인식이 달랐을 것임
      결국 책임이 사용자에게 전가되고, 시스템을 만든 기업은 “시스템”이라는 익명 뒤에 숨음
    • 실제로 사용자 설정 변경 능력에 대한 통계 데이터를 찾아봤는데, 컴퓨터 교육 수준이 매우 낮음. 단순한 타자 교육이 아니라 디지털 리터러시가 필요함
  • 원문 기사: FBI Extracts Suspect’s Deleted Signal Messages Saved in iPhone Notification Database

    • 다만 구독자 전용이라 세부 내용은 제한적임
  • Apple이 앱을 삭제해도 알림 데이터베이스에 남은 기록을 왜 지우지 않는지 의문임.
    오래된 알림 내용을 계속 보관하는 건 보안 사고의 씨앗

    • 이런 문제가 드러나면 “왜 이제야?” 싶을 정도로 명백함. 앞으로는 구조가 바뀔 것으로 예상함
    • Android는 앱을 삭제하면 알림 기록이 사라지고, 알림 기록 기능을 껐다 켜면 이전 데이터가 초기화됨
      Android 공식 문서에 따르면 일정 기간만 보관함
    • 하지만 플래시 메모리에 실제로 기록됐다면, 삭제 후에도 블록이 남아 있을 가능성이 있음
      wear leveling 때문에 데이터가 수년간 남을 수도 있음
    • 대부분 데이터베이스(sqlite 등)는 행을 삭제해도 실제 디스크 데이터는 바로 지워지지 않음.
      파일시스템과 SSD 레벨에서도 비슷한 일이 일어남
  • 결국 E2E의 한쪽 끝은 앱이 아니라 폰 자체임을 보여주는 사례임
    WhatsApp처럼 알림에서 메시지를 읽어도 읽음 표시가 안 되는 건, OS가 중간자(MITM) 역할을 하는 셈임

    • 하지만 Signal이 직접 알림을 생성하므로, echo "my_private_data" | notify-send처럼 단순히 알림을 띄우는 행위 자체가 위험하다고 보긴 어려움
  • 사실 이런 알림 데이터 저장 문제는 예전부터 알려져 있었음.
    RealityNet iOS Forensics References
    The Forensics Scooter의 글에서도 이미 다뤄졌음