포렌식 결과는 데이터베이스나 알고리즘의 이름만이 아니라 기기와 키의 실제 상태에 달려 있습니다.
종단 간 암호화와 로컬 데이터 보호는 관련되어 있지만 서로 다른 문제입니다. 네트워크 경로에서 보호된 메시지도 기기에 표시하려면 읽을 수 있는 상태가 되어야 합니다. 포렌식 조사 결과는 기기 상태, 접근 유형, 시스템과 앱 버전, 키의 위치에 달려 있습니다. 어떤 알고리즘 이름도 혼자서 결과를 결정하지는 않습니다.
따라서 “물리적으로 접근하면 모든 내용을 즉시 읽을 수 있다”는 주장과 “추출은 절대 불가능하다”는 약속 모두 신중하게 다뤄야 합니다.
네 가지 보호 계층을 따로 살펴보세요
| 계층 | 주요 역할 | 중요한 한계 |
|---|---|---|
| 메시지 E2EE | 참여자 기기 사이의 내용 보호 | 기기 건전성과 로컬 사본 보호를 보장하지 않음 |
| 앱 격리 | 일반 앱이 서로의 데이터에 접근하는 것을 제한 | 높은 권한의 접근이나 취약점이 모델을 바꿀 수 있음 |
| 파일 또는 디스크 암호화 | 특정 조건에서 저장 데이터 보호 | 잠금 상태와 키 사용 가능 여부가 중요 |
| 앱 내 데이터베이스 암호화 | 데이터베이스 파일에 추가 경계 제공 | 키를 보관하고 사용하는 방식이 결정적 |
Android FBE 문서는 사용자 인증 정보에 의존하는 공간과 Direct Boot에서 접근할 수 있는 공간을 구분합니다. “휴대전화가 잠겨 있다”는 말만으로 모든 키의 상태를 알 수는 없습니다. 부팅 후 최초 잠금 해제 전인지 후인지도 중요할 수 있습니다.
SQLite 파일은 무엇을 증명하나요?
SQLite는 저장 형식과 엔진이지, 모든 보호의 존재 여부를 혼자 보여 주는 표지가 아닙니다. 파일은 운영체제의 암호화된 공간 안에 있거나 별도 방식으로 보호될 수 있습니다.
또한 행 하나를 삭제한다고 모든 파일에서 그 흔적이 모두 사라지는 것은 아닙니다. SQLite 문서는 안전한 삭제 설정과 가상 테이블의 한계를 설명합니다. 데이터 수명주기를 살펴볼 때는 부속 파일과 백업도 고려해야 합니다. 그렇다고 모든 휴대전화에서 삭제한 메시지를 모두 복구할 수 있다는 보장은 아닙니다.
앱을 이해하지 못한 채 실제 데이터에 데이터베이스 유지관리 명령을 실행하지 마세요. 앱 파일을 직접 바꾸면 데이터가 손상되거나 증거가 변경될 수 있습니다.
SQLCipher와 Keystore는 수단이지 무적의 증명서가 아닙니다
SQLCipher는 투명한 데이터베이스 암호화를 위해 설계되었지만, 사양은 버전과 함께 읽어야 합니다. SQLCipher 설계 페이지는 인증을 함께 사용하는 AES-CBC 구조를 설명하고, 2026년 9월 버전 5 베타 소개는 AES-GCM으로의 변경을 설명합니다. 따라서 하나의 암호 모드를 모든 버전에 적용하는 것은 정확하지 않습니다.
Android Keystore도 키 보호와 사용 제어를 제공할 수 있지만, 앱이 실제로 어떤 기능과 하드웨어 수준을 사용했는지 밝혀야 합니다. 글에 StrongBox라는 이름이 등장한다고 제품이 이를 쓴다는 증거가 되지는 않습니다. Keystore 안내를 참고하세요.
추출할 수 없는 키도 특정 조건에서는 허용된 작업을 통해 사용할 수 있습니다. “키를 복사할 수 없다”와 “공격자가 어떤 데이터도 복호화할 수 없다”는 같은 주장이 아닙니다.
RAM과 래칫은 어떤 역할을 하나요?
키와 민감한 평문의 수명을 제한하면 노출 기회를 줄일 수 있습니다. 그러나 버퍼 하나를 지웠다고 라이브러리, 미리보기 또는 표시 과정에 다른 사본이 남아 있지 않다는 증명이 되지는 않습니다.
래칫의 적용 범위도 유출된 키의 종류와 공격자의 접근이 계속되는지에 따라 달라집니다. “메시지마다 별도 키”라는 사실만으로 한 번의 메모리 추출이 최대 한 메시지만 노출한다고 결론 낼 수는 없습니다. 기기에 읽을 수 있는 기록을 저장하는 것은 전송 키와 별개의 문제입니다.
Livara에 대해 확인되지 않은 것은 무엇인가요?
Livara 위협 모델은 감염되거나 잠금 해제된 기기의 보호를 보장하지 않습니다. 이 글은 특정 Livara 버전의 SQLCipher나 StrongBox 사용, RAM의 완전한 삭제 또는 로컬 통화 데이터의 부재를 독립적으로 확인하지 않습니다. 시험 보고서와 구현 증거 없이 이런 특성을 제품에 부여해서는 안 됩니다.
또한 보안 문서의 신원 복구 패키지는 기록 백업과 다릅니다. Proof Lab에서 APK 해시를 확인하면 파일과 신뢰하는 해시가 일치하는지 보여 줄 수 있습니다. 그 결과는 저장 방식 감사나 포렌식 방어 시험이 아닙니다.
신뢰할 수 있는 포렌식 주장에는 어떤 정보가 필요한가요?
기기 모델, 시스템과 앱 버전, 잠금 상태, 접근 방법과 권한 수준, 확보한 데이터 유형, 시험의 한계를 요구하세요. 한 도구가 한 시험에서 실패한 것은 모든 방법이 불가능하다는 증거가 아닙니다. 제한적인 성공도 모든 사용자에게 일반화할 근거가 되지 않습니다.
일반 사용자에게는 업데이트, 강력한 잠금, 불필요한 미디어 사본 줄이기, 복구 경로 보호가 우선입니다. 심각한 사건에서는 데이터나 증거를 바꾸는 조치를 하기 전에 권한 있는 전문가의 도움을 받으세요.
