Soatok의 비공식 위협 모델 가이드

1 hour ago 2

위협 모델은 보호 대상과 공격자를 적는 데서 끝나지 않고, 자산 간 관계·가정·일부러 제외한 위협까지 드러낼 때 설계 판단에 쓸 수 있음
좋은 모델은 자산을 목록이 아니라 그래프로 보고, 컴포넌트의 입력·출력·의존성을 좁혀 가며 위험과 전제를 확인함
가정이 깨지면 수용한 위험도 다시 봐야 하며, Invisible Salamanders 공격은 E2EE 남용 신고 기능과 AEAD의 “메시지당 유효 키 1개” 가정이 충돌할 때 문제가 됨
publickey.directory 사례는 가정·자산·행위자·위험 상태를 나눠 보지만 완벽하지 않고, Matrix v1.18 위협 모델은 공격 유형 목록에 가까우며 암호화·키 관리가 빠져 있음
위협 모델링은 passkey 인증, 분산 E2EE 설계, PQC 논쟁처럼 기술 선택의 제약과 실제 위험을 분리해 더 나은 설계 결정을 돕음

위협 모델이 답해야 할 질문

위협 모델은 정식 사이버보안 프로세스일 수 있지만, 새 제품이나 서비스의 설계·아키텍처 단계에서도 비공식적으로 수행할 수 있음
최소한 다음 질문에 답해야 함
- 무엇을 보호하는가
- 누가 또는 무엇이 보호 대상을 해치려 하는가
- 공격자는 어떤 방식으로 공격할 수 있는가
- 그 공격을 막기 위해 무엇을 할 것인가
이 네 가지로도 위협 모델이라고 부를 수는 있지만, 실무에서는 중요한 세부사항이 빠지기 쉬움
추가로 필요한 질문은 다음과 같음
- 보호 자산들이 어떻게 연결되어 있는가
- 어떤 가정을 하고 있는가
- 어떤 위협은 일부러 다루지 않는가
모든 미래 공격을 다룰 수는 없으므로, 제외한 위협을 명시해야 함
가정이 틀리면 모델은 불완전해지고, 이미 수용한 위험 목록도 다시 검토해야 함
위협 모델은 특정 시점의 스냅샷이 아니라 필요할 때 갱신되는 살아 있는 문서여야 함

가정이 깨질 때 생기는 문제

Invisible Salamanders attack은 일부 E2EE 메시징 설계에서 남용 신고 기능을 도입할 때 그 기능을 깨뜨릴 수 있음
이 공격은 AES-GCM, ChaCha20-Poly1305 같은 AEAD 스킴의 가정과 맞물림
- 해당 스킴에는 특정 메시지에 대해 유효한 키가 하나라는 가정이 들어 있음
- 메시지 하나에 여러 유효 키를 도입하거나 confused deputies를 만들면 알고리듬의 보안 보장 밖으로 벗어남
가정을 명확히 적으면 스스로의 unknown unknowns를 식별하는 데 도움이 됨
완벽할 필요는 없지만, 무엇을 전제로 삼는지는 분명해야 함

위협 모델링을 시작하는 절차

전문적으로 위협 모델링을 하려면 Threat Modeling Manifesto를 읽는 것이 권장됨
실무에서는 먼저 7개 항목을 빠르게 복사해 쓸 수 있는 형식으로 적는 것에서 시작함
이후 분석 대상 시스템의 컴포넌트를 종이나 디지털 도구에 그림
- 어떤 위젯이 다른 위젯과 직접 통신하거나 의존하거나 상호작용한다면 그 관계를 표시함
- 관계 표기 방식은 작업자에게 가장 유용한 방식이면 됨
전체 그래프를 박스로 감싼 뒤, 점점 박스를 좁혀 각 컴포넌트에 집중함
- 각 반복에서 컴포넌트의 입력과 출력을 기록함
- 가능한 한 7개 질문에 답함
추상화 수준이 허용하는 만큼 깊게 내려간 뒤, 더 깊게 파고들지 않은 계층에 대해 어떤 가정을 하는지 브레인스토밍함
데이터베이스가 로드 밸런서와 같은 방식으로 X25519의 보안에 의존하지는 않을 수 있음
데이터베이스에 RSS 피드가 들어가는 식의 부적절한 관계는 기록하고, 가능하면 끊는 것이 목표임

publickey.directory 사례

Fediverse에 키 투명성을 제공하는 작업은 publickey.directory에서 추적됨
이 작업은 public-key-directory-specification 명세에서 시작했고, 명세에는 위협 모델이 포함됨
해당 위협 모델은 다음 섹션으로 구성됨
- 가정
- 자산
- 공격자와 보호하려는 사람을 포함한 행위자 및 역할 이름
- 위험과 위험 상태
위험 상태는 네 가지로 나뉨
- Prevented by design: 공격이 설계상 동작하지 않음
- Mitigated: 가정이 틀리지 않으면 공격이 성공하지 않아야 함
- Addressable: 완화 방법은 있지만 노력이나 주의가 필요하며 운영자가 알아야 함
- Open: 완화할 수 없거나 완화하지 않을 위험이며, 해당 공격은 성공함
이 위협 모델도 완벽하지는 않음
- 자산과 행위자의 관계를 사람이 읽기 쉬운 그래프로 완전히 연결하지 않았음
- 위험 섹션에 고려하지 못한 사각지대가 있을 수 있음
- 시스템 보안에 중요한 가정을 빠뜨렸을 수 있음

Matrix와 Signal의 대비

Matrix v1.18의 Security Threat Model은 서비스 거부, 스푸핑, 스팸, 스파잉 같은 공격 유형을 나열함
해당 문서에는 다음 문제가 있음
- 공격 유형 목록에 가까움
- 가정 목록이 없음
- 자산 목록과 자산 간 관계가 없음
- 공격 목록이 불완전함
- Matrix가 E2EE 메신저로 홍보되지만, 위협 모델은 암호화나 키 관리를 다루지 않음
Matrix 위협 모델은 v1.1 이후 크게 바뀌지 않았으며, 그 사이 취약점 공개와 Lotte의 두 가지 추가 암호학 공격이 있었음
그래도 Matrix에는 위협 모델이 있음
Signal은 기술 명세를 제공하지만, 위협 모델은 사용자가 스스로 파악해야 하는 형태임
나쁜 위협 모델이라도 위협 모델이 전혀 없는 것보다는 나음

위협 모델이 설계를 개선하는 방식

보안 실무에서는 방어자가 항상 맞아야 하고 공격자는 한 번만 성공하면 된다는 격언이 자주 등장함
방어자가 충분히 준비되어 있으면 공격자가 움직일 지형을 정할 수 있음
실제 defense-in-depth는 위협 모델을 충분히 이해해 공격자를 예측 가능한 막다른 길로 몰아넣는 것을 포함함
Credential stuffing 방지
- Credential stuffing은 현실에서 지나치게 효과적인 단순 공격임
- 원인은 사람들이 비밀번호를 재사용하기 때문임
- 사용자는 여러 개의 고유하고 안전한 비밀번호를 기억하기 어렵기 때문에, 비밀번호 관리자가 한동안 적절한 완화책이었음
- 현재는 passkey가 더 나은 선택으로 다뤄짐
- passkey는 인증에 비대칭 암호를 쓰게 하는 더 사용자 친화적인 방식임
- 최선의 경우 SoloKeys나 YubiKeys 같은 하드웨어 보안 토큰을 사용함
- 평균적인 경우 운영체제나 비밀번호 관리자가 이를 제공함
- credential stuffing과 유사한 단순 공격을 피하려면 다음 설계가 필요함
  - 애플리케이션이 passkey를 요구하도록 설계함
  - 사용자가 여러 passkey를 등록하게 하거나, 최소한 백업용 하나를 요구함
  - 모든 자격 증명을 잃은 사용자를 위해 관리자가 새 passkey를 추가할 수 있는 break glass 경로를 제공함
  - 해당 관리 작업은 관리자가 검열할 수 없는 방식으로 로그에 남김
  - 가능하면 인증용 비밀번호를 전혀 지원하지 않음
  - 암호화 키 도출용 비밀번호는 별도 맥락에서 괜찮음
- passkey는 등록 시 자격 증명이 도메인 이름에 암호학적으로 바인딩되므로 피싱이 불가능함
- passkey 온보딩 비용이 있더라도 credential stuffing과 피싱으로 인한 지원 부담을 더 크게 줄일 수 있음
- 사람이 고엔트로피 비밀값을 기억하고 재사용하지 않아야 한다는 비현실적 기대를 제거하면, 여러 공격 클래스를 없애고 사용성도 개선할 수 있음
- “사용성을 희생한 보안은 보안을 희생한다”는 Avi Douglen의 문장이 인용됨

분산 E2EE와 위협 모델

직접 메시지용 E2EE에 대해 두 가지 제안이 논의되고 있음
- Fediverse 소프트웨어, 예를 들어 Mastodon의 비공개 DM을 목표로 하는 ActivityPub E2EE specification
- ATProto, 예를 들어 BlueSky에서 같은 목표를 가진 Germ Network 같은 프로젝트
두 프로젝트 모두 어느 시점에 MLS를 E2EE 대화 키 관리 프로토콜로 사용하는 방안을 고려함
비중앙화 시스템에서 MLS에는 두 가지 중요한 제약이 있음
- MLS는 Authentication Service라는 추상 개념을 명세함
- MLS의 epoch를 뒷받침하는 ratcheting tree의 보안에는 메시지 순서가 중요함
ActivityPub은 첫 번째 제약에 대해 키 투명성을 채택한다면, 여러 서버에 걸쳐 여러 KeyUpdate 메시지가 경쟁할 때의 처리 방식을 명시해야 함
ATProto와 BlueSky의 상황은 더 까다로움
- ATProto에는 Fediverse 같은 인스턴스가 없음
- 보안 분석에서는 거의 P2P처럼 다뤄야 함
- 분산 시스템에서 메시지 순서를 보장하는 복잡한 프로토콜, 예를 들어 Raft consensus algorithm 같은 접근이 필요할 수 있음
- 또는 MLS를 건너뛰고 pairwise E2EE를 택해 그룹 추상화를 포기해야 함
사용자 간 메시지 기밀성이 보안 목표이고 호스팅을 분산하려 한다면, ATProto의 블록체인식 설계는 오늘날 표준화된 효율적인 그룹 키 합의 프로토콜 사용에 장애물이 됨
위협 모델링은 이런 설계 제약을 초기 도면 단계에서 드러낼 수 있음

PQC 논쟁에서 드러나는 위협 모델링의 역할

hybrid post-quantum constructions와 관련해, IETF TLS 워킹그룹 메일링 리스트에서는 non-hybrid ML-KEM 코드 포인트를 세우는 RFC 논의가 진행 중임
논의의 전제는 다음과 같음
- ML-KEM은 NSA 설계가 아님
- 주 제출자는 Peter Schwabe이며, Daniel J. Bernstein과 NaCl 암호 라이브러리에서 협업했고 독일에 거주함
- 다른 제출자들도 유럽 여러 지역에 있음
- Sophie Schmieg의 글처럼 정보 이론은 ML-KEM 백도어를 배제함
- ML-KEM은 NIST의 공개적이고 10년간 진행된 국제 표준화 노력으로 선택됨
- NIST, FIPS, NSA는 기밀 시스템에서 non-hybrid ML-KEM과 ML-DSA를 요구함
해당 IETF 초안은 non-hybrid ML-KEM을 지정하며 Recommend=N으로 표시됨
hybrid KEM RFC는 Recommend=Y로 표시될 예정이며, hybrid KEM이 non-hybrid KEM보다 선호됨
항상 hybrid KEM을 쓰도록 설정한 시스템은 ML-KEM RFC가 생겨도 보안 저하가 없음
Google Chrome은 이미 non-hybrid ML-KEM을 지원하고 있으며, IETF RFC가 나오지 않아도 이 사실은 바뀌지 않음
이 RFC의 실질적 효과는 CNSA 2.0, FIPS 140-3 또는 유사한 규칙을 따라야 하고, Internet Draft가 아니라 안정적인 IETF RFC 번호가 필요한 조직의 절차적 제약을 풀어주는 것임
이 문제는 특히 정부 고객에게 판매하는 일부 사업 분야에서 흔할 수 있음
Hybrid PQ+ECDH와 Pure PQ의 차이
- KEM에서 직면한 위험은 “Q-Day 이후 암호를 깨기”가 아니라 Harvest Now, Decrypt Later임
- Q-Day는 공격자가 암호 관련 양자 컴퓨터를 갖게 되는 시점을 가리키는 약어로 쓰임
- 위험을 나누면 다음과 같음
  - 순수 ECDH, 즉 PQ 없음은 Q-Day에 소급적으로 깨짐
  - 순수 PQ는 PQ 알고리듬이 먼저 깨지지 않는다는 가정하에 Q-Day에 깨지지 않음
  - Hybrid PQ+ECDH는 Q-Day 전 알고리듬 붕괴에 대한 헤지지만, Q-Day 이후에는 Pure PQ 대비 쓸모가 없음
- ECDH + ML-KEM을 주장하는 것은 장기적으로 ML-KEM이 안전한 알고리듬이라는 점을 인정하는 셈임
- hybrid를 선호할 이유는 두 가지로 정리됨
  - 완전히 낯선 알고리듬보다 받아들이기 쉬워 PQ 도입을 더 빠르게 함
  - ML-KEM 또는 격자 기반 암호 전체의 알고리듬 붕괴에 대비할 수 있음
- 암호 관련 양자 컴퓨터에도 견디는 방식으로 헤지하려면 PQ+PQ hybrid가 필요함
- 알고리듬 다양성을 중시한다면 ML-KEM + HQC + ECDH의 3-way hybrid가 더 정직한 주장에 가까움
- ML-KEM은 격자 기반 KEM이며 양자 공격에 견딜 것으로 여겨짐
- HQC는 코드 기반 KEM이며 양자 공격에 견딜 것으로 여겨짐
- ECDH는 현재 사용하는 방식이지만 양자 공격에 취약함
- 위협 모델링은 이런 논쟁에서 이념적 반대와 기술적 위험을 분리해 판단하는 데 쓰일 수 있음