통화 보안을 판단할 때는 “암호화되었는가?”만 묻지 말고, 암호화가 어디서 끝나는지와 녹음·녹화로 무엇이 달라지는지 물어보세요.
채팅이 암호화된다는 사실만으로 음성, 영상, 화면 공유 또는 통화 녹음·녹화도 같은 보호를 받는다고 입증할 수는 없습니다. 통화를 평가하려면 미디어가 어디까지 암호화된 상태로 유지되는지, 누가 키를 보유하는지, 녹음·녹화 같은 기능을 켜면 무엇이 달라지는지 물어봐야 합니다.
이 안내서는 보안 주장을 확인 가능한 계층으로 나누어 살펴봅니다. 프로토콜 이름이나 자물쇠 표시는 이러한 질문의 답을 대신하지 못합니다.
하나의 앱에 있는 세 가지 서로 다른 경로
| 경로 | 데이터 예시 | 보안 관련 질문 |
|---|---|---|
| 저장되는 메시지 | 텍스트, 사진, 파일, 음성 메시지 | 기기, 서버, 백업에 있는 사본을 누가 읽을 수 있나요? |
| 실시간 미디어 | 마이크 음성, 영상, 화면 공유 | 암호화가 상대방 기기에서 끝나나요, 아니면 중간 서버에서 끝나나요? |
| 시그널링 | 통화 초대, 응답, 연결 조정 정보 | 제어 메시지나 연결 대상의 신원을 누가 변경할 수 있나요? |
채팅으로 보내는 음성 메시지는 파일이고, 음성 통화는 실시간 스트림입니다. 제품은 이 둘에 서로 다른 키와 방식을 사용할 수 있습니다. 음질이 좋거나 문자 메시지가 도착하지 않는다는 사실만으로 다른 통신 방식의 보안에 관해 알 수 있는 것도 아닙니다.
DTLS-SRTP는 무엇을 보여 주나요?
WebRTC에서 SRTP는 미디어 스트림을 보호하며, DTLS-SRTP는 그에 필요한 키 자료를 설정하는 한 가지 방식입니다. RFC 5764는 DTLS-SRTP의 동작 방식을, RFC 3711은 미디어 패킷 보호를 설명합니다.
하지만 “WebRTC를 사용한다”는 말만으로 회의 서버가 미디어를 복호화하는지 알 수는 없습니다. 암호화의 종단점과 그 인증 방식이 명확해야 합니다. 사용자와 서버 사이의 연결은 암호화되어 있어도, 서버가 처리나 녹음·녹화를 위해 복호화된 내용에 접근할 수 있습니다. 이는 참여자 간 E2EE와 같지 않습니다.
RFC 8827의 WebRTC 보안 아키텍처는 미디어 보호와 더불어 웹 앱에 대한 신뢰, 시그널링 경로, 상대방의 신원도 중요하다는 점을 보여 줍니다. 패킷이 암호화된다는 것이 제품의 모든 구성 요소를 신뢰할 수 있다는 뜻은 아닙니다.
시그널링은 왜 별도로 평가해야 하나요?
시그널링은 누가 누구와 통화하고 어떻게 연결을 설정할지 조정합니다. 앱이 제어 메시지를 보호하더라도, 그 보호가 참여자의 실제 신원 및 미디어 키와 어떻게 연결되는지는 따로 확인해야 합니다.
문서를 읽을 때는 다음 세 가지를 물어보면 됩니다.
- 초대, 응답, 키 정보는 변조로부터 보호되나요?
- 사용자는 그 키가 의도한 상대방의 것임을 어떻게 알 수 있나요?
- 키나 기기가 바뀌면 어떤 경고가 표시되나요?
E2EE 통화에서도 서비스는 라우팅 정보, 시간, 통화 참여자를 알 수 있습니다. 메시징 메타데이터 설명에서는 이러한 차이를 다룹니다.
통화 녹음·녹화는 새로운 보안 경계입니다
“암호화된 통화”라는 표현만으로 녹음·녹화된 사본에 관한 모든 답을 얻을 수는 없습니다. 참여자는 자신의 기기로 음성이나 영상을 기록할 수 있습니다. 서버 측 녹음·녹화도 별도로 문서화해야 합니다. 서버가 기록을 위해 읽을 수 있는 형태의 미디어에 접근하나요? 누가 파일을 보관하나요? 언제 삭제하나요?
녹음·녹화를 켰을 때 보안 모드가 바뀐다면 참여자에게 그 변화가 명확히 드러나야 합니다. 민감한 대화를 시작하기 전에 녹음·녹화 상태와 사람들의 동의를 확인하세요. 앱 내부의 녹음·녹화 표시가 꺼져 있어도 누군가 다른 장비로 기록하고 있지 않다는 보장은 없습니다.
Livara의 현재 문서를 어떻게 읽어야 하나요?
Livara 보안 페이지는 직접 통화와 그룹 통화를 E2EE로 설명하지만, 선택적으로 사용하는 서버 측 녹음·녹화는 예외로 명시합니다. REC가 표시되는 모드에서는 통화 보호가 전송 암호화로 바뀝니다. 이는 제품 문서의 주장이지, 이 글에서 수행한 테스트나 독립 감사의 결과가 아닙니다.
이전 글에서 모든 그룹 통화를 “Android 사용자 2~6명”으로 제한한 내용은 현재 문서와 일치하지 않으므로 이 안내서의 근거로 삼지 않습니다. 원하는 수용 인원, 플랫폼, 버전에 대해서는 최신 안내와 앱의 실제 동작을 확인해야 합니다. 이 글은 수용 인원 테스트를 제공하지 않습니다.
또한 ML-KEM 같은 채팅 알고리즘 이름만으로 같은 알고리즘이 통화 미디어에도 쓰인다고 입증할 수는 없습니다. 통화가 양자 내성을 갖췄다고 주장하려면 미디어 경로와 인증에 관한 구체적인 증거가 필요합니다. Livara 위협 모델은 기능 페이지와 함께 읽어야 하며, 독립적인 테스트를 대신하는 것으로 보아서는 안 됩니다.
두 서비스를 비교하기 전 간단한 체크리스트
“예”라고 답하는 항목마다 버전 이름과 출처도 기록하세요.
- 일대일 통화, 그룹 통화, 화면 공유가 각각 설명되어 있나요?
- 서버가 패킷만 전달하는지, 미디어를 복호화할 수도 있는지 명확한가요?
- 참여자의 신원과 키를 확인할 수 있나요?
- 기기 변경, 참여자 추가, 녹음·녹화 활성화가 명확히 드러나나요?
- 웹과 앱의 통화 경로는 같은가요, 아니면 차이가 있나요?
- 녹음·녹화 파일과 메타데이터의 보관에 관한 설명이 있나요?
- 테스트나 감사 증거가 동일한 버전과 기능에 관한 것인가요?
문서에 답이 없다면 “알 수 없음”이라고 쓰세요. 답이 없다는 것은 안전하다는 증거도, 도청한다는 증거도 아닙니다.
자주 묻는 질문
E2EE 통화는 상대방의 녹음·녹화를 막을 수 있나요?
아니요. 권한이 있는 수신자는 읽을 수 있는 형태의 내용에 접근할 수 있으며, 소프트웨어 도구나 다른 기기로 이를 기록할 수 있습니다.
전송 암호화는 나쁜 것인가요?
전송 암호화는 통신 경로상의 도청을 막는 중요한 보호 기능을 제공합니다. 차이는 종단점인 서비스가 복호화된 내용에 접근할 수 있다는 점입니다. 이를 사용자 간 E2EE라고 불러서는 안 됩니다.
채팅에서 양자 내성 암호화를 사용하면 통화도 양자 내성을 갖게 되나요?
아니요. 주장은 동일한 계층, 알고리즘, 구현 버전에 관한 것이어야 합니다. 채팅과 통화를 따로 평가하세요.
