그룹 암호화 메시징이 실제로 작동하는 방식

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portions you want translated) here? I’ll keep the source line, formatting, markdown, and any code blocks exactly as they are.

Background

암호화된 대화에 세 번째 사람을 추가하는 것은 간단해 보이지만, 실제로는 그렇지 않습니다. 1:1 메시지를 안전하게 만드는 암호학적 특성—전방 비밀성, 사후 타협 보안, 부인 가능성—은 그룹 규모가 커질수록 유지하기가 크게 어려워집니다.

Signal이 그룹 채팅을 도입했을 때, 1:1 메시징에서는 존재하지 않는 문제에 직면했습니다: 다수의 수신자에게 단일 메시지를 효율적으로 암호화하면서 강력한 보안 보장을 유지하려면 어떻게 해야 할까요? 순진한 답변—각 수신자마다 메시지를 별도로 암호화하는 것—은 작동하지만 확장성이 좋지 않습니다.

Pairwise Encryption (Signal v1)

가장 간단한 그룹 메시징 구현은 pairwise encryption(쌍별 암호화)입니다. 송신자는 각 그룹 구성원과 별도의 보안 채널을 설정하고, 메시지를 각각 개별적으로 전송합니다. 이는 각 채널이 Signal Protocol(Double Ratchet)을 사용하여 매 메시지마다 키를 교체하기 때문에 완전한 전방 비밀성을 제공합니다.

• 장점: 강력한 보안; 각 쌍별 채널이 1:1 대화만큼 안전합니다.
• 단점: 선형 확장성 — 메시지 오버헤드가 그룹 규모에 비례하여 증가합니다. 예를 들어 100명의 그룹에서는 하나의 메시지를 보내기 위해 100번의 개별 암호화, 100번의 네트워크 전송, 그리고 100번의 래칫 진행이 필요합니다.

Sender Keys (Signal current)

Signal의 현재 그룹 구현은 Sender Keys를 사용하여 확장성 문제를 해결합니다.

1. 각 그룹 구성원은 Sender Key를 생성합니다—이 키는 해당 구성원의 발신 메시지를 위한 일련의 암호화 키를 파생시키는 체인 키입니다.
2. Sender Key는 각 그룹 구성원에게 개별적으로 배포됩니다(한 번의 비용).
3. 그 후, 발신자는 자신의 체인에서 현재 키를 사용해 각 메시지를 한 번만 암호화합니다.

이렇게 하면 이후 메시지에 대한 메시지 오버헤드가 **O(N)**에서 **O(1)**으로 감소합니다.

• 트레이드‑오프: Sender Keys는 해시 체인을 따라 앞으로 진행되며, 수동 관찰자에 대한 전방 비밀성을 제공합니다. 그러나 전체 Double Ratchet의 침입 복구 기능은 부족합니다. 구성원의 현재 상태가 손상되면, 공격자는 체인이 재설정될 때까지 이후 메시지를 복호화할 수 있습니다.
• 결과: 전방 비밀성은 유지되지만, 손상 후 보안(post‑compromise security)은 약해집니다.

멤버십 변경

보안 그룹 메시징에서 가장 어려운 문제는 메시지를 암호화하는 것이 아니라, 멤버십 변화를 안전하게 관리하는 것입니다.

• 새로운 멤버에 대한 전방 비밀성: 새로운 멤버는 자신이 가입하기 전에 보낸 메시지를 복호화할 수 없어야 합니다.
• 제거 후 비밀성: 제거된 멤버는 이후 메시지를 복호화할 수 없어야 합니다. 이를 달성하려면 제거 후 그룹 키를 회전해야 하며, 1,000명의 멤버가 있는 그룹에서는 쌍별 또는 Sender‑Key 방식으로 999개의 개별 키 배포가 필요합니다.

Messaging Layer Security (MLS, RFC 9420)

**Messaging Layer Security (MLS)**는 그룹 메시징 보안을 대규모로 해결하기 위해 기본 원칙에서 설계되었습니다.

• MLS는 멤버십 변경 시 O(N) 키 배포를 이진 트리(“ratchet tree”)로 대체합니다. 여기서 그룹 구성원은 리프에 위치하고 내부 노드는 중간 키를 보유합니다.
• 구성원이 키 자료를 업데이트할 때(“commit”)는 자신의 리프에서 루트까지 경로에 있는 노드만 업데이트하면 됩니다. N명의 구성원이 있는 균형 트리에서는 O(log N) 연산이 필요하며, O(N)보다 적습니다—예를 들어 1,000명일 경우 약 10번의 연산으로 999번이 필요했던 경우와 비교됩니다.

Epochs

MLS는 epoch이라는 개념을 도입합니다—그룹 상태의 버전입니다. 그룹 멤버십이 변경되거나 키 자료가 업데이트될 때마다 그룹은 새로운 epoch으로 전진합니다. 메시지는 전송 시점에 유효한 epoch 키로 암호화됩니다. 이를 통해 다음을 제공합니다:

• 전방 비밀성(forward secrecy)을 위한 명확한 경계.
• 새로운 epoch으로 전환하여 장치 탈취로부터 복구.
• 그룹 상태 변경에 대한 암호학적 감사 로그.

Concurrency

분산 시스템에서는 두 구성원이 동시에 epoch을 전진시키려 할 수 있습니다—이를 “동시 커밋(concurrent commit)”이라고 합니다. MLS는 해결 메커니즘을 정의하며, 이는 Sender‑Key 접근 방식이 피하는 복잡성을 추가합니다.

채택 (2026년 현재)

• WhatsApp이 MLS 채택을 발표했습니다.
• Apple Messages가 그룹 채팅에 MLS 사용을 시작했습니다.
• Matrix는 MLS 구현을 개발 중입니다.
• Haven은 암호화된 그룹 채팅에 MLS를 사용하며, 특히 O(log N) 회원 변경 오버헤드와 강력한 사후 타협 보안 보장을 위해 사용합니다.
• Signal은 대규모 그룹에 대해 Sender Keys 사용을 계속하고 있습니다—두 접근 방식 모두 그룹 규모 분포와 적대자 모델에 따라 정당화될 수 있습니다.

비교 표

보안 그룹 메신저 앱을 위한 핵심 질문

1. 멤버를 제거하면 앞으로의 메시지를 읽을 수 없게 되나요?
2. 새로운 멤버가 가입하기 전의 대화 기록을 읽을 수 있나요?
3. 그룹 프로토콜이 문서화되어 있으며 독립적인 감사를 받았나요?
4. 한 멤버의 기기가 침해되면 어떻게 되나요?

1:1 상황에서의 포워드 시크리티는 잘 이해되고 있지만, 그룹 상황에서는 구현마다 크게 다른 명시적인 설계 선택이 필요합니다.

원본은 havenmessenger.com에서 발행되었습니다.