End-to-end encryption

froajnzd·2024년 12월 13일

real world cryptography

목록 보기

11/12

end-to-end 암호화와 그 중요성

이메일 암호 해결을 위한 다양한 시도

end-to-end 암호화가 메시징 환경을 변화시키는 방법

용어 정리
*CA(Certificate Authority) : 인증 기관

TLS, Noise같은 프로토콜을 통한 운송 보안을 확보할 수 있다.(기밀성, 무결성, 인증)
웹에서의 신뢰는 CA 네트워크에 기반한다. 브라우저와 운영 체제가 CA를 신뢰하고 있으며, 이들은 웹사이트의 정체성을 확인해주는 디지털 인증서를 발급한다.

대칭 암호화 알고리즘은 충분히 신뢰할 수 있다. 여기서 문제는 당사자 간 신뢰를 구축하는 일이다.
즉, Alice와 Bob이 누구인지를 증명하고, 공개 키를 안전하게 공유하는 것이 중요하다는 것.

암호학에서는 상황에 따라 실용적/확장 가능한 여러 신뢰를 구축할 수 있는 솔루션을 제공한다.
예로, PKI는 공개 키를 배포하고 검증하는 데 사용되고, Noise 프로토콜은 동적으로 신뢰를 구축한다.

이 장에서는 참가자들이 서로 알지 못하는 상황에서도 신뢰를 보장할 수 있는 시스템 설계의 필요성을 강조한다.
암호학을 실제 사용할 때는 신뢰 구축 방법이 중요하다!

Why end-to-end encryption?

왜 end-to-end 암호화인가?
단순하게 암호화 프로토콜이 아니라, 통신을 안전하게 보호하려는 개념이다.
적대적인 경로를 거쳐서 두명 이상의 참여자 간 통신을 보호하는 방법이다.

통신 보안을 위해서 TLS로 충분하지 않을까?
이론적으론 그럴 수 있다. TLS는 통신을 보호하는데 사용된다. 하지만, E2EE는 실제 사람 간의 신뢰를 기반으로 한 개념이다.
반면, TLS는 설계상 "men in the middle" 시스템에서 가장 자주 사용된다.
이런 시스템에서는 TLS가 중앙 서버-사용자 간 통신을 보호하는 데만 사용되므로 중앙 서버는 모든 메세지를 볼 수 있는 것이다.

이 MITM 서버가 메세지를 훔쳐볼 수 있는 문제를 해결하는 방법 중 하나로, 이 MITM 서버를 믿을 수 있는 서버로 (trusted third parties) 생각할 수도 있다
즉, 프로토콜을 안전하다고 간주하기 위해 시스템의 이런 부분을 신뢰하는 것이다.

실제로 사용되는 구조 중 더 최악이 있다
사용자-서버 간 통신은 여러 네트워크 홉을 통해 이루어지며, 이 hop 중 일부가 트래픽을 살펴볼 수 있다.(이런 머신을 middlebox라고 한다)
트래픽이 암호화되더라도 일부 미들박스는 TLS 연결을 종료하도록 설정되어 있고, 해당 시점부터 트래픽을 평문으로 전달하거나 새 TLS 연결을 시작하기도 한다.
이런 방식은 "트래픽을 더 잘 필터링하기 위해", "데이터 센터 내에서 연결을 지리적으로 분산시키기 위해"같이 좋은 의도로 사용되기도 한다.

그러나, 이는 트래픽이 평문으로 노출될 위험을 높이고, 공격 대상 면적을 넓힌다.

최악의 경우, TLS 종료는 "트래픽을 가로채거나", "데이터를 기록하거나", "사용자 활동을 감시하는" 악의적인 이유로 사용되기도 한다.

실제 사례

2015년, 레노버가 특정 SW와 CA을 사전 설치한 노트북을 판매하다 발각되었다.
이 SW는 HTTPS 연결을 MITM 방식으로 중단하고, 웹페이지에 광고를 삽입하였다.

중국과 러시아 같은 나라에서 인터넷 트래픽을 자국 네트워크로 우회시켜 통신을 가로채고 감시하기도 했다.

2015년에 Edward Snowden이 미국 NSA 및 여러 정부가 인터넷 케이블을 가로채서 사람들의 통신을 감시했다고 폭로하기도 했다.

기업 관점에서 문제
사용자의 데이터를 소유하거나 접근할 수 있다는 건 기업 입장에서도 부담이다.
데이터 유출/해킹 사고가 자주 발생하고, 기업 신뢰도에 치명적일 수 있는 중요한 책임인 것이다.

그러나 EE2E 시스템에서는 공유할 데이터 자체가 없어 이런 문제들을 피할 수 있다.

결론
현재 사용하는 대부분의 인기 있는 온라인 애플리케이션은 이미 하나 이상의 정부가 데이터를 볼 수 있거나, 볼 수 있는 방법을 갖고 있을 가능성이 높아. 애플리케이션의 위협 모델(어떤 위험을 방어하려 하는지)에 따라, 또는 가장 취약한 사용자를 보호하기 위한 위협 모델에 따라, 엔드투엔드 암호화는 사용자 기밀성과 프라이버시를 지키는 데 핵심 역할을 한다.

end-to-end encryption는 송신자와 수신자만 데이터 내용을 열람할 수 있도록 보장하며, 이는 현재의 TLS 기반 시스템이 제공하지 못하는 프라이버시와 보안의 최고 수준을 제공한다.

A root of trust nowhere to be found

: 찾을 수 없는 신뢰의 근원

가장 단순한 엔드투엔드 암호화 시나리오: Alice가 인터넷을 통해 Bob에게 암호화된 파일을 보내려한다.
1. Bob이 자신의 공개 키를 Alice에게 보낸다
2. Alice가 그 공개 키를 사용해 파일을 암호화한 뒤, Bob에게 파일을 보낸다.
이런 시나리오에서, Alice와 Bob이 실제로 만나거나, 신뢰할 수 있는 다른 채널을 사용해 첫 번째 과정에서 공개 키를 교환할 수 있다면 최고일 것이다. -> 이 경우를 out-of-band 방식으로 신뢰를 생성한다고 한다.
하지만, 현실에서는 out-of-band 방식으로 할 수 없다.

Alice는 자신이 받은 공개 키가 정말로 Bob의 공개 키인지 어떻게 알까? 첫 번째 메세지가 중간에서 변조되었을 가능성은 항상 존재한다.
암호학은 이 신뢰 문제에 대한 완벽한 해결책을 제공하지 못한다.
대신, 다양한 상황에서 쓸 수 있는 여러 해결 방법을 제시한다.

공개 키 변조를 막는 문제의 어려움

공개 키 변조로부터 보호하는 것은 실질적인 공개 키 응용 분야에서 가장 어려운 분야이다. 이는 공개 키 암호학의 아킬레스건이며, 이 문제를 해결하기 위해 소프트웨어 설계가 복잡할 수밖에 없다. - Zimmermann et al. 1992

다시 Alice&Bob의 시나리오에서,

악의적인 능동적 MITM 공격자가 밥의 공개 키를 첫 번째 메시지에서 교체하지 않았다면, 이 프로토콜은 안전하다 볼 수 있다. 심지어 이 메세지가 기록되었더라도, 공격자는 두 번째 메세지를 암호화된 상태에서 해독할 수 없다.

물론, "MITM 공격 가능성이 낮을 것이다"의 가정에 기대어 암호학을 설계하는 것은 최선의 방법이 아니다.

turtles all the way down problem
예로, 구글 크롬은 CA 세트를 신뢰하도록 설정되어 있다.
크롬 설치 -> 운영체제의 기본 브라우저 -> 노트북 -> ....

threat mode에서는 특정 turtle 이후의 문제를 다루지 않고, 그 이후는 out-of-scope로 간주한다.
다음부터는 신뢰의 근원을 안전하게 확보할 방법이 있다고 가정한다.
모든 암호학 기반 시스템은 root of trust에 의존해서 작동한다. 신뢰의 근원은 프로토콜이 안전성을 쌓을 수 있는 기반이 되는 것이다. 이 신뢰의 근원은 프로토콜이 시작할 때 사용하는 비밀 값이나 공개 값, 또는 이를 얻을 수 있는 밴드 외 채널(out-of-band)이 될수 있다.

The failure of encryted email

: 이메일 암호화 실패

이메일은 처음 만들어졌을 때부터 암호화되지 않은 프로토콜이었다. 당시에는 보안이 중요하지 않았다.

이메일 암호화는 1991년에 Pretty Goog Privacy(PGP) 도구가 등장하면서 구체적 아이디어로 자리잡기 시작한다. PGP의 창시자인 Phil Zimmermann은 '미국 정부가 모든 전자 통신 회사 및 제조사로부터 음성/텍스트 통신 데이터를 허용'하려 한 법안에 반발하며 공개했다.

짐머만이 쓴 "Why do you need PGP?"에서 "PGP는 사람들이 자신의 프라이버시를 스스로 지킬 수 있도록 도와줍니다. 이는 사회적으로 필요성이 커져가고 있기에 만들었습니다"라고 밝혔다.

PGP의 표준화와 OpenPGP
PGP는 1998년에 RFC 2440 표준으로 정식화됐고, OpenPGP라는 이름으로 알려졌다.
동시에, GNU Privacy Guard(GPG) 오픈 소스 구현이 등장하면서 많은 사람들이 사용하게 되었다.

오늘날에도 GPG는 주 구현방식으로 사용되고, 사람들은 PGP와 GPG를 같은 의미로 사용한다.

PGP or GPG? And how does it work?

PGP, OpenPGP는 hybrid encryption을 사용한다.

발신자가 이메일을 작성하고, 내용을 암호화하기 전, 압축한다.
OpenPGP는 무작위 대칭 키를 생성하고, 이 대칭 키를 사용해 이메일 내용을 암호화한다
생성된 대칭 키를 각 수신자의 공개 키로 비대칭 암호화한다
각 수신자를 위한 암호화된 대칭 키들을 암호화된 이메일 메시지를 concatenate한다. 이메일 본문은 이 데이터(암호화된 대칭키와 메시지)로 대체되어 전송된다
수신자는 자신의 개인 키로 암호화된 대칭 키를 복호화한 후, 이 대칭키를 사용해 이메일 내용을 복호화한다

이메일 서명(Signing)
OpenPGP는 발신자가 메시지를 서명해 본인임을 인증할 방법도 정의한다.

이메일 내용을 해시하고, 발신자의 개인 키로 서명한다
(2단계에서) 이 서명은 암호화 전에 메시지에 추가된다.
수신자가 서명을 검증하기 위해 사용될수 있도록, (4단계에서) 발신자의 공개 키가 암호화된 이메일에 포함된다

왜 암호화 전에 압축할까?
압축은 데이터의 패턴을 제거해 데이터를 더 작게 만들고, 암호화의 보안성을 높인다. 암호화 후에 압축하고자 한다면 암호화된 데이터는 이미 난수화되어 있어 압축이 효과를 발휘하지 못한다.

메타데이터 문제
암호화는 메시지의 본문 내용을 보호하지만, 항상 메타데이터를 숨길수는 없다.
메타데이터는 IP address, 메시지 길이, 송수신 빌도 및 대상을 포함할 수 있다.
이 데이터는 사용자의 익명성을 해칠 수 있다.

Scaling trust between users with the web of trust

PGP에서는 신뢰를 스스로 쌓아야 한다.

친구 Bob의 PGP 공개 키를 안전하게 얻을 수 있는 방법을 찾아야 한다. 가장 확실한 방법은 만나서 공개 키를 받는 것이다.

그럼 이메일을 보내고 싶은 사람에게 모두 이렇게 해야할까? 물론 아니다. 다음을 가정해 보겠다.

나는 만나서 Bob의 공개 키를 얻었으므로 신뢰할 수 있다.
나는 Mark의 공개 키를 가지고 있지 않지만, Bob은 가지고 있고 그는 그것을 신뢰한다

Bob은 Mark의 키에 간단히 서명할 수 있으며, 공개 키와 마크의 이메일 사이 연관성을 신뢰한다는 것을 보여준다.
Bob을 믿으면 Mark의 공개 키를 믿고 나의 레퍼토리에 추가할 수 있다.
이것은 PGP의 decentralized trust 개념의 주요 아이디어이다. Web of trust(WOT)라고 한다.

WOT: 사용자가 서명에 의존해 다른 사용자를 일시적으로 신뢰할 수 있는 개념

Key discovery(키 검색) is a real issue

PGP는 공개 키를 검색(discovery)하는 문제를 해결하기 위해 key registries 방식을 시도했다.
: 내 PGP 공개 키와 내 신원을 보증하는 다른 사람들의 서명을 공개 목록에 올려서 다른 사람들이 이를 찾을 수 있도록 하는 것

현실적으로, 누구나 자신의 이메일에 해당하는 공개 키와 서명을 마음대로 게시할 수 있기에, 공격자도 의도적으로 잘못된 키를 업로드할 수 있다.

S/MIME: PGP의 대안
1995년 RSA 회사는 PGP의 대안으로 S/MIME를 제안했다.

S/MIME(Secure/Multipurpose Internet Mail Extensions): 이메일 표준의 확장판인 MIME 포맷을 기반으로 한 암호화 방식. RFC 5751로 표준화됨. PKI를 통해 신뢰를 중앙집중식으로 관리.

PGP와 S/MIME의 문제점
모두 이메일 송수신에 사용되는 SMTP(Simple Mail Transfer Protocol)위에서 동작한다.
SMTP 이후에 발명되었기 때문에 완벽히 통합되지 못했다.

이메일 body는 암호화되지만, subject나 기타 메타데이터는 암호화되지 않는다.
S/MIME도 구식 암호화 방식을 사용하며, 인증된 암호화(authenticated encryption)를 제공하지 않는다.

Efail 취약점
최근 연구에서 두 프로토콜의 이메일 클라이언트 통합 방식에서 데이터 유출(exfiltration) 공격에 취약하다고 밝혀졌다.

exfiltration attack: 암호화된 이메일을 관찰한 공격자가 이를 변조해 수신자에게 보내서 내용을 탈취할 수 있다

현실적인 문제, PGP의 쇠퇴

대부분의 이메일이 여전히 전세계적으로 암호화되지 않은 상태로 전송되고 있다.
1. PGP의 복잡성
- PGP는 이해, 사용하기 어렵다
2. PGP 지원 낮음
- 대중적인 이메일 클라이언트는 PGP를 잘 지원하지 않거나 아예 지원하지 않는다.

이메일 암호화의 미래
이메일 암호화가 HTTPS처럼 성공적으로 채택될 가능성이 희박하다

이메일은 기본적으로 평문 전송을 염두하고 설계됨
주류 이메일 소프트웨어는 여전히 평문으로, 인터넷 이메일 시스템 자체가 암호화되지 않은 전송에 기반하고 있음

If not PGP, then what?

saltpack

PGP와 유사한 프로토콜, 메세지 형식
2021년 saltpack의 주요구현은 keybase, keys.pub(네이티브 데스크톱 애플리케이션)
WOT에서 벗어나 사용자가 자신의 공개 키를 다른 소셜 네트워크에서 브로드캐스트하여 자신의 신원을 공개 키에 주입할 수 있도록 한다

Secure messaging: A modern look at end-to-end encryption with signal

OTR(Off-The-Record) 프로토콜

PGP의 한계를 넘어섬
채팅 메세지를 암호화하기 위해 설계된 프로토콜
XMPP(Extensible Messaging and Presence Protocol) 채팅 프로토콜을 확장한 방식
deniability(부인 가능성)
- OTR의 메시지는 수신자와의 공유 키를 사용해 대칭 암호화되고 인증됨. 따라서 수신자 또는 외부 관찰자는 해당 메시지를 법정에서 증거로 사용할 수 없다. 왜냐하면 수신자가 해당 메시지를 직접 위조했을 가능성을 주장할 수 있기 때문
- 반대로, PGP는 메시지에 서명을 포함하기 때문에 부인할 수 없는(non-repudiable) 성질을 가지며, 이는 OTR과 대조적
- 하지만, 이러한 부인 가능성의 법적 효력이 실제로 법정에서 테스트된 적은 없음

Signal 프로토콜

기존 방식(PGP, S/MIME, OTR)과는 다른 현대적인 접근 방식
중앙 서비스 기반: 대부분 과거 보안 프로토콜은 네트워크 내에서 중앙 서버 없이 동작(federated protocols)했지만, Signal은 중앙 서버와 단일 공식 클라이언트를 사용
Signal 프로토콜의 확산: Signal 프로토콜은 오픈 표준으로 제공되며, 많은 메시징 앱(WhatsApp, Facebook Messenger, Skype 등)에 채택됨. 현재 전 세계 수십억 명이 Signal 프로토콜을 사용함

signal이 해결하고자 하는 문제

PGP의 신뢰 모델(WOT)을 대체할 수 있을까?
- TOFU(Trust On First Use) 방식을 사용해서 처음 통신 시 사용자 간 신뢰를 맹목적으로 수용하고, 이를 기반으로 장기적인 안전 통신 채널을 구축한다
- 이후 사용자가 session secret을 out-of-band 방식으로 검증한다. 초기 교환이 MITM 공격에 노출되지 않았는지 확인할 수 있다
PGP에 매 대화마다 forward secrecy(순방향 비밀)을 추가하려면?
- 대화 시작 시 Extended Triple Diffie-Hellman(X3DH) 확장된 키 교환 방식 사용. 매번 새로운 키로 암호화됨
단일 메세지에 대해 forward secrecy를 추가하려면?
- 대화는 오래 이어질 수 있으므로, 키가 유출되더라도 과거 메세지가 해독되지 말아야한다.
- 이를 위해 symmetric ratchet 도입
세션 비밀이 유출되면 어떻게 복구할까?
- 새로운 Post-Compromise Security(PCS) 보안 속성 도입
- Diffie-Hellman ratchet 사용하여 유출 후에도 대화를 안전하게 이어갈 수 있도록 함

1. More user-friendly than the WOT: Trust but verify

WOT(Web Of Trust)의 한계

PGP는 원래 WOT 모델을 통해 사용자 간 신뢰 구축하려 함
WOT는 직접 만나 서로의 공개 키를 인증하도록 설계되었으나 매우 번거로움
현재 WOT를 사용하는 사람은 거의 없다.

TOFU

대부분 현대 암호화 애플리케이션(ex: PGP, OTR, Signal 등)은 TOFU 모델을 사용한다

첫 번째 연결 시 공개 키를 맹목적으로 신뢰
이후 해당 공개 키와 다른 키가 나타나면 거부

장점:
- 공격자는 초기 연결만 공격할 수 있으며, 능동적인 MITM 공격이어야만 한다.
- 첫 연결이 안전할 가능성이 높을 때 효과적임
- 사용자가 추후 out-of-band를 통해 키를 검증할 수 있다.

TOFU 사례: SSH

TOFU를 사용하여 서버의 공개 키를 신뢰함

처음 연결 시 서버의 공개 키를 신뢰할지 여부를 묻는 메세지가 나타남
이후 연결 시 공개 키가 변경되면 경고 메세지가 표시되며 연결 차단

Signal의 TOFU 구현

사용자 지문(fingerprint)을 생성하여 TOFU 모델 구현.
지문 생성 과정
1. 사용자 식별 키(identity key)를 해싱하고, 그 결과를 숫자 문자열로 변환
1. 두 사용자의 숫자 문자열을 연결해 표시
QR 코드 사용: 긴 문자열을 쉽게 검증할 수 있도록 함

TOFU의 한계

첫 연결이 안전하지 않을 경우 MITM 공격에 취약
사용자가 지문을 검증하지 않으면, 공격자가 악용할 가능성있음
session secret을 해싱하여 검증 시 단일 문자열만 비교하도록 개선. 그러나 사용자가 이 작업을 무시한다면 위험

TOFU는 완벽하지는 않지만 현실적으로 가장 실용적인 보안 모델이 되었다.

2. X3DH: the Signal protocol's handshake

Signal의 프로토콜, X3DH(Extended Triple Diffie-Hellman) 는 비동기적(end-to-end) 암호화를 지원하는 현대적 접근 방식을 제공한다.
기존 메시징 앱은 대체로 동기적 방식으로 작동했기 때문에, 한쪽이 오프라인일 경우 대화를 시작하거나 지속하기 어려웠다.
반면, Signal은 이메일처럼 비동기적으로 작동하므로, 한쪽 사용자가 오프라인일 때도 안전한 통신을 시작할 수 있다.

X3DH의 핵심 개념
세 가지 Diffie-Hellman 키교환을 결합하여 강력한 보안을 제공한다.

Identity Key : 사용자를 대표하는 long-term key
One-time prekeys : 순방향 비밀성을 추가하기 위해 업로드된 단일 사용 공개 키(대화 시작 시 사용, 사용 후 서버에서 삭제됨)
Signed prekeys : medium-term key로, 사용자가 직접 서명해 업로드. one-time prekeys가 모두 소진되었을 때, 백업 역할 함. 주기적으로 signed prekey를 교체해야 함

Signal 대화 시작 흐름

Bob이 자신의 identity key, signed prekey, 서명, 여러 개의 one-time prekeys(=prekey bundle)를 중앙 서버에 업로드한다.
Alice가 Bob의 prekey bundle을 가져오고, 다음 작업을 수행한다.
i. signed prekey의 서명이 올바른지 검증
ii. X3DH handshake 수행 (Bob의 모든 공개 키와 Alice가 새로 생성한 ephmeral key, identity key를 사용
iii. key exchange 결과를 사용해 메세지를 암호화
Bob은 메세지를 받아 Alice의 공개 키와 자신의 개인 키를 사용해 동일한 X3DH 키 교환을 수행한다. (Alice가 사용한 Bob의 one-time prekey는 서버, Bob 측에서 삭제된다!)

X3DH에서 이루어지는 키 교환

다음 네 가지 Diffie-Hellman 키 교환으로 구성된다

Alice's Identity Key ↔ Bob's signed prekey
Alice's ephmeral key ↔ Bob's identity key
Alice's ephmeral key ↔ Bob's signed prekey
(option) Alice's ephmeral key ↔ Bob's One-time prekey

이 결과물은 KDF(Key Derivation Function)을 통해 단일 세션 키로 결합되고, 이후의 대화에서 사용된다.

1/2 교환은 상호 인증(mutual authentication)을 제공
3/4 교환은 순방향 비밀성을 제공

X3DH의 장점

비동기적 통신: 상대방이 오프라인 상태여도 대화를 시작할 수 있다
강력한 순방향 비밀성: 과거 키가 유출되더라도 이전 메세지가 노출 안됨
키 관리 효율적: signed prekey & one-time prekey를 결합해 키 관리/보안 최적화

3. Double Ratchet: Signal's post-handshake protocol

X3DH handshake 이후 단계는 두 사용자가 대화를 삭제하거나 키를 잃어버리지 않는 한 지속된다
signal은 메세지 단위에서 순방향 비밀성(forward secrecy)을 제공하기 위해 Double Ratchet이라는 프로토콜을 도입했다.

일반적으로 키가 서로 다른 목적으로 사용되면, 분리하는 것이 좋다.
이를 위해 X3DH의 결과물을 KDF(Key Derivation Function)의 입력값으로 사용해 두 개의 키를 생성한다.

Alice는 하나의 키를 사용해 Bob에게 보낼 메세지를 암호화
Bob은 다른 키를 사용해 Alice에게 보낼 메시지를 암호화

signal에서는 메시지 세션이 수년간 지속될 수 있기에, 세션 키가 한번 유출되면 과거에 기록된 모든 메시지가 복호화될 위험이 있다. 이 해결을 위해 signal은 symmetric ratchet 방식 도입

Symmetric Ratchet

Sending chain key, Receiving chain key
- 기존의 sending key는 sending chain key로 이름이 변경되고, 메시지 암호화를 위해 직접 사용되지 않는다.
- 메시지를 보낼 때마다 Alice는 sending chain key를 one-way function에 통과시킨다
  - 새로운 sending chain key를 생성
  - 실제 메시지를 암호화하는 sending key를 생성
- 메시지를 받을 때에도 동일한 방식으로 receiving chain key가 처리
Forward Secrecy 보장
- 한 번의 sending key나 sending chain key가 유출되더라도, 과거의 키는 복구할 수 없다
- receiving chain key도 동일한 원리로 보호된다

: 각 메시지를 보낼 때마다 sending chain key는 KDF(Key Derivation Function)를 통해 다음 키로 갱신됨(Forward Secrecy 보장)

Signal 프로토콜: PCS(Post-compromise security, backward secrecy)

PCS는 키가 어느 시점에서 손상되더라도 프로토콜이 스스로 복구할 수 있다는 개념
(공격자가 손상 이후에도 여전히 사용자의 기기에 접근할 수 있다면 무의미하긴 하다.)

entropy를 도입함으로서 PCS가 작동할 수 있다.
일시적인 손상(nonpersistent compromise)이 엔트로피에 접근할 수 없어야 한다.
새로운 엔트로피는 대화 참여자에게 동일해야 한다.
ephemeral key exchange를 수행하여 signal이 이러한 엔트로피를 찾는다.
송신되는 모든 메시지는 현재의 래칫 공개 키를 포함한다.

signal 프로토콜은 지속적인 엔트로피 갱신과 안전한 키 교환이 핵심이다.

Bob
ping-pong: Alice로부터 새로운 래칫 키를 수신했을 때 수행해야 하는 작업

메시지 복호화
i. Alice의 새 래칫 키와 자신의 래칫 키로 새로운 DH 키 교환 수행
ii. 키 교환의 출력값과 symmetric ratchet으로 수신된 메시지 복호화
새로운 무작위 래칫 키 생성
i. Alice의 새 래칫 키와 자신의 새 래칫 키로 또다른 키교환 수행하여 Alice에게 보낼 메시지 암호화

Double Ratchet: DH 래칫과 대칭 래칫의 결합
Alice의 관점
더블래칫은 DH래칫과 대칭 래칫 결합된 것. X3DH 프로토콜 이후, 손산 후 보안(PCS)과 전방 비밀성(Forward secrecy)을 제공.
첫 메시지에서는 아직 상대의 래칫 키를 모르기에 Bob의 presigned key를 대신 사

The state of end-to-end encryption

오늘날에는 이메일을 암호화하기 보다는 메시지 어플리케이션을 안전하게 만들어 통신한다.
이 속에 Signal 프로토콜이 많이 사용되고 있다. 어플리케이션뿐만 아니라 XMPP, Matrix 같은 오픈 소스나 연합 프로토콜에서도 채택되었다.
반면, PGP와 S/MIME는 사용되지 않는다.

그럼 자체 end-to-end encrypted messaging app을 만들고 싶다면?
불행하게도 이 분야에서 사용되는 많은 기술은 임시방편적으로 설계되있으며, 완전/안전 시스템을 만들기 위해서는 많은 세부사항을 직접 채워야 한다.
signal은 많은 코드를 오픈소스로 공개했지만, 문서화가 부족하고 정확히 사용하는 것이 어렵다.
만면, Matrix 같은 분산형 오픈소스 솔루션을 사용하는 것이 더 나을 수 있다.(프랑스 정부도 채택함)

활발히 진행되고 있는 몇 가지 연구들

group messaging
- 애플리케이션마다 다른 방식으로 구현됨.
- signal 애플리케이션 : [client-side fanout] 그룹 채팅 구조를 클라이언트가 처리. 서버는 무조건 두명간 통신만 확인할 수 있다. 따라서 클라이언트는 그룹 채팅 메시지를 그룹 참가자 모두에게 개별적으로 암호화하여 전송해야 함. 확장성이 크지 않음.
- WhatsApp : [server-side fanout] signal 프로토콜을 변형하여 사용함. 서버가 그룹 채팅의 멤버를 인지함. 참가자가 서버에 단일 암호화 메시지를 보낼 수 있고, 서버는 이를 그룹 멤버들에게 전달하는 역할을 함
- 문제: 대규모 그룹에 대한 확장성(scalability) : 최근, 안전한 대규모 그룹 메시징을 목표로 하는 Messaging Layer Security(MLS) 표준을 만들고 있다. 그러나, 100명 이상 참가자가 있는 그룹에서 기밀성이 정말로 보장되는가의 의문이 든다.
- cf. 그룹 채팅에서 각 접근 방식은 보안성과 사용성에서 다른 트레이드오프를 가지고 있다. transcript consistency(그룹 채팅의 모든 참가자가 동일한 메시지를 동일한 순서로 볼 수 있도록 보장하는 암호화 속성)를 제공하지 못할 수 있다.
multiple devices 지원
- 제대로 구현되지 않거나 다양한 방식으로 구현되고 있다. 대부분은, 사용자의 각 기기를 그룹 채팅의 별도 참가자로 간주하는 방식으로 처리한다.
- TOFU 모델이 여러 기기를 관리하기 어렵게 한다. 각 기기가 서로다른 ID 키를 가지기 때문에 키 관리가 복잡해진다.
  - 사용자는 자신의 모든 기기와 친구들의 모든 기기에 대해 fingerprint을 확인해야 할 수도 있다.
TOFU보다 더 나은 보안 보장
- TOFU 모델도 이상적이지 않음. 처음으로 공개 키를 확인할 때 신뢰를 기반으로 하며, 이후엔 fingerprint가 일치하는지 확인하지 않기 때문.
- google이 제안한 certificate transparency 프로토콜이 해결하려는 문제.

Summary

end-to-end encryption은 실제 인간들 간의 통신을 안전하게 보호한다.
end-to-end encryption은 사용자들 간의 신뢰를 초기화할 방법이 필요하다. 이는 out-of-band 채널에서 올 수 있다.
PGP와 S/MIME는 이메일 암호화에 주로 사용되는 프로토콜이지만 안전하지 않다.
- PGP는 Web of Trust(WOT) 모델을 사용, 사용자가 서로의 공개 키를 서명함으로써 신뢰를 형성한다
- S/MIME는 Public Key Infrastructure(PKI)를 사용해 참여자 간 신뢰를 구축한다.
PGP의 대안으로 saltpack이 있다. 소셜 네트워크를 통해 다른 사람의 공개 키를 찾는 방식이다.
이메일은 암호화를 염두해 두고 설계한 프로토콜이 아니기에 암호화 관련 문제를 항상 갖는다. 반면, 현대 메시징 프로토콜/애플리케이션은 처음부터 end-to-end 암호화를 염두했기에 더 낫다.
- signal 프로토콜은 사용자 간의 종단간 통신을 보호하기 위해 대부분의 메시징 애플리케이션에서 사용됨(Signal 메신저, WhatsApp, Facebook 메신저, Skype)
- Matrix와 같은 다른 프로토콜은 end-to-end 암호화 메시징을 위한 federated protocol(누구나 상호운용할 수 있는 개방형 프로토콜)을 표준화하려한다.