# Soatok의 비공식 위협 모델 가이드 > Clean Markdown view of GeekNews topic #31003. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31003](https://news.hada.io/topic?id=31003) - GeekNews Markdown: [https://news.hada.io/topic/31003.md](https://news.hada.io/topic/31003.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-01T18:05:14+09:00 - Updated: 2026-07-01T18:05:14+09:00 - Original source: [soatok.blog](https://soatok.blog/2026/06/30/soatoks-informal-guide-to-threat-models/) - Points: 2 - Comments: 1 ## Topic Body - **위협 모델**은 보호 대상과 공격자를 적는 데서 끝나지 않고, 자산 간 관계·가정·일부러 제외한 위협까지 드러낼 때 설계 판단에 쓸 수 있음 - 좋은 모델은 자산을 목록이 아니라 **그래프**로 보고, 컴포넌트의 입력·출력·의존성을 좁혀 가며 위험과 전제를 확인함 - 가정이 깨지면 수용한 위험도 다시 봐야 하며, **Invisible Salamanders** 공격은 E2EE 남용 신고 기능과 AEAD의 “메시지당 유효 키 1개” 가정이 충돌할 때 문제가 됨 - publickey.directory 사례는 가정·자산·행위자·위험 상태를 나눠 보지만 완벽하지 않고, Matrix v1.18 위협 모델은 공격 유형 목록에 가까우며 암호화·키 관리가 빠져 있음 - 위협 모델링은 passkey 인증, 분산 E2EE 설계, PQC 논쟁처럼 기술 선택의 제약과 실제 위험을 분리해 더 나은 설계 결정을 돕음 --- ### 위협 모델이 답해야 할 질문 - 위협 모델은 정식 사이버보안 프로세스일 수 있지만, 새 제품이나 서비스의 **설계·아키텍처 단계**에서도 비공식적으로 수행할 수 있음 - 최소한 다음 질문에 답해야 함 - 무엇을 보호하는가 - 누가 또는 무엇이 보호 대상을 해치려 하는가 - 공격자는 어떤 방식으로 공격할 수 있는가 - 그 공격을 막기 위해 무엇을 할 것인가 - 이 네 가지로도 위협 모델이라고 부를 수는 있지만, 실무에서는 중요한 세부사항이 빠지기 쉬움 - 추가로 필요한 질문은 다음과 같음 - 보호 자산들이 어떻게 연결되어 있는가 - 어떤 **가정**을 하고 있는가 - 어떤 위협은 일부러 다루지 않는가 - 모든 미래 공격을 다룰 수는 없으므로, 제외한 위협을 명시해야 함 - 가정이 틀리면 모델은 불완전해지고, 이미 수용한 위험 목록도 다시 검토해야 함 - 위협 모델은 특정 시점의 스냅샷이 아니라 필요할 때 갱신되는 **살아 있는 문서**여야 함 ### 가정이 깨질 때 생기는 문제 - [Invisible Salamanders attack](https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/)은 일부 E2EE 메시징 설계에서 남용 신고 기능을 도입할 때 그 기능을 깨뜨릴 수 있음 - 이 공격은 AES-GCM, ChaCha20-Poly1305 같은 AEAD 스킴의 가정과 맞물림 - 해당 스킴에는 특정 메시지에 대해 유효한 키가 하나라는 가정이 들어 있음 - 메시지 하나에 여러 유효 키를 도입하거나 [confused deputies](https://scottarc.blog/2022/10/17/lucid-multi-key-deputies-require-commitment/)를 만들면 알고리듬의 보안 보장 밖으로 벗어남 - 가정을 명확히 적으면 스스로의 **unknown unknowns**를 식별하는 데 도움이 됨 - 완벽할 필요는 없지만, 무엇을 전제로 삼는지는 분명해야 함 ### 위협 모델링을 시작하는 절차 - 전문적으로 위협 모델링을 하려면 [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/)를 읽는 것이 권장됨 - 실무에서는 먼저 7개 항목을 빠르게 복사해 쓸 수 있는 형식으로 적는 것에서 시작함 - 이후 분석 대상 시스템의 컴포넌트를 종이나 디지털 도구에 그림 - 어떤 위젯이 다른 위젯과 직접 통신하거나 의존하거나 상호작용한다면 그 관계를 표시함 - 관계 표기 방식은 작업자에게 가장 유용한 방식이면 됨 - 전체 그래프를 박스로 감싼 뒤, 점점 박스를 좁혀 각 컴포넌트에 집중함 - 각 반복에서 컴포넌트의 **입력과 출력**을 기록함 - 가능한 한 7개 질문에 답함 - 추상화 수준이 허용하는 만큼 깊게 내려간 뒤, 더 깊게 파고들지 않은 계층에 대해 어떤 가정을 하는지 브레인스토밍함 - 데이터베이스가 로드 밸런서와 같은 방식으로 X25519의 보안에 의존하지는 않을 수 있음 - 데이터베이스에 RSS 피드가 들어가는 식의 부적절한 관계는 기록하고, 가능하면 끊는 것이 목표임 ### publickey.directory 사례 - Fediverse에 키 투명성을 제공하는 작업은 [publickey.directory](https://publickey.directory)에서 추적됨 - 이 작업은 [public-key-directory-specification](https://github.com/fedi-e2ee/public-key-directory-specification) 명세에서 시작했고, 명세에는 [위협 모델](https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#threat-model)이 포함됨 - 해당 위협 모델은 다음 섹션으로 구성됨 - 가정 - 자산 - 공격자와 보호하려는 사람을 포함한 행위자 및 역할 이름 - 위험과 위험 상태 - 위험 상태는 네 가지로 나뉨 - **Prevented by design**: 공격이 설계상 동작하지 않음 - **Mitigated**: 가정이 틀리지 않으면 공격이 성공하지 않아야 함 - **Addressable**: 완화 방법은 있지만 노력이나 주의가 필요하며 운영자가 알아야 함 - **Open**: 완화할 수 없거나 완화하지 않을 위험이며, 해당 공격은 성공함 - 이 위협 모델도 완벽하지는 않음 - 자산과 행위자의 관계를 사람이 읽기 쉬운 그래프로 완전히 연결하지 않았음 - 위험 섹션에 고려하지 못한 사각지대가 있을 수 있음 - 시스템 보안에 중요한 가정을 빠뜨렸을 수 있음 ### Matrix와 Signal의 대비 - Matrix v1.18의 [Security Threat Model](https://spec.matrix.org/v1.18/appendices/#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](https://github.com/swicg/activitypub-e2ee) - ATProto, 예를 들어 BlueSky에서 같은 목표를 가진 [Germ Network](https://www.germnetwork.com/) 같은 프로젝트 - 두 프로젝트 모두 어느 시점에 [MLS](https://www.rfc-editor.org/rfc/rfc9420.html)를 E2EE 대화 키 관리 프로토콜로 사용하는 방안을 고려함 - 비중앙화 시스템에서 MLS에는 두 가지 중요한 제약이 있음 - MLS는 Authentication Service라는 추상 개념을 명세함 - MLS의 epoch를 뒷받침하는 ratcheting tree의 보안에는 **메시지 순서**가 중요함 - ActivityPub은 첫 번째 제약에 대해 키 투명성을 채택한다면, 여러 서버에 걸쳐 여러 KeyUpdate 메시지가 경쟁할 때의 처리 방식을 명시해야 함 - ATProto와 BlueSky의 상황은 더 까다로움 - [ATProto에는 Fediverse 같은 인스턴스가 없음](https://overreacted.io/there-are-no-instances-in-atproto/) - 보안 분석에서는 거의 P2P처럼 다뤄야 함 - 분산 시스템에서 메시지 순서를 보장하는 복잡한 프로토콜, 예를 들어 [Raft consensus algorithm](https://raft.github.io/) 같은 접근이 필요할 수 있음 - 또는 MLS를 건너뛰고 pairwise E2EE를 택해 그룹 추상화를 포기해야 함 - 사용자 간 메시지 기밀성이 보안 목표이고 호스팅을 분산하려 한다면, ATProto의 블록체인식 설계는 오늘날 표준화된 효율적인 그룹 키 합의 프로토콜 사용에 장애물이 됨 - 위협 모델링은 이런 설계 제약을 초기 도면 단계에서 드러낼 수 있음 ### PQC 논쟁에서 드러나는 위협 모델링의 역할 - [hybrid post-quantum constructions](https://soatok.blog/2026/04/13/hybrid-constructions-the-post-quantum-safety-blanket/)와 관련해, IETF TLS 워킹그룹 메일링 리스트에서는 non-hybrid ML-KEM 코드 포인트를 세우는 RFC 논의가 진행 중임 - 논의의 전제는 다음과 같음 - ML-KEM은 NSA 설계가 아님 - 주 제출자는 Peter Schwabe이며, Daniel J. Bernstein과 NaCl 암호 라이브러리에서 협업했고 독일에 거주함 - 다른 제출자들도 유럽 여러 지역에 있음 - [Sophie Schmieg](https://keymaterial.net/2025/11/27/ml-kem-mythbusting/)의 글처럼 정보 이론은 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는 현재 사용하는 방식이지만 양자 공격에 취약함 - 위협 모델링은 이런 논쟁에서 이념적 반대와 기술적 위험을 분리해 판단하는 데 쓰일 수 있음 ### 마무리 - 인터넷에는 위협 모델과 관련 방법론을 정식으로 다루는 가이드가 많음 - 여기서의 목표는 위협 모델 문서의 품질과 효과를 빠르게 걸러낼 수 있는 **스모크 테스트**를 갖추는 것임 - 좋은 위협 모델은 보호 대상, 공격자, 공격 방식, 방어책을 넘어서 자산 관계, 가정, 수용한 위험까지 드러내야 함 ## Comments ### Comment 60960 - Author: neo - Created: 2026-07-01T18:05:15+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/gwrlsv/soatok_s_informal_guide_threat_models) - 이번엔 드물게 **거만하고 불쾌한 태도** 없이 블로그 글을 쓴 줄 알고 칭찬하려 했는데, 결국 그 블로그에서 흔한 **Matrix 비판 글** 구간에 도달했음 “불친절함”은 댓글 신고 사유로 유효한데, 기술 인터넷을 더 낫게 만들려면 이 저자가 블로그에서 너무 자주 쓰는 공격적인 톤을 더 이상 소비하지 말고 추천도 멈춰야 하지 않을까 싶음. 아예 해당 도메인을 금지하는 것도 고려할 만함 - 비판 대상 문구를 전부 인용하고, 실질적인 반박 근거를 제시한 **상당히 합리적인 비판**이었음. 대부분의 비판보다 훨씬 나은 예시라고 봄 - 이건 **멸시 문화**임: https://blog.aurynn.com/2015/12/16-contempt-culture - 누군가를 “거만하고 불쾌한 멍청이”라고 부르면서, 동시에 불친절하다는 이유로 그 사람을 금지하자고 하는 게 어떻게 양립하는지 모르겠음. 보고 싶은 변화를 스스로 보여줘야 함 - 톤은 괜찮다고 봄 그리고 “모든 것은 그래프”라는 프로토콜은 실제로 **연구 프로젝트**처럼 취급해야 한다고 생각함. 결론은 “이런, 그래프 알고리즘은 실제로 추론하기 정말 어렵다”였던 셈임