v0.3

R3covery 카드 기술 심층 분석서¶

1. Executive Summary¶

본 문서는 D'CENT X R3covery 카드의 엔터프라이즈 적용 가능성을 SE 보안 구조, 물리적 내구성, 벤더 독립성 3개 축으로 심층 분석한다. R3covery 카드는 NFC 기반 SE 칩에 시드를 암호화하여 저장하는 백업 카드로, 기존 금속 시드 플레이트(BIP-39 니모닉 24단어 각인) 대비 니모닉 비노출 백업이 가능하여 보안을 근본적으로 강화한다.

종합 평가:

평가 항목	등급	요약
SE 보안 구조	적합 (조건부)	EAL5+ SE 탑재 시 엔터프라이즈 요구 수준 충족. SE-to-SE 상호 인증 프로토콜은 HW-CONFIRM 필요
물리적 내구성	적합	EEPROM 10-25년 보존, 금고 보관 시 환경 내성 충분. 다중 카드 발급으로 위험 분산 가능
벤더 독립성	부분 적합 (보완 필요)	D'CENT 독점 포맷 사용 시 벤더 종속 위험. 하이브리드 백업 의무화 + 사양서 에스크로로 완화

핵심 결론: R3covery 카드는 엔터프라이즈 환경에 도입 가능하나, (1) HW-CONFIRM 5개 항목의 하드웨어 팀 확인, (2) 하이브리드 백업 의무화(금속 시드 또는 SLIP-39 병행), (3) 사양서 에스크로 체계 구축이 전제 조건이다. 이 세 조건이 충족되면, STRIDE 위협 모델의 RR-06(시드 백업 물리 탈취, 잔여 위험 MEDIUM)을 LOW로 하향할 수 있다.

2. SE 보안 구조 분석 (R3C-01)¶

2.1. NFC 칩 유형 분석¶

R3covery 카드에 탑재될 SE 칩 후보군은 하드웨어 월렛 및 스마트카드 시장의 주요 SE 공급사 제품이다. hardware-capability-assessment.md의 D'CENT X 본체 SE 분석(섹션 2.1)과 동일한 후보군을 기반으로 평가한다.

칩 후보	제조사	CC 인증	JavaCard	GlobalPlatform	NFC 지원	비고
SLC37 시리즈	Infineon	EAL5+~EAL6+	v3.0.4+	v2.3+	ISO 14443 Type A	SECORA 플랫폼, NFC 카드에 최적화
SLE78 시리즈	Infineon	EAL5+	v3.0.4	v2.2	ISO 14443 Type A/B	레거시 라인, 점진적 EOL 예정
ST33J2M0	STMicroelectronics	EAL5+	v3.0.5	v2.3	ISO 14443 Type A/B	금융 카드 시장 점유율 높음
ST33K1M5	STMicroelectronics	EAL6+	v3.1	v2.3.1	ISO 14443 Type A/B	차세대 플랫폼, 더 넓은 메모리
S3K250AF	Samsung	EAL6+	v3.0.5	v2.3	ISO 14443 Type A	삼성 보안칩, 내장형 NFC

선정 기준: - 최소 요구: EAL5+ CC 인증, JavaCard v3.0.4+, GlobalPlatform v2.3+ - 권장 타겟: EAL6+ (D'CENT X 본체 SE와 동등 수준으로, 엔터프라이즈 차별화) - NFC 필수: ISO 14443 Type A 또는 Type A/B 듀얼 지원

[HW-CONFIRM-R01] R3covery 카드 SE의 정확한 칩 모델명 및 CC 인증 레벨이 확인되어야 한다. 상기 후보군은 산업 표준 기반 추정이다.

2.2. 암호화 알고리즘 분석¶

R3covery 카드가 시드를 안전하게 저장·복원하기 위해 사용하는 암호화 체계를 분석한다.

시드 암호화 스택 (추정):

┌───────────────────────────────────────────────────┐
│  Layer 3: 시드 암호화 (Storage Encryption)          │
│  AES-256-GCM(derived_key, seed_data)               │
│  → 128-bit Auth Tag으로 무결성 검증                  │
├───────────────────────────────────────────────────┤
│  Layer 2: 키 파생 (Key Derivation)                  │
│  PBKDF2-HMAC-SHA256(PIN, salt, iterations=600000)  │
│  → 256-bit derived_key 생성                         │
│  (대안: Argon2id — SE 메모리 제약 시 PBKDF2 우선)    │
├───────────────────────────────────────────────────┤
│  Layer 1: PIN 입력 (User Authentication)            │
│  카드 SE 내부에서 PIN 검증                            │
│  → 시도 횟수 제한 적용 [HW-CONFIRM-R03]             │
└───────────────────────────────────────────────────┘

알고리즘	용도	보안 강도	SE 호환성	비고
AES-256-GCM	시드 데이터 암호화	256-bit 대칭키	EAL5+ SE 하드웨어 가속 표준	GCM 모드로 기밀성+무결성 동시 보장
PBKDF2-HMAC-SHA256	PIN → 암호화 키 파생	반복 횟수 의존	SE 내부 처리 가능	600K iterations 시 ~1초(SE 기준)
HMAC-SHA256	데이터 무결성 검증	256-bit	SE 하드웨어 가속	카드 데이터 변조 탐지
ECDH (secp256k1)	SE-to-SE 세션 키 교환	128-bit 등가	airgap-communication-protocol.md 참조	NFC 채널 암호화용
AES-128-CCM	NFC 세션 암호화	128-bit	airgap-communication-protocol.md 섹션 7.3	SE-to-SE 통신 보호

AES-256-GCM vs AES-256-CBC 선택 근거: - GCM은 인증 태그(Auth Tag)를 포함하여 별도 HMAC 계산 없이 무결성 검증 가능 - CBC + HMAC 대비 SE 연산 효율이 높음 (단일 패스 처리) - 단, SE 칩에 따라 GCM 하드웨어 가속 미지원 시 CBC + HMAC-SHA256 폴백

2.3. SE-to-SE 채널 분석¶

D'CENT X 본체 SE와 R3covery 카드 SE 간 NFC 통신 시 상호 인증 및 보안 채널 확보가 핵심이다. airgap-communication-protocol.md의 NFC 세션 키 교환 프로토콜(섹션 7.3)을 기반으로 분석한다.

SE-to-SE 상호 인증 프로토콜 (추정):

D'CENT X 본체 SE                    R3covery 카드 SE
      │                                    │
      │ ──── NFC Field Activation ───────▶ │
      │                                    │
      │ ◀──── SELECT (AID) ───────────── │
      │     R3covery 앱릿 선택              │
      │                                    │
      │ ──── INIT_SESSION ───────────────▶ │
      │     본체 ephemeral pubkey           │
      │     본체 SE 인증서/ID               │
      │                                    │
      │ ◀──── SESSION_RESPONSE ────────── │
      │     카드 ephemeral pubkey           │
      │     카드 SE 인증서/ID               │
      │     상호 인증 챌린지                 │
      │                                    │
      │  ── shared_secret = ECDH ───────── │
      │  session_key = HKDF-SHA256(        │
      │    shared_secret,                   │
      │    "dcent-r3covery-session", 16)    │
      │                                    │
      │ ──── AUTH_CHALLENGE_RESP ─────────▶ │
      │     AES-128-CCM(session_key,        │
      │       challenge_response)           │
      │                                    │
      │ ◀──── CHANNEL_ESTABLISHED ──────── │
      │     암호화 채널 활성화               │
      │                                    │
      │ ════ 이후 모든 통신 암호화 ════════ │

프로토콜 유형 분석:

프로토콜	특성	가능성	장점	단점
SCP03 (GlobalPlatform)	표준 보안 채널 프로토콜	높음	표준 준수, 검증된 보안	카드-to-카드 사용 사례가 드묾
자체 ECDH 프로토콜	D'CENT 커스텀	높음	유연한 설계, NFC 최적화	독립 보안 감사 필요
SCP11c (GP Amendment F)	인증서 기반 상호 인증	중간	PKI 기반 강력한 상호 인증	칩 지원 제한적

[HW-CONFIRM-R02] SE-to-SE NFC 상호 인증이 SCP03 기반인지 자체 프로토콜인지, 세션 키 교환 방식(ECDH secp256k1 vs P-256), 중간자 공격 방어 메커니즘을 확인해야 한다.

중간자 공격 방어: - NFC 통신 거리(~10cm)가 물리적 방어 1차 레이어 - SE-to-SE 상호 인증으로 가짜 카드/디바이스 탐지 - ECDH 기반 세션 키로 도청 방지 - AES-128-CCM 암호화로 채널 기밀성·무결성 보장

2.4. EAL 인증 레벨 분석¶

인증 레벨	검증 범위	R3covery 카드 적용	엔터프라이즈 요구 부합
EAL4+	방법론적 설계, 테스트, 검토	소규모 기업 최소 수준	미달 — 전용 SE가 아닌 범용 MCU 가능
EAL5+	반정형 설계 및 테스트	최소 요구 수준	충족 — 전용 SE 필수, 부채널 공격 방어
EAL6+	반정형 검증 설계	권장 타겟	우수 — Ledger Enterprise 동급, 금융기관 신뢰
EAL7	정형 검증	과도한 비용, 불필요	군사/국가급, 엔터프라이즈 ROI 미달

본체 SE와의 인증 레벨 일관성: - hardware-capability-assessment.md 기준: 본체 SE는 EAL5+ 최소, EAL6+ 타겟 - R3covery 카드 SE도 동일 인증 레벨을 유지해야 전체 보안 체인의 약한 고리 방지 - 본체가 EAL6+이고 카드가 EAL5+이면, 카드가 보안 하한선(weakest link)이 됨 - 권장: 본체 SE와 동일 레벨의 R3covery 카드 SE 채택

2.5. HW-CONFIRM 항목 종합¶

R3covery 카드의 엔터프라이즈 적용을 위해 D'CENT 하드웨어 팀에 확인이 필요한 5개 핵심 항목:

항목 ID	질문	설계 영향도	대안 (확인 전 가정값)	확인 대상
HW-CONFIRM-R01	R3covery 카드 SE 칩의 정확한 모델명 및 CC 인증 레벨은?	High	Infineon SLC37 계열, EAL5+ 가정	HW팀 — SE 설계 담당
HW-CONFIRM-R02	SE-to-SE NFC 상호 인증 프로토콜의 상세는? (SCP03 vs 자체, ECDH 커브, 세션 키 교환)	High	자체 ECDH(secp256k1) + AES-128-CCM 가정	HW팀 — 펌웨어/보안 담당
HW-CONFIRM-R03	R3covery 카드 PIN 시도 횟수 제한값은? 잠금 후 동작은? (영구 잠금 vs 타임아웃 vs PUK)	High	5회 실패 → 영구 잠금 가정	HW팀 — SE 앱릿 담당
HW-CONFIRM-R04	R3covery 카드 SE EEPROM 데이터 보존 보장 기간은? (제조사 데이터시트 기준)	Medium	10년 보존 보장 가정 (보수적)	HW팀 — SE 하드웨어 담당
HW-CONFIRM-R05	콜드룸 환경(Faraday cage 내부) NFC 통신 가능 여부는?	Medium	근거리(~5cm) NFC 허용 가정	HW팀 — RF/NFC 담당

설계 영향도 상세:

HW-CONFIRM-R01 (High): CC 인증 레벨이 EAL4+ 이하일 경우 엔터프라이즈 시장 진입 불가. 칩 모델에 따라 지원 알고리즘, 메모리 용량, JavaCard 버전이 달라져 전체 설계가 변동된다.
HW-CONFIRM-R02 (High): 상호 인증 미지원 시 가짜 R3covery 카드 공격에 취약. 자체 프로토콜일 경우 독립 보안 감사가 필수적이다.
HW-CONFIRM-R03 (High): PIN 시도 제한이 없거나 과도하게 높으면 무차별 대입 공격에 취약. 영구 잠금 시 복구 경로 설계가 달라진다 (PUK 지원 여부에 따라 PIN-02 Shamir 분할 전략 변경).
HW-CONFIRM-R04 (Medium): 보존 기간이 10년 미만이면 카드 정기 교체 주기 단축 필요. 엔터프라이즈 고객의 장기 자산 보관(10-20년)에 대한 위험 커뮤니케이션 필요.
HW-CONFIRM-R05 (Medium): 콜드룸 Faraday cage에서 NFC 불가 시 키 세레모니 장소 제약. QR 코드 폴백 경로 설계가 필요할 수 있다.

3. 물리적 내구성 및 수명 분석 (R3C-02)¶

3.1. EEPROM 데이터 보존¶

NFC SE 칩의 비휘발성 메모리(EEPROM)는 전원 없이 데이터를 장기 보존하며, 보존 기간은 칩 제조사의 데이터시트에 명시된다.

제조사별 EEPROM 보존 기간:

제조사	칩 계열	보증 기간	조건	출처
Infineon	SLC37/SECORA	25년	25도C 보관	Infineon SECORA Blockchain 데이터시트
STMicroelectronics	ST33 시리즈	20년	25도C 보관	ST33J2M0 Product Brief
Samsung	S3K 시리즈	15-20년 (추정)	25도C 보관	삼성 SE 제품 사양 (비공개, 업계 추정)
NXP	SmartMX3 (참고)	25년	25도C 보관	NXP P71D321 데이터시트

[HW-CONFIRM-R04] R3covery 카드에 탑재된 SE의 정확한 EEPROM 보존 보장 기간은 하드웨어 팀 확인이 필요하다. 상기 데이터는 업계 범용 수치이다.

온도 가속 팩터 (아레니우스 모델):

EEPROM 데이터 보존 수명은 온도에 민감하다. 아레니우스 모델에 따르면, 온도가 10도C 상승할 때마다 수명이 약 절반으로 단축된다.

보관 온도	가속 팩터	25년 보증 칩의 실효 수명
25도C (표준)	1.0x	25년
35도C	~0.5x	~12.5년
45도C	~0.25x	~6.2년
55도C	~0.12x	~3.1년
15도C	~2.0x	~50년

엔터프라이즈 시사점: 금고 보관 시 온도 통제(18-25도C)를 유지하면 제조사 보증 수명을 달성 또는 초과할 수 있다. 반면, 고온 환경(창고, 비공조 금고)은 수명을 대폭 단축시킨다.

쓰기 횟수 제한 (Endurance Cycle):

항목	일반적 범위	R3covery 카드 사용 패턴	위험도
EEPROM 쓰기 횟수	500,000 ~ 1,000,000회	카드 발급(1회) + 소수 PIN 변경(~50회/년)	극히 낮음
읽기 횟수	무제한	복구 시 읽기만 수행	없음

R3covery 카드는 발급 후 쓰기가 거의 발생하지 않으므로 endurance cycle은 실질적 제약이 아니다.

3.2. 환경 내성¶

카드 소재별 내구성 비교:

소재	온도 범위	습도 내성	굴곡 내성	비용	엔터프라이즈 적합성
PVC (표준 신용카드)	-20~50도C	5~95%RH	ISO 7810 준수 (2000회 굴곡)	낮음	적합 (금고 보관 전제)
PET-G	-30~60도C	5~95%RH	PVC 대비 30% 우수	중간	우수 (내구성 강화)
금속 하이브리드 (메탈 코어)	-40~70도C	5~99%RH	매우 우수	높음	최우수 (프리미엄 포지셔닝)

환경 내성 요소별 분석:

환경 요소	영향	허용 범위	완화 방안
온도	SE 칩 동작: -25~85도C, 카드 소재: -20~50도C (PVC)	보관: 0~40도C (보수적)	금고 내 온도 통제 (18-25도C 권장)
습도	장기 고습도 시 카드 소재 변형, 안테나 접점 부식	5~95%RH (비응축)	방습 포장(실리카겔), 밀봉 보관
자기장	NFC 안테나에 영향 미미 (13.56MHz 대역은 자기장 간섭 낮음)	일반 자석 근접 무해	강력 자석(네오디뮴) 직접 접촉 회피
전자기 간섭(EMI)	강한 EMI 환경에서 NFC 통신 장애 가능	일반 사무/금고 환경 무해	통신 시 EMI 차폐 없는 환경 확보
물리적 굴곡	ISO/IEC 7810 기준 2000회 굴곡 내성	금고 보관 시 굴곡 없음	하드 케이스 보관 권장
정전기 (ESD)	SE 칩 ESD 내성: 최소 2kV (HBM 모델)	일반 취급 시 안전	정전기 방지 포장(ESD 파우치)
자외선 (UV)	카드 인쇄 면 퇴색, SE 기능 영향 없음	직사광선 장기 노출 회피	불투명 케이스/봉투 보관

3.3. 고장률 분석¶

스마트카드 산업 평균 고장률 데이터:

지표	값	출처
AFR (Annual Failure Rate)	0.1~0.5%	EMVCo 스마트카드 산업 통계 (2020-2024)
MTBF (Mean Time Between Failures)	200~1000년 (통계적)	칩 레벨 가속 수명 시험 결과
10년 누적 고장률	1.0~4.9%	AFR 기반 계산 (1-(1-AFR)^10)

고장 모드별 분류:

고장 모드	발생 빈도	원인	탐지 방법	복구 가능성
칩 고장 (SE 오동작)	극히 드묾 (AFR < 0.05%)	제조 결함, 극한 온도, ESD 손상	NFC 응답 없음 또는 APDU 에러	불가 → 카드 교체 필요
안테나 단선	드묾 (AFR ~0.1%)	물리적 충격, 반복 굴곡, 제조 결함	NFC 인식 실패	불가 → 카드 교체 필요
접촉부 부식	매우 드묾 (NFC 전용이면 해당 없음)	습기, 화학물질	접촉식 통신 불가	NFC 통신은 비접촉이므로 해당 없음
카드 소재 변형	드묾 (AFR ~0.1%)	고온, 물리적 압력, 용매 노출	육안 확인	변형 경미 시 NFC 가능, 심각 시 교체

3.4. 엔터프라이즈 보관 환경 권장 사양¶

항목	권장 사양	비고
보관 장소	내화 금고 (UL 350 이상)	disaster-recovery.md 사이트 보관 기준 준용
온도	18-25도C (항온)	EEPROM 수명 최적화
습도	30-60%RH (비응축)	안테나 부식 방지
포장	정전기 방지 파우치(ESD bag) + 방습제(실리카겔)	이중 보호
보관 용기	하드 플라스틱/금속 카드 케이스	물리적 굴곡 방지
정기 점검	연 1회 NFC 응답 테스트	카드 생존 확인
점검 방법	테스트 디바이스로 NFC 탭 → APDU SELECT 응답 확인	시드 복호화 불필요 (PIN 미입력)
점검 기록	점검 일시, 응답 결과, 담당자 서명 → 감사 로그	CCSS 감사 대비

3.5. 다중 카드 발급 시 위험 분산¶

하나의 시드로 복수의 R3covery 카드를 발급하면 단일 카드 고장 시 복구 실패 위험을 분산할 수 있다.

전체 복구 실패 확률 (이항분포 모델):

카드 N장 발급, 각 카드의 10년 내 고장 확률을 p라 할 때, 전체 N장이 모두 고장나는 확률:

P(전체 고장) = p^N

AFR	10년 고장률(p)	카드 1장	카드 2장	카드 3장	카드 5장
0.1%	1.0%	1.00%	0.010%	0.0001%	10^-10
0.3%	3.0%	3.00%	0.090%	0.0027%	2.4x10^-8
0.5%	4.9%	4.90%	0.240%	0.0118%	2.8x10^-7

권장: 엔터프라이즈 환경에서 최소 2장, 권장 3장의 R3covery 카드를 발급하여 지리적 분산 보관한다. 3장 발급 시 10년 내 전체 고장 확률은 AFR 0.3% 기준 0.0027% (약 37,000분의 1)로 극히 낮다.

다중 카드 발급 보안 고려사항: - 모든 카드에 동일 시드가 저장되므로, 카드 1장 탈취 = 시드 접근 가능 (PIN 보호 하에) - 발급 장수가 늘수록 공격 표면(탈취 대상)도 증가 → 보관 보안 강화 필요 - 카드별 동일 PIN vs 상이 PIN: 상이 PIN 권장 (1장 PIN 유출 시 나머지 카드 보호) - 다중 카드 발급은 키 세레모니 중 에어갭 환경에서만 수행

4. 벤더 독립성 분석 (R3C-03)¶

4.1. 현황 분석¶

R3covery 카드의 데이터 포맷이 D'CENT 독점인지 오픈 표준 기반인지에 따라 벤더 독립성이 크게 달라진다.

표준 준수 분석:

계층	표준 여부	상세
물리 계층 (NFC)	표준	ISO 14443 Type A, NFC Forum Type 4 Tag
통신 프로토콜 (APDU)	표준	ISO/IEC 7816-4 APDU 명령 체계
앱릿 선택	표준	GlobalPlatform AID 기반 앱릿 선택
데이터 포맷 (시드 저장)	추정: D'CENT 독점	시드 암호화 포맷, APDU 커맨드 시퀀스가 비공개
암호화 알고리즘	표준	AES-256, PBKDF2, ECDH 등 표준 알고리즘 사용

핵심 문제: NFC 물리 계층과 APDU 프로토콜은 표준이지만, 시드 데이터를 읽고 복호화하는 구체적 APDU 커맨드 시퀀스와 데이터 포맷이 D'CENT 독점이면, D'CENT 소프트웨어 없이는 카드에서 시드를 복원할 수 없다.

4.2. 독점 포맷 위험 시나리오¶

시나리오	발생 조건	영향	위험 수준
D'CENT 사업 중단	회사 파산, 인수합병 후 제품 라인 종료	R3covery 카드 복원 소프트웨어 이용 불가	High
제품 EOL	R3covery 카드 지원 종료, 후속 모델 비호환	기존 카드의 복원 경로 단절	Medium
소프트웨어 버그	복원 앱의 크리티컬 버그, 앱 스토어 삭제	일시적 복원 불가	Medium
OS 비호환	미래 OS 버전에서 NFC API 변경	복원 앱 실행 불가	Low (장기)

최악의 시나리오: R3covery 카드만 보유하고, D'CENT 디바이스/소프트웨어가 모두 이용 불가한 상태에서, 카드에 저장된 시드에 접근할 수 없으면 고객 자산 영구 접근 불가가 발생한다.

4.3. 비상 탈출 경로 설계¶

3가지 비상 탈출 경로를 분석하여, 벤더 독립성을 확보한다.

경로 A: 오픈소스 복구 도구¶

R3covery 카드 데이터를 표준 NFC 리더 + 오픈소스 소프트웨어로 추출하는 방식.

항목	상세
필요 조건	(1) APDU 커맨드 시퀀스 공개, (2) 데이터 포맷(암호화 방식, 키 파생 파라미터) 공개, (3) 오픈소스 참조 구현(Reference Implementation) 배포
구현	Python/Rust 기반 CLI 도구: NFC 리더(ACR122U 등) → APDU 전송 → 암호화된 시드 수신 → PIN 입력 → 복호화 → BIP-39 니모닉 복원
장점	완전한 벤더 독립, 커뮤니티 유지보수 가능, 감사 가능성
단점	보안 민감 사양 공개 위험 (공격자에게도 정보 제공), SE 내부 PIN 검증을 우회하지는 못함 (SE 보안 유지)
보안 영향	SE가 PIN을 검증하므로, 오픈소스 도구가 있어도 PIN 없이는 시드 추출 불가. 보안 수준 유지 가능
적합도	★★★★☆

경로 B: 사양서 에스크로¶

R3covery 카드 데이터 포맷 및 복구 프로토콜 사양서를 제3자 에스크로 기관에 보관.

항목	상세
에스크로 기관	법률사무소, 신탁회사, 독립 보안 감사 기관
보관 대상	(1) APDU 커맨드 시퀀스 전체 문서, (2) 데이터 포맷 사양 (암호화 방식, 키 파생 파라미터), (3) 참조 구현 소스코드, (4) 테스트 벡터
해제 조건	D'CENT 사업 중단, 제품 EOL 공식 선언, 또는 계약 위반 시
장점	사양이 비공개로 유지되므로 보안 민감 정보 노출 최소화
단점	에스크로 기관 신뢰 필요, 법적 계약 복잡성, 비용 발생
적합도	★★★☆☆

경로 C: 하이브리드 백업 의무화¶

R3covery 카드만 단독 사용을 금지하고, 반드시 금속 시드 또는 SLIP-39 셰어와 병행.

항목	상세
정책	R3covery 카드 도입 시 금속 시드 플레이트 또는 SLIP-39 Shamir 셰어 중 하나 이상 필수 병행
운영 모델	R3covery 카드: 일상 복구(빠르고 안전), 금속 시드/SLIP-39: 최후 비상 복구(벤더 독립)
장점	벤더 독립성 100% 보장 (금속 시드 = BIP-39 표준), 구현 비용 최소, 즉시 적용 가능
단점	금속 시드 보관 시 니모닉 노출 위험 존재 (RR-06), 이중 백업 관리 부담
보안 트레이드오프	R3covery 카드로 니모닉 비노출 백업의 이점을 얻으면서, 금속 시드는 최후 수단으로만 사용하여 노출 위험 최소화
적합도	★★★★★

4.4. 벤더 독립성 vs 보안 강화 트레이드오프 매트릭스¶

self-custody-architecture.md의 "벤더 락인 제로" 원칙(섹션 4.1 검증 매트릭스)과의 정합성을 5점 척도로 평가한다.

평가 항목	R3covery 카드 단독	경로 A (오픈소스)	경로 B (에스크로)	경로 C (하이브리드)	경로 B+C (이중 안전장치)
벤더 독립성	★☆☆☆☆ (1)	★★★★★ (5)	★★★☆☆ (3)	★★★★★ (5)	★★★★★ (5)
보안 수준	★★★★★ (5)	★★★★☆ (4)	★★★★★ (5)	★★★★☆ (4)	★★★★★ (5)
구현 비용	★★★★★ (5)	★★☆☆☆ (2)	★★★☆☆ (3)	★★★★★ (5)	★★★☆☆ (3)
운영 편의	★★★★★ (5)	★★★★☆ (4)	★★★★★ (5)	★★★☆☆ (3)	★★★☆☆ (3)
즉시 적용	★★★★★ (5)	★☆☆☆☆ (1)	★★☆☆☆ (2)	★★★★★ (5)	★★☆☆☆ (2)
종합 점수	21/25	16/25	18/25	22/25	21/25

4.5. 권장 전략¶

기본 전략: 경로 C (하이브리드 백업 의무화)

R3covery 카드 도입 시 금속 시드 플레이트(BIP-39) 또는 SLIP-39 셰어 병행을 엔터프라이즈 정책으로 강제
R3covery 카드는 일상 복구 수단으로 우선 사용 (NFC 탭으로 빠르고 안전한 복구)
금속 시드/SLIP-39는 최후 비상 수단으로 별도 금고에 보관 (D'CENT 벤더 독립)

추가 권장: 경로 B (사양서 에스크로) 병행

D'CENT가 R3covery 카드 데이터 포맷 사양서를 에스크로 기관에 보관
대형 기관 고객(금융기관, 거래소) 대상으로 에스크로 계약을 옵션 제공
에스크로 해제 조건: D'CENT 사업 중단 또는 R3covery 카드 제품 EOL

결론: 경로 C(하이브리드)를 기본으로 하고, 경로 B(에스크로)를 대형 고객 옵션으로 추가하는 이중 안전장치가 self-custody-architecture.md의 벤더 독립성 원칙을 충족하면서 R3covery 카드의 보안 이점을 극대화한다.

5. 엔터프라이즈 적용 제약 조건 요약¶

5.1. Phase 17 입력 사항¶

Phase 17 백업 옵션 카탈로그 설계 시 반영해야 할 R3covery 카드 기술적 제약 조건:

#	제약 조건	카탈로그 반영 방향
C-01	R3covery 카드 단독 사용 금지 (하이브리드 의무화)	백업 옵션에서 "R3covery 카드 단독" 조합 제외
C-02	R3covery 카드 SE 인증 레벨은 본체 SE와 동등해야 함	보안 수준 평가 시 SE 인증 레벨 반영
C-03	다중 카드 발급 시 최소 2장, 권장 3장	카드 수량을 백업 옵션 파라미터에 포함
C-04	카드별 상이 PIN 권장	PIN 관리 복잡성을 옵션 비교 항목에 포함
C-05	연 1회 NFC 응답 테스트 필수	운영 비용에 정기 점검 비용 포함
C-06	금고 보관 온도 18-25도C 유지	보관 환경 요구사항으로 명시
C-07	HW-CONFIRM 5개 항목 확인 전까지는 설계 가정값 기반	가정값과 실제값의 차이에 따라 설계 수정 필요

5.2. Phase 18 입력 사항¶

Phase 18 기존 설계 문서 변경 시 고려해야 할 R3covery 카드 기술 전제 조건:

기존 문서	변경 필요 섹션	R3covery 카드 전제 조건
key-ceremony.md	Step 3 (시드 생성/백업)	R3covery 카드 발급 단계 추가, 니모닉 표시 조건부
disaster-recovery.md	DS-01 (디바이스 장애) 복구 경로	R3covery 카드 기반 복구 경로 추가 (NFC 탭 복원)
stride-threat-model.md	RR-06 (시드 백업 물리 탈취)	R3covery 카드가 RR-06 위험을 LOW로 하향하는 근거
self-custody-architecture.md	섹션 2.4 키 백업 벤더 독립성	R3covery 카드 독점 포맷 위험 + 하이브리드 완화 전략
airgap-communication-protocol.md	섹션 5 NFC APDU 커맨드셋	R3covery 카드 전용 APDU 커맨드 정의 필요
hardware-capability-assessment.md	섹션 2.1 SE 칩 분석	R3covery 카드 SE 사양 추가 (본체 SE와 별도 분석)

5.3. HW-CONFIRM 전체 요약표¶

항목 ID	질문 요약	확인 상태	설계 영향도	가정값	담당
HW-CONFIRM-R01	SE 칩 모델 및 CC 인증 레벨	미확인	High	Infineon SLC37, EAL5+	HW팀 SE 설계
HW-CONFIRM-R02	SE-to-SE 상호 인증 프로토콜 상세	미확인	High	자체 ECDH + AES-128-CCM	HW팀 펌웨어/보안
HW-CONFIRM-R03	PIN 시도 횟수 제한 및 잠금 후 동작	미확인	High	5회 실패 → 영구 잠금	HW팀 SE 앱릿
HW-CONFIRM-R04	EEPROM 데이터 보존 보장 기간	미확인	Medium	10년 (보수적)	HW팀 SE 하드웨어
HW-CONFIRM-R05	콜드룸 Faraday cage NFC 통신 가능 여부	미확인	Medium	근거리 (~5cm) 허용	HW팀 RF/NFC

확인 절차 권장: 1. 본 문서의 HW-CONFIRM 5개 항목을 하드웨어 팀에 공식 질의 2. 확인 결과에 따라 본 문서의 가정값을 실제값으로 교체 3. 가정값과 실제값의 차이가 큰 항목은 Phase 17/18 설계에 반영

6. STRIDE 위협 모델 연계¶

6.1. RR-06 위험 완화 분석¶

stride-threat-model.md의 RR-06(금속 시드 백업 물리적 탈취, 잔여 위험 MEDIUM)에 대한 R3covery 카드의 완화 효과:

공격 시나리오	금속 시드 (현행)	R3covery 카드	완화 효과
물리적 탈취 후 시드 획득	니모닉 육안 판독 가능 → 즉시 시드 노출	PIN 보호 + SE 암호화 → 시드 접근 불가	극대
복사/사진 촬영	니모닉 촬영 가능 → 비대면 탈취	NFC 통신 + PIN 필요 → 원격 복사 불가	극대
내부자 위협 (접근 권한 남용)	금고 접근 시 시드 노출	금고 접근 시에도 PIN 모르면 시드 보호	높음
무차별 대입 (PIN 공격)	해당 없음 (PIN 없음)	SE가 시도 횟수 제한 → 5회 후 잠금 [HW-CONFIRM-R03]	방어
부채널 공격 (SE 물리)	해당 없음	EAL5+ SE의 부채널 방어	방어

RR-06 위험 재평가: - 하이브리드 백업(R3covery 카드 + 금속 시드) 적용 시: - R3covery 카드: 일상 복구 → RR-06 위험 LOW (SE + PIN 보호) - 금속 시드: 최후 비상 → RR-06 위험 MEDIUM (물리 보안 의존) — 그러나 접근 빈도 최소화로 실효 위험 LOW-MEDIUM - 종합 RR-06 재평가: MEDIUM → LOW (R3covery 카드 도입 시)

6.2. 새로운 위협 항목¶

R3covery 카드 도입으로 추가되는 위협 항목 (Phase 18에서 stride-threat-model.md에 반영 필요):

위협 ID	카테고리	위협	위험도	완화 수단
R3C-T01	Information Disclosure	R3covery 카드 PIN 탈취 + 카드 물리 탈취 → 시드 노출	MEDIUM	PIN-카드 분리 보관, PIN Shamir 분할 (PIN-02)
R3C-T02	Spoofing	가짜 R3covery 카드로 잘못된 시드 복원 유도	LOW	SE-to-SE 상호 인증 [HW-CONFIRM-R02]
R3C-T03	Tampering	NFC 통신 도청으로 암호화된 시드 캡처	LOW	AES-128-CCM 세션 암호화, ECDH 키 교환
R3C-T04	Denial of Service	R3covery 카드 고의 파손 (내부자 공격)	LOW	다중 카드 발급 (3장), 금속 시드 폴백

본 문서는 Phase 16 R3covery 카드 분석 및 PIN 관리 설계의 Plan 01 산출물로, R3covery 카드의 기술적 제약 조건과 설계 기반을 확립한다. Phase 17 백업 옵션 카탈로그와 R3covery 카드 라이프사이클 설계의 입력 자료로 사용된다. hardware-capability-assessment.md(SE 사양), stride-threat-model.md(RR-06 위협), airgap-communication-protocol.md(NFC 프로토콜), disaster-recovery.md(DS-01 복구), self-custody-architecture.md(벤더 독립성)를 참조한다.