좋은 위협 모델은 구체적인 위험을 확인 가능한 조치와 연결합니다. 가장 긴 기능 목록을 좇는 것이 아닙니다.
메신저의 위협 모델을 만든다는 것은 어떤 정보가 자신에게 중요한지, 누가 그 정보에 접근할 수 있는지, 자신의 위험과 상황에 어떤 조치가 적절한지 정하는 일입니다. 가족, 기자, 업무용 휴대전화를 사용하는 직원이 마주하는 위협이 반드시 같지는 않습니다. 이 가이드는 개인 보안 계획을 작성하기 위한 간단한 틀이지, 메신저의 안전성을 단정적으로 평가한 순위표가 아닙니다.
핵심 요점
- 위협 모델은 서너 문장이지, 제품이 아닙니다. 무엇을 누구로부터 지키려는지, 어느 정도의 노력을 들일 것인지 적어 보세요. 이 문장들이 없으면 메신저 선택은 기능 목록을 모으는 일에 그칩니다.
- 채팅에는 네 가지 연결 고리가 있습니다. 자신의 기기, 네트워크, 메신저 서버, 상대방의 기기입니다. 이 네 영역은 출발점일 뿐입니다. 백업, 계정, 연결된 서비스도 따로 살펴보세요.
- 종단 간 암호화는 중간에 있는 주체가 메시지 내용을 읽지 못하게 보호합니다. 기기의 보안, 키, 백업, 수신자의 행동은 여전히 중요합니다.
- 자신의 상황에 맞춰 위협을 평가하세요. 기기에 대한 물리적 접근, 알림 미리 보기, 피싱, 백업, 연결된 기기는 검토할 사례이지, 통계에 따른 위험 순위가 아닙니다.
- 메타데이터는 메시지 본문과 별개입니다. 누구와 언제 대화했는지는 본문이 완전히 암호화되어 있어도 남는 정보이며, 따로 판단해야 합니다.
위협 모델이란 무엇이며, 메신저 선택에 왜 중요할까요?
위협 모델은 “무엇을 누구로부터 지키고 싶은지, 어느 정도의 노력을 들일 것인지”를 간단히 적은 것입니다. 이 세 가지가 분명하지 않으면 메신저를 비교해도 기능 목록만 길어질 뿐, 어떤 기능이 자신에게 필요한지 알 수 없습니다.
전자프런티어재단(EFF)도 Security Planning (Threat Modeling) 가이드에서 같은 취지를 설명합니다. 가능한 모든 위협을 언제나 막으려 하면 좌절하기 쉽습니다. 보안은 한 번의 구매가 아니라 지속적인 과정이기 때문입니다. 기술팀을 위한 OWASP 위협 모델링 프로젝트도 비슷한 틀을 제공하며, OWASP 개발자 가이드의 위협 모델 라이브러리에는 참고할 만한 예제가 많이 있습니다.
실용적인 조언 하나를 덧붙이면, 위협 모델은 고정된 문서가 아닙니다. 이직, 출장, 가족 단체방에 새 구성원이 들어오는 일만으로도 전제가 완전히 달라질 수 있습니다. 이런 변화가 생길 때마다 그 네 문장을 다시 써 보세요.
내 메시지는 누가 읽을까요? 연결 고리를 네 부분으로 나눠 보세요
짧게 답하면, 모든 메시지는 자신의 기기, 네트워크, 메신저 서버, 상대방의 기기라는 네 연결 고리를 거칩니다. 복사본이나 연결된 계정도 접근 경로가 될 수 있습니다. 따라서 올바른 질문은 “어떤 메신저가 더 안전할까?”가 아니라 “내 상황에서는 어느 연결 고리가 더 약할까?”입니다.
첫 번째 연결 고리: 자신의 기기
휴대전화 화면에 보이는 모든 내용은 이미 복호화된 상태입니다. 휴대전화가 잠겨 있지 않거나, 잠금 화면에 알림 미리 보기가 켜져 있거나, 누군가 자신의 네 자리 잠금 코드를 알고 있다면, 메시지 전송 경로의 암호화는 그 기기에서 접근 가능한 내용을 읽는 행위를 막아 주지 못합니다.
두 번째 연결 고리: 네트워크
네트워크 관찰자는 연결 대상, 시각, 트래픽 양을 볼 수 있습니다. 그렇다고 DNS 서비스가 전체 경로나 모든 메시지 패킷을 볼 수 있는 것은 아닙니다. 종단 간 암호화를 사용하면 관찰자가 보는 것은 본문이 아니라 암호화된 데이터입니다. 다만 메시지를 주고받았다는 사실과 그 양은 일반적으로 숨겨지지 않습니다.
세 번째 연결 고리: 메신저 서버
서버는 기기 간 동기화를 담당하는 지점입니다. 종단 간 암호화를 사용하면 서버는 본문을 읽지 못하지만, 라우팅 메타데이터는 여전히 볼 수 있고 저장할 수도 있습니다. 바로 여기에서 “암호화되어 있다”와 “사생활이 보호된다”의 차이가 드러납니다.
네 번째 연결 고리: 상대방의 기기
마지막 연결 고리는 자신의 통제 밖에 있습니다. 상대방은 스크린샷을 찍거나 메시지를 전달할 수 있고, 상대방의 휴대전화가 악성코드에 감염되어 있을 수도 있습니다. 이 부분에서는 종단 간 암호화를 쓰더라도 결국 “상대방을 신뢰할 수 있는가”라는 문제가 남습니다. 그 이상을 해결해 주지는 않습니다.
정리하면, 종단 간 암호화는 내용에 접근할 수 있는 범위를 제한하지만, 기기, 키 관리, 정당한 수신자도 여전히 위협 모델의 일부입니다.
자신의 상황에서 어떤 위협을 살펴봐야 할까요?
잠금이 풀린 휴대전화, 계정 접근, 알림 미리 보기, 백업은 살펴볼 만한 사례입니다. 전문적인 표적 공격을 받는 사람에게는 고도화된 악성코드나 신체적 강압도 중요한 문제가 될 수 있습니다. 상황을 알지 못한 채 위험을 작게 보아서는 안 됩니다.
백업은 별도의 접근 경로입니다. 메신저가 백업을 클라우드에 저장하는데 그 백업이 종단 간 암호화되어 있지 않다면, 휴대전화의 암호화가 보호하는 범위는 클라우드 경계까지입니다. 제대로 된 문에 자물쇠를 채웠지만 열쇠를 바로 옆에 둔 셈입니다. 「암호화된 채팅을 안전하게 백업하는 방법」 가이드는 이 경로를 점검하는 데 도움이 됩니다.
두 번째 위협은 가까운 사람입니다. 동료, 함께 사는 사람, 또는 “잠깐만” 휴대전화를 빌려 달라는 사람이 그 예입니다. 세 번째 위협은 로그인 계정입니다. 이메일로 로그인하는데 해당 이메일의 보호가 취약하다면, 가장 약한 고리에서 전체 연결이 뚫릴 수 있습니다. 암호화를 더 강하게 한다고 이런 문제가 해결되지는 않습니다.
해커로부터 채팅 보호하기: 실제로 어떤 공격이 일어날까요?
짧게 답하면, 흔한 채팅 공격은 암호화의 수학적 원리를 깨는 방식이 아닙니다. 피싱, 악성코드, 로그인 코드 탈취, 기기 자체에 대한 공격입니다. 공격자는 자물쇠를 부수기보다 열쇠를 찾습니다.
따라서 계정에 로그인할 때의 행동은 키 길이만큼 중요합니다. Livara는 인증에 SRP, 즉 비밀번호를 알고 있다는 사실을 영지식 방식으로 증명하는 방식을 사용합니다. 기기는 비밀번호 자체를 네트워크로 보내지 않고도 비밀번호를 알고 있음을 증명합니다. 실제로는 로그인 트래픽을 기록하더라도 비밀번호가 드러나지 않는다는 의미입니다. 한계도 명확히 해야 합니다. 사용자가 가짜 페이지에 직접 비밀번호를 입력하는 행위는 SRP가 막지 못합니다. 그때는 수학이 아니라 사용자가 가짜임을 알아차리는지가 문제입니다.
두 번째 공격 표면은 앱 자체입니다. 변조된 APK는 어떤 암호화도 우회할 수 있습니다. Livara는 릴리스마다 SHA-256 체크섬을 공개하므로, 다운로드한 파일을 신뢰할 수 있는 기준값과 비교할 수 있습니다. 검증 실험실에서는 이 작업을 브라우저에서 수행합니다. 다른 메신저에 무엇을 물어봐야 하는지 알고 싶다면, 「안전한 메신저를 선택하기 전에 확인해야 할 질문 목록」이 좋은 출발점입니다.
종단 간 암호화는 무엇을 보호하고, 무엇을 보호하지 못할까요?
짧게 답하면, 종단 간 암호화는 자신의 기기에서 상대방의 기기까지 메시지 내용을 보호해 서버에는 암호화된 데이터만 보이게 합니다. 하지만 이 기능의 이름만으로 모든 메타데이터, 백업, 스크린샷, 공개 채널에 관해 결론을 내릴 수는 없습니다. 각각 별도의 통제 수단이 필요합니다.
특정 제품을 살펴볼 때는 알고리즘 이름으로 추측하지 말고, 기능별 보호 범위 표를 읽으세요. Livara 보안 페이지와 위협 모델은 채팅, 채널, 통화, 메타데이터, 복구를 설명합니다. 이는 제조사가 공개한 주장이며, 독립적인 시험을 대신하지 않습니다. 특히 통화 녹음이 어떻게 처리되는지, 신원 복구와 채팅 기록 복구가 어떻게 다른지는 따로 확인하세요.
본문이 암호화되어 있어도 메타데이터는 무엇을 드러낼까요?
짧게 답하면, 메타데이터는 누가 누구와 언제 얼마나 많은 데이터를 주고받았는지 알려 줍니다. 본문을 암호화한다고 이 정보가 사라지지는 않습니다.
Livara는 기기를 끊김 없이 동기화하기 위해 발신자, 수신 대상, 전달 시각이라는 표준 라우팅 메타데이터를 보관합니다. 이는 명시적인 한계이지, 무시해도 되는 사소한 사항이 아닙니다. 본문을 읽지 않더라도 “누가 누구와 연락하는가”를 보여 주는 관계망은 민감할 수 있습니다. 의사와 환자, 변호사와 의뢰인, 업무 협상의 양측이 그 예입니다. 더 자세한 설명은 「메시징 메타데이터가 드러내는 정보」에 있습니다.
자신의 위협 모델에 “내 통신 패턴을 볼 수 있는 사람”이 포함된다면, 어떤 종단 간 암호화 메신저도 그것만으로는 이 문제의 답이 되지 못합니다. 누구와, 어디에서 대화하는지도 생각해야 합니다.
5분 안에 자신의 위협 모델 작성하기
짧게 답하면, 네 가지 질문에 답하세요. 누구를 경계하는가, 그 사람은 무엇을 원하는가, 어느 정도의 능력이 있는가, 메시지가 유출되면 어떤 일이 생기는가입니다. 그런 다음 비용과 부담이 가장 적으면서 효과적인 조치를 선택하세요. 순서를 거꾸로 해서는 안 됩니다.
- 위협을 가하는 사람은 누구인가요? 동료, 전 연인, 도둑, 기업, 정부처럼 구체적으로 적으세요.
- 무엇을 보호할 가치가 있나요? 대화 본문, 파일, 또는 통신 패턴 자체인가요?
- 그 사람의 능력은 어느 정도인가요? 휴대전화에 직접 접근할 수 있나요? 계정에 접근할 수 있나요? 풍부한 자원을 갖고 있나요?
- 유출되면 어떤 일이 생기나요? 평판, 직장, 신체적 안전에 영향을 주나요? 아니면 단지 창피한 정도인가요?
- 이 답을 바탕으로 비용과 부담이 가장 적으면서 효과적인 조치를 선택하세요.
위협이 같은 Wi-Fi의 관찰자라면, 유효성이 검증된 TLS 연결과 인증된 종단 간 암호화가 중요합니다. 기기에 대한 물리적 접근이 문제라면 기기 잠금이 또 다른 우선순위가 됩니다. 「보안 번호로 암호화된 채팅을 확인하는 방법」은 그 절차를 보여 줍니다. 특정 메신저에서 누가 무엇을 볼 수 있는지 알고 싶다면, Livara가 공개한 위협 모델이 구호가 아닌 구체적인 설명을 제공합니다.
짧은 위협 모델 예시
“내 휴대전화의 업무 파일은 민감하다. 지금 가장 큰 위험은 동료가 잠금이 풀린 휴대전화와 갤러리에 저장된 복사본에 접근하는 것이다. 이번 주에는 자동 잠금 대기 시간을 줄이고, 알림 미리 보기를 제한하며, 백업 폴더를 확인하겠다. 그런 다음 테스트 파일로 결과를 확인하겠다.”
이는 예시일 뿐입니다. 자신을 통제하려는 사람이 기기에 접근할 수 있다면, 설정을 갑자기 바꾸는 것이 그 사람의 주의를 끌 수 있습니다. 안전한 기기와 신뢰할 수 있는 사람의 도움을 받아 계획하고, 신체적 안전을 최우선으로 두세요.
자주 묻는 질문
“위협 모델”을 한 문장으로 어떻게 정의할 수 있나요?
무엇을 누구로부터 지키고 싶은지, 어느 정도의 노력을 들일 것인지 명확히 하는 것입니다. 이 한 문장이 어떤 보안 기능이 비용을 들일 가치가 있고, 어떤 기능이 복잡성만 늘리는지 결정합니다.
종단 간 암호화를 사용해도 해커를 걱정해야 하나요?
네. 다만 생각하는 방식과는 다를 수 있습니다. 공격자는 자물쇠를 부수기보다 기기, 피싱, 로그인 코드를 노립니다. 따라서 올바른 질문은 휴대전화가 잠겨 있는지, 클라우드 백업이 암호화되어 있는지, 이메일 계정이 보호되고 있는지입니다.
공개 채널도 종단 간 암호화되나요?
아니요. 채널은 내용을 읽을 수 있는 공개 방송 공간으로, 신고 처리와 악용 콘텐츠 삭제가 가능하도록 되어 있습니다. Livara 문서에 따르면 비공개 일대일 채팅과, 호환되며 E2EE가 활성화된 비공개 그룹은 종단 간 암호화됩니다. 호환되지 않는 오래된 그룹은 E2EE 보호 범위 밖이라는 상태가 명확히 표시된 채로 남을 수 있습니다. 해당 대화의 실제 상태를 확인하세요. 그룹 구성원 관리 역시 여전히 서버가 담당합니다.
설치한 Android 버전이 변조되지 않았는지 어떻게 알 수 있나요?
다운로드한 APK 파일의 해시를 신뢰할 수 있는 출처에서 제공하는 동일 버전의 체크섬과 비교하세요. 검증 실험실은 브라우저에서 파일을 확인하도록 설계되었습니다. 해시가 같다는 것은 기준 대상과 일치한다는 뜻일 뿐입니다. 공격자가 파일과 기준 해시를 함께 바꿨다면, 일치만으로는 충분하지 않습니다. 변조된 APK는 암호화를 우회할 수 있으므로, 앱의 무결성 확인은 암호화 자체만큼 중요합니다.
