안전한 통화에는 데이터 경로가 하나 이상 있습니다. 시그널링은 누가 통화하고 엔드포인트가 어떻게 연결되는지 조율하며, 미디어 경로는 오디오와 비디오를 전달합니다. 한 경로를 보호한다고 다른 경로가 자동으로 보호되지는 않으며, 어느 한쪽만으로 모든 통신 패턴을 숨길 수도 없습니다.
WebRTC는 중요한 보안 메커니즘을 제공하지만, 앱의 신원 확인, 서버 역할, 녹음·녹화 모드 역시 전체 개인정보 보호 경계를 결정합니다.
시그널링과 미디어의 역할은 다르다
| 계층 | 일반적인 목적 | 보안 질문 |
|---|---|---|
| 시그널링 | 초대, 세션 설명, 연결 후보 | 누가 연결 설정 정보를 읽거나 변경할 수 있으며, 의도한 상대의 신원은 어떻게 인증하는가? |
| 미디어 | 오디오, 비디오 및 관련 실시간 스트림 | 암호화는 어디에서 끝나며 어떤 엔드포인트가 미디어에 접근할 수 있는가? |
| 운영 기록 | 라우팅, 연결 시점, 전달 상태 | 서비스나 네트워크가 어떤 메타데이터를 관찰할 수 있는가? |
| 녹음·녹화 | 보존할 사본 생성 | 누가 평문 또는 사용 가능한 기록용 키를 받으며, 사본은 어디에 저장되는가? |
메시징 프로토콜이 암호화된 시그널링을 전달할 수 있지만, WebRTC가 특정 메신저의 봉투 형식을 보편적으로 요구하지는 않습니다. 다른 인증된 설계도 가능합니다.
DTLS-SRTP가 제공하는 것
WebRTC 보안 아키텍처, RFC 8827은 미디어 채널 보호를 요구하고 DTLS-SRTP 키 설정을 설명합니다. 간단히 말해 DTLS는 암호학적 컨텍스트 설정을 돕고, SRTP는 실시간 미디어 패킷을 보호합니다.
그 보호의 종단점이 중요합니다. 참여자 간 직접 암호화 연결은 미디어 처리 서버에서 끝나는 연결과 다릅니다. 일부 다자간 시스템은 서버를 향한 전송 암호화 위에 별도의 종단간 계층을 추가합니다. “WebRTC”라는 말만으로는 제품이 어떤 아키텍처를 사용하는지 알 수 없습니다.
시그널링 인증이 중요한 이유
통화 설정에는 미디어 연결을 의도한 상대와 결합하는 데 쓰이는 정보가 포함될 수 있습니다. 공격자가 이 정보를 들키지 않고 바꿀 수 있다면, 암호화는 잘못된 엔드포인트를 향한 보호된 연결을 만들 수 있습니다.
RFC 8827은 시그널링, 신원, DTLS 지문 간의 이런 관계를 다룹니다. HTTPS는 시그널링 서비스로 향하는 연결을 보호하지만, 그 자체만으로 악의적이거나 침해된 서비스를 고려할 필요가 사라지지는 않습니다. 종단간 인증된 시그널링 또는 적절한 독립적 상대 검증 메커니즘은 이 경계를 강화할 수 있습니다.
시그널링 기밀성은 관련되어 있지만 다른 목표로, 누가 설정 세부 정보를 읽을 수 있는지 제한합니다. 설계는 암호화된 데이터 덩어리만을 두 특성의 충분한 증거로 간주하지 말고 기밀성과 인증을 모두 설명해야 합니다.
암호화된 시그널링도 통화를 보이지 않게 만들지는 않는다
릴레이는 자신이 어떤 계정이나 기기 사이에서 라우팅하는지 여전히 알 수 있습니다. 네트워크 관찰자는 연결 시점, 트래픽 양, 서버 주소를 볼 수 있습니다. 연결 설계에 따라 상대방이나 릴레이 인프라도 네트워크 정보를 알 수 있습니다.
따라서 통화 초대를 암호화한다고 해서 서비스가 통화를 추론하거나, 관계를 파악하거나, 통화 관련 기록을 보존할 수 없다는 증거가 되지는 않습니다. 콘텐츠를 숨기는 것과 트래픽 패턴을 숨기는 것은 별개 문제입니다.
Livara가 공개한 경계
Livara의 보안 페이지는 직접 통화와 그룹 통화를 종단간 암호화라고 설명하지만, 선택적 서버 녹음·녹화에는 명시적 예외를 둡니다. 화면에 표시되는 REC 상태가 활성화된 동안 통화는 E2EE 대신 전송 암호화를 사용합니다.
위협 모델 역시 메타데이터 익명성이나 침해된 기기로부터의 보호를 주장하지 않습니다. 이는 제품 측 설명이며, 모든 통화 경로에 대한 독립적 검증이 아닙니다. 이 안내는 검증되지 않은 참여자 수 제한, 시그널링 형식 또는 양자내성 미디어 구현을 주장하지 않습니다.
특히 메신저의 양자내성 키 교환이 별도의 WebRTC 미디어 핸드셰이크를 자동으로 업그레이드하지는 않습니다. 미디어 경로의 알고리즘과 키 결합은 독립적으로 평가해야 합니다.
민감한 통화 전
- 참여자를 확인하고 예상치 못한 신원 변경을 검토합니다.
- 녹음·녹화가 활성화되었는지, 그로 인해 무엇이 바뀐다고 앱이 설명하는지 확인합니다.
- 서비스가 미디어를 처리하는지, 보호된 패킷만 전달하는지 이해합니다.
- 참여자 주변의 기기와 방을 고려합니다. 악성코드, 화면 캡처 또는 근처의 청취자는 복호화 후 콘텐츠를 노출할 수 있습니다.
- 일반적인 “암호화된 통화” 표시 대신 실제 사용하는 정확한 모드에 대한 아키텍처와 테스트 증거를 요청합니다.
유용한 보안 주장은 시그널링, 미디어, 메타데이터, 녹음·녹화에 누가 접근할 수 있는지를 각각 명시합니다.
