v0.3
키 세레모니/재해 복구/셀프 커스터디 아키텍처 변경 영향도 분석서¶
1. 분석 개요¶
1.1. 분석 범위¶
본 문서는 Phase 16-17에서 설계한 새로운 백업 옵션 체계가 v0.0 핵심 설계 문서 3종에 미치는 구체적 변경 사항을 섹션 단위로 도출한다.
분석 대상 문서:
| # | 문서 | Phase | 핵심 내용 |
|---|---|---|---|
| 1 | key-ceremony.md | Phase 3 | 키 세레모니 8단계 워크플로우 |
| 2 | disaster-recovery.md | Phase 3 | 5개 재해 시나리오(DS-01~DS-05) 및 복구 절차 |
| 3 | self-custody-architecture.md | Phase 4 | True Self-Custody 구조, 벤더 독립성, 오픈 표준 |
1.2. 방법론¶
섹션별 대조 분석: Phase 16-17 산출물 5개 문서의 설계 결정 사항을 추출하여, 기존 v0.0 문서의 각 섹션과 1:1 대조한다. 변경 항목마다 변경 유형(추가/수정/삭제), 변경 근거(Phase 16-17 출처), 영향도(High/Medium/Low)를 명시한다.
1.3. Phase 16-17 핵심 설계 변경 요약¶
| 결정 사항 | Phase | 출처 문서 | 기존 문서 영향 |
|---|---|---|---|
| 하이브리드 백업 의무화(경로 C) | 16 | r3covery-card-technical-analysis.md | key-ceremony, disaster-recovery |
| R3covery 카드 다중 발급(3장 권장) | 16 | r3covery-card-technical-analysis.md | key-ceremony, disaster-recovery |
| PIN 3종 라이프사이클 상태 머신 | 16 | pin-management-system-design.md | key-ceremony |
| PIN Shamir 분할(2-of-3/3-of-5) | 16 | pin-management-system-design.md | key-ceremony |
| SLIP-39 키 세레모니 Step 3 통합 | 17 | slip39-shamir-enterprise-design.md | key-ceremony |
| Super Shamir 3그룹 RBAC 매핑 | 17 | slip39-shamir-enterprise-design.md | key-ceremony, self-custody |
| R3covery 카드 5단계 라이프사이클 | 17 | r3covery-card-lifecycle-operations.md | key-ceremony, disaster-recovery |
| 백업 옵션 카탈로그 A/B/C/D | 17 | backup-options-catalog.md | disaster-recovery, self-custody |
| SE 내부 SLIP-39 불가 가정(보수적) | 17 | slip39-shamir-enterprise-design.md | self-custody |
| SaaS 배포 시 Super Shamir(D) 비권장 | 17 | backup-options-catalog.md | self-custody |
2. key-ceremony.md 영향도 분석¶
2.1. 변경 사항 총괄¶
| 섹션 | 변경 유형 | 변경 내용 | 영향도 | 근거 |
|---|---|---|---|---|
| 3.1 사전 준비 | 수정 | 장비 목록에 R3covery 카드, NFC 리더, SLIP-39 분할 도구 추가 | Medium | [근거: Phase 17 r3covery-card-lifecycle-operations.md 2.2절] |
| 3.2 Step 1 | 수정 | 환경 검증 체크리스트에 R3covery 카드 장비 확인 항목 추가 | Low | [근거: Phase 17 r3covery-card-lifecycle-operations.md 2.1절] |
| 3.2 Step 2 | 수정 | PIN 설정 절차 확장 — PIN 3종 중 디바이스 PIN 라이프사이클 적용 | Medium | [근거: Phase 16 pin-management-system-design.md 3.1~3.3절] |
| 3.2 Step 2.5 | 추가 (신규) | R3covery 카드 발급 절차 전체 신규 삽입 | High | [근거: Phase 17 r3covery-card-lifecycle-operations.md 2.3절] |
| 3.2 Step 3 | 수정 (대폭) | 시드 백업을 3방식 옵션 선택형으로 확장 | High | [근거: Phase 17 slip39-shamir-enterprise-design.md 2.3절] |
| 3.2 Step 4 | 수정 | 백업 검증에 R3covery 카드 NFC 읽기 테스트 및 SLIP-39 셰어 체크섬 검증 추가 | Medium | [근거: Phase 17 r3covery-card-lifecycle-operations.md 2.3절 Phase D] |
| 3.2 Step 7 | 수정 | 백업 분산 보관에 R3covery 카드 + SLIP-39 셰어 분산 규칙 추가 | Medium | [근거: Phase 17 slip39-shamir-enterprise-design.md 2.6절] |
| 3.2 Step 8 | 수정 | 세레모니 기록에 카드 일련번호, 셰어 분배 매핑, PIN Shamir 분배 기록 추가 | Medium | [근거: Phase 17 r3covery-card-lifecycle-operations.md 2.3절 Phase F] |
| 2.2 참석자 역할 | 수정 | Super Shamir 그룹별 셰어 수령자 역할 추가 | Medium | [근거: Phase 17 slip39-shamir-enterprise-design.md 3.2절] |
| 4.1 서명자 교체 | 수정 | 퇴임 서명자의 R3covery 카드 폐기 + SLIP-39 셰어 재분배 절차 추가 | Medium | [근거: Phase 17 r3covery-card-lifecycle-operations.md 6절] |
| 1 세레모니 유형 | 수정 | 소요 시간 변경 — 초기 설정 4-8시간 → 6-10시간 (하이브리드 백업 추가분) | Low | [근거: Phase 17 slip39-shamir-enterprise-design.md 2.3절 소요시간 표] |
2.2. Step 2.5 (신규): R3covery 카드 발급 상세¶
변경 유형: 추가 (신규 Step 삽입) 영향도: High 근거: [Phase 17 r3covery-card-lifecycle-operations.md 2.1~2.3절]
기존 key-ceremony.md는 Step 2(디바이스 초기화) → Step 3(시드 백업)으로 직행한다. Phase 17에서 설계한 R3covery 카드 라이프사이클에 따르면, 시드 백업(Step 3) 전에 카드 SE 초기화와 카드 PIN 설정이 선행되어야 한다.
삽입 내용:
Step 2.5: R3covery 카드 발급 (서명자당 15분, 카드 3장 기준)
각 서명자별, 각 카드별:
[Phase A: 카드 SE 초기화]
□ 미개봉 R3covery 카드 개봉 (봉인 상태 확인)
□ NFC 탭으로 카드 SE 응답 확인 (공장 초기 상태)
[Phase B: 카드 PIN 설정]
□ 카드별 상이 PIN 설정 (6-8자리 숫자)
□ 서명자 본인만 PIN 입력
□ PIN 봉인 봉투 에스크로 + PIN Shamir 분할(3-of-5) 수행
[Phase C: 카드 라벨링]
□ 일련번호, 발급일, 보관 위치, 서명자 식별자 기록
□ 증인 2인 확인 및 서명
기존 Step 넘버링 영향: Step 3~8이 Step 3.5~8.5로 재넘버링 되거나, Step 2.5를 Step 2 하위 절차로 통합해야 한다.
2.3. Step 3 확장: SLIP-39 옵션 통합 상세¶
변경 유형: 수정 (대폭 확장) 영향도: High 근거: [Phase 17 slip39-shamir-enterprise-design.md 2.3절]
기존 Step 3은 "금속 시드 플레이트에 24단어 니모닉 각인"으로 단일 방식만 기술한다. Phase 17 설계에 따라 3방식 옵션 선택형으로 확장해야 한다.
확장 후 구조:
| Phase | 기존 | 추가/변경 |
|---|---|---|
| Phase A: 백업 방식 결정 | 없음 (금속 시드 단독) | 추가 — 방식 1(금속 시드)/방식 2(SLIP-39)/방식 3(하이브리드) 중 선택. Phase 16 정책에 따라 방식 3 의무 |
| Phase B: SLIP-39 셰어 생성 | 없음 | 추가 — SE 내부 또는 오프라인 앱에서 GF(256) 분할, M-of-N 파라미터 설정, N개 셰어 생성 |
| Phase C: 하이브리드 금속 시드 | 기존 Step 3 전체 | 기존 절차를 Phase C로 재배치, "최후 폴백 수단" 목적 명시 |
| Phase D: 셰어 분산 보관 | 없음 | 추가 — R-01(M 집중 금지), R-02(지리적 분산), R-03(봉인 보관) 규칙 적용 |
| R3covery 카드 기록 | 없음 | 추가 — D'CENT X SE → NFC → 카드 SE로 시드/셰어 전송, SE-to-SE 암호화 채널 사용 |
소요 시간 영향: 기존 20분/서명자 → 하이브리드(방식 3) 선택 시 45분/서명자 (+25분)
2.4. PIN 설정 절차 확장 상세¶
변경 유형: 수정 영향도: Medium 근거: [Phase 16 pin-management-system-design.md 2.1~3.3절, 5.3절]
기존 Step 2의 "PIN 설정 (서명자 본인만 입력)"은 디바이스 PIN 1종만 언급한다. Phase 16 설계에 따라 PIN 3종 체계를 반영해야 한다.
확장 내용:
| PIN 유형 | 설정 시점 | 추가 절차 | Shamir 분할 |
|---|---|---|---|
| 디바이스 PIN (4-8자리) | Step 2 (기존) | 봉인 봉투 에스크로 절차 추가 | 2-of-3 (Admin 3인) |
| R3covery 카드 PIN (6-8자리) | Step 2.5 (신규) | 카드별 상이 PIN, 봉인 봉투 + Shamir | 3-of-5 (Super Admin 2 + Admin 3) |
| SLIP-39 Passphrase (12자+) | Step 3 Phase B | Passphrase 기록 및 봉인 | 분할하지 않음 (SLIP-39 자체가 분할) |
2.5. 참석자/역할 변경¶
변경 유형: 수정 영향도: Medium 근거: [Phase 17 slip39-shamir-enterprise-design.md 3.2~3.3절]
기존 참석자 역할 테이블에 다음 역할이 추가되어야 한다:
| 추가 역할 | 인원 | 책임 | 적용 조건 |
|---|---|---|---|
| 셰어 수령자 | N명 | Super Shamir 그룹별 셰어 수령 및 보관 | Super Shamir(옵션 D) 선택 시 |
| PIN Shamir 셰어 보유자 | 3-5명 | PIN 셰어 수령 및 봉인 보관 | 모든 경우 (PIN Shamir 분할 적용) |
| R3covery 카드 발급자 | 1명 (Admin) | 카드 SE 초기화, NFC 발급 진행 | R3covery 카드(옵션 B) 사용 시 |
3. disaster-recovery.md 영향도 분석¶
3.1. 변경 사항 총괄¶
| 섹션 | 변경 유형 | 변경 내용 | 영향도 | 근거 |
|---|---|---|---|---|
| 2.1 재해 시나리오 | 수정 | DS-01~DS-05에 백업 옵션별 복구 경로 매핑 추가 | High | [근거: Phase 17 backup-options-catalog.md 3.3절] |
| 2.2 시나리오 상세 | 추가 | DS-06~DS-08 신규 시나리오 3건 추가 | High | [근거: Phase 16/17 전체] |
| 3.1 RTO/RPO | 수정 | 백업 옵션별 RTO 차등 적용 | Medium | [근거: Phase 17 backup-options-catalog.md 3.3절] |
| 4.1 금속 시드 백업 | 수정 | "유일한 백업 수단" → "백업 옵션 A (하이브리드 필수 구성요소)" 위상 변경 | Medium | [근거: Phase 16 r3covery-card-technical-analysis.md 4.5절] |
| 4 키 백업 전략 | 추가 | 옵션 B(R3covery 카드), 옵션 C(SLIP-39), 옵션 D(Super Shamir) 백업 섹션 추가 | High | [근거: Phase 17 backup-options-catalog.md 2절] |
| 4.4 SSS 사용 | 수정 | "제한적 사용" → "SLIP-39 표준 기반 M-of-N 정식 백업 옵션" 격상 | Medium | [근거: Phase 17 slip39-shamir-enterprise-design.md 2절] |
| 5.2 디바이스 교체 | 수정 | 시드 복원 옵션에 R3covery 카드(NFC 탭) 경로 추가 | Medium | [근거: Phase 17 r3covery-card-lifecycle-operations.md] |
| 6 복구 드릴 | 수정 | 드릴 시나리오에 R3covery 카드 복구, SLIP-39 셰어 조립 드릴 추가 | Medium | [근거: Phase 17 r3covery-card-lifecycle-operations.md 4절] |
| 4.3 백업 무결성 검증 | 수정 | R3covery 카드 5단계 검증 절차 + SLIP-39 셰어별 체크섬 검증 추가 | Medium | [근거: Phase 17 r3covery-card-lifecycle-operations.md 4.2절] |
| 7.2 긴급 월렛 | 수정 | 긴급 월렛에 대한 별도 R3covery 카드 발급 여부 정책 명시 | Low | [근거: Phase 17 backup-options-catalog.md] |
3.2. DS-01~DS-05 백업 옵션별 복구 경로 매핑¶
기존 disaster-recovery.md는 금속 시드 백업(옵션 A)만을 전제로 복구 경로를 기술한다. Phase 17에서 4가지 백업 옵션(A/B/C/D)이 정의되었으므로, 각 시나리오별로 옵션에 따른 차등 복구 경로를 매핑해야 한다.
변경 유형: 수정 영향도: High 근거: [Phase 17 backup-options-catalog.md 3.3절, Phase 16 r3covery-card-technical-analysis.md 4.5절]
| 시나리오 | 기존 복구 경로 | 옵션 A 경로 | 옵션 B 경로 | 옵션 C 경로 | 옵션 D 경로 |
|---|---|---|---|---|---|
| DS-01: 디바이스 장애 | 백업 디바이스에 시드 복원 | 금속 시드 → 백업 디바이스 입력 (RTO 4h) | R3covery 카드 NFC → 백업 디바이스 복원 (RTO 2h) | SLIP-39 M개 셰어 수집 → 시드 재조립 → 입력 (RTO 8h) | 그룹별 셰어 수집 → 2단계 재조립 (RTO 12h) |
| DS-02: 사이트 재해 | 원격 사이트 백업에서 복구 | Site B/C 금속 시드 반출 (RTO 24h) | 분산 보관 카드 반출 (RTO 24h) | 분산 셰어 M개 수집 (RTO 24-48h) | 다수 사이트 셰어 수집 (RTO 48h+) |
| DS-03: 서명자 비가용 | 대체 서명자 + 시드 복원 | 변경 없음 | 변경 없음 (카드 PIN Shamir 복원으로 카드 접근) | 변경 없음 (셰어는 역할별 보관) | Super Shamir 그룹 재구성 필요 시 키 세레모니 |
| DS-04: 소프트웨어 장애 | 서버 백업 복원 | 변경 없음 | 변경 없음 | 변경 없음 | 변경 없음 |
| DS-05: 보안 침해 | 긴급 자산 이전 → 새 키 생성 | 금속 시드 폐기 + 재생성 | 카드 SE WIPED + 새 카드 발급 | 전체 셰어 폐기 + 재분할 | 전 그룹 셰어 폐기 + 재구성 |
3.3. 신규 재해 시나리오 추가¶
Phase 16-17에서 도입한 백업 옵션들이 자체적으로 새로운 장애 시나리오를 생성한다. 기존 DS-01~DS-05에 포함되지 않는 3건의 신규 시나리오를 추가해야 한다.
변경 유형: 추가 영향도: High 근거: [Phase 16 r3covery-card-technical-analysis.md 3.3절, Phase 16 pin-management-system-design.md 6.3절, Phase 17 slip39-shamir-enterprise-design.md 2.6절]
DS-06: R3covery 카드 고장/접근 불가 (신규)¶
| 항목 | 설명 |
|---|---|
| 원인 | NFC 안테나 단선, SE 칩 고장, 카드 소재 변형, PIN LOCKED→WIPED 전이 |
| 영향 | 해당 카드의 시드/셰어 접근 불가 |
| 긴급도 | 중간 (다중 카드 발급 + 하이브리드 백업으로 폴백 가능) |
| 복구 방법 | (1) 다른 R3covery 카드로 복구, (2) 금속 시드 폴백, (3) SLIP-39 셰어 재조립 |
| RTO | 4시간 (다중 카드 즉시 사용) ~ 24시간 (금속 시드 반출) |
| RPO | 0 (다른 매체에 동일 시드 존재) |
DS-07: SLIP-39 셰어 M개 미만 확보 (신규)¶
| 항목 | 설명 |
|---|---|
| 원인 | 셰어 보관 매체 파손/분실, 셰어 보유자 다수 동시 비가용 |
| 영향 | SLIP-39 복구 불가 → 다른 백업 옵션 폴백 필요 |
| 긴급도 | 중간 (하이브리드 백업 의무화로 폴백 보장) |
| 복구 방법 | (1) R3covery 카드 복구, (2) 금속 시드 복구, (3) 잔여 셰어 + 보험 가능 시 협상 |
| RTO | 2시간 (R3covery 카드) ~ 24시간 (금속 시드) |
| RPO | 0 |
DS-08: PIN 3종 동시 분실/잠금 (신규)¶
| 항목 | 설명 |
|---|---|
| 원인 | PIN 봉인 봉투 변조/분실, Shamir 셰어 보유자 M명 미만 가용, PUK 미지원 |
| 영향 | 디바이스 및 R3covery 카드 접근 불가 |
| 긴급도 | 높음 (모든 전자적 복구 경로 차단) |
| 복구 방법 | PIN 분실 3단계 폴백 절차: Level 1(Shamir 셰어 복원) → Level 2(봉인 봉투 에스크로) → Level 3(금속 시드/SLIP-39 전체 재구축) |
| RTO | 4-48시간 (폴백 레벨에 따라 차등) |
| RPO | 0 (시드 자체는 안전) |
3.4. RTO/RPO 변경 영향¶
변경 유형: 수정 영향도: Medium 근거: [Phase 17 backup-options-catalog.md 3.3절]
기존 RTO 정의는 금속 시드(옵션 A) 기준이다. 백업 옵션에 따라 RTO가 크게 달라지므로, 시나리오별 RTO를 백업 옵션별로 차등 표기해야 한다.
| 시나리오 | 기존 RTO | 옵션 B 적용 시 RTO | 옵션 C 적용 시 RTO | 비고 |
|---|---|---|---|---|
| DS-01 | 4시간 | 2시간 (NFC 탭 복원) | 8시간 (셰어 M개 수집) | 옵션 B가 최단 복구 시간 |
| DS-02 | 24시간 | 24시간 (동일) | 24-48시간 (분산 셰어 수집) | 옵션 C는 분산도가 높아 수집 시간 증가 |
| DS-05 | 1시간 (긴급 이전 시작) | 1시간 (동일) | 1시간 (동일) | 자산 이전은 백업 방식과 무관 |
3.5. 하이브리드 의무화에 따른 다중 복구 경로 보장¶
변경 유형: 수정 영향도: Medium 근거: [Phase 16 r3covery-card-technical-analysis.md 4.5절]
기존 disaster-recovery.md는 "금속 시드 + 지리적 분산"을 유일한 백업 전략으로 기술한다. Phase 16의 하이브리드 의무화 결정에 따라, 복구 경로가 단일 경로에서 다중 경로로 전환된다.
다중 복구 경로 보장 원칙 (신규 섹션):
복구 경로 우선순위:
경로 1 (최우선): R3covery 카드 NFC 복원
- 조건: 카드 물리적 접근 가능 + PIN 또는 PIN Shamir 복원 가능
- RTO: 2시간 이내
- 장점: 니모닉 비노출, 빠른 복구
경로 2 (차선): SLIP-39 셰어 재조립
- 조건: M개 이상 셰어 수집 가능
- RTO: 8시간 이내
- 장점: 분산 보관, 부분 유출 안전
경로 3 (최후): 금속 시드 직접 복원
- 조건: 금속 시드 물리적 접근 가능
- RTO: 4-24시간
- 장점: 벤더 독립, 기술 의존성 제로
4. self-custody-architecture.md 영향도 분석¶
4.1. 변경 사항 총괄¶
| 섹션 | 변경 유형 | 변경 내용 | 영향도 | 근거 |
|---|---|---|---|---|
| 2.1 키 생성 및 저장 | 수정 | 키 라이프사이클에 R3covery 카드 경유 백업 경로 추가 | Medium | [근거: Phase 17 r3covery-card-lifecycle-operations.md 2.3절] |
| 2.4 키 백업 벤더 독립성 | 수정 (대폭) | 벤더 독립성 검증 매트릭스에 옵션 B/C/D 행 추가, R3covery 카드 벤더 종속 위험 명시 | High | [근거: Phase 16 r3covery-card-technical-analysis.md 4.1~4.5절] |
| 2.3 D'CENT 서비스 중단 시나리오 | 수정 | R3covery 카드 전용 복구 불가 시나리오 추가 + 하이브리드 의무화로 완화 설명 | Medium | [근거: Phase 16 r3covery-card-technical-analysis.md 4.2절] |
| 3.1 오픈 표준 목록 | 추가 | SLIP-39(SatoshiLabs) 표준 추가 | Medium | [근거: Phase 17 slip39-shamir-enterprise-design.md 2.1절] |
| 4.1 벤더 독립성 검증 매트릭스 | 추가 | 질문 11-14 신규 추가 (R3covery 카드 독립성, SLIP-39 호환성 등) | Medium | [근거: Phase 16 r3covery-card-technical-analysis.md 4.1절] |
| 4.2 벤더 독립성 등급 | 수정 | L2 등급 설명에 R3covery 카드 벤더 종속 요소 + 하이브리드 완화 설명 추가 | Low | [근거: Phase 16 r3covery-card-technical-analysis.md 4.5절] |
| 5.4 D'CENT 완전 독립 구조 | 수정 | 벤더 종속도 분석 바 차트에 "백업 복구" 항목 신규 추가 | Medium | [근거: Phase 16 r3covery-card-technical-analysis.md 4.4절] |
| DFD / 3-Zone 아키텍처 | 수정 | Zone 3에 R3covery 카드 SE 컴포넌트 추가, NFC 채널 명시 | Medium | [근거: Phase 16 r3covery-card-technical-analysis.md 2.3절] |
4.2. 3-Zone 보안 아키텍처 확장¶
변경 유형: 수정 영향도: Medium 근거: [Phase 16 r3covery-card-technical-analysis.md 2.3절, Phase 17 r3covery-card-lifecycle-operations.md]
기존 3-Zone 아키텍처는 Zone 3(D'CENT X 콜드월렛 SE)만 포함한다. R3covery 카드 SE는 별도의 보안 컴포넌트로서 Zone 3에 추가되어야 한다.
Zone 3 확장:
Zone 3: 에어갭 하드웨어 보안 영역 (기존 + 확장)
기존:
├─ D'CENT X 본체 SE (키 생성, 저장, 서명)
├─ 물리 버튼 (WYSIWYS 승인)
└─ 디스플레이 (TX 정보 표시)
추가 (Phase 16-17):
├─ R3covery 카드 SE (시드/셰어 암호화 저장) [신규]
├─ NFC SE-to-SE 채널 (본체 ↔ 카드 통신) [신규]
└─ 카드 PIN 인증 (카드 SE 내부) [신규]
NFC 통신 채널 보안: - 본체 SE ↔ 카드 SE: ECDH 키 교환 + AES-128-CCM 세션 암호화 - Trust Boundary TB-4의 하위 경계(TB-4a)로 분류 가능 - 에어갭 원칙 유지: NFC는 근거리(~10cm) 물리적 통신이며, 네트워크 연결 없음
4.3. 에어갭 원칙 준수 검증¶
변경 유형: 수정 (검증 항목 추가) 영향도: Medium 근거: [Phase 17 slip39-shamir-enterprise-design.md 2.4~5절]
Phase 17에서 "SE 내부 SLIP-39 처리 불가 시 오프라인 앱에서 처리"를 보수적 기본안으로 설계했다. 오프라인 앱에서 SLIP-39 셰어를 생성/재조립하는 과정에서 시드가 앱 메모리에 일시 존재한다.
에어갭 준수 평가:
| 처리 위치 | 시드 노출 여부 | 에어갭 준수 | 비고 |
|---|---|---|---|
| SE 내부 SLIP-39 처리 | 시드 SE 외부 미노출 | 완전 준수 | 이상적이나 HW-CONFIRM 필요 |
| 오프라인 앱 SLIP-39 처리 | 시드가 앱 메모리에 일시 존재 | 조건부 준수 | 앱이 에어갭 디바이스에서 실행되면 네트워크 노출 없음 |
| 온라인 앱 처리 | 시드가 네트워크 연결 기기에 존재 | 위반 | 금지 |
결론: 오프라인 앱 처리는 "에어갭 디바이스(네트워크 완전 차단된 전용 기기)에서만 실행" 조건 하에 에어갭 원칙을 준수한다. self-custody-architecture.md에 이 조건을 명시적으로 추가해야 한다.
4.4. RBAC 역할 모델 확장¶
변경 유형: 수정 영향도: Medium 근거: [Phase 17 slip39-shamir-enterprise-design.md 3.2~3.3절]
기존 RBAC 역할(Super Admin/Admin/Approver/Viewer/Auditor)에 Super Shamir 그룹별 역할 매핑이 추가된다.
| RBAC 역할 | 기존 백업 책임 | 추가 백업 책임 (Phase 17) |
|---|---|---|
| Super Admin | 백업 정책 결정, 금고 접근 승인 | Super Shamir 그룹 1(경영진) 셰어 보유, PIN Shamir 셰어 보유 |
| Admin | 키 세레모니 진행, 백업 검증 | Super Shamir 그룹 2(운영팀) 셰어 보유, R3covery 카드 발급/폐기 진행 |
| Approver | 자신의 키 백업 관리 | Super Shamir 그룹 3(서명자) 셰어 보유, 자신의 R3covery 카드 PIN 관리 |
4.5. 키 백업 벤더 독립성 검증 확장¶
변경 유형: 수정 (대폭) 영향도: High 근거: [Phase 16 r3covery-card-technical-analysis.md 4.1~4.4절]
기존 섹션 2.4의 백업 방식 벤더 독립성 테이블(금속 시드/SSS/멀티시그 3행)을 4가지 백업 옵션으로 확장해야 한다.
| 백업 방식 | 벤더 독립 | 근거 | 변경 사항 |
|---|---|---|---|
| A: 금속 시드 | 완전 독립 | BIP-39 표준 → 모든 호환 월렛 복구 가능 | 변경 없음 |
| B: R3covery 카드 | 부분 독립 (벤더 종속 위험) | D'CENT 독점 포맷 → D'CENT 소프트웨어 없이 복원 불가 | 신규 추가 |
| C: SLIP-39 Shamir | 높은 독립성 | SLIP-39 = SatoshiLabs 오픈 표준 → Trezor 등 호환 | SSS → SLIP-39 표준으로 격상 |
| D: Super Shamir | 높은 독립성 | SLIP-39 Advanced 표준 | 신규 추가 |
R3covery 카드 벤더 종속 완화 방안 (Phase 16 결정 반영): 1. 하이브리드 백업 의무화: 옵션 B 단독 사용 금지 → 옵션 A 또는 C와 반드시 병행 2. 사양서 에스크로: 대형 고객 대상 APDU 커맨드 시퀀스 및 데이터 포맷 사양서를 제3자 에스크로 기관에 보관
4.6. 벤더 독립성 검증 매트릭스 신규 질문¶
변경 유형: 추가 영향도: Medium 근거: [Phase 16 r3covery-card-technical-analysis.md 4.1~4.2절]
기존 10개 검증 질문에 4개를 추가해야 한다:
| # | 검증 질문 | 답변 | 근거 |
|---|---|---|---|
| 11 | D'CENT 없이 R3covery 카드에서 시드 복원 가능한가? | 불가 (조건부 가능) | D'CENT 전용 포맷이나, 에스크로 사양서 보유 시 복원 도구 제작 가능 |
| 12 | D'CENT 없이 SLIP-39 셰어를 재조립할 수 있는가? | 가능 | SLIP-39는 오픈 표준 — python-shamir, Trezor Suite 등으로 재조립 가능 |
| 13 | Super Shamir 그룹 구조가 D'CENT 독점인가? | 아니오 | SLIP-39 Advanced 표준의 일부 — 호환 구현체에서 재조립 가능 |
| 14 | R3covery 카드 PIN이 D'CENT 독점 인증인가? | 예 | 카드 SE 내부 PIN 검증은 D'CENT 앱릿 의존 → 에스크로로 완화 |
5. 통합 변경 사항 요약표¶
5.1. 문서별 변경 항목 수 및 영향도 분포¶
| 문서 | 총 변경 항목 | High | Medium | Low | 추가 | 수정 | 삭제 |
|---|---|---|---|---|---|---|---|
| key-ceremony.md | 11 | 2 | 7 | 2 | 1 (Step 2.5) | 10 | 0 |
| disaster-recovery.md | 10 | 3 | 6 | 1 | 4 (DS-06~08, 다중 복구 경로) | 6 | 0 |
| self-custody-architecture.md | 8 | 1 | 6 | 1 | 2 (질문 11-14, Zone 3 확장) | 6 | 0 |
| 합계 | 29 | 6 | 19 | 4 | 7 | 22 | 0 |
5.2. 변경 규모 평가¶
- 전체 29건 중 삭제 항목은 0건 — 기존 설계를 제거하지 않고 확장하는 방향
- High 영향도 6건: Step 2.5 신규 삽입, Step 3 대폭 확장, DS-01~05 복구 경로 매핑, DS-06~08 신규 시나리오, 백업 전략 섹션 추가, 벤더 독립성 매트릭스 확장
- 수정 22건: 대부분 기존 내용의 범위를 확장하는 형태 (예: 단일 방식 → 다중 방식)
6. 교차 영향 분석¶
6.1. 3개 문서 간 연쇄 변경¶
Phase 16-17 설계 변경은 3개 문서에 상호 연쇄적 영향을 미친다. 한 문서의 변경이 다른 문서의 변경을 요구하는 관계를 식별한다.
| 변경 원인 | 1차 영향 문서 | 연쇄 영향 문서 | 연쇄 변경 내용 |
|---|---|---|---|
| Step 2.5 신규 삽입 (key-ceremony) | key-ceremony.md | disaster-recovery.md | DS-06(카드 고장) 시 카드 재발급 절차가 키 세레모니 Step 2.5를 참조해야 함 |
| Step 3 SLIP-39 확장 (key-ceremony) | key-ceremony.md | disaster-recovery.md | 복구 드릴에 SLIP-39 셰어 재조립 시나리오 추가 필요 |
| DS-06~08 신규 시나리오 (disaster-recovery) | disaster-recovery.md | key-ceremony.md | 긴급 복구 세레모니(5절)에 DS-06~08 대응 절차 추가 |
| R3covery 카드 벤더 종속 (self-custody) | self-custody-architecture.md | disaster-recovery.md | DS-06 복구 경로에서 벤더 종속 시나리오(D'CENT 사업 중단 + 카드만 보유) 언급 |
| 에어갭 준수 검증 (self-custody) | self-custody-architecture.md | key-ceremony.md | Step 3 SLIP-39 처리 시 "에어갭 전용 디바이스" 조건 명시 |
| 다중 복구 경로 (disaster-recovery) | disaster-recovery.md | self-custody-architecture.md | 벤더 독립성 등급 평가에 "다중 복구 경로 보장" 근거 반영 |
6.2. 연쇄 변경 패턴¶
Phase 16-17 설계 결정
│
├─▶ key-ceremony.md 변경 (Step 2.5, Step 3 확장)
│ │
│ └─▶ disaster-recovery.md 연쇄 변경 (DS-06 참조, 드릴 시나리오)
│
├─▶ disaster-recovery.md 변경 (DS-06~08, 복구 경로 매핑)
│ │
│ ├─▶ key-ceremony.md 연쇄 변경 (긴급 복구 세레모니)
│ └─▶ self-custody-architecture.md 연쇄 변경 (다중 경로 벤더 독립성)
│
└─▶ self-custody-architecture.md 변경 (Zone 3 확장, 벤더 독립성)
│
└─▶ key-ceremony.md 연쇄 변경 (에어갭 조건 명시)
결론: 3개 문서는 상호 참조 관계가 밀접하여, 1개 문서만 업데이트하면 나머지 2개 문서와의 불일치가 발생한다. 반드시 3개 문서를 동시에 업데이트해야 한다.
7. 후속 작업 권장사항¶
7.1. 문서 업데이트 우선순위¶
| 우선순위 | 문서 | 핵심 변경 | 예상 작업량 | 근거 |
|---|---|---|---|---|
| 1 (최우선) | key-ceremony.md | Step 2.5 삽입, Step 3 확장, PIN 절차 확장 | 대규모 (기존 문서 50%+ 변경) | 키 세레모니는 다른 모든 문서의 기초 절차 |
| 2 | disaster-recovery.md | DS-06~08 추가, 복구 경로 매핑, RTO 재산정 | 대규모 (신규 시나리오 3건 + 기존 5건 매핑) | 복구 절차가 키 세레모니 변경에 직접 의존 |
| 3 | self-custody-architecture.md | Zone 3 확장, 벤더 독립성 매트릭스 갱신 | 중규모 (기존 프레임워크에 항목 추가) | 아키텍처 변경은 상위 수준이므로 상세 절차 후 정리 |
7.2. 업데이트 시 주의사항¶
- 3개 문서 동시 업데이트 필수: 교차 영향 분석(6절) 결과, 순차 업데이트 시 불일치 위험. 동일 마일스톤 내 동시 수정 권장
- 기존 Step 넘버링 결정 필요: Step 2.5 삽입 시 후속 Step 번호 재지정 방식 결정 (2.5/3/4... vs 2/2a/3...)
- HW-CONFIRM 항목 반영: Phase 16 HW-CONFIRM-R01~R05 + Phase 17 HW-CONFIRM-R06~R08 결과에 따라 추가 변경 발생 가능
- 컴플라이언스 매핑 갱신: 각 문서 말미의 컴플라이언스 매핑 테이블에 새로운 AC-ID 대응 항목 추가 필요
- cross-reference 무결성: 문서 간 참조 경로(예: "disaster-recovery.md 참조", "key-ceremony.md 긴급 모드 참조")가 변경 후에도 유효한지 검증
7.3. 변경 이력 추적 참조¶
본 분석서의 모든 변경 항목은 Phase 16-17 산출물로 역추적 가능하다:
| 약칭 | 전체 경로 |
|---|---|
| Phase 16 R3C | deliverables/minho-16-r3covery-card-pin-management/r3covery-card-technical-analysis.md |
| Phase 16 PIN | deliverables/minho-16-r3covery-card-pin-management/pin-management-system-design.md |
| Phase 17 SSS | deliverables/minho-17-backup-catalog-operations/slip39-shamir-enterprise-design.md |
| Phase 17 R3C-LC | deliverables/minho-17-backup-catalog-operations/r3covery-card-lifecycle-operations.md |
| Phase 17 CAT | deliverables/minho-17-backup-catalog-operations/backup-options-catalog.md |
본 문서는 Phase 18 기존 설계 영향도 분석의 일부로, Phase 16-17 백업 옵션 체계가 기존 v0.0 핵심 설계 문서 3종에 미치는 변경 사항을 도출한다. Part B(STRIDE 위협 모델 업데이트 및 펌웨어 요구사항)는 threat-model-firmware-impact-analysis.md에서 다룬다.
관련 문서¶
- STRIDE 위협 모델 업데이트 및 펌웨어 요구사항 추가 도출 -- 제품 설계