종단간 암호화는 단말 사이에서 지원되는 내용을 보호하지만, 단말이나 사용자의 오류와 약점까지 없애지는 않습니다.
종단간 암호화(E2EE)는 지원되는 메시지 내용을 보호해, 전달 서비스가 아니라 참여 기기가 내용을 읽을 수단을 갖도록 합니다. 누가 통신하는지 자동으로 숨기거나, 감염된 휴대전화를 안전하게 만들거나, 수신자가 메시지를 복사하지 못하게 하지는 않습니다.
이 안내서는 메시지가 발신자에서 수신자에게 도달하는 과정을 따라가며, E2EE와 HTTPS를 비교하고, 메신저의 암호화 주장을 평가할 때 필요한 실용적인 확인 사항을 설명합니다.
종단간 암호화란 무엇인가요?
종단간 암호화는 정보를 발신자의 기기에서 암호화하고 참여하는 수신자의 기기에서만 복호화하도록 보호하는 방식입니다.
올바르게 설계된 E2EE 대화에서 메시지는 읽을 수 있는 평문 상태로 발신 기기를 떠나지 않습니다. 대신 암호문, 즉 올바른 암호화 키 없이는 사용할 수 없어야 하는 변환된 정보로 나갑니다.
메시지 서비스는 보호되는 내용을 읽을 수 있는 형태로 받지 않고도 암호화 데이터를 전달하고 동기화하도록 도울 수 있습니다. 프로토콜에 따라 같은 원리를 일대일 통신이나 그룹 통신에 적용할 수 있습니다.
여기서 ‘종단’은 참여 기기를 뜻하며, 반드시 휴대전화 두 대만을 뜻하지는 않습니다. 그룹이나 사용자가 연결한 노트북으로 허가된 단말이 더 많아질 수 있습니다.
이것이 종단간 암호화와 일반적인 전송 암호화의 핵심 차이입니다.
E2EE는 어떻게 작동하나요?
수학은 복잡할 수 있지만, 메시지의 기본적인 이동 과정은 이해할 수 있습니다.
1. 각 참여자가 암호화 키를 가집니다
안전한 메시지 클라이언트는 사용자의 기기에 암호화 키 자료를 생성하거나 저장합니다.
일부 키는 공개적으로 공유할 수 있습니다. 개인 키는 기기가 메시지 복호화에 필요한 비밀 정보를 설정하거나 복구하도록 돕기 때문에 보호되어야 합니다.
2. 기기들이 메시지용 공유 비밀을 설정합니다
참여자들은 서로 일치하는 비밀 값을 도출하는 데 필요한 공개 정보를 교환합니다.
비밀 값 자체를 읽을 수 있는 데이터로 전송할 필요는 없어야 합니다. 각 기기는 필요한 암호 연산을 독립적으로 수행합니다.
3. 메시지를 로컬에서 암호화합니다
발신자가 보내기를 누르면 앱이 발신 기기에서 메시지를 암호화합니다.
읽을 수 있는 문장은 업로드되거나 중계되기 전에 암호문으로 바뀝니다.
4. 서버가 암호문을 전달합니다
메시지 인프라는 암호화된 메시지를 수신자에게 전달하며, 동기화와 배달, 여러 허가된 기기를 지원하기 위해 암호문을 보관할 수 있습니다.
서버는 여전히 중요한 운영 작업을 수행합니다. E2EE는 서버가 다루는 메시지 내용의 형태를 바꿉니다.
5. 수신자가 복호화합니다
허가된 수신 기기는 자신의 암호 자료를 사용해 암호문을 인증하고 복호화합니다.
읽을 수 있는 메시지는 허가된 단말에 표시됩니다. 그 뒤에는 로컬 기록, 알림, 백업, 내보낸 파일에 각각 별도의 보호가 필요합니다.
종단간 암호화는 무엇을 보호하나요?
E2EE는 주로 대화의 내용을 보호하도록 설계되었습니다.
앱과 구현에 따라 다음 내용이 포함될 수 있습니다.
- 개인 텍스트 메시지
- 사진과 동영상
- 음성 메시지
- 문서와 첨부파일
- 음성 또는 영상 통화
- 메시지 편집과 답장
이 내용이 클라이언트에서 올바르게 암호화되면 네트워크 트래픽을 가로채는 공격자는 원래 메시지가 아니라 암호화된 데이터를 보게 되어야 합니다.
서비스 인프라가 이용할 수 있는 읽을 수 있는 대화 내용의 양도 줄어듭니다.
하지만 ‘암호화’라는 말을 마법의 단어처럼 여겨서는 안 됩니다. 사용자는 정확히 어떤 대화 유형과 콘텐츠 처리 경로가 보호되는지 알 권리가 있습니다.
E2EE가 자동으로 보호하지 않는 것
종단간 암호화는 강력하지만, 그 경계는 자주 오해됩니다.
메시지 메타데이터
시스템은 메시지를 전달하고 동기화하기 위해 운영 정보가 필요할 수 있습니다.
서비스에 따라 다음 정보가 포함될 수 있습니다.
- 메시지를 보낸 계정
- 메시지를 받은 대화
- 메시지 전송 시각
- 전달 및 읽음 상태
- 대화 구성원 정보
- 암호화된 메시지의 크기
- 기기 또는 세션 정보
메시지 본문은 읽을 수 없더라도 메시지를 둘러싼 일부 정보는 시스템에서 이용할 수 있습니다.
따라서 ‘메시지 내용이 암호화된다’와 ‘서비스가 메타데이터를 수집하지 않는다’는 별개의 주장입니다.
침해된 기기
종단간 암호화는 악성코드나 단말에 충분히 접근할 수 있는 다른 공격자로부터 평문을 보호하지 못합니다. 이러한 접근에 반드시 화면 잠금 해제가 필요한 것은 아닙니다. 화면이 잠겨 있다는 사실만으로 침해된 운영체제가 메시지 데이터에 접근할 수 없다고 입증되지는 않습니다.
메시지는 결국 허가된 기기에서 읽을 수 있어야 합니다. 앱의 복호화된 데이터, 메모리 또는 화면에 접근할 수 있는 공격자는 내용을 얻을 수 있습니다. 정확한 노출 범위는 기기, 소프트웨어, 침해 상황에 따라 달라집니다.
기기 보안은 여전히 필수입니다.
- 운영체제 업데이트를 설치하세요
- 강력한 기기 잠금 암호를 사용하세요
- 브라우저 확장 프로그램을 검토하세요
- 계정 복구 정보를 보호하세요
- 알 수 없는 앱과 다운로드를 피하세요
수신자의 행동
메시지가 복호화된 뒤 참여자가 이를 복사하거나 전달하거나 촬영하거나 스크린샷을 찍는 것을 E2EE는 막을 수 없습니다.
암호화는 단말 사이의 전달을 보호합니다. 반대쪽 단말을 사용하는 사람을 통제하지는 않습니다.
계정 복구의 실수
복구 시스템은 보안과 사용 편의성 사이에서 균형을 잡아야 합니다.
취약한 복구 절차는 강력한 암호화를 약화할 수 있습니다. 반대로 복구를 전혀 허용하지 않는 시스템에서는 키를 잃었을 때 암호화된 기록에 영구적으로 접근할 수 없게 될 수 있습니다.
신뢰할 수 있는 앱은 복구가 어떻게 작동하는지, 어떤 정보를 백업하는지, 복구 인증 정보를 잃으면 어떻게 되는지 설명해야 합니다.
E2EE와 TLS는 같은 것이 아닙니다
대부분의 현대적인 웹사이트는 HTTPS와 TLS로 브라우저와 서버 사이의 트래픽을 보호합니다.
이는 중요합니다. 같은 네트워크나 전송 경로의 다른 위치에 있는 사람이 연결을 쉽게 읽거나 수정하지 못하도록 돕습니다.
TLS는 그 양 끝점 사이의 연결을 보호합니다. 일반적인 웹 메시지 서비스에서는 한쪽 끝점이 서비스입니다. 별도의 콘텐츠 암호화 계층이 보호하지 않는 한 서비스는 앱 데이터를 읽을 수 있습니다. TLS 명세는 해당 연결에서의 도청, 변조, 위조 방지를 설명합니다.
서버가 읽을 수 있는 일반적인 메시지 방식에서는 다음과 같이 작동합니다.
- 기기가 네트워크 연결을 암호화합니다.
- 서버가 읽을 수 있는 메시지 내용을 받아 처리합니다.
- 서버가 수신자에게 별도의 보호된 연결을 엽니다.
종단간 암호화에서는 메시지 자체가 참여자를 대상으로 먼저 암호화된 뒤 보호된 네트워크 연결 안에 들어갑니다.
간단히 비교하면 다음과 같습니다.
| 보호 항목 | TLS만 사용하는 메시지 | 종단간 암호화 |
|---|---|---|
| 네트워크 전송 중 데이터 보호 | 예 | 예 |
| 네트워크를 건너기 전에 보호됨 | 예, 해당 TLS 연결에 대해 | 예, 의도한 메시지 단말에 대해 |
| 전달 서비스가 보호된 메시지 내용을 읽을 수 있음 | 별도 콘텐츠 암호화가 없으면 일반적으로 가능 | 의도된 키 설계에서는 암호문만으로 불가능 |
| 단말 보안이 여전히 필요함 | 예 | 예 |
| 메타데이터가 자동으로 숨겨짐 | 아니요 | 아니요 |
TLS와 E2EE는 경쟁 관계가 아닙니다. 비공개 메시지 시스템에는 보통 안전한 전송과 올바르게 구현된 콘텐츠 암호화가 모두 필요합니다.
이 정의를 Livara에 적용하기
보안 문서에 따르면 Livara는 개인 통신에 P-256과 ML-KEM-768을 결합한 LVR1 하이브리드 키 합의를 사용합니다. 호환되는 비공개 그룹은 일대일 세션을 통해 배포되는 LGS1 발신자 키를 사용합니다. 공개 채널은 서버가 읽을 수 있으므로 E2EE라고 설명해서는 안 됩니다.
이 구분은 브랜드 이름이 아니라 실제 통신 기능에 관한 것입니다. 문서는 통화 암호화도 별도로 설명하며, 다른 신뢰 경계를 가지며 녹음 여부가 표시되는 모드를 포함합니다. 모든 기능이 같은 보호를 가진다고 가정하지 말고 현재 대화와 통화 상태를 확인하세요.
이는 제품 문서에 명시된 주장이며, 이 글을 위해 수행한 독립 감사 결과가 아닙니다. 운영 메타데이터와 침해된 기기는 여전히 중요한 한계입니다. 양자내성 키 합의는 특정 종류의 암호학적 위험을 다룹니다. 피싱, 안전하지 않은 백업, 잠금 해제된 화면을 무해하게 만들지는 않습니다.
공개 키 지문이 중요한 이유
암호화된 대화는 시스템이 제시하는 아무 키가 아니라 의도한 키로 통신하는 데 달려 있습니다.
공개 키 지문은 참여자의 공개 키를 짧게 나타낸 값입니다. 두 사람은 직접 대화하거나 상대가 확인된 통화를 하는 등 다른 신뢰할 수 있는 경로를 통해 지문을 비교할 수 있습니다.
지문이 일치하면 예상한 키를 사용 중이라는 확신을 더할 수 있습니다.
지문 변경이 자동으로 공격을 입증하지는 않습니다. 정상적인 키 초기화나 기기 복구 후에도 발생할 수 있습니다. 그러나 변경은 조용히 무시할 것이 아니라 표시되고 설명될 수 있어야 합니다.
백업과 복구는 실시간 암호화와 별개입니다
앱이 실시간 메시지를 종단간 암호화하더라도 별도의 백업은 다른 키와 접근 규칙을 사용할 수 있습니다. 평문 내보내기 역시 읽을 수 있는 내용을 암호화된 대화 밖으로 옮길 수 있습니다. 무엇을 백업하는지, 누가 복호화할 수 있는지, 복구 자료를 잃으면 어떻게 되는지 물어보세요.
Livara 문서에 설명된 복구 백업은 업로드 전에 암호화해 봉인되며, 채팅 기록이 아니라 신원 자료를 복원합니다. 계정이나 신원을 복구하면 모든 이전 대화도 복구된다고 추정하지 마세요. 더 폭넓게 판단하려면 암호화된 채팅을 안전하게 백업하는 방법을 참고하세요.
비공개 메시지 앱을 평가하는 방법
‘암호화’나 ‘안전’이라는 단어만으로 메시지 서비스를 판단하지 마세요.
구체적인 질문을 하세요.
어떤 대화가 E2EE인가요?
개인 채팅, 그룹, 채널, 통화, 첨부파일에 보호가 적용되는지 확인하세요.
키는 어디에서 생성되고 저장되나요?
클라이언트에서 키를 생성하는지, 백업을 어떻게 보호하는지 명확한 설명을 찾으세요.
서버는 무엇을 보관하나요?
책임 있는 서비스는 메시지 내용과 라우팅, 타임스탬프, 구성원 정보, 전달 정보 및 기타 운영 데이터를 구분해야 합니다.
키가 바뀌면 어떻게 되나요?
예상하지 못한 키 교체는 표시되어야 합니다. 알림 없는 키 변경은 사용자가 연락처를 검증할 수 있는 능력을 약화합니다.
복구는 어떻게 작동하나요?
제공업체가 키를 복원할 수 있는지, 복구 비밀 정보가 필요한지, 그 비밀 정보를 잃으면 어떻게 되는지 확인하세요.
주장이 독립적으로 검증되었나요?
보안 문서, 공개 프로토콜, 전문가 검토, 독립 감사는 서로 다른 수준의 확신을 제공합니다.
마케팅 표현만으로는 감사가 되지 않습니다.
프라이버시에는 명확한 경계가 필요합니다
가장 강력한 프라이버시 설명은 ‘우리를 믿으세요’가 아닙니다.
다음 사항을 정확하고 시험 가능한 방식으로 설명하는 것입니다.
- 무엇이 암호화되는지
- 어디에서 암호화하는지
- 어떤 키가 관련되는지
- 서버가 무엇을 받는지
- 어떤 메타데이터가 남는지
- 어떤 대화 유형이 제외되는지
- 복구가 위협 모델을 어떻게 바꾸는지
종단간 암호화가 프라이버시의 전부는 아닙니다. 하지만 신중하게 구현하고 정직하게 설명하면 비공개 통신의 핵심 기반이 됩니다.
실용적인 다음 단계로 안전한 메시지 점검표 12문항을 사용해 실제로 이용하는 개인 채팅, 그룹, 첨부파일, 통화, 백업을 살펴보세요.
자주 묻는 질문
E2EE는 무엇의 약자인가요?
E2EE는 종단간 암호화의 약자입니다. 보호되는 내용을 한 참여자의 단말에서 암호화하고 다른 허가된 단말에서 복호화한다는 뜻입니다.
인터넷 제공업체가 E2EE 메시지를 읽을 수 있나요?
인터넷 제공업체는 연결이 존재한다는 사실과 일부 네트워크 수준의 정보를 볼 수 있습니다. 하지만 올바르게 암호화된 메시지 내용은 전송 중에 읽을 수 있는 평문으로 나타나지 않아야 합니다.
종단간 암호화는 메타데이터를 숨기나요?
자동으로 숨기지는 않습니다. 메시지 시스템은 서비스를 운영하기 위해 라우팅, 구성원 정보, 타임스탬프, 전달 상태, 암호문 크기 또는 다른 정보를 계속 처리할 수 있습니다.
E2EE가 도난당한 잠금 해제 상태의 휴대전화를 보호할 수 있나요?
공격자가 이미 허가되고 잠금 해제된 기기를 통제한다면 어떤 암호화 프로토콜도 메시지를 완전히 보호할 수 없습니다. 강력한 기기 보안은 여전히 필요합니다.
Livara의 모든 대화가 종단간 암호화되나요?
Livara는 현재 일대일 개인 메시지 본문과 미디어, 호환되는 비공개 그룹에 E2EE를 제공한다고 문서화합니다. 해당 그룹은 LGS1으로 종단간 암호화되며 구성원이 바뀌면 발신자 키가 자동으로 교체됩니다. 채널은 TLS와 인증이 적용된 서버 측 권한을 사용하며 종단간 암호화된다고 주장하지 않습니다.
분실한 Livara 암호화 키를 복구할 수 있나요?
공개 문서는 필요한 복구 비밀 정보를 사용해 백업된 신원 자료를 복원하는 방법을 설명합니다. 이는 채팅 기록을 복원하지 않습니다. 원래 기기를 삭제하거나 교체하기 전에 현재 복구 절차를 읽으세요.
E2EE와 전방향 안전성은 같은가요?
아닙니다. E2EE는 누가 보호된 내용을 읽을 수 있어야 하는지를 설명합니다. 전방향 안전성은 나중에 키가 침해되었을 때 이전 메시지에 어떤 영향을 주는지에 관한 성질입니다. 침해 후 보안은 명시된 조건에서 침해 뒤 보호를 회복하는 성질입니다. 이 특성은 프로토콜과 구현에 따라 달라집니다. 예를 들어 MLS 명세는 그룹 키 설계에 대해 두 성질을 명확히 정의하지만, 모든 암호화 메신저가 자동으로 이를 제공하거나 MLS를 사용한다는 뜻은 아닙니다.
