TECH 으로 돌아가기
TECH HACKER NEWS 오늘 7분 읽기 20 READS

시그널 '자동 키 검증'과 제3자 감사자: 신뢰를 코드로 옮기다

시그널 '자동 키 검증'과 제3자 감사자: 신뢰를 코드로 옮기다
SOURCE IMAGE · HACKER NEWS

엔드투엔드 암호화 메신저를 쓰는 사람들이 흔히 놓치는 사실이 하나 있다. 대화 내용이 암호화된다는 것과, 그 암호화가 '올바른 상대'를 향한다는 것은 별개의 문제라는 점이다. 시그널을 예로 들면 모든 대화는 클라이언트가 서버에 상대방 전화번호에 연결된 공개키를 요청하는 데서 시작한다. 문제는 서버가 건네준 그 공개키가 진짜 상대의 것인지 클라이언트가 알 방법이 마땅치 않다는 데 있다. 만약 서버가 침해당해 공격자의 공개키를 대신 내려보낸다면, 사용자는 자기도 모르게 공격자에게 메시지를 암호화해 보내게 된다. 암호화 자체는 완벽해도 수신자가 바뀌는, 이른바 중간자 공격의 전형이다.

지금까지 이런 조작을 잡아내는 유일한 방법은 상대와 직접 만나거나 신뢰할 수 있는 다른 경로로 '안전 번호(safety number)'를 대조하는 것이었다. 하지만 현실에서 이 과정을 꼬박꼬박 수행하는 사용자는 극소수다. 시그널이 최근 내놓은 '자동 키 검증(Automatic Key Verification)'은 이 수작업 대조 없이도 대화의 무결성을 확인하도록 돕는 기능이다. 보안 감사 기업 Trail of Bits는 이 시스템을 신뢰할 수 있게 만드는 세 곳의 감사자(auditor) 중 하나를 직접 구축하고 운영한다고 밝혔다.

키 투명성이라는 접근법

자동 키 검증의 핵심은 '키 투명성(key transparency)'이라는 개념이다. 각 전화번호에 연결된 공개키 집합에 대해 전 세계적으로 일관된 하나의 뷰를 만들어, 서버가 특정 사용자에게만 다른 키를 보여주는 조작을 숨기기 어렵게 만드는 것이다. 이를 위해 시그널 앱은 주기적으로 자기 점검을 수행한다. 전역 키 맵에 저장된 자기 계정의 키가 모두 실제 자기 기기의 것인지 확인하고, 로그를 검증하지 못하거나 예상치 못한 키가 발견되면 '이 기기에서는 자동 키 검증을 현재 사용할 수 없습니다'라는 경고를 띄운다.

감사자의 역할은 이 사용자↔공개키 맵이 전역적으로 일관되고 올바른 형태이며 어떤 항목도 숨기지 않는다는 점을 외부에서 검증하는 것이다. Trail of Bits는 새 항목이 추가될 때마다 자체 보관하는 맵을 갱신하는데, 이 맵은 머클 트리(Merkle tree) 형태로 저장된다. 그리고 자신만 아는 서명키로 트리의 최상단(head)에 주기적으로 서명한다. 오직 하나의 일관된 머클 트리 계보에만 서명하기로 약속하기 때문에, 클라이언트는 자신이 보고 있는 공개키 집합이 다른 모든 사용자가 보는 것과 동일하다는 사실을 확신할 수 있다. 현재 클라이언트는 시그널, 클라우드플레어, Trail of Bits 세 감사자 모두의 서명을 요구한다.

'최대 일주일'이라는 방어선

동작 방식을 구체적으로 보면 방어의 성격이 분명해진다. 자동 키 검증이 켜지면 시그널 클라이언트는 키 투명성 서버에서 머클 트리 head를 주기적으로 가져오고, 각 head가 등록된 모든 감사자에 의해 최근 7일 이내에 승인된 계보에 속하는지 확인한다. 서버가 유효한 감사자 서명을 제시하지 못하면 클라이언트는 경고를 띄우고 검증은 실패한다. 이 설계의 함의는 뚜렷하다. 완전히 악의적인 서버라 하더라도 서로 다른 사용자에게 분리된 뷰(split view)를 보여주는 상태를 최대 일주일밖에 유지할 수 없다. 그 이후에는 클라이언트에 경고가 뜨기 시작하기 때문이다. 즉 조작을 원천 차단하는 것이 아니라, 조작이 오래 은폐될 수 없도록 만드는 방식이다.

실무자 관점에서 주목할 대목은 감사자 구현 방식이다. Trail of Bits는 시그널의 참조 구현을 그대로 쓰지 않고 명세만 보고 처음부터 독립적으로 감사자를 작성했으며 코드를 오픈소스로 공개했다. 서로 다른 팀이 같은 명세를 각자 구현해 상호 검증하는 이 구조는, 특정 구현에 숨은 버그나 백도어가 전체 신뢰를 무너뜨리는 단일 실패 지점이 되는 것을 막는다. 신뢰를 특정 조직에 대한 믿음이 아니라 서로 독립적인 코드와 서명의 교차 검증으로 분산시키는 셈이다.

한계와 실무적 시사점

다만 이 기능이 만능은 아니다. Trail of Bits는 상대의 사용자명(username)을 검색해 시작한 대화에서는 자동 검증이 지원되지 않는 경우가 많다고 명시한다. 그 밖의 이유로도 자동 키 검증이 제공되지 않을 수 있으며, 자동 검증에 실패하면 사용자는 여전히 기존의 안전 번호 대조 방식으로 되돌아가야 한다. 설정 경로는 '설정 > 개인정보 보호 > 고급'에서 기능을 켠 뒤, 지원되는 대화의 안전 번호 화면에서 '자동으로 검증'을 누르는 식이다. 결국 자동화는 다수의 일반적 상황을 덮어주는 편의 장치이고, 최후의 신뢰 근거는 여전히 사람이 직접 확인하는 안전 번호에 남아 있다.

이 사례가 던지는 더 큰 메시지는 공개키 무결성이 엔드투엔드 암호화 시스템의 필수 구성 요소라는 점이다. 아무리 암호 알고리즘이 견고해도 키 배포 단계가 신뢰되지 않으면 전체 보안이 무너진다. Trail of Bits는 시그널이나 어느 쪽으로부터도 대가를 받지 않고 사용자와 커뮤니티의 이익을 위해 이 감사자를 운영한다고 밝혔다. 자체 서비스에 키 투명성이나 엔드투엔드 암호화를 도입하려는 개발자라면, 알고리즘 선택만큼이나 '키가 올바른가'를 지속적으로 외부에서 검증하는 구조를 어떻게 설계할지가 핵심 과제가 된다는 점을 이 구현에서 읽어낼 수 있다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://blog.trailofbits.com/2026/08/11/how-trail-of-bits-he...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...