키 투명성

역사

키 투명성의 출발점은 2015년 USENIX Security '15에서 발표된 논문 「CONIKS: Bringing Key Transparency to End Users」(마르셀라 S. 멜라라, 에런 블랭크스타인, 조지프 보노, 에드워드 W. 펠튼, 마이클 J. 프리드먼)이다. CONIKS 연구는 신뢰할 수 없는 제공자가 운영하는 안전한 웹메일 서비스를 설계하는 과정에서 시작되었다. 지문 대조 방식의 수동 검증은 오류가 잦고 자동화하기 어려운 반면, 중앙집중식 키 서버는 제공자의 키 조작을 무조건 신뢰하도록 요구한다는 문제가 있었다.

2023년 4월 WhatsApp은 키 투명성을 배포하고 오픈소스 감사 가능 키 디렉터리(Auditable Key Directory, AKD) 라이브러리를 공개했다. 그 구현은 CONIKS와 SEEMless를 비롯한 초기 학술 연구에 바탕을 두고, Parakeet 논문의 확장을 더해 Rust AKD 크레이트로 이어졌다. 이후 WhatsApp은 안드로이드와 iOS에서 키 투명성이 완전히 제공된다고 밝혔다. 표준화는 IETF 키 투명성 워킹그룹에서 진행 중이며, draft-ietf-keytrans-architecture-05(2025년 10월 19일, 저자 B. McMillion)는 보안 그룹 메시징 인프라에 KT를 배포하기 위한 용어, 상호작용 패턴, 보안 속성을 정의한다.

구분

인증서 투명성(Certificate Transparency, RFC 6962)과 비교할 때 KT의 결정적 개선점은 로그에서 특정 참여자와 관련된 항목을 찾는 효율적 검색 프로토콜을 갖춘 것이다. 사용자가 로그 전체를 내려받을 필요가 없고, 정말 필요한 참여자에게만 로그 항목을 보여줌으로써 프라이버시를 더 잘 보존할 수 있다.

KT는 대면 QR 코드나 60자리 보안 코드 대조를 대체하지 않고 보완한다. QR 대조는 두 사람이 대면으로 검증 절차를 맞춰야 하지만 KT는 클라이언트 한쪽만 디렉터리를 확인하면 되며, 대규모 그룹처럼 수동 검증이 비현실적인 상황에서도 작동한다. 자동 확인이 연결이 안전하지 않을 수 있다고 알리면 WhatsApp은 수동 검증을 계속할 것을 권한다.

작동과 관계

KT는 중앙의 투명성 로그가 권위 있는 사본을 보유하는 클라이언트-서버 구조다. 사용자 조작은 검색(포함 증명과 함께 레이블의 값을 조회), 갱신(새 레이블-값 쌍 추가, 포함 증명 반환), 모니터링(로그가 정직하게 작동하고 자신의 레이블이 바뀌지 않았는지 주기적으로 확인)이다. 갈라진 뷰를 탐지하려면 신뢰하는 제3자(제3자 감사자나 관리자), 투명성 로그와의 익명 통신, 또는 동등 계층 간 가십(gossip)이 필요하다. 갈라진 뷰가 탐지되면 사용자는 로그의 부정 행위에 대한 부인 불가 증거를 만들어 공표할 수 있다.

배포 방식은 세 가지다. 제3자 관리(제3자가 저장과 운영의 대부분을 맡고 로그가 새 항목에 서명), 제3자 감사(로그가 대부분의 작업을 하고 제3자 감사자의 서명을 주기적으로 받음), 접촉 모니터링(제3자 없이 당사자끼리 하며, 레이블 소유자와 조회자 사이에 감시를 분담).

사례

WhatsApp 클라이언트는 AKD를 통해 상대방의 암호화 키가 진짜인지 자동으로 검증하므로, 사용자는 '보안 코드 확인' 화면에서 검증이 빠르고 자동으로 이루어지는 것을 본다. AKD는 오픈소스라 누구나 디렉터리의 정확성에 대한 감사 증명을 확인할 수 있다. WhatsApp은 분당 수만 건의 키 변경(등록, 재등록 등)을 처리하므로 보류 중인 변경을 분산된 고처리량 큐에 담아 에포크 단위로 묶어 추가 전용 로그에 삽입한다. 서비스 규모에서 이는 계속 늘어나는 수십억 건의 항목에 해당한다.