디스크 사본, 서버의 실시간 통제, 휴대전화 접근은 서로 다른 세 상황입니다. 하나의 포괄적인 보장으로 셋을 설명할 수는 없습니다.
메신저 서버가 장악되었을 때 “무엇이 노출되는가?”에 대한 정확한 답은 저장된 데이터, 키의 위치, 공격자의 접근 유형에 달려 있습니다. 디스크 사본을 얻는 것과 실행 중인 서비스 및 앱 배포 경로를 통제하는 것은 같지 않습니다.
이 글은 Livara의 공개 문서를 바탕으로 가상의 상황을 검토합니다. Livara 데이터센터의 위치, 실제 압수 발생 여부, 인터넷 차단 중 서비스 작동 보장에 관해 주장하지 않습니다. 콘텐츠 암호화, 네트워크 가용성, 인프라 보안은 별개의 문제입니다.
먼저 접근 유형을 구분하기
서버의 저장된 사본: 공격자는 그 사본에 포함된 파일, 데이터베이스 또는 백업에 접근합니다. 비공개 콘텐츠가 기기에서 올바르게 암호화되었고 서버가 복호화 키를 갖고 있지 않다면, 그 사본을 보유하는 것만으로 대화의 평문이 드러나지는 않습니다.
서비스의 능동적 통제: 공격자는 기존 데이터를 읽는 것 외에도 일부 요청을 중단하거나, 오래된 데이터를 반환하거나, 통제하는 구성 요소의 동작을 바꿀 수 있습니다. 이 경우 상대방 신원, 버전 관리, 클라이언트 무결성 확인이 더 중요해집니다.
동시에 기기에 접근: 잠금이 풀린 휴대전화, 악성코드, 또는 대화 참여자가 보유한 읽을 수 있는 사본을 통해 완전히 다른 경로로 내용이 노출될 수 있습니다. Livara 위협 모델 역시 잠금이 풀렸거나 감염된 기기의 보호를 보장하지 않습니다.
Livara 문서에 따르면 서버에서 어떤 데이터를 볼 수 있나?
버전 0.1.68로 표시된 Livara 보안 페이지는 LVR1 직접 대화와 호환되는 LGS1 비공개 그룹의 콘텐츠를 운영 정보와 구분합니다. 같은 페이지는 호환되지 않는 기존 그룹이 명시적으로 E2EE 범위 밖에 남는다고 설명합니다. 따라서 해당 대화 자체의 상태를 확인해야 합니다.
| 데이터 범주 | 문서에 명시된 경계와 가능한 결과 |
|---|---|
| 보호되는 대화의 텍스트와 첨부파일 | 서버는 암호화된 사본을 보관하며, 읽으려면 적절한 키가 필요함 |
| 통신 메타데이터 | 통신 당사자, 시간, 크기, 전달 상태 등의 정보를 서비스가 이용할 수 있음 |
| 그룹 구성원 정보 | 서버의 운영 정보와 조작 권한의 일부임 |
| 공개 채널 | 콘텐츠가 공개되어 있고 서버가 읽을 수 있음 |
| v7 신원 복구 패키지 | 업로드 전에 암호화되며 별도의 복구 비밀정보가 필요함 |
| 선택적 서버 녹음·녹화 모드 | REC 표시로 E2EE 모드와 구별되며 종단간 프라이버시를 전제해서는 안 됨 |
문서에는 메타데이터 보호를 위한 LSS1 코드가 언급되지만, 일반 메시지 전송에는 연결되어 있지 않습니다. 프로젝트에 프로토콜 이름이 존재한다는 사실만으로 모든 통신에서 활성화되었다고 볼 수는 없습니다.
이 표는 제품 주장을 설명한 것으로, 실제 압수 실험의 결과나 모든 데이터베이스 사본에 대한 독립 감사 결과가 아닙니다.
메타데이터는 얼마나 중요할 수 있나?
사람 간의 연결, 시간, 그룹 소속에 관한 정보는 메시지 텍스트가 없어도 민감할 수 있습니다. 다만 보관 기간, 로그 범위, 확보된 데이터 사본을 모른 채 “전체 통신 관계망이 영구히 노출된다”고 말하는 것은 정확하지 않습니다.
실제 평가에서는 어떤 필드가 수집되었는지, 얼마나 오래 남아 있었는지, 어떤 백업에 접근할 수 있는지를 물어야 합니다. 콘텐츠 암호화만으로 데이터 보관 정책이 정해지는 것은 아닙니다. 또한 한 메신저의 구조를 근거로 모든 메신저가 반드시 같은 메타데이터를 보관한다고 결론 내릴 수 없습니다.
서버 통제가 향후 메시지에 어떤 위험을 주나?
보안 검토에서는 구성원 목록 변조, 다른 신원 키 제공, 업데이트 차단, 악성 클라이언트 배포를 각각 시험해야 합니다. 각 공격의 영향은 클라이언트 측 검증, 변경 사항 표시, 신원 확인에 따라 달라집니다.
구현 시험 없이 장악된 모든 서버가 반드시 숨겨진 구성원을 추가할 수 있다고 말할 수는 없습니다. 마찬가지로 서버의 능동적 통제가 아무 영향도 없다고 말할 수도 없습니다. 민감한 대화에서는 예상치 못한 신원 또는 구성원 변경을 조사해야 합니다. 독립적이고 신뢰할 수 있는 경로로 상대방과 키 지문을 비교하면 표시 이름만 믿는 것보다 더 많은 정보를 얻을 수 있습니다.
공격자가 기기에서 실행되는 코드를 바꾸면 암호화되기 전의 텍스트를 볼 수 있습니다. 따라서 앱 배포와 업데이트의 보안은 이 상황의 일부이지, 암호화와 무관한 외부 문제가 아닙니다.
양자내성 특성은 무엇을 더하나?
ML-KEM에 관한 NIST FIPS 203 표준은 공유 비밀을 설정하는 데 도움을 줍니다. 하이브리드 구성에서 올바르게 사용하면 키 교환에 대한 일부 미래 공격의 위험을 줄일 수 있습니다. 하지만 기기 보안, 메타데이터 보관 제한, 서버 접근 통제를 대신하지는 않습니다.
Proof Lab 역시 일부 로컬 P-256, HKDF, AES-GCM 연산만 보여 주며, 완전한 LVR1/LGS1 조합은 해당 실험 범위 밖이라고 명시합니다. 성공적인 결과가 제품 전체의 인프라 장악 저항성을 보장하는 것은 아닙니다.
평가나 실제 사고에서 무엇을 해야 하나?
- 접근 유형과 확인된 정보를 기록하고, 장애 소문을 확정된 보안 사고와 동일시하지 마세요.
- 앱 버전과 해당 대화 자체의 암호화 상태를 확인하세요.
- 신원 변경, 그룹 구성원 변경, 알 수 없는 세션을 공식 경로를 통해 확인하세요.
- “보안 점검”을 명목으로 모르는 사람에게 복구 비밀정보, 비밀번호, 비공개 콘텐츠를 제공하지 마세요.
- 심각한 위험이나 법적 문제에는 적절한 전문가의 도움을 구하고, 한 편의 글만 근거로 되돌릴 수 없는 행동을 하지 마세요.
신뢰할 만한 결론은 어떤 데이터가 어떤 버전에서 어떤 접근에 대해 보호되는지 밝혀야 합니다. “서버가 압수되어도 아무 일도 일어나지 않는다”는 말로 그 답을 대신할 수는 없습니다.
