▲

시그널 프로토콜과 포스트-양자 래칫

 (signal.org)
1P by GN⁺ 11일전 | ★ favorite | 댓글 1개
  • Signal이 Sparse Post Quantum Ratchet(SPQR, 희소 포스트 양자 래칫) 을 도입하여 Signal 프로토콜의 보안을 크게 향상시키며, 미래의 양자 컴퓨팅 위협에 대한 복원력을 강화하면서도 기존의 Forward Secrecy(FS) 와 Post-Compromise Security(PCS) 보장 유지
  • Signal 프로토콜은 전 세계 수십억 명이 매일 주고받는 비공개 통신에 종단 간 암호화를 제공하는 암호학적 사양 세트이며, 2013년 발표 이후 Signal 앱뿐만 아니라 다른 주요 메시징 제품에서도 채택
  • 이전에 발표한 PQXDH는 채팅 세션 설정 시 양자 저항 암호화 비밀을 통합하여 harvest-now-decrypt-later 공격으로부터 보호했지만, SPQR은 대화가 계속됨에 따라 손상을 최소화하고 복구하는 FS와 PCS 보장을 양자 안전 방식으로 달성
  • SPQR은 Signal의 기존 Double Ratchet과 혼합되어 Triple Ratchet이라 불리는 조합을 형성하며, 사용자 경험은 변경되지 않고 모든 대화가 자동으로 새 프로토콜로 전환되며 현재와 미래의 통신을 모두 보호
  • 학계 연구(Eurocrypt 25, USENIX 25 논문), erasure code 기반 청킹, 형식 검증(ProVerif, hax/F*)을 통해 프로토콜 정확성과 보안 속성을 기계적으로 검증하며, CI 파이프라인에서 매 변경마다 재검증하여 개발 프로세스의 동적 부분으로 유지함

개요

  • Signal은 Sparse Post Quantum Ratchet(SPQR) 의 도입으로 Signal Protocol의 보안을 한 단계 올림
  • SPQR은 기존의 강력한 보안성을 기반으로, 미래의 양자 컴퓨팅 위협에 대응하며 전방위 비밀성(Forward Secrecy, FS) 과 사후 복구성(Post-Compromise Security, PCS) 보장 구조를 한층 강화함
  • 사용자는 변화를 느끼지 못할 정도로 시스템 전체에 자연스럽게 적용되며, 대화 내용이 양자컴퓨터가 실현되더라도 안전하게 보호받는 환경을 확보

기존 Signal Protocol의 현황

  • Signal Protocol은 일상적으로 사용되는 종단간 암호화 메시지 표준임
  • 기존 프로토콜 내 더블 래칫 구조는 해시 함수(양자 안전)로 전방위 비밀성을, 타원 곡선 디피-헬만(ECDH) 으로 사후 복구성을 구현해 옴
  • ECDH는 현재 보안성이 높지만, 장차 양자컴퓨터에 의해 취약해질 위험 있음
  • 래칫이란, 대화 중간마다 새로운 비밀키를 생성해 이전 또는 이후 메시지의 내용 노출을 막는 기술임
  • Alice와 Bob이 주기적으로 새로운 ECDH 비밀 정보를 합의하며 세션을 갱신함

양자 보안 요소의 혼합 필요성

  • 양자컴퓨터는 ECDH와 같은 기존 비대칭 암호화 방식을 무력화할 수 있음
  • 이를 대비해 PQXDH라는 최초 도입 방식에서 세션 시작 시 양자 안전 비밀 정보를 혼합함
  • 대화 중 지속적으로 양자 안전 알고리듬 기반의 Key Encapsulation Mechanism(KEM) 으로 키 교환 필요성이 부각됨
  • KEM은 Diffie-Hellman처럼 공유 비밀을 생성하나, 정렬된 비대칭 메시지 교환이 필요함
  • ML-KEM과 같은 표준화된 KEM을 활용해 세션 중 연속적, 양자 안전 비밀을 생성함

상태머신 및 대역폭 최적화

  • KEM 방식은 키 교환 데이터 크기가 크기 때문에(약 1000바이트) 통신 대역폭 최적화가 중요 이슈임
  • 상태머신(State Machine) 논리를 활용해 Alice와 Bob이 서로 어떤 데이터(Encapsulation Key, Ciphertext 등)를 언제 주고받을지 관리함
  • 데이터 청크화 및 소거코드(Erasure Codes) 활용으로 큰 데이터를 작은 조각으로 나눠, 메시지 손실이나 유실 시 복구 용이하게 유지함
  • 공격자가 선택적으로 키 교환 청크만을 드롭해 프로토콜 중단을 유발하는 것도 어렵도록 설계함
  • 이로써 메시지 손실, 재정렬, 지연 등 실제 모바일 환경의 효과적 처리가 가능해짐

효율-안전 트레이드오프와 최적화

  • 공유 비밀(Shared Secret) 생성 속도를 무조건 빠르게 하면 오히려 일정 시점의 모든 비밀 정보가 공격 시 노출될 위험 있음
  • Signal은 다수의 상태머신 시뮬레이션을 수행해 병렬-직렬 전송 사이에서 안전성과 효율의 균형점을 찾음
  • ML-KEM 세부 과정 분석 및 청크를 분할-동시 전송 등으로 대역폭 활용도를 극대화함
  • 이 과정을 ML-KEM Braid라고 명명하고, 자체 프로토콜의 한 모듈로 활용함

트리플 래칫(Tiple Ratchet) 구조

  • 더블 래칫(기존) 과 SPQR(신규, 양자 안전) 을 함께 동작시키고, 키를 결합하여 하이브리드 방식의 암호화 키를 생성
  • Triple Ratchet 방식은, 두 알고리듬 다 뚫려야만 메시지 노출 위험이 있으므로, 보안성이 획기적으로 상승함
  • 실제 구현은, 더블 래칫과 SPQR 각각에서 암호키를 받아 키 파생 함수로 한 번 더 결합하여 사용
  • 트리플 래칫 구조는 과거와 미래 메시지에 대해 양자 및 기존 보안 모두를 보장함

이질적(이분화된) 도입 및 호환성 처리

  • 업그레이드가 점진적으로 적용되기 때문에, SPQR 미적용 사용자와의 호환성 문제 발생 가능
  • 초기 메시지 협상 과정 중 일시적으로 다운그레이드를 허용해 두 사용자가 서로 호환 가능한 방식으로 통신하도록 설계함
  • 메시지 중 SPQR 데이터 부착 시, 인증코드로 보호되어 공격자에 의한 다운그레이드 강제 방어
  • 일단 양측이 호환 협상을 완료하면, 이후에는 세션 전체에서 SPQR 사용 결정이 고정됨
  • 모든 사용자가 SPQR 지원 버전으로 업그레이드되면, 구 세션은 보관/종료 및 신세션부터 완전 SPQR 적용 예정임

프로토콜의 안전성 검증 및 검증 도구

  • 프로토콜 설계 단계부터 학계 연구진, PQShield, AIST, NYU 등과 활발히 협력 진행
  • Eurocrypt 25, USENIX 25 등 학회 논문을 통해 프로토콜이 이론적으로 양자 안전성과 기존 보증 요건을 충족함을 증명
  • 제안된 6가지 포스트-양자 래칫 프로토콜 중 SPQR과 Katana(KEM 활용 신규 프로토콜)가 생존
  • 공식적 검증(Formal Verification) 은 Cryspen, ProVerif, hax, F* 등 도구와 CI 파이프라인에서 상시 자동화 관리
  • Rust 구현과 검증 모델의 동기화를 통해, 설계와 실제 코드 일치성을 보장
  • 구현 과정 중 불변조건(assertion)도 코드에 적극 도입, 오류 발생 시 앱이 중단되어 잠재적 취약점 미연 방지

검증과 지속적 개발의 병행

  • 공식적 검증 절차는 일회성 작업이 아니라, 코드베이스 변경이 있을 때마다 자동으로 반복 실행
  • 새 코드 병합 시 검증이 실패하면 빌드도 불가
  • 실제 경험상, 경계값 오류나 사전/사후 조건만 명확히 관리하면 유지보수 용이, 프로토콜 완성도도 극대화 가능

요약 결론

  • Signal은 신뢰성 높은 트리플 래칫(Double Ratchet + SPQR) 구조를 도입하여, 모든 메시지의 양자 내성 보안 제공을 추구함
  • 프로토콜 전환은 단계적으로, 서비스 중단이나 사용자 불편 없이 이뤄질 예정
  • 추가 데이터 전송량 최소화로 모바일 환경의 비용 부담 거의 없음
  • 프로토콜은 공격자가 조작 시 서비스 거부 상태를 유발해야 하므로, 중간자(MITM) 공격에도 강함
  • 코드와 설계는 체계적으로 공식 검증되며, 향후 계속해서 보안성을 유지
  • Signal 사용자 입장에서는 프로토콜 변화나 양자컴퓨터 위협이 눈에 띄지 않게 보호받는 환경을 보장할 전망임
▲
GN⁺ 11일전  [-]
Hacker News 의견

  • Signal은 정말 훌륭한 암호화 논문을 계속 발표함에도 불구하고, 제품 관점에서는 무엇이 성공할지 몰라 이것저것 시도하는 느낌임. 포스트양자 핸드셰이크, 스토리, 머니 트랜스퍼 등 새로운 시도를 시도하고 있지만, 여전히 SDK, API, 봇 지원이 부재함. 공식 라이브러리도 미완성에다가 문서도 없음. 기능이 여전히 많은 부분 클라이언트에 숨어있음. 프로토콜 명세를 공개해 놓긴 했지만, 그걸로 직접 라이브러리 만들라고 하는 건 실제 제품 운영 방법과 완전히 동떨어진 무책임한 태도임. 수백만 명이 사용하는 플랫폼에 이 정도 기본이 안 되어 있음. WhatsApp, iMessage 같은 앱들은 개발자에게 뭐라도 열어주는데 Signal은 개발자 관련은 철저히 배제하는 분위기임. 제품 담당자가 없는 게 아닐까 싶을 정도로 명확한 전략을 찾아볼 수 없음. 오랜 Signal 사용자이자 적극적으로 홍보도 해왔던 입장에서는, Signal이 뜨거운 암호화 기술을 덕지덕지 붙인, 애플 생태계보다도 개발자에 더 닫힌 메신저로 느껴짐. 그럼에도 제품 만든 분들에겐 감사함

    • 공감함. 특히 "스토리" 기능은 정말로 뭐가 될지 그냥 던져보는 느낌이 확 들었음. Signal이 아나키즘을 지향하는 비영리 단체 출신이라 목표 자체가 보통 회사와 다르다고 생각함. 앱이 본연의 임무엔 충실하니 괜찮지만, SDK가 있으면 정말 좋을 것 같음

    • API나 비즈니스 봇 같은 기능이 정말 중요한지 궁금함. WhatsApp, iMessage는 비즈니스용 API가 있지만, 일반 사용자로서는 실제로 그걸로 비즈니스와 상호작용한 적이 없음. 대신 가끔 봇이 귀찮게 하는 경험만 있었음. Signal에서 진짜 문제는 앱이 조용히 구버전이 되거나 업데이트가 멈추면 알림을 안 주고 메시지를 완전히 놓치는 상황임. 메신저의 핵심 미션인데 그게 안 됨

    • 오히려 API랑 봇이 없다는 게 나에겐 오히려 장점임

    • 나는 그런 기능 없이 지금처럼 안전하고 쓸 만한 메신저 만드는 데 집중해줬으면 좋겠음

    • 내가 Signal에서 정말 짜증나는 건, 발신자가 듣는 링 소리가 실제 수신자 폰에서 울리지 않아도 들린다는 점임. 예전부터 일부러 이렇게 하고 있다며 방어해 온 공식적인 정책임. 예전의 잠수함 사운드 없앤 이후로 계속 이러고 있음

  • Signal 프로토콜 이름이 SPQR라서 깜짝 놀랐음. SPQR는 라틴어로 "Senatus Populusque Romanus"의 약자임 위키피디아 참고. 너무 멋짐

    • 미래 지향적인 프로토콜 이름에 SPQR을 사용한 건 오지맨디아스(Ozymandias) 같은 느낌이 있음

    • 아주 영리한 작명임. BBC 미니시리즈 "Rome"에서 로마 군단병 문신으로 자주 나온다고 익히 알고 있음 Rome 위키피디아

    • Strength and Honor(강인함과 명예)

    • 이런 유머는 Hacker News에서만 볼 수 있다고 생각함. 예전에 "수학자가 자기 사물함 번호를 외우는 법"을 다룬 만화가 떠오름. ("1975? 그건 3,900,625의 제곱근이지!")

    • 혹시 그냥 "SPQR"이 "Speaker"처럼 들리니까 채팅앱과 어울려서 그렇게 지은 건 아닐까? 모든 걸 로마와 엮을 필요는 없음

  • Signal의 가장 큰 약점은 전화번호로 신원을 구분하는 방식임. 해커뿐 아니라 권위주의 정부 입장에서도 언제든 전화번호를 탈취할 수 있음. 미래의 위협을 고민하는 것도 중요하지만 우선순위가 바뀌어야 함

    • 아직 모르는 사람이 있을까 봐 공유함: Signal에서 사용자 이름으로 전화번호 비공개 기능 소개(2024년 2월)

    • 많은 보안 메신저들이 전화번호 없이도 돌아가고, 메타데이터까지 지워가며 서비스를 제공하고 있음. 전화번호와 SIM카드가 개인에게 묶이는 국가에서는 Signal의 방식이 진입장벽임

    • 전화번호 요구는 스팸 방지 측면이 있어서 쉬우면서도 신뢰도 있는 방법임

    • 전화번호로 신원을 확인한다는 것 자체가 치명적인 문제로 느껴지진 않음. 권위주의 정부가 번호를 탈취하더라도 메시지 기록까지 얻는 건 아님. 신호를 받은 사용자는 이미 경고를 받게 됨. Signal이 문제 없는 건 아니고, 비판과 기준 제시는 반드시 필요하지만, 여전히 일반인이 쓸 수 있는 유일한 완전 종단간 암호화와 메타데이터 보호 메신저임. 더 보안·프라이버시 강한 서비스도 있지만 내 할머니도 쓸 수 있다는 점이 진짜 중요함. Signal이 보안은 충분히 다졌으니 이제 프라이버시에 집중하면 좋겠음. 비판하면서도 여전히 강력히 추천하고 스스로 친구들에게 적극적으로 권장함. 기부도 여러 번 함 Signal의 투명성 보고 참고

    • Signal에는 "등록 잠금"이라는 기능이 있어서, 비밀번호 설정 시 SIM 탈취로 계정이 도용되는 것을 막을 수 있음

  • Signal이 이번에 SPQR(양자 저항형 라쳇)을 적용한 후, iMessage의 PQ3와 비교하면 어떤 위치인지 궁금함. Cyph와 Simplex의 과거 양자저항 메시징 시도에 대한 고찰도 들어보고 싶음. iMessage PQ3 소개 / Cyph - Post-Quantum Castle / Simplex - 양자저항 기능

    • Signal의 SPQR는 PQ3와 비슷하게 ML-KEM 기반 라쳇 구조지만, 키 전송 방식이 다름. ML-KEM 키 길이가 커서 PQ3는 키를 가끔만 주기적으로 보내고, Signal은 메시지와 함께 나눠보내는 식임. 숨겨진 대역폭, 보안상 chunking이 오히려 더 안전하고 효율적이라는 판단임. 에러 정정 코딩 때문에 전체 대역폭은 늘 수 있지만, 각 메시지 사이즈는 일정해짐. 애플은 네트워크 제어권이 더 세니까 적극적인 재키 교체 방어가 수월할 것임

    • iMessage가 실제로 현재 환경에서 의미 있나 싶음. 왜냐면 대부분의 iPhone 사용자는 iCloud 백업을 E2E 없이 쓰고, 완전 암호화 백업은 선택 옵션임. 즉 법 집행 요청이 오면 애플이 암호를 풀어줄 수 있으니, 양자컴퓨터까지 오지 않아도 이미 충분히 취약함

  • SPQR(Sparse Post-Quantum Ratchet)란 이름 보고 Signal팀에 로마역사 마니아가 있는 듯함

    • 다들 로마제국에 대해 얼마나 자주 생각함?

    • 어쩌면 채팅앱 최적의 단어 "Speaker"의 변주로 작명한 것일 수도 있음

  • Signal의 가장 큰 약점은 전화번호 기반 신원 인증임. 해커만이 아니라 권위주의 정부도 언제든 번호 소유권을 탈취할 위험이 있음. 미래의 위협도 좋지만 우선순위가 바뀌어야 함

    • 전화번호 없이도 잘 운영되는 보안 메신저들이 많음. 이런 서비스들은 메타데이터 보호도 뛰어남. 많은 나라에서 SIM카드 실명제라 Signal 방식은 현실적으로 진입장벽이 큼

  • Signal이 메시지 전송 기반 역할, 즉 '전송 버스'가 되길 바람. 예를 들어 특정 연락처(아내 등)에게 내 위치 정보를 안전하게 요청하고 줄 수 있다면 Google을 통하지 않아도 됨. 신원 인증을 이미 해결했으니, 이제 Signal 위에서 앱을 만드는 걸 독려해야 한다고 생각함. 2FA도 Signal로 하면 SMS보다 더 안전할 거라 생각함

    • Signal로 써드파티 앱이 거의 나오지 않는 이유가 AGPL 3 라이선스 때문이 아닐까 싶음

  • 현대 Signal 프로토콜과 Matrix, MLS 같은 것과의 비교도 꼭 보고 싶음. 빠르게 발전해서 따라가기 힘든데, 현 시점에서 관계도가 궁금함

    • 요약하자면, Signal Protocol은 Signal이 시시각각 발전시켜 온 암호 프로토콜 계열을 통칭함. 더블 라쳇 기반으로 시작해서 PQXDH(초기 키 교환에 Kyber512 적용), 이제 SPQR 라쳇(세션 갱신 암호까지 PQ적용)까지 장착함. Signal의 장점은 메타데이터 보호(그룹 구조 안 노출, sealed sender 등)이고, 완전히 중앙화된 운영, 원본 구현 외에는 제3자 구현 금지(AGPL+CLA).
      Matrix는 오픈스탠다드로, Olm+Megolm(더블라쳇+그룹키 라쳇) 조합을 쓰고, 메타데이터는 서버 오픈해 보여주는 구조임(그룹 구조 서버 노출, 속성 값 평문 저장 등 개선 작업 중: Element 블로그 - 방 메타데이터 암호화 계획). 분산 구조여서 누구나 서버를 만들 수 있음.
      마지막으로 MLS(RFC 9420)는 그룹 멤버십·키교환 프로토콜로, 더블라쳇 대체 가능하고 최근 PQ 적용 제안들도 있음. 퍼포먼스는 그룹 당 O(log N)으로 효율적임. 아직 성숙하지 않았고, 더블라쳇에 비해 복잡함. 확산은 더딘 편이지만, IETF 표준으로 Google은 RCS, Discord/웹엑스 VoIP 등에서 도입함. 메타데이터 은닉이나 암호학적 부정성(deniability)은 제공하지 않음

  • 이 글은 내가 본 암호화 관련 글 중 최고급으로 잘 쓰여 있음. 암호화 관련해서 일정 수준 이해력이 있다고 생각하지만, 비슷한 주제의 다른 글은 중간에 진짜 눈이 피곤해졌는데, 이번 글은 전혀 낯선 주제를 다뤄도 흐름을 완전히 따라갈 수 있었음

  • 양자암호 위협에 대해 잘 아는 분이 지금 Signal의 최신 프로토콜이 어떻게 더 안전해졌는지 쉽게 설명해 줄 수 있나? 읽어도 왜 더 안전해졌는지 정확히 모르겠음. 실제 체감 속도 저하가 있는지도 궁금함

    • 간단히 설명하자면, 아군의 적이 "지금은 해독할 수 없지만, 언젠가 양자컴퓨터가 가능해지면, 미래에 현재 모은 암호문을 모아놓고 한번에 푸는 것"이 표준적인 위협 시나리오임. "Harvest and decrypt"라는 모델임. Signal이 지금 비밀을 꼭 오래 보존해야 하거나 앞으로 안전하게 지켜야 한다면 오늘부터 PQ 키합의가 필요함. 그래서 PQXDH와 같은 새로운 프로토콜이 필요한 이유임.
      PQ 라쳇이 중요한 건, 만약 공격자가 장기적으로 암호문을 수집할 뿐 아니라 언젠가 디바이스 해킹·특정 구현 결함을 통한 키 유출이 생길 수 있다는 매우 현실적인 위협 때문임. Forward secrecy와 post-compromise security라는 2중 방어가 필요함. 순간마다 키를 계속 갱신하면 한번이라도 공격에 노출돼도 과거 메시지나 미래 메시지까지 위험해지진 않음. 이 방어가 양자암호 환경에서도 제대로 동작하려면 전체 라쳇 구조까지 PQ로 완성해야 함. 그렇지 않으면 공격자가 라쳇 구간만 노리게 되고, 모든 보안성이 깨짐

    • 기존 Signal의 양자내성 암호 구현은 PCS(침해 이후 보안)가 없었음. 이번엔 제공함. 드디어 PCS의 의미를 알게 되어 좋았음. 새로운 개념이라 기대했지만 OTR(오프더레코드) 프로토콜에서도 이미 사용하던 방식이라는 점이 조금 아쉬웠음. 이 키 교환은 자주 일어나는 게 아니라 실제 성능 저하는 거의 없음

    • 공식 블로그 요약:

      1. 사용자 입장에선 앱 사용 경험이 변하지 않음
      2. 이번 프로토콜 변경은 자동적이므로 별도 조치 필요 없음
      3. 이로 인해 미래 양자컴퓨터 위협까지 대비하고, 기존 보안 원칙(전방/침해후 보안)을 고수하게 됨

  • Sono pazzi, questi Romani(로마인들은 정말 이상함)

    • Die spinnen, die Römer!(로마인들은 괴짜임)
답변달기