E2EE는 제공자가 읽을 수 있는 범위를 제한하지만, 대화가 존재할 수 있는 모든 장소를 설명하지는 않습니다.
메신저 제공자에 대한 법적 요청은 제공자가 보유하거나 접근할 수 있는 기록을 대상으로 할 수 있습니다. 종단 간 암호화는 개인 메시지 내용을 제공자가 읽을 수 있는 형태로 보유하지 못하게 할 수 있지만, 계정을 익명으로 만들거나 수사기관이 다른 곳에서 정보를 얻는 것을 막지는 않습니다.
결과는 서비스의 실제 데이터 보관, 사용한 통신 기능, 증거 출처, 적용되는 법적 절차에 달려 있습니다. 자료 제출 명령, 수색영장, 기기 조사는 서로 같은 것이 아닙니다. 이 글은 특정 법원이나 관할권이 사건을 처리하는 방식이 아닌 기술적 경계를 설명합니다. 실제 요청에는 자격 있는 전문가의 법률 자문을 받으세요.
데이터 출처부터 살펴보기
“경찰이 암호화된 메시지를 읽을 수 있나요?”라는 질문은 너무 포괄적입니다. 사본이 어디에서 나오는지 물어보세요.
| 출처 | 확보할 수 있는 정보 | E2EE가 바꾸는 것 |
|---|---|---|
| 메신저 제공자 | 계정 기록, 저장된 메타데이터, 공개 게시물, 암호화된 전달 데이터 | 제공자에게 키가 없을 때 올바르게 구현된 E2EE는 개인 평문 접근을 제한함 |
| 참여자의 기기 | 표시된 대화, 로컬 데이터베이스, 다운로드한 파일, 알림 | 전송 중 암호화는 접근 가능한 단말에 이미 있는 데이터를 숨기지 않음 |
| 백업 서비스 | 해당 백업 자체의 암호화 및 키 정책에 따른 백업 내용 | 채팅 E2EE가 백업 E2EE까지 자동으로 보장하지는 않음 |
| 수신자 또는 그룹 구성원 | 그들의 사본, 스크린샷, 내보내기 파일, 증언 | 수신자는 자신이 받은 정보를 공개할 수 있음 |
이 범주들은 겹칠 수 있습니다. 읽을 수 있는 개인 대화 기록이 없는 서버도 유용한 기록을 보유할 수 있고, 방대한 기록을 가진 제공자도 보관 정책에 따라 특정 항목을 삭제했을 수 있습니다. 암호화 표시만으로 어느 결과도 추론할 수 없습니다.
문서화된 사례: Signal이 공개한 대응
Signal은 2021년 10월 캘리포니아 대배심 요청 공개 자료에서, 요청된 메시지·연락처·그룹 정보 대신 계정 생성 타임스탬프와 마지막 접속 날짜를 제공했다고 설명했습니다. 이는 공개된 그 대응에서 Signal이 확보할 수 있었던 기록에 관한 증거입니다.
모든 암호화 메신저가 같은 두 필드를 보관한다는 증거는 아닙니다. 데이터 최소화는 별도의 아키텍처 선택입니다. 또한 수사기관이 사용자의 기기, 다른 참여자, 다른 서비스에서 무엇을 얻을 수 있는지도 이 사례로는 알 수 없습니다.
Livara가 설명하는 서버 가시성
버전 0.1.68용으로 표시된 Livara의 보안 개요는 LVR1로 보호되는 직접 메시지와 LGS1로 보호되는 호환 비공개 그룹을 설명합니다. 호환되지 않는 구형 그룹은 E2EE 밖에 있다는 점이 명확히 표시됩니다. 문서화된 첨부파일 설계는 업로드 전에 파일을 암호화하고, 키를 암호화된 대화 봉투로 전달합니다.
같은 개요에는 발신자·대상 정보, 타임스탬프, 크기, 그룹 구성원 정보 등 보관되는 통신 메타데이터가 나옵니다. 공개 채널은 서버가 읽을 수 있습니다. 선택적인 서버 녹음 통화는 REC로 명확히 표시되며, 해당 녹음 모드에서는 E2EE가 아니라 전송 암호화를 사용합니다. 한 앱의 모든 내용을 동일하게 취급하지 말고 기능별 경계를 읽으세요.
문서는 LSS1 메타데이터 보호가 일반 전송에 연결되어 있지 않다고도 설명합니다. 따라서 일반 메시징이 서비스로부터 통신 관계 그래프를 숨긴다고 말하면 오해를 일으킵니다.
이는 제품 문서의 설명이지 법적 요구에 대한 공개 답변이나 모든 서버 기록의 독립 감사 결과가 아닙니다. 의도된 한계를 이해하려면 위협 모델부터 보는 것이 적절합니다.
암호화와 보관은 다른 질문에 답한다
암호화는 저장된 바이트를 해석할 키를 누가 갖는지 묻습니다. 보관은 어떤 바이트와 기록이 아직 존재하는지 묻습니다. 암호화 파일은 오랫동안 저장될 수 있고, 읽을 수 있는 로그는 짧게만 남을 수도 있습니다. “메시지를 복호화할 수 없다”는 주장은 IP 주소, 지원 상담, 악용 신고, 전달 기록이 없음을 입증하지 않습니다.
유용한 투명성 보고서는 보고 기간, 요청 유형, 요구된 기록, 제공된 기록, 공개 제한을 밝혀야 합니다. 개인정보 처리방침은 수집과 보관을 구분하고 예외를 설명해야 합니다. 일반적인 개인정보 보호 약속에서 “로그 없음”을 추론하지 마세요.
인증에도 별도의 기록이 있습니다. SRP는 정직하게 이루어지는 프로토콜 교환에서 비밀번호 전송을 피할 수 있지만, 서버는 검증값을 보관합니다. RFC 5054의 3.3절은 비밀번호 추측을 포함한 검증값 도난 위험을 설명합니다. “평문 비밀번호 없음”은 “공개되거나 도난당할 민감한 것이 전혀 없음”을 뜻하지 않습니다.
메신저에 의존하기 전에 물을 질문
- 이 정확한 채팅, 백업, 통화, 첨부파일 모드가 E2EE로 보호되는가?
- 제공자는 어떤 메타데이터와 보관 기간을 문서화하는가?
- 추가 기기나 계정 복구 경로가 로컬 사본을 노출할 수 있는가?
- 공개 게시물, 지원 제출 자료, 신고된 메시지를 별도로 처리하는가?
- 근거 없는 법적 면책 주장 대신 날짜가 있는 투명성 보고서나 실제 공개된 요청이 있는가?
진행 중인 법적 사안에서는 블로그 글을 기록 삭제, 보관 변경, 명령 무시의 지시로 받아들이지 마세요. 관할권에 적합한 자문을 받고, 자문에 따라 관련 자료를 보전하세요.
양자내성 암호화가 답을 바꿀까?
적절하게 설계된 키 설정 프로토콜을 강화해, 수집된 암호문에 대한 미래 양자 공격에 대비할 수 있습니다. 하지만 기존 메타데이터, 공개 내용, 단말 사본, 법적 의무를 없애지는 않습니다. 실질적인 구분은 여전히 같습니다. 데이터와 그 위치, 키, 그리고 접근을 요구하는 절차를 파악해야 합니다.
