v0.3

STRIDE 위협 모델 업데이트 및 펌웨어 요구사항 추가 도출¶

Part A: STRIDE 위협 모델 업데이트 (IMP-02)¶

1. 분석 개요¶

1.1. 공격 표면 확대 요약¶

Phase 16-17에서 도입한 백업 옵션 체계(R3covery 카드 다중 발급, SLIP-39/Super Shamir, 하이브리드 의무화)는 기존 위협 모델의 공격 표면을 확장한다.

신규 공격 표면:

공격 표면	도입 원인	STRIDE 범주	위험 수준
R3covery 카드 NFC 통신 채널	R3covery 카드 다중 발급 (Phase 16)	S, T, I	Medium
R3covery 카드 PIN 인증	카드 SE 내부 PIN 검증 (Phase 16)	S, I, E	Medium
PIN 봉인 봉투/Shamir 셰어	PIN 분리 보관 체계 (Phase 16)	T, I	Medium
SLIP-39 셰어 물리 매체	SLIP-39 M-of-N 분산 백업 (Phase 17)	I, D	Low-Medium
Super Shamir 그룹 구조	다중 그룹 임계값 (Phase 17)	E	Low
오프라인 앱 SLIP-39 처리	SE 미지원 시 앱 처리 (Phase 17)	I, T	Medium

1.2. STRIDE 6개 범주별 신규 위협 스크리닝¶

STRIDE 범주	신규 위협 수	주요 위협
Spoofing	2	가짜 R3covery 카드 삽입, 가짜 SLIP-39 셰어 주입
Tampering	3	PIN 봉인 봉투 조작, NFC 데이터 변조, 셰어 매체 변조
Repudiation	1	R3covery 카드 발급/폐기 부인
Information Disclosure	4	NFC 도청, PIN 셰어 수집, SLIP-39 셰어 노출, 앱 메모리 잔류
Denial of Service	2	카드 NFC 재밍, 셰어 파괴로 M 미달
Elevation of Privilege	2	PIN Shamir 셰어 공모, Super Shamir 그룹 간 공모

2. RR-06 확장 분석¶

2.1. 현행 RR-06 내용 요약¶

기존 stride-threat-model.md 섹션 7.1의 RR-06:

RR-06: 금속 시드 백업 물리적 탈취 — 위험도 MEDIUM. 지리적 분산(2+ 위치), 금고 보관, 접근 통제로 완화.

현행 RR-06은 금속 시드(옵션 A)만을 대상으로 단일 위험으로 기술하고 있다. Phase 16-17에서 3가지 백업 옵션(B/C/D)이 추가되었으므로, RR-06을 하위 항목으로 세분화하여 백업 방식별 차등 위험 평가가 필요하다.

2.2. RR-06a: 금속 시드(옵션 A) 위협¶

항목	내용
위협 시나리오	(1) 금고 침입에 의한 금속 시드 물리적 탈취, (2) 내부자에 의한 시드 사본 생성(사진/필기), (3) 자연재해로 인한 물리적 소실
공격 난이도	중간 — 금고 물리 보안 돌파 필요하나, 시드가 평문이므로 탈취 즉시 사용 가능
영향도	Critical — 24단어 확보 = 전체 시드 즉시 복원 가능, 자산 탈취
현재 완화 조치	지리적 분산(2+ 사이트), 내화금고(UL-350), 접근 통제(RBAC + CCTV), 봉인 봉투(변조 탐지)
Phase 16-17 변경 영향	하이브리드 의무화로 금속 시드가 "유일한 수단"에서 "최후 폴백"으로 위상 변경 → 접근 빈도 감소 → 노출 위험 감소
잔여 위험	MEDIUM (기존 유지) — 평문 노출 근본 한계는 존재하나, 접근 빈도 감소로 실질 위험 소폭 완화
근거	[Phase 16 r3covery-card-technical-analysis.md 4.5절, Phase 17 backup-options-catalog.md 2절 옵션 A]

2.3. RR-06b: R3covery 카드(옵션 B) 위협¶

항목	내용
위협 시나리오	(1) NFC 도청에 의한 SE-to-SE 통신 데이터 가로채기, (2) SE 사이드채널 공격(DPA/SPA)으로 암호화 키 추출, (3) 가짜 R3covery 카드로 교체(Spoofing), (4) PIN 무차별 대입(5회 제한[HW-CONFIRM-R03]으로 방어)
공격 난이도	높음 — SE 하드웨어 보안(EAL5+) 돌파 필요, NFC 도청은 근거리(~10cm) 물리 접근 + 세션 암호화(AES-128-CCM) 해독 필요
영향도	High — 카드 SE 돌파 시 시드 노출. 단, PIN 보호 + 다중 카드 발급으로 단일 카드 침해의 실질 영향은 제한적
현재 완화 조치	SE-to-SE 상호 인증(ECDH), AES-128-CCM 세션 암호화, PIN 시도 횟수 제한(5회), EAL5+/6+ SE 사이드채널 방어, 카드별 상이 PIN
Phase 16-17 신규 완화	다중 카드 발급(3장 권장)으로 공격 대상 분산, 하이브리드 의무화로 카드 단독 의존 제거
잔여 위험	LOW — SE 하드웨어 보안 + PIN 보호 + 다중 카드 + 하이브리드 의무화
근거	[Phase 16 r3covery-card-technical-analysis.md 2.2~2.4절, Phase 17 r3covery-card-lifecycle-operations.md]

2.4. RR-06c: SLIP-39/Super Shamir(옵션 C/D) 위협¶

항목	내용
위협 시나리오	(1) 셰어 수집 공격 — M개 이상 셰어를 점진적으로 확보, (2) 임계값 미달 DoS — 셰어 (N-M+1)개 이상을 파괴하여 복원 불가 유도, (3) GF(256) 구현 취약점 — 오프라인 앱의 SLIP-39 라이브러리 버그로 잘못된 셰어 생성/복원, (4) 셰어 봉인 봉투 조작으로 셰어 교체
공격 난이도	높음 — M개 셰어 수집은 다수 보관 위치 물리 침입 필요 (지리적 분산 30km+), 수학적 공격은 정보 이론적으로 불가
영향도	Critical (수집 성공 시) — M개 셰어 확보 = 시드 재구성 가능. 그러나 수집 난이도가 매우 높음
현재 완화 조치	M 집중 금지(R-01), 지리적 분산(R-02), 봉인 보관(R-03), 셰어 정기 검증(R-04)
Super Shamir 추가 완화	2단계 임계값 구조로 단일 그룹 내 공모만으로는 복원 불가, 최소 2개 그룹의 임계값 동시 충족 필요
잔여 위험	LOW — 수학적 보안(정보 이론적) + 물리적 분산 + 다중 임계값
근거	[Phase 17 slip39-shamir-enterprise-design.md 2.6절, 3.1~3.3절, Phase 17 backup-options-catalog.md 3.5절]

2.5. RR-06 위험 등급 재평가 요약¶

하위 항목	백업 옵션	기존 등급	재평가 등급	변경 근거
RR-06a	A (금속 시드)	MEDIUM	MEDIUM (유지)	평문 노출 근본 한계 불변. 접근 빈도 감소로 소폭 완화되나 등급 변경 불충분
RR-06b	B (R3covery 카드)	N/A (신규)	LOW	SE 암호화 + PIN + 다중 카드 + 하이브리드 의무화
RR-06c	C/D (SLIP-39/Super Shamir)	N/A (신규)	LOW	수학적 보안 + 물리적 분산 + 다중 임계값
RR-06 통합	하이브리드 조합	MEDIUM	LOW (하향 가능)	다중 백업 경로 + 옵션별 상호 보완으로 통합 잔여 위험 감소

3. 신규 위협 항목 도출¶

3.1. TH-PIN-01: PIN 봉인 봉투 조작/탈취¶

항목	내용
위협 ID	TH-PIN-01
STRIDE 범주	Tampering + Information Disclosure
위협 시나리오	공격자가 PIN 봉인 봉투에 물리적으로 접근하여: (1) 봉투를 정교하게 개봉 → PIN 확인 → 재봉인(위조), (2) 봉투를 탈취하여 PIN 확보
사전 조건	금고 물리 접근 권한 또는 내부자 공모
영향도	High — PIN 확보 시 디바이스/R3covery 카드 접근 가능 (단, 디바이스/카드도 별도 탈취 필요)
가능성	Low (금고 접근 통제, CCTV, 듀얼 컨트롤)
위험 등급	MEDIUM
완화 조치	(1) 변조 방지 봉투(VOID 패턴) 사용, (2) 봉인 일련번호 대조 검증, (3) 정기 봉인 무결성 점검(분기별), (4) PIN Shamir 분할로 봉투 1개 탈취 시에도 원본 PIN 미복원, (5) 카드-PIN 분리 보관 원칙
잔여 위험	LOW — Shamir 분할 + 분리 보관으로 단일 봉투 탈취의 실질 가치 제로
근거	[Phase 16 pin-management-system-design.md 4.1~4.2절]

3.2. TH-PIN-02: PIN Shamir 셰어 수집 공모¶

항목	내용
위협 ID	TH-PIN-02
STRIDE 범주	Elevation of Privilege
위협 시나리오	PIN Shamir 셰어 보유자 M명이 공모하여: (1) 각자 셰어를 수집 → PIN 복원, (2) 복원된 PIN으로 디바이스/R3covery 카드 접근
사전 조건	디바이스 PIN: Admin 2명 공모 (2-of-3), R3covery 카드 PIN: Super Admin 1명 + Admin 2명 공모 (3-of-5)
영향도	High — PIN + 디바이스/카드 동시 확보 시 시드 접근 가능
가능성	Low (디바이스 PIN) / Very Low (R3covery 카드 PIN — Super Admin 포함 3명 공모 필요)
위험 등급	MEDIUM (디바이스 PIN) / LOW (R3covery 카드 PIN)
완화 조치	(1) Super Admin과 Admin 혼합 분배(역할 분리), (2) 셰어 보유자 정기 배경 조사, (3) 감사 로그로 셰어 접근 시도 추적, (4) 디바이스/카드도 별도 물리 보관이므로 PIN만으로는 불충분
잔여 위험	LOW — PIN + 디바이스/카드 동시 확보 필요, M-of-N 다중 서명과 조합하면 추가 방어
근거	[Phase 16 pin-management-system-design.md 5.5절]

3.3. TH-NFC-01: R3covery 카드 NFC 도청/중간자 공격¶

항목	내용
위협 ID	TH-NFC-01
STRIDE 범주	Information Disclosure + Spoofing
위협 시나리오	(1) NFC 통신 도청: 본체 SE ↔ 카드 SE NFC 통신을 근거리 안테나로 가로채기, (2) 중간자 공격: NFC 프록시 디바이스로 통신 중계 및 데이터 조작
사전 조건	키 세레모니 또는 복구 시 물리적 근접 (NFC 도청 거리 ~1-3m, 중간자는 ~10cm 이내)
영향도	High — 시드 암호문 가로채기 시 오프라인 복호화 시도 가능 (AES-256-GCM 돌파 필요)
가능성	Very Low (세션 암호화 + 물리 접근 제한 + 콜드룸 환경)
위험 등급	LOW
완화 조치	(1) ECDH 세션 키 교환 → 도청 시 세션 키 미확보, (2) AES-128-CCM 세션 암호화 → 암호문만 도청, (3) 콜드룸(Faraday cage) 환경에서 NFC 통신 수행, (4) SE-to-SE 상호 인증으로 가짜 디바이스 탐지
잔여 위험	VERY LOW — ECDH + AES 세션 암호화가 도청을 무력화
근거	[Phase 16 r3covery-card-technical-analysis.md 2.3절]

3.4. TH-NFC-02: R3covery 카드 NFC 릴레이 공격¶

항목	내용
위협 ID	TH-NFC-02
STRIDE 범주	Spoofing
위협 시나리오	NFC 릴레이 디바이스 2대를 사용하여 본체와 카드 사이의 NFC 통신을 원격 중계. 공격자가 카드 근처와 본체 근처에 각각 릴레이를 배치하여 원격에서 카드 데이터 접근 시도
사전 조건	카드 보관 위치에 릴레이 디바이스 설치 + 본체 디바이스 접근
영향도	Medium — 릴레이 성공 시 원격에서 카드 SE와 통신 가능 (PIN 필요)
가능성	Very Low (금고 내 릴레이 설치 어려움, NFC 세션 타임아웃으로 릴레이 지연 탐지)
위험 등급	LOW
완화 조치	(1) NFC 세션 타임아웃 (~500ms) — 릴레이 왕복 지연으로 타임아웃 가능, (2) SE-to-SE 상호 인증 — 릴레이는 인증 자체를 중계하지만 PIN은 본체 측에서 입력 필요, (3) 물리 보안 — 금고 내 전자장비 반입 통제, (4) 거리 제한 검증(distance bounding) 프로토콜 적용 검토
잔여 위험	VERY LOW — 실현 가능성 극히 낮음
근거	[Phase 16 r3covery-card-technical-analysis.md 2.3절, 기존 stride-threat-model.md 5.6절 NFC 릴레이 분석 확장]

3.5. TH-SSS-01: SLIP-39 셰어 보관소 침해¶

항목	내용
위협 ID	TH-SSS-01
STRIDE 범주	Information Disclosure
위협 시나리오	공격자가 SLIP-39 셰어 보관 위치(금고, 은행 안전금고, 법률사무소 등)에 침입하여 셰어 매체(금속 플레이트 또는 R3covery 카드)를 탈취. M개 이상 셰어 확보 시 시드 재구성 가능
사전 조건	M개 이상 보관 위치에 동시 또는 순차 침입
영향도	Critical — M개 셰어 확보 = 시드 노출
가능성	Very Low (지리적 분산 30km+, 각 보관소 독립 보안, M 집중 금지 규칙)
위험 등급	LOW
완화 조치	(1) R-01: 동일 위치에 M개 이상 셰어 집중 금지, (2) R-02: 최소 2개, 권장 3개 이상 물리적 위치 분산(30km+), (3) R-03: 개별 봉인 봉투 + 변조 탐지, (4) 정기 봉인 무결성 점검, (5) 셰어가 R3covery 카드에 저장된 경우 PIN 보호 추가
잔여 위험	VERY LOW — 다수 보관소 동시 침해는 국가급 공격자 수준
근거	[Phase 17 slip39-shamir-enterprise-design.md 2.6절]

3.6. TH-SSS-02: Super Shamir 그룹 간 공모¶

항목	내용
위협 ID	TH-SSS-02
STRIDE 범주	Elevation of Privilege
위협 시나리오	Super Shamir 구조에서 2개 이상 그룹의 임계값을 각각 충족시키는 내부자 공모. 예: 3그룹 구성(경영진 2-of-3 + 운영팀 2-of-3 + 서명자 3-of-5), 전체 2-of-3 시 경영진 2명 + 운영팀 2명 = 4명 공모로 시드 복원
사전 조건	최소 4명의 다른 역할 그룹 구성원이 동시 공모
영향도	Critical — 시드 복원 = 자산 접근 가능
가능성	Very Low (4명 이상, 다른 역할 그룹, 경영진 포함 공모 — 조직적 내부 통제로 억제)
위험 등급	LOW
완화 조치	(1) 그룹 간 역할 분리 (경영진/운영팀/서명자), (2) 각 그룹 구성원 독립 배경 조사, (3) 셰어 접근 감사 로그, (4) 정기 셰어 재분할로 셰어 무효화, (5) 기본 Shamir(C) 대비 추가 공모 인원 필요(3명 → 4명+)
잔여 위험	VERY LOW — 기술적 완전 방어 한계이나, 운영 통제(배경 조사, 감사, 역할 분리)로 보완
근거	[Phase 17 slip39-shamir-enterprise-design.md 3.3절]

4. 위협 간 상호작용 분석¶

4.1. 복합 공격 시나리오¶

단일 위협만으로는 위험이 낮으나, 복수 위협을 조합하면 공격 성공 가능성이 높아지는 시나리오를 식별한다.

시나리오 1: PIN 셰어 수집 + 카드 물리 탈취

항목	내용
조합	TH-PIN-02 (PIN 셰어 수집) + 카드 물리 탈취
공격 경로	(1) R3covery 카드 PIN Shamir 셰어 3-of-5 중 3개 수집 → PIN 복원, (2) R3covery 카드 물리 탈취, (3) 복원된 PIN으로 카드 SE 접근 → 시드 복호화
필요 조건	3명 공모 (셰어 수집) + 카드 보관 금고 침입 (물리 탈취)
실현 가능성	Very Low — 내부 공모 + 외부 침입 동시 필요
추가 완화	카드-PIN 분리 보관 원칙이 이 복합 공격의 핵심 방어선
근거	[Phase 16 pin-management-system-design.md 4.1절 + 5.5절]

시나리오 2: NFC 도청 + PIN 봉인 봉투 탈취

항목	내용
조합	TH-NFC-01 (NFC 도청) + TH-PIN-01 (PIN 봉투 탈취)
공격 경로	(1) 키 세레모니 중 NFC 도청으로 암호화된 시드 데이터 가로채기, (2) PIN 봉인 봉투 탈취로 PIN 확보, (3) 암호문 + PIN → 오프라인 복호화 시도
실현 가능성	Extremely Low — ECDH 세션 키 교환으로 도청 데이터가 복호화 불가. PIN을 확보해도 세션 키 없이는 무의미
결론	SE-to-SE 세션 암호화가 이 복합 공격을 근본적으로 무력화
근거	[Phase 16 r3covery-card-technical-analysis.md 2.3절]

시나리오 3: SLIP-39 셰어 부분 탈취 + R3covery 카드 침해

항목	내용
조합	TH-SSS-01 (셰어 부분 탈취, M-1개) + RR-06b (R3covery 카드 침해)
공격 경로	(1) SLIP-39 셰어 (M-1)개 확보 — 이것만으로는 시드 복원 불가, (2) R3covery 카드 침해로 시드 직접 접근 시도 — 성공 시 SLIP-39 셰어 불필요
실현 가능성	Very Low — 두 독립적 경로를 모두 공격해야 하며, 어느 하나만 성공해도 충분(R3covery 카드) 또는 부족(SLIP-39 M-1개)
시사점	하이브리드 의무화는 "여러 백업 경로 중 하나만 성공하면 복구 가능"이라는 가용성 이점이 있으나, 동시에 "여러 경로 중 하나만 침해되면 시드 노출"이라는 보안 트레이드오프 존재. 이는 각 경로의 독립적 보안 강화가 중요함을 의미
근거	[Phase 16 r3covery-card-technical-analysis.md 4.5절, Phase 17 backup-options-catalog.md 3.5절]

5. 기존 위협 항목 재평가¶

Phase 16-17 설계로 인해 기존 위협 항목의 위험 등급이 변경되는 항목을 식별한다.

기존 위협 ID	기존 위험 등급	재평가 등급	변경 근거
RR-06	MEDIUM	하위 항목별 차등 (RR-06a: MEDIUM, RR-06b: LOW, RR-06c: LOW)	Phase 16-17 다중 백업 옵션 도입으로 세분화 필요
RR-06 통합	MEDIUM	LOW (하이브리드 조합 시)	다중 복구 경로로 단일 백업 탈취 영향 감소
5.8 PIN 무차별 대입	LOW	LOW (유지, 범위 확대)	R3covery 카드 PIN(5회 제한)이 추가 분석 대상이나 기존 방어 체계와 동일 원리
RR-05 WYSIWYS 미확인	MEDIUM	MEDIUM (유지)	백업 옵션과 직접 관련 없음
RR-01 M명 공모	MEDIUM	MEDIUM (유지, 범위 확대)	Super Shamir 도입으로 백업 복원 공모도 분석 대상에 추가되나, 서명 공모와 별개

Part B: 펌웨어 요구사항 추가 (IMP-03)¶

6. 분석 개요¶

6.1. 기존 FW-ID 체계 요약¶

hardware-capability-assessment.md에서 정의한 기존 펌웨어 요구사항 체계: - SE 암호화 알고리즘 (ECDSA, Schnorr, SHA-256, AES-128-CCM, ECDH 등) - WYSIWYS 파싱 엔진 (PSBT/RLP/ABI 파싱, 해시 비교) - HW 정책 엔진 (4규칙 평가, Merkle Root 검증) - MuSig2 서명 (2라운드 프로토콜, 상태 관리) - QR + USB-C 인터페이스 (서명 통신), NFC 인터페이스 (R3covery 카드 전용)

6.2. HW-CONFIRM 8항목 기반 신규 요구사항¶

Phase 16에서 도출된 HW-CONFIRM-R01~R05와 Phase 17에서 추가된 HW-CONFIRM-R06~R08을 기반으로 펌웨어 신규 요구사항을 도출한다.

HW-CONFIRM	질문	관련 FW 요구사항	Phase
R01	R3covery 카드 SE 칩 모델/인증	FW-R3C-01~04	16
R02	SE-to-SE NFC 상호 인증 프로토콜	FW-NFC-01~04	16
R03	R3covery 카드 PIN 시도 제한	FW-R3C-02	16
R04	카드 SE EEPROM 보존 기간	FW-R3C-03 (라이프사이클 관리)	16
R05	콜드룸 NFC 통신 가능 여부	FW-NFC-03	16
R06	SE 내부 SLIP-39 GF(256) 처리	FW-SLIP-01~03	17
R07	Super Shamir 그룹 구조 SE 지원	FW-SLIP-02 (확장)	17
R08	SLIP-39 Passphrase PBKDF2 SE 처리	FW-SLIP-03	17

7. SE SLIP-39 처리 요구사항¶

7.1. FW-SLIP-01: SE 내부 SLIP-39 인코딩/디코딩¶

항목	내용
요구사항 ID	FW-SLIP-01
분류	SE 펌웨어
설명	D'CENT X SE 내부에서 SLIP-39 표준의 GF(256) 기반 Shamir Secret Sharing 인코딩(셰어 생성) 및 디코딩(셰어 재조립)을 수행한다
상세 기능	(1) GF(256) 유한체 곱셈/역원 연산 테이블 구현 (~512 bytes EEPROM), (2) 차수 (M-1) 다항식 생성 (TRNG 기반 계수), (3) N개 평가점에서 셰어 생성, (4) M개 셰어에서 라그랑주 보간법으로 원본 복원, (5) EMS(Exponent-Mapped Sharing) 워드리스트 1024단어 ROM 저장 (~5KB)
SE 리소스 영향	EEPROM: +5.5KB (GF 테이블 + 워드리스트), RAM: +256B (다항식 연산 임시)
대안 (SE 미지원 시)	오프라인 앱에서 SLIP-39 셰어 생성/재조립 수행. 이 경우 시드가 앱 메모리에 일시 존재하므로 에어갭 전용 디바이스에서만 실행해야 함
우선순위	Phase 1 (핵심) — SLIP-39 백업의 보안 수준을 결정하는 핵심 요구사항
근거	[Phase 17 slip39-shamir-enterprise-design.md 2.4절, HW-CONFIRM-R06]

7.2. FW-SLIP-02: SE 내부 셰어 생성 및 시드 복원¶

항목	내용
요구사항 ID	FW-SLIP-02
분류	SE 펌웨어
설명	SE 내부에서 마스터 시드를 입력으로 SLIP-39 셰어를 생성하고, 역으로 M개 셰어를 입력으로 마스터 시드를 복원한다
상세 기능	(1) 셰어 생성 흐름: 시드(BIP-39) → GF(256) 다항식 생성 → N개 셰어 평가 → 각 셰어 EMS 인코딩(20단어) → 디바이스 화면 순차 표시, (2) 시드 복원 흐름: M개 셰어(20단어) 입력 → EMS 디코딩 → GF(256) 라그랑주 보간 → 원본 시드 복원 → SE 내부 저장, (3) Super Shamir 지원: 다중 그룹별 임계값 관리 (HW-CONFIRM-R07)
메모리 제약 분석	셰어 생성: M개 계수 x 1B = 최대 7B (4-of-7), 셰어 복원: M개 셰어 x 33B(최대) = 최대 231B (7 셰어). SE RAM 8.5KB 피크 내 처리 가능
대안 (SE 미지원 시)	오프라인 앱에서 처리. SE는 시드 표시(기존 24단어 표시 기능)만 수행하고, 앱이 GF(256) 연산 담당
우선순위	Phase 1 (핵심)
근거	[Phase 17 slip39-shamir-enterprise-design.md 2.4절, HW-CONFIRM-R06, R07]

7.3. FW-SLIP-03: SLIP-39 Passphrase 검증¶

항목	내용
요구사항 ID	FW-SLIP-03
분류	SE 펌웨어
설명	SLIP-39 Passphrase(선택적 추가 보호)를 SE 내부에서 검증한다. Passphrase는 PBKDF2-HMAC-SHA256을 사용하여 마스터 시크릿에서 마스터 시드를 파생한다
상세 기능	(1) PBKDF2-HMAC-SHA256 실행: iterations=20000 (SLIP-39 표준), salt="shamir" + passphrase, (2) 파생된 마스터 시드의 유효성 검증 (BIP-39 체크섬), (3) Passphrase 입력은 디바이스 물리 버튼/화면을 통해 수행 (에어갭 유지)
SE 리소스 영향	PBKDF2 20000 iterations: ~2-5초 (SE HMAC-SHA256 하드웨어 가속 기준), RAM: +128B (HMAC 임시)
대안 (SE 미지원 시)	오프라인 앱에서 PBKDF2 수행 → 파생된 마스터 시드를 SE에 입력. 보안적으로 열등 (시드가 앱 메모리 경유)
우선순위	Phase 2 (중요) — Passphrase는 선택적 기능이므로 기본 SLIP-39보다 후순위
근거	[Phase 17 slip39-shamir-enterprise-design.md, HW-CONFIRM-R08]

8. NFC 프로토콜 요구사항¶

8.1. FW-NFC-01: SE-to-SE 상호 인증 프로토콜¶

항목	내용
요구사항 ID	FW-NFC-01
분류	본체 SE + 카드 SE 펌웨어
설명	D'CENT X 본체 SE와 R3covery 카드 SE 간 NFC 통신 시 상호 인증을 수행하여 가짜 디바이스/카드를 탐지한다
상세 기능	(1) Challenge-Response 프로토콜: 양측 SE가 각각 난수 챌린지를 생성하여 상대방에게 전송, (2) 양측이 자신의 개인키로 챌린지에 서명하여 응답, (3) 양측이 상대방의 공개키로 서명 검증, (4) 검증 성공 시 ECDH 세션 키 교환 진행, (5) 검증 실패 시 즉시 세션 종료 + 경고 로그
프로토콜 옵션	SCP03(GlobalPlatform 표준) 또는 자체 ECDH 기반 프로토콜 (HW-CONFIRM-R02에서 결정)
SE 리소스 영향	본체 SE: ECDSA verify ~100ms + ECDH ~100ms = ~200ms, 카드 SE: 동일
우선순위	Phase 1 (핵심) — R3covery 카드 보안의 근본
근거	[Phase 16 r3covery-card-technical-analysis.md 2.3절, HW-CONFIRM-R02]

8.2. FW-NFC-02: NFC 암호화 채널¶

항목	내용
요구사항 ID	FW-NFC-02
분류	본체 SE + 카드 SE 펌웨어
설명	SE-to-SE 상호 인증 완료 후 NFC 통신 채널을 AES-256-GCM(또는 AES-128-CCM) 세션 키로 암호화한다
상세 기능	(1) ECDH 공유 비밀 → HKDF-SHA256 키 파생 → 세션 키 생성, (2) 모든 후속 APDU를 세션 키로 암호화 (기밀성), (3) GCM/CCM Auth Tag으로 무결성 검증, (4) 세션 카운터(메시지 번호)로 리플레이 공격 방지, (5) 세션 종료 시 키 즉시 삭제
SE 리소스 영향	AES 암호화/복호화: ~0.5ms/APDU (하드웨어 가속), 세션 키: +32B RAM
우선순위	Phase 1 (핵심)
근거	[Phase 16 r3covery-card-technical-analysis.md 2.2~2.3절]

8.3. FW-NFC-03: NFC 릴레이 공격 방지¶

항목	내용
요구사항 ID	FW-NFC-03
분류	본체 SE + 카드 SE 펌웨어
설명	NFC 릴레이 공격을 탐지하기 위한 거리 제한(distance bounding) 및 타이밍 검증 메커니즘을 구현한다
상세 기능	(1) 세션 설정 시 타이밍 챌린지: 랜덤 비트 전송 → 응답 시간 측정 → 기대 RTT(~500us for NFC) 초과 시 릴레이 의심, (2) NFC 세션 타임아웃: 개별 APDU 응답 500ms 이내, 전체 세션 30초 이내, (3) 콜드룸 환경에서 NFC 통신 수행 시 Faraday cage 내부 릴레이 불가
SE 리소스 영향	타이밍 측정: 하드웨어 타이머 사용 (~0 추가 리소스)
우선순위	Phase 2 (중요) — 물리 보안(콜드룸)이 1차 방어선이므로 소프트웨어 방어는 2차
근거	[Phase 16 r3covery-card-technical-analysis.md 2.3절, HW-CONFIRM-R05, TH-NFC-02]

8.4. FW-NFC-04: R3covery 카드 데이터 포맷¶

항목	내용
요구사항 ID	FW-NFC-04
분류	카드 SE 펌웨어
설명	R3covery 카드 SE 내부에 시드/셰어를 저장하는 데이터 포맷을 정의하고 구현한다
상세 기능	(1) 데이터 구조: 헤더(카드 버전, 포맷 ID, 발급 일시) + 암호화 페이로드(AES-256-GCM 암호문) + Auth Tag(16B) + Salt(32B) + PBKDF2 Iterations(4B), (2) 시드 저장 모드: BIP-39 24단어 시드 암호화 저장, (3) 셰어 저장 모드: SLIP-39 개별 셰어(20단어) 암호화 저장, (4) 카드 메타데이터: 카드 일련번호, 발급 세레모니 ID, 라이프사이클 상태
SE 리소스 영향	카드 SE EEPROM: ~512B (헤더 + 암호문 + 메타데이터)
우선순위	Phase 1 (핵심)
근거	[Phase 16 r3covery-card-technical-analysis.md 2.2절, Phase 17 r3covery-card-lifecycle-operations.md 2.3절]

9. R3covery 카드 상호 인증 요구사항¶

9.1. FW-R3C-01: 본체 SE - 카드 SE 상호 인증 (PKI 기반)¶

항목	내용
요구사항 ID	FW-R3C-01
분류	본체 SE + 카드 SE 펌웨어
설명	D'CENT X 본체 SE와 R3covery 카드 SE 간 PKI 기반 상호 인증을 구현한다. 각 SE는 고유 키 쌍을 보유하며, D'CENT Root CA가 서명한 인증서로 신원을 증명한다
상세 기능	(1) 각 SE에 고유 ECDSA 키 쌍(secp256k1 또는 P-256) 생성 및 저장, (2) D'CENT Root CA 공개키를 양측 SE에 사전 저장, (3) 상대방 인증서의 Root CA 서명 검증, (4) 인증서 내 SE 고유 ID 매칭, (5) 인증 실패 시 통신 거부 + 보안 이벤트 로깅
SE 리소스 영향	본체 SE: +128B (Root CA 공개키 + 자체 인증서), 카드 SE: +128B 동일
우선순위	Phase 1 (핵심) — 가짜 카드 공격 방어의 근본
근거	[Phase 16 r3covery-card-technical-analysis.md 2.3절, HW-CONFIRM-R02]

9.2. FW-R3C-02: 카드 PIN 시도 횟수 제한 및 WIPED 전이¶

항목	내용
요구사항 ID	FW-R3C-02
분류	카드 SE 펌웨어
설명	R3covery 카드 SE 내부에서 PIN 인증 시도 횟수를 제한하고, 초과 시 데이터를 보안 삭제(WIPED)한다
상세 기능	(1) PIN 시도 카운터: SE 내부 단조 증가 카운터, 리셋 불가, (2) 잠금(LOCKED) 전이: 연속 5회 실패 시 (HW-CONFIRM-R03), (3) WIPED 전이: LOCKED 상태에서 PUK 실패 또는 추가 3회 실패 시 SE 데이터 전체 보안 삭제, (4) PIN 성공 시 카운터 리셋, (5) PUK 지원 여부: HW-CONFIRM-R03에서 확인
SE 리소스 영향	카드 SE EEPROM: +8B (카운터 + 상태 플래그)
우선순위	Phase 1 (핵심) — PIN 무차별 대입 방어의 근본
근거	[Phase 16 pin-management-system-design.md 3.2~3.3절, HW-CONFIRM-R03]

9.3. FW-R3C-03: 카드 라이프사이클 상태 관리¶

항목	내용
요구사항 ID	FW-R3C-03
분류	카드 SE 펌웨어
설명	R3covery 카드 SE 내부에서 카드 라이프사이클 상태(발급/활성/잠금/폐기)를 관리한다
상세 기능	(1) 상태 머신: UNSET → ACTIVE → LOCKED → WIPED (Phase 16 PIN 라이프사이클과 동일), (2) 상태 전이 조건: 섹션 3.3 참조 (PIN 설정, 인증 실패, PUK, 긴급 폐기), (3) 상태별 허용 APDU 커맨드 제한: UNSET(초기화만), ACTIVE(읽기/쓰기/PIN 변경), LOCKED(PUK 해제만), WIPED(응답 없음), (4) 상태 변경 이벤트 로깅: 카드 SE 내부에 최근 10건 이벤트 저장
SE 리소스 영향	카드 SE EEPROM: +64B (상태 플래그 + 이벤트 로그 10건)
우선순위	Phase 1 (핵심)
근거	[Phase 16 pin-management-system-design.md 3.1~3.3절, Phase 17 r3covery-card-lifecycle-operations.md]

9.4. FW-R3C-04: 다중 카드 관리¶

항목	내용
요구사항 ID	FW-R3C-04
분류	본체 SE + 오프라인 앱 펌웨어
설명	D'CENT X 본체에서 복수의 R3covery 카드를 인식하고 관리하는 카드 인벤토리 기능을 구현한다
상세 기능	(1) 카드 인벤토리: 발급된 카드 목록(일련번호, 발급일, 라이프사이클 상태) 관리, (2) 카드 식별: NFC 태깅 시 카드 일련번호 자동 인식, (3) 카드-서명자 매핑: 어떤 서명자의 시드/셰어가 어느 카드에 저장되었는지 추적, (4) 카드 교체 워크플로우: 기존 카드 → 신규 카드 데이터 이전 지원, (5) 카드 폐기 확인: WIPED 상태 카드를 인벤토리에서 비활성화
SE 리소스 영향	본체 SE EEPROM: +256B (카드 10장 인벤토리), 오프라인 앱: 카드 관리 UI
우선순위	Phase 2 (중요) — 다중 카드 관리는 운영 편의 기능
근거	[Phase 16 r3covery-card-technical-analysis.md 3.5절, Phase 17 r3covery-card-lifecycle-operations.md 2.4절]

10. 기존 FW 요구사항 영향 분석¶

hardware-capability-assessment.md의 기존 요구사항 중 Phase 16-17 설계로 변경/확장이 필요한 항목을 식별한다.

기존 요구사항	영향 유형	변경 내용	영향도
SE 저장 공간 (~9.8KB)	확장	FW-SLIP-01(+5.5KB) + FW-R3C(+0.5KB) = +6KB 추가 → 총 ~15.8KB	High — EAL5+ SE 가용 공간(32-128KB) 내이나 여유 축소
SE RAM (~8.5KB 피크)	확장	SLIP-39 연산 시 +256B → 피크 ~8.8KB	Low — 기존 피크와 비슷 수준
NFC APDU 체이닝	확장	R3covery 카드 SE-to-SE 통신 시 추가 APDU 커맨드셋 필요 (SELECT, INIT_SESSION, AUTH, READ_SEED, WRITE_SEED, VERIFY_PIN 등)	Medium
NFC 세션 암호화	확장	기존 AES-128-CCM → R3covery 카드 데이터 저장 시 AES-256-GCM 추가 지원	Medium
디스플레이 요구사항	확장	SLIP-39 셰어 20단어 표시 (기존 24단어 BIP-39와 유사, 셰어 N개 순차 표시)	Low
카메라/QR 요구사항	변경 없음	SLIP-39 셰어는 물리 매체(금속/카드) 기록이므로 QR 관련 변경 없음	없음

SE 저장 공간 재산정:

카테고리	기존	Phase 16-17 추가	합계
Private Keys + 체인코드	1,600B	-	1,600B
토큰 DB	2,048B	-	2,048B
함수 셀렉터 DB	4,096B	-	4,096B
정책 데이터	1,120B	-	1,120B
MuSig2 세션	132B	-	132B
서명 카운터 + 메타	68B	-	68B
GF(256) 테이블 + 워드리스트	-	5,632B	5,632B
R3C 카드 인벤토리	-	256B	256B
R3C Root CA 공개키 + 인증서	-	128B	128B
예비 (10% 마진)	930B	+600B	1,530B
합계	~9.8KB	+~6.0KB	~15.8KB

판정: EAL5+ SE의 가용 공간(32-128KB)에서 15.8KB는 충분히 수용 가능하다. 단, SE 가용 공간의 정확한 크기는 HW-CONFIRM 필수.

11. 요구사항 우선순위 및 구현 의존성¶

11.1. 펌웨어 요구사항 간 의존성 그래프¶

FW-R3C-01 (SE-to-SE 상호 인증)
    │
    ├──▶ FW-NFC-01 (Challenge-Response 인증)
    │       │
    │       └──▶ FW-NFC-02 (암호화 채널)
    │               │
    │               ├──▶ FW-NFC-04 (데이터 포맷)
    │               └──▶ FW-NFC-03 (릴레이 방지)
    │
    ├──▶ FW-R3C-02 (PIN 시도 제한)
    │       │
    │       └──▶ FW-R3C-03 (라이프사이클 상태)
    │
    └──▶ FW-R3C-04 (다중 카드 관리)

FW-SLIP-01 (GF(256) 인코딩/디코딩)
    │
    ├──▶ FW-SLIP-02 (셰어 생성/시드 복원)
    │       │
    │       └──▶ FW-SLIP-03 (Passphrase PBKDF2)
    │
    └──── [독립] FW-NFC-01~04 (SLIP-39 셰어를 카드에 저장 시 필요)

11.2. 구현 우선순위¶

우선순위	Phase	요구사항	근거
Phase 1 (핵심 — 즉시)	1	FW-R3C-01, FW-R3C-02, FW-R3C-03	R3covery 카드 기본 보안 (인증, PIN, 상태 관리)
Phase 1 (핵심 — 즉시)	1	FW-NFC-01, FW-NFC-02, FW-NFC-04	NFC 보안 채널 + 데이터 포맷
Phase 1 (핵심 — 즉시)	1	FW-SLIP-01, FW-SLIP-02	SLIP-39 기본 셰어 생성/복원
Phase 2 (중요 — 다음)	2	FW-NFC-03	릴레이 방지 (물리 보안이 1차 방어선)
Phase 2 (중요 — 다음)	2	FW-R3C-04	다중 카드 관리 (운영 편의)
Phase 2 (중요 — 다음)	2	FW-SLIP-03	Passphrase 검증 (선택적 기능)

11.3. 총 신규 요구사항 요약¶

카테고리	요구사항 수	Phase 1	Phase 2	SE 영향
SE SLIP-39 처리	3 (FW-SLIP-01~03)	2	1	EEPROM +5.5KB, RAM +256B
NFC 프로토콜	4 (FW-NFC-01~04)	3	1	세션 키 +32B RAM
R3covery 카드 상호 인증	4 (FW-R3C-01~04)	3	1	EEPROM +448B
합계	11	8	3	EEPROM +~6KB, RAM +~288B

본 문서는 Phase 18 기존 설계 영향도 분석의 일부로, Phase 16-17 백업 옵션 체계에 따른 STRIDE 위협 모델 업데이트(Part A)와 펌웨어 신규 요구사항 도출(Part B)을 다룬다. Part A(키 세레모니/재해 복구/셀프 커스터디 아키텍처 변경 사항)는 core-design-impact-analysis.md에서 다룬다.