v0.5

기존 13개 산출물 v0.5 영향도 분석 및 수정 범위 정의¶

1. 분석 개요¶

1.1. 목적¶

v0.5 마일스톤(Phase 24~27)에서 확정된 2단계 서명 아키텍처, 개인 서명 기기, RBAC v2, MuSig2 QR 최적화 설계가 기존 산출물(v0.0~v0.2)에 미치는 영향을 체계적으로 분석하여 후속 마일스톤에서 효율적으로 업데이트할 수 있는 기반을 마련한다.

1.2. 분석 방법론¶

v0.3 Phase 18, v0.4 Phase 23과 동일한 4단계 방법론을 적용한다:

현재 내용 요약: 산출물의 핵심 섹션/구조 파악
v0.5 변경 사항 매핑: Phase 24~27 중 어떤 설계가 영향을 미치는지 식별
영향도 판정: H(핵심 결론/구조 변경 필요) / M(보강 필요, 결론 유효) / L(참조 추가, 내용 유효)
변경 명세 도출: 섹션별 변경 위치, 변경 내용, 변경 유형(추가/수정/삭제), 우선순위

1.3. v0.5 핵심 변경 원인 (Phase 24~27)¶

Phase	핵심 설계	주요 영향 영역
Phase 24	옵션 A(오프체인 승인+온체인 마스터 서명 완전 분리) 채택	서명 플로우, 키 구조, Zone 아키텍처 전면 변경
Phase 24	5단계 TX 파이프라인 (Request-Approve-Collect-Sign-Broadcast)	4단계->5단계 확장, Collect 단계 신설
Phase 24	Zone 3+(Personal SE Sub-Zone) 확장, TB-6/TB-7	3-Zone->4-Zone, Trust Boundary 추가
Phase 24	ApprovalBundle CBOR 스키마 (UR 45052)	통신 프로토콜 UR 타입 추가
Phase 25	D'CENT X 1순위, 기기 적합성 평가, 키 라이프사이클	기기 사양, 펌웨어 요구사항 확장
Phase 25	Approval Signing Applet APDU 7개 명령 (INS 0x50~0x71)	SE 인터페이스 대폭 확장
Phase 26	RBAC v2 6역할 체계 (Approver+Operator 분리)	역할 모델 근본적 변경
Phase 26	S-01~S-12 v2 재배치 + S-06a/S-06b/S-07a/S-07b/S-08a/S-08b 세분화	운영 시나리오 전면 개정
Phase 27	Pre-commitment Pipelining, NFC 우선 전략	QR 교환 최적화, 통신 프로토콜 확장
Phase 27	ThresholdSigningProtocol 추상화, FROST-ready 계층	펌웨어 아키텍처 확장

2. 산출물 1: `airgap-signing-flow.md` (Phase 03)¶

2.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	에어갭 원칙, 3개 컴포넌트 역할, Request-Approve-Sign-Broadcast 4단계 파이프라인
2. TX 라이프사이클	4단계 파이프라인 상세, 상태 머신(7개 상태), 에러 핸들링
3. 서명 요청 포맷	PSBT(BTC), EIP-712(EVM) 서명 요청 구조
4. 서명 프로토콜 분기	MuSig2(BTC), Safe(EVM), MPC-TSS 3가지 분기
5. 에러 핸들링	타임아웃, 서명 실패, 통신 오류 복구
6. 감사 로그	TX별 감사 추적 필드

2.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	3개 컴포넌트 -> 4개 컴포넌트(+개인 기기), 4단계 -> 5단계 파이프라인	H	Phase 24 옵션 A
2. TX 라이프사이클	수정	4단계 -> 5단계(Collect 추가), Stage 1/2 분리 명시, 상태 머신 확장	H	Phase 24, Phase 28 core-flow-redesign
2. TX 라이프사이클	추가	Approve 단계: 개인 기기 SE ECDSA 승인 서명 절차 상세	H	Phase 24-01
3. 서명 요청 포맷	추가	ApprovalRequest(UR 45050), ApprovalBundle(UR 45052) CBOR 스키마 참조	H	Phase 24-02
4. 서명 프로토콜 분기	수정	MuSig2 BTC: 단일 콜드월렛 단일 서명으로 단순화(옵션 A), 복수 콜드월렛 시에만 MuSig2	H	Phase 24-02
4. 서명 프로토콜 분기	수정	EVM Safe: Approver M명 서명 -> Operator 단일 execTransaction	H	Phase 24-03
5. 에러 핸들링	추가	개인 기기 승인 실패/타임아웃, ApprovalBundle 검증 실패 에러 핸들링	M	Phase 25 firmware-requirements
6. 감사 로그	수정	Approver/Operator 역할 분리 기록, 개인 기기 ID 추적	M	Phase 26 RBAC v2

2.3. 영향도 판정: 높음 (H)¶

4단계 -> 5단계 파이프라인 변경, Stage 1/2 분리, 4번째 컴포넌트(개인 기기) 추가로 문서의 핵심 구조가 변경되어야 한다. v0.5의 가장 근본적인 변경이 이 문서에 집중된다.

2.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
1-1	1. Executive Summary	4단계 -> 5단계 파이프라인, 4번째 컴포넌트(개인 기기 Zone 3+) 추가	수정	P1
1-2	2. TX 라이프사이클	5단계 파이프라인 상태 머신 재설계, Collect 단계 추가, Stage 1/2 분리	수정	P1
1-3	2. TX 라이프사이클	Approve 단계: 개인 기기 ECDSA 승인 서명 절차 상세 (NFC APDU INS 0x50/0x51)	추가	P1
1-4	3. 서명 요청 포맷	ApprovalRequest/ApprovalBundle CBOR 스키마 참조 섹션 추가	추가	P1
1-5	4. 서명 프로토콜 분기	BTC: 단일 콜드월렛 단일 Schnorr 서명으로 간소화, MuSig2는 복수 콜드월렛 폴백으로 재배치	수정	P1
1-6	4. 서명 프로토콜 분기	EVM: Operator 단일 execTransaction으로 단순화	수정	P1
1-7	5. 에러 핸들링	개인 기기 승인 실패/타임아웃 에러 추가	추가	P2
1-8	6. 감사 로그	Approver/Operator 분리 기록 필드 추가	수정	P2

총 변경 항목: 8건 (P1: 6건, P2: 2건)

3. 산출물 2: `key-ceremony.md` (Phase 03)¶

3.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	키 세레모니 5가지 유형, 참석자, 소요 시간
2. 키 세레모니 개요	목적, 공통 참석자 역할
3. 초기 설정 8단계	사전 준비, 환경 검증, 키 생성, 백업, 검증 등
4. 서명자 추가/교체	서명자 변경 절차
5. 키 로테이션	연간 키 교체 절차
6. 긴급 복구	비상 시 복구 세레모니

3.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	세레모니 유형에 "개인 기기 키 세레모니" 추가, 참석 인원 변경 (8명+ -> 4~6명 + 원격)	H	Phase 28 core-flow-redesign
2. 키 세레모니 개요	수정	참석자 역할: Approver -> Operator로 콜드월렛 키 생성자 변경, Approver는 원격 참여	H	Phase 26 RBAC v2
3. 초기 설정	수정	8단계 -> 11단계 확장, Phase C(개인 기기 키 세레모니) 추가, Day-1 통합 절차	H	Phase 25 key-lifecycle, Phase 28 core-flow-redesign
3. 초기 설정	추가	개인 기기 배포(D'CENT X 1순위/바이오메트릭 2순위/카드 제한적), 기기 유형별 정책	H	Phase 25 device-evaluation
3. 초기 설정	추가	approval_sk 생성(SE TRNG), approval_pk 대시보드/콜드월렛 레지스트리 등록	H	Phase 25 key-lifecycle, firmware-requirements
4. 서명자 추가/교체	수정	Approver 교체(S-08a, 원격, 온체인 무영향)와 Operator 교체(S-08b, 콜드룸) 분리	H	Phase 26, Phase 28
5. 키 로테이션	수정	approval_sk 교체 주기 12개월, 전이 기간 72시간, ACTIVE->ROTATING->REVOKED	M	Phase 25 key-lifecycle
6. 긴급 복구	수정	approval_sk 유출 시 기기 교체로 대응(긴급 키 세레모니 불필요), master_sk 유출 시 기존 절차 유지	H	Phase 28 core-flow-redesign

3.3. 영향도 판정: 높음 (H)¶

키 세레모니의 핵심 절차(8단계 -> 11단계), 참석자 구성, 대상 키가 모두 변경되어 문서 전면 개정이 필요하다.

3.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
2-1	1. Executive Summary	세레모니 유형 표에 "개인 기기 키 세레모니" 추가, 참석 인원 변경	수정	P1
2-2	2. 참석자 역할	Operator 역할 추가, Approver 원격 참여 가능 명시	수정	P1
2-3	3. 초기 설정	11단계로 확장: Phase C(개인 기기 키 세레모니 3단계) 추가	수정	P1
2-4	3. 초기 설정	개인 기기 배포 절차(기기 유형별 정책, SE attestation 검증) 추가	추가	P1
2-5	3. 초기 설정	R3covery 카드 Day-1 통합 발급 절차 반영	수정	P2
2-6	4. 서명자 교체	Approver 교체(S-08a)/Operator 교체(S-08b) 분리	수정	P1
2-7	5. 키 로테이션	approval_sk 12개월 교체, 72시간 전이기간, 상태 전이 반영	수정	P1
2-8	6. 긴급 복구	approval_sk 유출 대응(기기 교체), master_sk 유출 대응 분리	수정	P1

총 변경 항목: 8건 (P1: 7건, P2: 1건)

4. 산출물 3: `multisig-workflow.md` (Phase 03)¶

4.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	BTC MuSig2, EVM Safe, MPC-TSS 체인별 다중 서명 방식
2. 방식 결정 프레임워크	체인별 매핑, 의사결정 매트릭스
3. BTC MuSig2 상세	N-of-N 구조, 2라운드 프로토콜, 서명 수집 흐름
4. EVM Safe 상세	M-of-N 구조, execTransaction, 가스 최적화
5. 서명 수집 흐름	순차/병렬/하이브리드, 타임아웃 정책
6. 긴급 승인 체계	축소 쿼럼, Emergency Approver

4.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	2단계 서명 구조 반영: 오프체인 승인(Stage 1) + 온체인 서명(Stage 2) 분리	H	Phase 24
3. BTC MuSig2	수정	단일 콜드월렛 시 MuSig2 불필요(단일 Schnorr), 복수 콜드월렛 폴백 시에만 MuSig2	H	Phase 24-02
3. BTC MuSig2	추가	Pre-commitment Pipelining: QR 교환 62.5~70% 감소, NFC 우선 전략	H	Phase 27 qr-optimization
4. EVM Safe	수정	Approver M명 서명 -> Operator 단일 execTransaction + ApprovalBundle 검증	H	Phase 24-03, Phase 26
5. 서명 수집 흐름	수정	승인 서명 수집(비동기, stateless)과 블록체인 서명 실행 분리	H	Phase 24-01
6. 긴급 승인 체계	수정	Emergency Operator 역할, approval_sk/master_sk 유출 분리 대응	M	Phase 26, Phase 28

4.3. 영향도 판정: 높음 (H)¶

다중 서명의 기본 구조(누가 서명하는가)가 근본적으로 변경된다. BTC MuSig2와 EVM Safe 모두 2단계 분리 반영이 필요하다.

4.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
3-1	1. Executive Summary	2단계 서명 구조 개요 추가: Stage 1(개인 기기 승인) + Stage 2(콜드월렛 서명)	수정	P1
3-2	3. BTC MuSig2	단일 콜드월렛 단일 Schnorr 주 경로, MuSig2 복수 콜드월렛 폴백으로 재구조화	수정	P1
3-3	3. BTC MuSig2	Pre-commitment Pipelining, NFC 우선 전략 반영	추가	P1
3-4	4. EVM Safe	Operator 단일 execTransaction + ApprovalBundle 검증 흐름으로 변경	수정	P1
3-5	5. 서명 수집	승인 서명 비동기 수집(Collect 단계) + 블록체인 서명(Sign 단계) 분리	수정	P1
3-6	6. 긴급 승인	Emergency Operator, 유출 유형별 대응 분리	수정	P2

총 변경 항목: 6건 (P1: 5건, P2: 1건)

5. 산출물 4: `rbac-role-model.md` (Phase 03)¶

5.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	5개 역할(Super Admin, Admin, Initiator, Approver, Viewer), 직무 분리
2. 역할 체계 설계 원칙	계층적/플랫 모델, 직무 분리 매트릭스
3. 역할 정의	5개 역할별 권한, 인증 방식, 시나리오 관여
4. 권한 매트릭스	3개 컴포넌트(대시보드/오프라인앱/콜드월렛) 기반
5. 커스텀 역할 확장	커스텀 역할 생성 메커니즘

5.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	5개 역할 -> 6개 역할(+Operator), Approver 역할 근본 변경	H	Phase 26 RBAC v2
2. 역할 체계	수정	Approver+Operator 겸임 조건부 허용(5인 미만, 동일 TX 금지) 추가	H	Phase 26
3. 역할 정의	수정	Approver: 승인+서명 -> 오프체인 승인 전용으로 대폭 변경	H	Phase 26
3. 역할 정의	추가	Operator 신규 역할: 콜드월렛 서명 실행, 콜드룸 운영 전담	H	Phase 26
4. 권한 매트릭스	수정	3개 컴포넌트 -> 4개 컴포넌트(+개인 기기), 6역할 x 4컴포넌트 매트릭스	H	Phase 26
5. 커스텀 역할	추가	Emergency Operator 커스텀 역할 사전 정의	M	Phase 26

5.3. 영향도 판정: 높음 (H)¶

RBAC의 핵심인 역할 정의 자체가 5개->6개로 변경되고, Approver 역할의 근본적 재정의가 필요하다. Phase 26에서 이미 RBAC v2를 설계했으므로 이를 반영하여 v1 문서를 전면 개정해야 한다.

5.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
4-1	1. Executive Summary	5역할 -> 6역할, Approver/Operator 분리 개요	수정	P1
4-2	2. 역할 체계	직무 분리 매트릭스: Approver+Operator 겸임 조건 추가	수정	P1
4-3	3. 역할 정의	Approver: 오프체인 승인 전용으로 전면 개정	수정	P1
4-4	3. 역할 정의	Operator 신규 역할 섹션 추가	추가	P1
4-5	4. 권한 매트릭스	6역할 x 4컴포넌트 매트릭스로 확장	수정	P1
4-6	5. 커스텀 역할	Emergency Operator 사전 정의 추가	추가	P2

총 변경 항목: 6건 (P1: 5건, P2: 1건)

6. 산출물 5: `operational-scenarios.md` (Phase 03)¶

6.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	12개 운영 시나리오(S-01~S-12) 개요
2. 시나리오 포맷	작성 규칙
3. 일상 운영 (S-01~S-04)	BTC 출금, 배치 전송, 내부 이체, 화이트리스트
4. 긴급 상황 (S-05~S-07)	긴급 출금, 서명자 비가용, 보안 침해
5. 관리 작업 (S-08~S-10)	서명자 교체, 정책 변경, 감사
6. 복구 상황 (S-11~S-12)	디바이스 복구, 초기 설정

6.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	12개 -> 16개 시나리오로 확장(S-06/S-07/S-08/S-11 세분화)	H	Phase 26 operational-scenarios-v2
3. S-01~S-04 일상	수정	5단계 파이프라인 반영, Approver 원격 승인 + Operator 콜드룸 서명으로 전면 변경	H	Phase 26, Phase 28
4. S-05~S-07 긴급	수정	S-06 -> S-06a/S-06b, S-07 -> S-07a/S-07b 세분화, approval_sk/master_sk 유출 분리	H	Phase 26
5. S-08~S-10 관리	수정	S-08 -> S-08a/S-08b(Approver/Operator 교체 분리), 정책 변경 개인 기기 반영	H	Phase 26, Phase 28
6. S-11~S-12 복구	수정	S-11 -> S-11a/S-11b(개인 기기/콜드월렛 복구 분리), Day-1 11단계 반영	H	Phase 26
전체	추가	콜드룸 집결 불필요 시나리오 비율 93.8% 감소 분석	M	Phase 26

6.3. 영향도 판정: 높음 (H)¶

12개 시나리오 중 10개가 2단계 서명으로 인해 역할/단계가 변경되며, 4개 시나리오가 세분화된다. Phase 26에서 이미 v2를 설계했으므로 v1 문서를 v2 기준으로 전면 개정해야 한다.

6.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
5-1	1. Executive Summary	12개 -> 16개 시나리오, 분류표 업데이트	수정	P1
5-2	3. S-01~S-03	5단계 파이프라인 + Approver 원격 + Operator 콜드룸으로 전면 재작성	수정	P1
5-3	4. S-05 긴급 출금	Approver 원격 즉시 승인, Operator 대기 서명 반영	수정	P1
5-4	4. S-06	S-06a(Approver 비가용) + S-06b(Operator 비가용) 세분화	수정+추가	P1
5-5	4. S-07	S-07a(approval_sk 유출) + S-07b(master_sk 유출) 세분화	수정+추가	P1
5-6	5. S-08	S-08a(Approver 교체) + S-08b(Operator 교체) 세분화	수정+추가	P1
5-7	6. S-11	S-11a(개인 기기 복구) + S-11b(콜드월렛 복구) 세분화	수정+추가	P1
5-8	6. S-12	Day-1 11단계 반영, 원격 참여 가능 영역 명시	수정	P1

총 변경 항목: 8건 (P1: 8건)

7. 산출물 6: `disaster-recovery.md` (Phase 03)¶

7.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	5가지 재해 시나리오(DS-01~DS-05), RTO/RPO
2. 시나리오 분류	단일 기기 장애, 사이트 재해, 서명자 비가용, SW 장애, 보안 침해
3. 금속 시드 백업	Shamir 분할, 지리적 분산, 각인 절차
4. 복구 절차	시나리오별 복구 단계
5. 복구 드릴	정기 훈련 프레임워크

7.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	DS-01에 개인 기기 장애 추가, DS-05에 approval_sk/master_sk 유출 분리	H	Phase 25, Phase 28
2. 시나리오 분류	추가	DS-06: 개인 기기 분실/도난 (approval_sk 유출 가능) 시나리오 신규	H	Phase 25 key-lifecycle
3. 금속 시드 백업	수정	approval_sk 백업: SE 외부 비존재 (옵션 C 교체 우선) 명시, master_sk 백업만 기존 절차 유지	M	Phase 25 key-lifecycle
4. 복구 절차	추가	개인 기기 복구(S-11a): 기기 교체 + approval_pk 재등록, 온체인 무영향	H	Phase 28 core-flow-redesign
4. 복구 절차	수정	DS-05 보안 침해: approval_sk 유출 vs master_sk 유출 차등 대응	H	Phase 28
5. 복구 드릴	수정	개인 기기 교체 드릴 추가, approval_sk 유출 시나리오 훈련	M	Phase 25

7.3. 영향도 판정: 높음 (H)¶

개인 기기 관련 재해 시나리오가 신규 추가되고, 키 독립성을 활용한 차등 복구(approval_sk 유출 시 간소 대응)가 반영되어야 한다.

7.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
6-1	1. Executive Summary	재해 시나리오 5개->6개 확장, approval_sk/master_sk 유출 분리	수정	P1
6-2	2. 시나리오 분류	DS-06 개인 기기 분실/도난 시나리오 추가	추가	P1
6-3	3. 금속 시드 백업	approval_sk 백업 불가(SE 외부 비존재) 명시, 교체 우선 전략	수정	P1
6-4	4. 복구 절차	개인 기기 복구 절차(S-11a) 추가	추가	P1
6-5	4. 복구 절차	DS-05 차등 대응(approval_sk vs master_sk)	수정	P1
6-6	5. 복구 드릴	개인 기기 교체 드릴 시나리오 추가	추가	P2

총 변경 항목: 6건 (P1: 5건, P2: 1건)

8. 산출물 7: `policy-engine.md` (Phase 03)¶

8.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	정책 엔진 3중 방어(Request/Sign/Hardware), RBAC 연동
2. 정책 엔진 개요	아키텍처 위치, 정책 평가 흐름
3. 정책 유형	금액 한도, 화이트리스트, 시간대, 쿼럼, 자산 유형
4. 정책 변경 관리	버전 관리, 감사 추적
5. HW 정책 엔진	SE 내부 정책 검증 (Phase 4 범위)

8.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	정책 평가 시점 4중 방어로 확장: +개인 기기 SE 정책 검증 (카드 타입 금액 한도 등)	M	Phase 25 firmware-requirements
2. 정책 엔진 개요	추가	개인 기기 SE 정책 평가 단계 추가 (카드 타입: 금액 상한, delegatecall 차단)	M	Phase 25 device-evaluation
3. 정책 유형	추가	개인 기기 유형별 승인 제한 정책: 카드(저액/비금전만), 기기별 TX 허용 매트릭스	M	Phase 25
5. HW 정책 엔진	수정	Approval Verifier(콜드월렛 SE): 4개 HW 불변 규칙 + ApprovalBundle 검증 추가	H	Phase 24-02, Phase 25
5. HW 정책 엔진	추가	개인 기기 SE 정책: 금액 한도 검증(카드), delegatecall 차단(카드)	M	Phase 25

8.3. 영향도 판정: 중간 (M)¶

정책 엔진의 핵심 구조(3중 방어)는 유효하며, 개인 기기 SE 정책 평가 계층 추가와 카드 타입 제한 정책 보강이 필요하다.

8.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
7-1	1. Executive Summary	3중 방어 -> 4중 방어(+개인 기기 SE 정책)	수정	P1
7-2	2. 정책 엔진 개요	개인 기기 SE 정책 평가 단계 아키텍처 다이어그램 추가	추가	P2
7-3	3. 정책 유형	기기 유형별 승인 제한 정책 추가 (카드 TX 상한, delegatecall 차단)	추가	P1
7-4	5. HW 정책 엔진	Approval Verifier + ApprovalBundle 검증 로직 추가	수정	P1
7-5	5. HW 정책 엔진	개인 기기 SE 정책(카드 금액 한도, 차단 TX 유형) 섹션 추가	추가	P2

총 변경 항목: 5건 (P1: 3건, P2: 2건)

9. 산출물 8: `three-zone-security-architecture.md` (Phase 05)¶

9.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	3-Zone(Online/Offline/Hardware SE), Zero Trust, Air-Gap First
2. Zone 정의 및 경계	Zone 1/2/3 각각의 신뢰 수준, 허용 통신, 데이터 보호
3. Trust Boundary	TB-1~TB-5 정의
4. 데이터 흐름	Zone 간 데이터 흐름 다이어그램
5. 보안 제약 매핑	AC-ID 제약조건 매핑

9.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	3-Zone -> 4-Zone(+Zone 3+ Personal SE), TB-5 -> TB-7	H	Phase 24-03 zone3plus
2. Zone 정의	추가	Zone 3+(Personal SE Sub-Zone): 신뢰 수준 ABSOLUTE, NFC/QR 통신, approval_sk 보관	H	Phase 24-03
3. Trust Boundary	추가	TB-6(오프라인 앱 <-> 개인 기기), TB-7(외부 환경 <-> 개인 기기) 정의	H	Phase 24-03
4. 데이터 흐름	수정	Zone 3+와의 데이터 흐름 추가: ApprovalRequest/ApprovalBundle 경로	H	Phase 24
5. 보안 제약 매핑	추가	Zone 3+ 관련 AC-ID 추가 예상 (19~27개)	M	Phase 24-01

9.3. 영향도 판정: 높음 (H)¶

보안 아키텍처의 기본 구조(3-Zone)가 4-Zone으로 확장되고 TB-6/TB-7이 추가된다. Phase 24-03에서 이미 Zone 3+ 설계가 완료되었으므로 이를 반영하여 v1 문서를 확장해야 한다.

9.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
8-1	1. Executive Summary	3-Zone -> 4-Zone, 원칙에 "개인 기기 에어갭" 추가	수정	P1
8-2	2. Zone 정의	Zone 3+(Personal SE Sub-Zone) 섹션 신규 추가	추가	P1
8-3	3. Trust Boundary	TB-6, TB-7 정의 및 위협 표면 설명 추가	추가	P1
8-4	4. 데이터 흐름	Zone 3+ 데이터 흐름 다이어그램 추가	수정	P1
8-5	5. 보안 제약 매핑	Zone 3+ 관련 AC-ID 매핑 추가	추가	P2

총 변경 항목: 5건 (P1: 4건, P2: 1건)

10. 산출물 9: `stride-threat-model.md` (Phase 05)¶

10.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	5 TB x 6 STRIDE = 30 위협 셀 분석
2. 방법론	STRIDE + NIST CSF 매핑
3. TB별 위협 분석	TB-1~TB-5 각각의 STRIDE 6카테고리 분석
4. Top 10 공격 시나리오	고위험 시나리오 상세
5. 완화 전략	NIST CSF 매핑 대응

10.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	5 TB -> 7 TB, 30 위협 셀 -> 42 위협 셀	H	Phase 24-03
3. TB별 위협 분석	추가	TB-6(오프라인 앱<->개인 기기) STRIDE 6카테고리 분석	H	Phase 24-03
3. TB별 위협 분석	추가	TB-7(외부환경<->개인 기기) STRIDE 6카테고리 분석	H	Phase 24-03
4. Top 10 시나리오	수정	개인 기기 관련 공격 시나리오 추가: 기기 탈취+PIN 무차별 대입, NFC 중간자, approval_sk 유출	H	Phase 24-03, Phase 25
5. 완화 전략	추가	TB-6/TB-7 완화 전략: SE attestation, BLE 비활성화, 인증 실패 와이프	M	Phase 25 firmware-requirements

10.3. 영향도 판정: 높음 (H)¶

TB-6/TB-7 추가로 12개 새로운 위협 셀이 생기며, Top 10 공격 시나리오에 개인 기기 관련 위협이 추가되어야 한다.

10.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
9-1	1. Executive Summary	5 TB -> 7 TB, 30 -> 42 위협 셀	수정	P1
9-2	3. TB-6 분석	TB-6 STRIDE 6카테고리 위협 분석 신규 추가	추가	P1
9-3	3. TB-7 분석	TB-7 STRIDE 6카테고리 위협 분석 신규 추가	추가	P1
9-4	4. Top 10	개인 기기 공격 시나리오 추가 (기기 탈취, NFC 중간자, approval_sk 유출)	수정	P1
9-5	5. 완화 전략	TB-6/TB-7 완화 전략 추가	추가	P2

총 변경 항목: 5건 (P1: 4건, P2: 1건)

11. 산출물 10: `firmware-signing-interface.md` (Phase 05)¶

11.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	SE 앱릿 구조(Signing/Policy/WYSIWYS), 외부 통신 인터페이스
2. SE 통신 인터페이스	앱릿 구조 다이어그램, 메시지 처리 흐름
3. SignRequest/SignResponse	서명 요청/응답 메시지 명세
4. PolicyUpdate	정책 업데이트 인터페이스
5. SE 상태 조회	상태 쿼리 인터페이스

11.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	Approval Verifier 앱릿 추가: ApprovalBundle 검증 + approval_pk 레지스트리 관리	H	Phase 24, Phase 25
2. SE 앱릿 구조	추가	Approval Verifier Applet: approval_sig M개 검증, M-of-N 임계값 확인, 레지스트리 관리	H	Phase 25 firmware-requirements
3. SignRequest	수정	SignRequest에 ApprovalBundle 포함 필수화: Approval Verifier 통과 후에만 서명 실행	H	Phase 24-02
4. PolicyUpdate	추가	approval_pk 레지스트리 업데이트 인터페이스 (등록/삭제/조회)	M	Phase 25 key-lifecycle
5. SE 상태 조회	추가	등록된 approval_pk 목록 조회, 정족수 설정 조회 인터페이스	M	Phase 25

11.3. 영향도 판정: 높음 (H)¶

콜드월렛 SE에 Approval Verifier라는 완전히 새로운 앱릿이 추가되며, 기존 SignRequest 흐름에 ApprovalBundle 검증이 전제 조건으로 삽입된다.

11.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
10-1	1. Executive Summary	Approval Verifier Applet 개요 추가	수정	P1
10-2	2. SE 앱릿 구조	Approval Verifier Applet 상세 추가 (approval_sig 검증, 레지스트리)	추가	P1
10-3	3. SignRequest	ApprovalBundle 검증 전제 조건 추가	수정	P1
10-4	4. PolicyUpdate	approval_pk 레지스트리 CRUD 인터페이스 추가	추가	P1
10-5	5. SE 상태 조회	approval_pk 목록/정족수 조회 추가	추가	P2

총 변경 항목: 5건 (P1: 4건, P2: 1건)

12. 산출물 11: `airgap-communication-protocol.md` (Phase 05)¶

12.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	UR v2 기반 에어갭 프로토콜, QR + USB-C
2. UR 프로토콜 스택	4-Layer 구조 (Transport/UR/CBOR/Application)
3. CBOR 스키마	PSBT, PolicyUpdate 등 CBOR 정의
4. Animated QR	Fountain Code 파라미터, 프레임 크기
5. USB-C 프로토콜	HID/Bulk Transfer 명세

12.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	통신 채널에 NFC APDU 추가 (QR + USB-C + NFC), 4번째 컴포넌트(개인 기기) 반영	H	Phase 24-03, Phase 27
2. UR 프로토콜 스택	수정	Transport Layer에 NFC APDU 채널 추가	M	Phase 25, Phase 27
3. CBOR 스키마	추가	UR type 45050(ApprovalRequest), 45051(ApprovalResponse), 45052(ApprovalBundle), 45060~45063 추가	H	Phase 24-02, Phase 27
4. Animated QR	수정	Pre-commitment Pipelining 배치 전송 파라미터 추가, NFC 우선 전략 반영	H	Phase 27 qr-optimization
5. USB-C	수정	참조 변경: USB-C는 콜드월렛 전용, 개인 기기는 NFC/QR 명시	M	Phase 25, Phase 27
신규 섹션	추가	NFC APDU 통신 프로토콜: 개인 기기 7개 명령(INS 0x50~0x71) 명세	H	Phase 25 firmware-requirements

12.3. 영향도 판정: 높음 (H)¶

NFC APDU라는 새로운 통신 채널이 추가되고, UR 타입 4~8개가 신규 정의되며, Pre-commitment Pipelining 배치 전송이 반영되어야 한다.

12.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
11-1	1. Executive Summary	NFC APDU 통신 채널 추가, 4번째 컴포넌트(개인 기기) 반영	수정	P1
11-2	2. UR 스택	Transport Layer NFC APDU 추가	수정	P1
11-3	3. CBOR 스키마	UR 45050/45051/45052/45060~45063 CBOR 스키마 추가	추가	P1
11-4	4. Animated QR	Pre-commitment Pipelining 파라미터, NFC 우선 전략	수정	P1
11-5	신규 섹션 6	NFC APDU 통신 프로토콜 섹션 추가 (7개 명령 명세)	추가	P1
11-6	5. USB-C	개인 기기 대상 제외 명시	수정	P2

총 변경 항목: 6건 (P1: 5건, P2: 1건)

13. 산출물 12: `multichain-signing-firmware-spec.md` (Phase 06)¶

13.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	BTC/EVM/ERC-20 서명 펌웨어 요구사항, FW-SIGN-ID 체계
2. BTC 서명 요구사항	PSBT 파싱, Schnorr, MuSig2 2라운드, BIP-373
3. EVM 서명 요구사항	RLP, ECDSA, EIP-712, EIP-1559
4. ERC-20 요구사항	ABI 디코딩, 토큰 DB
5. Chain Parser Interface	향후 체인 확장 구조

13.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	추가	개인 기기 SE 펌웨어 요구사항 참조(Approval Signing Applet) 추가	M	Phase 25 firmware-requirements
2. BTC 서명	수정	단일 콜드월렛 단일 Schnorr 주 경로, MuSig2는 복수 콜드월렛 폴백으로 재우선순위화	M	Phase 24-02
2. BTC 서명	추가	Approval Verifier 통과 전제 조건(ApprovalBundle 검증) 추가	H	Phase 24-02
3. EVM 서명	추가	Approval Verifier 통과 전제 조건, delegatecall 경고 강화	H	Phase 24-03
5. Chain Parser	추가	ThresholdSigningProtocol 추상화 인터페이스 참조(MuSig2/FROST 전환)	M	Phase 27 frost-analysis
신규	추가	개인 기기 SE: Approval Signing Applet FW 요구사항 참조 섹션	M	Phase 25

13.3. 영향도 판정: 중간 (M)¶

기존 서명 펌웨어 요구사항의 결론은 유효하며, Approval Verifier 전제 조건 추가와 ThresholdSigningProtocol 추상화 참조 추가가 필요하다.

13.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
12-1	1. Executive Summary	개인 기기 SE 펌웨어 요구사항 참조 추가	수정	P2
12-2	2. BTC 서명	Approval Verifier 전제 조건 추가, MuSig2 폴백 재우선순위화	수정	P1
12-3	3. EVM 서명	Approval Verifier 전제 조건, delegatecall 경고 강화	수정	P1
12-4	5. Chain Parser	ThresholdSigningProtocol 추상화 인터페이스 참조	추가	P2
12-5	신규 섹션	개인 기기 Approval Signing Applet FW 요구사항 참조	추가	P2

총 변경 항목: 5건 (P1: 2건, P2: 3건)

14. 산출물 13: `signing-core-flow.md` (Phase 13)¶

14.1. 현재 내용 요약¶

섹션	내용
1. Executive Summary	Layer 1 핵심 서명 플로우, 4단계 파이프라인 9개 Step
2. 공통 서명 파이프라인	Step 1~9 번호부 스텝, WYSIWYS 독립 스텝
3. 프로토콜별 분기	MuSig2/Safe/MPC-TSS별 상세 절차
4. WYSIWYS 하드웨어 검증	독립 필수 스텝, Bybit 교훈
5. 서명 반환	에어갭 반환 흐름

14.2. v0.5 변경 사항 매핑¶

섹션	변경유형	변경내용	영향도	Phase 근거
1. Executive Summary	수정	4단계 -> 5단계 파이프라인, Step 재번호, Layer 2/3 어노테이션 참조 체계 갱신	H	Phase 24, Phase 28
2. 공통 파이프라인	수정	Step 재설계: Stage 1(개인 기기 승인) Step과 Stage 2(콜드월렛 서명) Step 분리	H	Phase 24, Phase 28 core-flow-redesign
2. 공통 파이프라인	추가	Collect 단계 Step: ApprovalBundle 수집/생성	H	Phase 24
3. 프로토콜별 분기	수정	BTC: 단일 Schnorr 주 경로, MuSig2 복수 콜드월렛 폴백	H	Phase 24-02
3. 프로토콜별 분기	수정	EVM: Operator 단일 execTransaction	H	Phase 24-03
4. WYSIWYS	수정	개인 기기 WYSIWYS(Stage 1) + 콜드월렛 WYSIWYS(Stage 2) 이중 검증	M	Phase 25 device-evaluation
5. 서명 반환	수정	NFC 우선 통신, QR 폴백 명시	M	Phase 27

14.3. 영향도 판정: 높음 (H)¶

Layer 1 핵심 서명 플로우의 4단계 -> 5단계 변경과 Step 재번호가 필요하며, 이는 Layer 2 델타와 Layer 3 어노테이션의 참조 체계에도 영향을 미친다.

14.4. 변경 명세표¶

#	변경 위치	변경 내용	변경 유형	우선순위
13-1	1. Executive Summary	4단계 -> 5단계, v0.5 참조 관계 갱신	수정	P1
13-2	2. 공통 파이프라인	Step 재설계: Stage 1 승인 Step + Collect Step + Stage 2 서명 Step	수정	P1
13-3	2. 공통 파이프라인	Collect 단계(ApprovalBundle 수집/생성) Step 추가	추가	P1
13-4	3. 프로토콜 분기	BTC 단일 Schnorr 주 경로, MuSig2 폴백	수정	P1
13-5	3. 프로토콜 분기	EVM Operator 단일 execTransaction	수정	P1
13-6	4. WYSIWYS	개인 기기 + 콜드월렛 이중 WYSIWYS	수정	P2
13-7	5. 서명 반환	NFC 우선, QR 폴백 명시	수정	P2

총 변경 항목: 7건 (P1: 5건, P2: 2건)

15. 종합 분석¶

15.1. 13개 산출물 영향도 총괄표¶

#	산출물	Phase	영향도	변경항목수	P1	P2	우선순위
1	airgap-signing-flow.md	03	H	8건	6	2	1순위
2	key-ceremony.md	03	H	8건	7	1	1순위
3	multisig-workflow.md	03	H	6건	5	1	1순위
4	rbac-role-model.md	03	H	6건	5	1	1순위
5	operational-scenarios.md	03	H	8건	8	0	1순위
6	disaster-recovery.md	03	H	6건	5	1	2순위
7	policy-engine.md	03	M	5건	3	2	2순위
8	three-zone-security-architecture.md	05	H	5건	4	1	1순위
9	stride-threat-model.md	05	H	5건	4	1	2순위
10	firmware-signing-interface.md	05	H	5건	4	1	2순위
11	airgap-communication-protocol.md	05	H	6건	5	1	1순위
12	multichain-signing-firmware-spec.md	06	M	5건	2	3	3순위
13	signing-core-flow.md	13	H	7건	5	2	1순위
	합계		H: 11, M: 2	80건	63	17

15.2. 산출물 간 변경 의존성 그래프¶

변경 작업 시 아래 의존성을 반드시 준수해야 한다. A -> B는 "A를 먼저 수정해야 B 수정 가능"을 의미한다.

rbac-role-model.md (4)
  ├──> operational-scenarios.md (5)     [역할 정의가 시나리오 참여 역할 기준]
  ├──> key-ceremony.md (2)              [참석자 역할이 RBAC에서 도출]
  ├──> policy-engine.md (7)             [정책 평가 주체가 역할 기반]
  └──> disaster-recovery.md (6)         [복구 역할이 RBAC에서 도출]

three-zone-security-architecture.md (8)
  ├──> stride-threat-model.md (9)       [TB 정의가 위협 모델 기준]
  ├──> airgap-communication-protocol.md (11) [Zone 정의가 통신 채널 기준]
  └──> firmware-signing-interface.md (10)    [Zone 3/3+ SE 구조 기준]

airgap-signing-flow.md (1)
  ├──> signing-core-flow.md (13)        [4단계->5단계 파이프라인 기준]
  └──> multisig-workflow.md (3)         [서명 파이프라인이 다중 서명 흐름 기준]

airgap-communication-protocol.md (11)
  └──> multichain-signing-firmware-spec.md (12) [통신 프로토콜이 FW 명세 기준]

15.3. 의존성 기반 수정 순서 권장¶

Wave 1: 기반 산출물 (독립 수정 가능, 병렬 작업 가능)¶

순서	산출물	근거
W1-1	rbac-role-model.md (4)	5개 산출물의 선행 의존 -- RBAC가 모든 역할 기반 문서의 기준
W1-2	three-zone-security-architecture.md (8)	3개 산출물의 선행 의존 -- Zone/TB가 보안 문서의 기준
W1-3	airgap-signing-flow.md (1)	2개 산출물의 선행 의존 -- 파이프라인이 서명 플로우의 기준

Wave 2: Wave 1 의존 산출물¶

순서	산출물	의존 대상
W2-1	operational-scenarios.md (5)	W1-1 rbac (역할 재배치 기준)
W2-2	key-ceremony.md (2)	W1-1 rbac (참석자 역할)
W2-3	multisig-workflow.md (3)	W1-3 airgap-signing-flow (파이프라인)
W2-4	signing-core-flow.md (13)	W1-3 airgap-signing-flow (파이프라인)
W2-5	stride-threat-model.md (9)	W1-2 three-zone (TB 정의)
W2-6	airgap-communication-protocol.md (11)	W1-2 three-zone (Zone 정의)
W2-7	firmware-signing-interface.md (10)	W1-2 three-zone (SE 구조)

Wave 3: Wave 2 의존 산출물¶

순서	산출물	의존 대상
W3-1	disaster-recovery.md (6)	W1-1 rbac + W2-2 key-ceremony
W3-2	policy-engine.md (7)	W1-1 rbac + W2-6 communication
W3-3	multichain-signing-firmware-spec.md (12)	W2-6 communication + W2-7 firmware-interface

15.4. v0.4 UPDATE-01 미반영분과의 통합 권장¶

Phase 23에서 도출된 v0.4 UPDATE-01(6개 산출물 40건, P1: 24건)과의 통합 가능성:

v0.4 대상 산출물	v0.5 대상 여부	통합 권장	근거
on-premise-zero-cloud.md	v0.5 대상 아님	독립 실행	v0.5 설계와 직접 무관
dashboard-backend-architecture.md	v0.5 대상 아님	독립 실행	v0.5 설계와 직접 무관
regulatory-landscape.md	v0.5 대상 아님	독립 실행	v0.5 설계와 직접 무관
compliance-architecture-matrix.md	v0.5 대상 아님	독립 실행	v0.5 설계와 직접 무관
security-certifications.md	v0.5 대상 아님	독립 실행	v0.5 설계와 직접 무관
business-model.md	v0.5 대상 아님	독립 실행	v0.5 설계와 직접 무관

결론: v0.4 UPDATE-01과 v0.5 영향도 분석의 대상 산출물이 겹치지 않으므로, 두 업데이트를 병렬로 독립 실행하는 것이 효율적이다. 단, rbac-role-model.md는 v0.4에서도 minor 업데이트가 식별되었을 수 있으므로, v0.5 전면 개정 시 v0.4 항목도 함께 반영하는 것이 중복 작업을 방지한다.

15.5. AC-ID 추가 예상 분류¶

Phase 24-01에서 19~27개 AC-ID 추가가 예상되었다. 상세 분류:

분류	예상 AC-ID 수	대상
AC-PD (개인 기기)	8~10개	기기 등록/폐기, 인증 정책, approval_sk 관리
AC-AP (승인 프로토콜)	4~6개	ApprovalBundle 검증, 정족수, 타임아웃
AC-TB (Trust Boundary)	4~5개	TB-6/TB-7 보안 요구사항, NFC 에어갭
AC-OP (Operator)	3~4개	Operator 역할, 콜드룸 접근 통제, 인수인계
AC-EM (긴급)	2~3개	긴급 정족수 완화, Emergency Operator
합계	21~28개

15.6. 후속 마일스톤 실행 순서 권장¶

마일스톤	범위	우선순위	근거
v0.6	Wave 1 기반 산출물 업데이트 (rbac-role-model, three-zone, airgap-signing-flow) + AC-ID 추가	최우선	모든 후속 업데이트의 선행 조건
v0.7	Wave 2 핵심 산출물 업데이트 (operational-scenarios, key-ceremony, multisig-workflow, signing-core-flow)	높음	Wave 1 완료 후 즉시 실행
v0.8	Wave 2 보안 산출물 업데이트 (stride-threat-model, communication-protocol, firmware-interface)	높음	Wave 1 완료 후 Wave 2-1~4와 병렬 가능
v0.9	Wave 3 산출물 업데이트 (disaster-recovery, policy-engine, firmware-spec) + v0.4 UPDATE-01 독립 실행	중간	Wave 2 완료 후
v1.0	전체 통합 검증, 교차 참조 일관성 감사, AC-ID 커버리지 최종 확인	높음	모든 업데이트 완료 후

예상 작업량: - v0.6: P1 기반 3개 산출물, ~15개 변경 항목 - v0.7: P1 핵심 4개 산출물, ~23개 변경 항목 - v0.8: P1 보안 3개 산출물, ~14개 변경 항목 - v0.9: P1/P2 3개 산출물 + v0.4 6개 산출물, ~35개 변경 항목 - v1.0: 통합 검증 (변경 항목 아님)

분석 기준: Phase 24 option-evaluation.md, btc-implementation.md, evm-implementation.md, zone3plus-security-architecture.md 분석 기준: Phase 25 device-evaluation.md, firmware-requirements.md, key-lifecycle.md 분석 기준: Phase 26 rbac-v2-role-definitions.md, operational-scenarios-v2.md 분석 기준: Phase 27 qr-optimization.md, frost-analysis.md 방법론 참조: Phase 18 core-design-impact-analysis.md, Phase 23 existing-deliverables-impact-analysis.md

기존 13개 산출물 v0.5 영향도 분석 및 수정 범위 정의¶

1. 분석 개요¶

1.1. 목적¶

1.2. 분석 방법론¶

1.3. v0.5 핵심 변경 원인 (Phase 24~27)¶

2. 산출물 1: airgap-signing-flow.md (Phase 03)¶

2.1. 현재 내용 요약¶

2.2. v0.5 변경 사항 매핑¶

2.3. 영향도 판정: 높음 (H)¶

2.4. 변경 명세표¶

3. 산출물 2: key-ceremony.md (Phase 03)¶

3.1. 현재 내용 요약¶

3.2. v0.5 변경 사항 매핑¶

3.3. 영향도 판정: 높음 (H)¶

3.4. 변경 명세표¶

4. 산출물 3: multisig-workflow.md (Phase 03)¶

4.1. 현재 내용 요약¶

4.2. v0.5 변경 사항 매핑¶

4.3. 영향도 판정: 높음 (H)¶

4.4. 변경 명세표¶

5. 산출물 4: rbac-role-model.md (Phase 03)¶

5.1. 현재 내용 요약¶

5.2. v0.5 변경 사항 매핑¶

5.3. 영향도 판정: 높음 (H)¶

5.4. 변경 명세표¶

6. 산출물 5: operational-scenarios.md (Phase 03)¶

6.1. 현재 내용 요약¶

6.2. v0.5 변경 사항 매핑¶

6.3. 영향도 판정: 높음 (H)¶

6.4. 변경 명세표¶

7. 산출물 6: disaster-recovery.md (Phase 03)¶

7.1. 현재 내용 요약¶

7.2. v0.5 변경 사항 매핑¶

7.3. 영향도 판정: 높음 (H)¶

7.4. 변경 명세표¶

8. 산출물 7: policy-engine.md (Phase 03)¶

8.1. 현재 내용 요약¶

8.2. v0.5 변경 사항 매핑¶

8.3. 영향도 판정: 중간 (M)¶

8.4. 변경 명세표¶

9. 산출물 8: three-zone-security-architecture.md (Phase 05)¶

9.1. 현재 내용 요약¶

9.2. v0.5 변경 사항 매핑¶

9.3. 영향도 판정: 높음 (H)¶

9.4. 변경 명세표¶

10. 산출물 9: stride-threat-model.md (Phase 05)¶

10.1. 현재 내용 요약¶

10.2. v0.5 변경 사항 매핑¶

10.3. 영향도 판정: 높음 (H)¶

10.4. 변경 명세표¶

11. 산출물 10: firmware-signing-interface.md (Phase 05)¶

11.1. 현재 내용 요약¶

11.2. v0.5 변경 사항 매핑¶

11.3. 영향도 판정: 높음 (H)¶

11.4. 변경 명세표¶

12. 산출물 11: airgap-communication-protocol.md (Phase 05)¶

12.1. 현재 내용 요약¶

12.2. v0.5 변경 사항 매핑¶

12.3. 영향도 판정: 높음 (H)¶

12.4. 변경 명세표¶

13. 산출물 12: multichain-signing-firmware-spec.md (Phase 06)¶

13.1. 현재 내용 요약¶

13.2. v0.5 변경 사항 매핑¶

13.3. 영향도 판정: 중간 (M)¶

13.4. 변경 명세표¶

14. 산출물 13: signing-core-flow.md (Phase 13)¶

14.1. 현재 내용 요약¶

14.2. v0.5 변경 사항 매핑¶

14.3. 영향도 판정: 높음 (H)¶

14.4. 변경 명세표¶

15. 종합 분석¶

15.1. 13개 산출물 영향도 총괄표¶

15.2. 산출물 간 변경 의존성 그래프¶

15.3. 의존성 기반 수정 순서 권장¶

Wave 1: 기반 산출물 (독립 수정 가능, 병렬 작업 가능)¶

Wave 2: Wave 1 의존 산출물¶

Wave 3: Wave 2 의존 산출물¶

15.4. v0.4 UPDATE-01 미반영분과의 통합 권장¶

15.5. AC-ID 추가 예상 분류¶

15.6. 후속 마일스톤 실행 순서 권장¶

2. 산출물 1: `airgap-signing-flow.md` (Phase 03)¶

3. 산출물 2: `key-ceremony.md` (Phase 03)¶

4. 산출물 3: `multisig-workflow.md` (Phase 03)¶

5. 산출물 4: `rbac-role-model.md` (Phase 03)¶

6. 산출물 5: `operational-scenarios.md` (Phase 03)¶

7. 산출물 6: `disaster-recovery.md` (Phase 03)¶

8. 산출물 7: `policy-engine.md` (Phase 03)¶

9. 산출물 8: `three-zone-security-architecture.md` (Phase 05)¶

10. 산출물 9: `stride-threat-model.md` (Phase 05)¶

11. 산출물 10: `firmware-signing-interface.md` (Phase 05)¶

12. 산출물 11: `airgap-communication-protocol.md` (Phase 05)¶

13. 산출물 12: `multichain-signing-firmware-spec.md` (Phase 06)¶

14. 산출물 13: `signing-core-flow.md` (Phase 13)¶