알고리즘 이름은 데이터 저장 위치와 키 보호에 관한 증거를 대신하지 못합니다.
저장 데이터 암호화(Data-at-Rest)는 저장된 데이터를 보호하고, 종단 간 암호화는 허가된 기기 사이에서 오가는 메시지 내용을 보호합니다. 메신저의 보안을 평가하려면 두 가지를 모두 살펴봐야 합니다. 알고리즘 이름이나 ‘양자 내성’이라는 표현만으로는 휴대전화의 데이터베이스, 미디어 캐시, 내보낸 파일이 어떻게 보호되는지 알 수 없습니다.
모바일 포렌식에서도 ‘파일을 확보하는 것’과 ‘그 파일의 암호화된 내용을 읽는 것’은 다릅니다. 결과는 기기 모델, 운영체제 버전, 잠금 상태, 데이터 유형, 사용할 수 있는 키, 조사 방법에 따라 달라집니다. 도구 이름만으로 모든 휴대전화에서 추출이 성공할지 실패할지 예측할 수는 없습니다.
혼동하면 안 되는 세 가지 계층
| 계층 | 무엇을 보호하나요? | 중요한 질문 |
|---|---|---|
| 메시지 종단 간 암호화 | 허가된 기기 사이에서 주고받는 내용 | 키는 누가 보유하며 상대방은 어떻게 확인하나요? |
| 기기 저장소 암호화 | 저장 공간에 보관된 파일 | 관련 키는 언제, 어떤 권한으로 사용할 수 있나요? |
| 앱 내부 및 백업 보호 | 데이터베이스, 내보낸 데이터 또는 별도의 사본 | 어떤 데이터가 보호 대상이며 각 사본의 키는 어디에 있나요? |
예를 들어 채팅에서 갤러리에 저장한 이미지는 더 이상 해당 메신저의 보관 정책만을 따르지 않습니다. 클라우드 백업이나 수동으로 내보낸 데이터도 별도로 살펴봐야 합니다. 채팅 백업 보안 안내에서 이 차이를 설명합니다.
BFU와 AFU는 무엇을 뜻하나요?
이 용어는 일반적으로 부팅 후 처음 잠금을 해제했는지를 기준으로 기기의 상태를 설명합니다.
- BFU(Before First Unlock): 전원을 켜거나 재부팅한 뒤 사용자가 아직 처음으로 잠금을 해제하지 않은 상태입니다.
- AFU(After First Unlock): 최초 잠금 해제가 이루어진 상태입니다. 현재는 기기에 잠금 화면이 다시 표시되고 있을 수도 있습니다.
이 두 표시는 보안 점수도, 포렌식 조사의 확정적인 결과도 아닙니다. AFU라고 해서 ‘모든 키를 추출할 수 있다’는 뜻은 아니며, BFU라고 해서 ‘어떤 데이터에도 접근할 수 없다’는 뜻도 아닙니다.
Android 파일 기반 암호화에서 Credential Encrypted, 즉 CE 저장소는 사용자가 잠금을 해제한 뒤 사용할 수 있습니다. Device Encrypted, 즉 DE 저장소는 Direct Boot에 필요한 기능에서도 사용할 수 있습니다. 각 데이터의 저장 위치와 키 정책이 중요하며, 모든 파일의 접근 상태가 같은 것은 아닙니다.
AES라는 이름보다 키 관리가 중요한 이유
데이터베이스 암호화는 키도 적절히 보호되어야 유용합니다. 보호되지 않은 키를 암호화된 파일 옆에 저장하는 것은 인증 및 보안 하드웨어에 연결된 키와 같은 보호 경계를 만들지 못합니다. 임시 파일, 첨부 파일, 앱 로그가 어떻게 처리되는지도 명확해야 합니다.
Android Keystore는 내보낼 수 없는 키를 사용할 수 있게 하며, 일부 키는 보안 하드웨어의 보호를 받을 수 있습니다. 하지만 키를 내보낼 수 없다는 것과 공격자가 그 키를 사용할 수 없다는 것은 다릅니다. Android 문서에 따르면 앱 프로세스를 장악한 공격자는 키 자체를 추출하지 못하더라도 그 키를 사용할 수 있을 수 있습니다.
화면에 보이는 앱 잠금만으로 데이터베이스가 독립적인 키로 암호화되었다고 입증되는 것도 아닙니다. 그런 주장을 하려면 해당 버전의 저장소 설계, 인증 조건, 실제 동작을 살펴봐야 합니다.
Livara에 대해서는 무엇을 결론 내릴 수 있나요?
Livara 보안 및 위협 모델 문서는 제품의 설계와 경계에 관한 제공자의 설명이며, 독립적인 포렌식 실험을 대신하지 않습니다.
특히 v7 형식의 신원 복구를 채팅 기록 백업이나 로컬 데이터베이스 암호화의 증거로 보아서는 안 됩니다. LVR1과 같은 메시징 프로토콜에 대한 설명만으로도 휴대전화의 각 파일이 어떤 키로, 어떤 상태에서 보호되는지 알 수는 없습니다.
이 글에서는 상용 포렌식 도구나 특정 Livara 버전의 데이터베이스를 시험하지 않았습니다. 따라서 ‘어떤 포렌식 도구도 Livara를 읽을 수 없다’거나 ‘ML-KEM이 저장소의 모든 파일을 암호화한다’는 주장은 근거 있는 결론이 아닙니다.
메신저를 평가할 때 어떤 증거를 요구해야 하나요?
시험에 근거하지 않은 순위표 대신 다음과 같은 구체적인 질문을 확인하세요.
- 어떤 앱 버전, 기기 모델, 운영체제 버전을 조사했나요?
- 메시지 텍스트, 파일, 썸네일, 캐시, 수동으로 내보낸 데이터는 각각 어디에 저장되나요?
- 데이터베이스 키는 어떻게 생성하고 보관하나요? 키를 사용하려면 인증이 필요한가요?
- 잠긴 상태, 잠금을 해제한 뒤, 앱이 실행 중일 때 어떤 차이가 있나요?
- 백업에는 정확히 무엇이 포함되며 백업 비밀번호나 복구 키는 누가 보유하나요?
- 독립적인 보고서, 시험 방법, 한계, 조사 날짜가 공개되어 있나요?
이 질문에 대한 답이 없다면 ‘암호화됨’이라는 표현만으로 제품을 비교하기에는 부족합니다. 기술 문서 공개는 가치가 있지만, 모든 주장을 독립적으로 검증한 것과 같다고 소개해서는 안 됩니다.
일상에서 실천할 수 있는 보호 조치
적절한 비밀번호로 기기를 잠그고, 운영체제와 앱 업데이트를 설치하며, 잠금 화면에 민감한 텍스트가 표시되는 것을 제한하세요. 갤러리, 다운로드 폴더, 백업에 있는 추가 사본도 의식적으로 관리하세요. 메신저 밖의 사본에는 다른 보호 정책이 적용될 수 있습니다.
민감한 대화에서는 상대방 기기의 안전 상태도 중요합니다. 악성코드가 앱을 연 뒤 텍스트를 읽을 수 있다면 문제는 단순히 암호화된 파일을 추출하는 데 그치지 않습니다. Android 세션 보안 안내는 이 경계를 자세히 설명합니다.
자주 묻는 질문
휴대전화가 꺼져 있으면 데이터 추출이 불가능한가요?
아닙니다. 기기 상태는 여러 요인 중 하나이지 결과를 보장하지는 않습니다. 하드웨어, 소프트웨어, 데이터, 조사 방법의 세부 사항을 알아야 합니다.
메시지의 양자 내성 암호화가 저장소 보안을 보장하나요?
아닙니다. 키 교환과 메시지 보호가 로컬 저장소의 설계 및 검토를 대신하지는 않습니다.
계정을 복구하면 모든 메시지가 돌아오나요?
반드시 그렇지는 않습니다. 신원 복구, 계정 재연결, 대화 기록 복원은 서로 다른 세 가지 기능입니다. 휴대전화를 바꾸기 전에 해당 제품과 버전에서 백업이 어디까지 포함하는지 확인하세요.
