종단간 암호화, 진짜 설명

암호화가 진짜 의미하는 것

메시지를 암호화한다는 것은 키라고 불리는 특정 정보를 가지고 있지 않은 누구에게나 노이즈처럼 보이는 것으로 변환하는 것을 의미합니다. 이 작업은 발신자의 장치에서 수행되며, 올바른 키를 사용하면 수신자의 장치에서 원래대로 복구됩니다. 그 사이에서 메시지는 겉으로 드러나는 의미가 없는 바이트의 연속으로 전송됩니다. 이것이 단순한 개념입니다. 기사의 나머지 부분에서는 경우에 따라 이것이 실제 보증이 될지 아니면 단순한 마케팅 라벨이 될지를 결정 짓는 뉘앙스에 대해 다룹니다.

종단간 — 영어로 end-to-end, 줄여서 E2EE — 이라는 형용사는 정밀함을 더합니다. 암호화는 중간 서버가 이를 읽고 전달할 수 있도록 하기 위해 수행되는 것이 아닙니다. 발신자의 장치와 수신자의 장치라는 두 끝단만이 키를 소유하도록 수행됩니다. 메시지가 통과하는 모든 서버는 메시지가 아닌 노이즈를 보게 됩니다. 이것이 콘텐츠가 한 서버에서 다음 서버로 암호화되어 이동하지만, 통과하는 각 서버가 전달을 위해 이를 복호화하여 일시적으로 평문을 복구하는 전송 중(in transit) 암호화와의 기술적 차이점입니다.

공유 비밀의 역설

명백한 문제가 있습니다. 두 사람이 서로 메시지를 암호화하고 복호화할 수 있으려면 두 사람 모두 동일한 키가 필요합니다. 하지만 정의상 누군가 엿들을 수 있는 채널을 통해 서로 보내는 모든 것이 전달되는데, 어떻게 이 키에 합의할 수 있을까요? 나중에 키를 사용할 동일한 채널에서 키를 합의하는 것은 불가능해 보입니다. 공격자가 합의하는 시점에 이를 듣게 된다면 이후의 모든 것을 복호화할 수 있기 때문입니다. 수십 년 동안 고전 암호학은 이를 어려운 방식으로 해결했습니다. 키는 사용을 시작하기 전에 물리적인 만남을 통해 직접 전달되었습니다. 대사들은 코트 안감에 꿰매어 놓은 키 가방을 가지고 다녔습니다.

현대의 이메일 환경에서 그 솔루션은 확장성이 없습니다. 우리가 암호화된 통신을 하려는 모든 사람의 집을 물리적으로 방문해야 한다면, 누구와도 대화할 수 없을 것입니다. 50년 전 암호학 커뮤니티가 던진 질문은 이것이었습니다. 서로를 모르고 공개 채널만 공유하는 두 사람이 그 동일한 공개 채널을 통해 채널을 듣고 있는 누구도 알 수 없는 비밀에 합의하는 것이 가능한가?

Diffie-Hellman의 우아함

1976년 Whitfield Diffie와 Martin Hellman이라는 두 수학자는 겉보기에 불가능해 보이는 것을 증명했습니다. 공개 채널(누구나 그들이 말하는 모든 것을 들을 수 있는 채널)만을 통해 대화하는 두 사람이 청취자가 이를 알아내지 못하게 하면서 비밀번호에 합의할 수 있다는 것입니다. 마법처럼 들리지만 그렇지 않습니다. 그것은 수학입니다. 그 이후로 알려진 Diffie-Hellman 키 교환은 사실상 인터넷의 모든 암호화 통신의 기초가 되었으며, 반세기에 걸친 집중적인 사용과 전 세계적인 학술적 조사가 그 견고함을 확인해 줍니다. 시각적 직관이나 수학을 보고 싶은 분은 계속 읽어주시기 바랍니다. 그것이 작동한다는 것을 믿고 싶은 분은 기사의 흐름을 잃지 않고 계속 진행하셔도 좋습니다.

이미지로 이해하고 싶은 분들을 위해 색상을 이용한 유명한 비유가 있습니다. 앨리스와 브루노가 그들을 엿듣는 에바 앞에서 공개적으로 기본 색상(예: 노란색)에 합의한다고 상상해 보십시오. 각자 비공개로 두 번째 비밀 색상을 선택하고 자신의 비밀을 노란색과 섞습니다. 앨리스는 특정한 주황색을 얻고, 브루노는 특정한 초록색을 얻습니다. 그들은 에바 앞에서 결과를 교환합니다. 이제 각자 받은 색상을 자신의 비밀과 섞으면, 섞는 순서는 상관없기 때문에 두 사람 모두 동일한 최종 색상에 도달하게 됩니다. 에바는 노란색과 두 개의 중간 혼합물을 보았지만 비밀은 보지 못했습니다. 비밀 중 하나라도 없으면 최종 색상에 도달할 수 없습니다. 실제 수학은 색상을 모듈러 군 또는 타원 곡선에서의 거듭제곱으로 대체하지만, 개념은 동일합니다. 공유 비밀은 채널에 있는 누구도 재구성할 수 없는 상태에서 공개적으로 구축됩니다.

Diffie-Hellman에서 Signal 프로토콜까지

오늘날 전문 메시징 애플리케이션이 사용하는 종단간 암호화는 거의 예외 없이 Diffie-Hellman 교환의 우아하고 강화된 버전에 의존합니다. 2013년에서 2016년 사이에 Trevor Perrin과 Moxie Marlinspike가 설계한 Signal 프로토콜이 참조 기준입니다. 이는 두 가지 핵심 아이디어를 결합합니다. 첫째, 두 장치 사이의 초기 공유 비밀을 생성하는 타원 곡선(X25519)에서의 키 교환입니다. 둘째, 메시지마다 자동으로 키를 갱신하는 Double Ratchet(더블 라쳇)이라 불리는 것입니다. 이를 통해 오늘 장치가 침해되더라도 과거의 메시지를 복호화할 수 없으며, 라쳇이 회전한 후의 미래 메시지도 복호화할 수 없습니다.

Zig에서 두 장치 사이의 공유 비밀을 생성하는 X25519 교환은 표준 라이브러리를 사용하여 6줄 안에 들어갑니다.

const std = @import("std");
const X25519 = std.crypto.dh.X25519;

// Alicia y Bruno generan cada uno un par (privada, pública).
const par_alicia = X25519.KeyPair.generate(io);
const par_bruno  = X25519.KeyPair.generate(io);

// Cada parte recibe la clave pública de la otra y deriva el mismo secreto.
const secreto_alicia = X25519.scalarmult(par_alicia.secret_key, par_bruno.public_key) catch unreachable;
const secreto_bruno  = X25519.scalarmult(par_bruno.secret_key,  par_alicia.public_key) catch unreachable;
// secreto_alicia == secreto_bruno  (32 bytes)

그렇다면 std.crypto.dh.X25519 내부에는 정확히 무엇이 있을까요? 숨겨진 마법은 없습니다. Zig의 자체 표준 라이브러리에서 전체를 읽을 수 있는 두 개의 짧은 함수입니다. 첫 번째는 개인 키에서 공개 키 — 교환의 «gᵃ» — 를 파생시킵니다.

pub fn recoverPublicKey(secret_key: [secret_length]u8) IdentityElementError![public_length]u8 {
    const q = try Curve.basePoint.clampedMul(secret_key);
    return q.toBytes();
}

기사의 표현을 빌리자면, 개인 키는 기초 산술적인 의미가 아니라 타원적인 의미에서 Curve25519 곡선의 기본점(base point)과 «곱해지며», 그 결과는 32바이트로 직렬화(serialize)됩니다. clampedMul 연산은 해당 스칼라 곱셈의 강화된 버전입니다. 알려진 공격 제품군에 저항하기 위해 암호화 커뮤니티가 수년에 걸쳐 추가한 보호 장치들을 통합하고 있습니다. 함수 본문은 2줄입니다.

두 번째 함수는 귀하의 개인 키를 상대방이 보낸 공개 키와 결합합니다. 이것이 교환의 «(gᵇ)ᵃ»이며, 두 사람 모두 결코 전송하지 않은 32바이트의 공유 비밀을 생성합니다.

pub fn scalarmult(secret_key: [secret_length]u8, public_key: [public_length]u8) IdentityElementError![shared_length]u8 {
    const q = try Curve.fromBytes(public_key).clampedMul(secret_key);
    return q.toBytes();
}

2줄이 더 있습니다. 수신된 공개 키는 곡선 위의 점으로 해석되며, 자신의 개인 키와 «곱해집니다». 곡선 연산의 교환 법칙(숫자 예시에서 보았던 지수 곱셈의 교환 법칙과 유사)에 의해 양 당사자는 직렬화된 동일한 점, 즉 이 기사에서 이야기하는 공유 비밀에 도달하게 됩니다.

종단간 암호화가 보호하는 것

올바른 구현을 가정할 때 E2EE가 잘 보호하는 것은 전송 중인 메시지의 내용입니다. 암호화된 데이터를 수신하고 전달하는 중간 서버에는 이해할 수 없는 바이트의 연속이 보일 것입니다. 케이블, 라우터, Wi-Fi 액세스 포인트에 접근할 수 있는 공격자도 똑같은 것을 보게 될 것입니다. 통신 사본을 보관하는 서비스 제공업체도 나중에 이를 읽을 수 없습니다. 서비스 운영자에게 콘텐츠 제출을 명령하는 정부도 서버가 처음에 가지고 있던 것과 동일한 이해할 수 없는 바이트를 받게 될 것입니다.

이는 실무적인 관점에서 매우 큰 의미를 갖습니다. 불투명한 봉투 안에 편지를 쓰는 것과 엽서에 쓰는 것의 차이입니다. 둘 다 도착합니다. 하지만 우체부로부터 내용을 보호하는 것은 하나뿐입니다.

종단간 암호화가 보호하지 않는 것

마찬가지로 알아두어야 할 사항이 있습니다. E2EE는 메타데이터를 보호하지 않습니다. 서버는 사용자 A가 사용자 B에게 몇 시에, 얼마나 자주, 어디서 데이터를 보내는지에 대해 무엇을 말하는지는 모르더라도 여전히 알고 있습니다. 이러한 메타데이터는 이전에 「암호화하는 것」이 「프라이버시를 지키는 것」은 아니다 에서 논의했듯이 종종 내용보다 더 많은 것을 드러냅니다. 누군가 금요일 밤 22:00에 이혼 전문 법률 사무소에 30분 동안 전화했다는 사실을 아는 것은 통화 내용이 결코 말하지 않은 이야기를 들려줍니다. 이것은 어떤 사람이 종양 클리닉을 여러 번 드나드는 것을 보는 것과 같은 상황입니다. 안에서 어떤 대화가 오가는지 듣지 않아도 무슨 일이 일어나고 있는지 상상하기에 충분합니다. 단일한 고립된 메타데이터는 아무런 의미가 없을 수 있지만, 여러 데이터가 교차하면 진실과 너무나 흡사한 무언가가 그려집니다. E2EE는 끝단(endpoints)을 보호하지 않습니다. 수신자의 장치가 악성 프로그램에 의해 침해되었다면 메시지는 해당 수신자에게 정상적으로 복호화되고 악성 프로그램이 이를 읽습니다. E2EE는 대화 상대방의 신원 자체를 보호하지 않습니다. 앨리스가 브루노와 대화하고 있다고 믿더라도 공격자가 처음에 개입했다면(중간자(man in the middle) 공격), 그리고 프로토콜에 독립적인 검증이 포함되어 있지 않다면 두 당사자는 서로 대화하고 있다고 생각하면서 침입자와 대화하게 됩니다.

모호함 없이 명확히 해두어야 할 네 번째 사항이 있습니다. E2EE는 이를 제공한다고 주장하는 제공업체가 자신의 시스템에 암호화되지 않은 메시지의 사본을 추가로 보관하는 것을 막지 않습니다. 「내 메시지는 종단간 암호화되어 있다」는 주장과 「제공업체는 내 콘텐츠를 보관하지 않는다」는 주장은 동일하지 않습니다. 애플리케이션은 두 번째 주장을 위반하면서 첫 번째 주장을 충족할 수 있습니다. 우리는 2018년 이후 뉴스 헤드라인에서 이를 반복해서 보아왔습니다. 사용자는 클라이언트 코드를 검증할 수 없는 한 전문가의 조사 없이는 한 경우와 다른 경우를 기술적으로 구별할 방법이 없습니다. 일반 대중에게 가장 잘 알려진 사례: WhatsApp은 전송 중에 메시지를 종단간 암호화하지만, 사용자가 추가 암호화 없이 iCloud나 Google Drive에서 백업을 활성화하면 해당 사본은 제3자의 인프라에 읽을 수 있는 상태로 저장되며, 암호화는 사용자 자신의 끝단에서 깨지게 됩니다.

운영자가 듣고 싶어 하지 않는 질문

종단간 암호화를 한다고 주장하는 애플리케이션은 기술적으로 키와 관련하여 다음 세 가지 중 하나를 수행할 수 있습니다.

1. 키는 장치에만 존재합니다. 키는 오직 사용자의 장치에서만 생성되고 존재합니다. 운영자는 키를 알지 못하며 저장하지도 않습니다. 이것이 최적의 사례입니다.
2. 운영자가 원하면 액세스할 수 있습니다. 운영자가 사용자의 키를 보유하고 있거나(원하는 대로 생성할 수 있거나) 자신의 데이터베이스에 저장합니다. 원하거나 강제될 경우 내용을 읽을 수 있습니다. 대부분의 '클라우드' 서비스가 이 경우에 해당합니다.
3. 설계상 액세스할 수 없지만, 액세스 권한을 제어합니다. 운영자가 키를 가지고 있지는 않지만, 키를 생성하는 애플리케이션을 제어합니다. 강제될 경우 암호화 전의 키나 내용을 캡처하는 악성 업데이트를 보낼 수 있습니다. 많은 상용 E2EE 서비스가 이 경우에 해당합니다.

따라서 실무적인 질문은 암호화 여부가 아니라, 장치와 키를 관리하는 소프트웨어를 누가 제어하느냐입니다. Solo2에서 키는 오직 귀하의 '금고'(귀하의 비밀번호로 암호화된 IndexedDB)에만 존재하며 소프트웨어는 검증 가능한 오픈 소스 코드입니다.

전문 독자를 위하여

종단간 암호화는 디지털 주권을 위한 도구입니다. 하지만 모든 도구와 마찬가지로 그 효과는 그것을 휘두르는 손과 그것이 딛고 선 땅에 달려 있습니다.

1. 암호화 키는 어디서 생성되며 물리적으로 어디에 존재합니까? 운영자가 (심지어 일시적으로라도, 복구를 구실로라도) 키에 접근할 수 있다면 E2EE는 명목상일 뿐입니다.
2. 대화를 설정하는 동안 중간자 공격을 방지하는 대화 상대에 대한 독립적인 검증(보안 번호, QR 코드, 대역 외 비교)이 있습니까?
3. 클라이언트 코드는 감사 가능(공개, 게시, 재현 가능)합니까, 아니면 클라이언트가 실제로 수행하는 작업에 대해 제공업체의 말을 신뢰해야 합니까?
4. 서비스는 어떤 메타데이터를 생성 및 유지하며, 기간은 얼마나 됩니까? 콘텐츠가 불투명하더라도 메타데이터는 민감한 정보의 상당 부분을 재구성할 수 있습니다.

이 네 가지 질문은 고급 기술 정보를 요구하지 않습니다. 정직한 운영자라면 공개 문서에서 답할 수 있는 정보를 요구합니다. 답변의 질과 정확성은 답변 자체만큼이나 제품에 대해 많은 것을 말해줍니다.

---

종단간 암호화는 제대로 구현될 경우 현대 암호학이 일상의 실천에 선사한 가장 정교한 구조 중 하나입니다. 공개된 채널을 통해 두 사람이 비밀에 합의할 수 있다는 독창적인 아이디어는 1976년 Whitfield Diffie와 Martin Hellman에게서 나왔습니다. 반세기가 지난 지금도 우리는 그 결과 속에 살고 있습니다. 그러나 모든 기술적 약속이 그러하듯, 그 가치는 라벨이 아니라 실제 이행 여부에 달려 있습니다. 정직한 전문가의 질문은 「암호화되어 있는가?」가 아니라 「누가 키를 가지고 있는가?」입니다. 그 답에 따라 결과는 판이하게 달라집니다. 이를 아는 것이 중요합니다.