v0.0

D'CENT X 하드웨어 역량 검증 및 제약사항 문서¶

1. Executive Summary¶

본 문서는 D'CENT X 엔터프라이즈 콜드월렛의 핵심 하드웨어 컴포넌트 — Secure Element(SE), 디스플레이, USB-C, NFC(R3covery 카드 전용), 카메라 — 의 역량과 제약사항을 체계적으로 검증한다. Phase 4에서 설계한 WYSIWYS 하드웨어 검증 기능과 하드웨어 정책 엔진, Phase 5에서 정의한 펌웨어 서명 인터페이스의 구현 가능성을 하드웨어 사양 관점에서 평가하며, 하드웨어 팀에 확인이 필요한 항목을 [HW-CONFIRM] 태그로 명확히 식별한다.

검증 범위: - Secure Element: 칩 모델, 인증 수준, 암호화 알고리즘, 저장 공간, 작업 메모리, 연산 성능 - 디스플레이: 해상도, 표시 문자 수, 폰트 렌더링, WYSIWYS 화면 요구사항 - 입력 장치: 물리 버튼 구성, 다단계 확인 지원 - USB-C: 앱↔콜드월렛 통신 인터페이스 - NFC: R3covery 카드 전용 (규격, APDU 체이닝, 세션 키 교환, 안테나 성능) - 카메라/QR: QR 스캐너 사양, Animated QR 처리 성능

핵심 결론: Phase 4/5에서 도출된 SE 리소스 요구사항 합산 결과, 총 저장 공간 ~9.3KB + 작업 메모리 ~10KB가 필요하다. 일반적인 엔터프라이즈급 SE 칩(CC EAL5+)의 가용 공간(32-256KB EEPROM, 8-32KB RAM)을 고려할 때 기술적으로 실현 가능하나, 정확한 D'CENT X SE 사양은 하드웨어 팀 확인이 필수적이다.

2. Secure Element(SE) 역량 분석¶

2.1. SE 칩 모델 및 인증¶

추정 사양 (D'CENT 기존 제품 기반):

항목	추정 사양	근거	비고
칩 제조사	Infineon / STMicroelectronics / Samsung	하드웨어 월렛 시장 주요 SE 공급사	[HW-CONFIRM] 정확한 칩 모델명 확인 필요
CC 인증 수준	EAL5+ (최소 목표)	CLAUDE.md 기술 스택 요구사항	[HW-CONFIRM] 현재 인증 수준 확인
타겟 인증	EAL6+ (엔터프라이즈 차별화)	Ledger Flex가 EAL6+ 달성	신규 SE 칩 채택 시 타겟
GlobalPlatform	v2.3+	앱릿 관리 표준	[HW-CONFIRM] GP 버전 확인
JavaCard	v3.0.4+	SE 앱릿 실행 환경	[HW-CONFIRM] JC 버전 확인
Tamper Resistance	Active Shield, Voltage/Clock Glitch 방어	EAL5+ 필수 요구사항	CC 인증 범위에 포함

인증 수준별 영향도:

인증 수준	기술적 의미	엔터프라이즈 시장 영향
EAL4+	기본 보안 수준, 일반 MCU 가능	엔터프라이즈 불충분 — CLAUDE.md 기준 미달
EAL5+	반정형 설계 검증, 전용 SE 필수	최소 요구 수준 — 시장 기대치 충족
EAL6+	준정형 구현 검증	차별화 수준 — Ledger Enterprise와 동급
EAL7	정형 검증, 군사/국가급	과도한 비용, 엔터프라이즈 불필요

2.2. 지원 암호화 알고리즘¶

D'CENT X SE가 엔터프라이즈 펌웨어에서 요구하는 암호화 알고리즘 목록과 SE 내 처리 성능 추정:

알고리즘	용도	SE 내 처리 시간 추정	필수 여부	비고
ECDSA (secp256k1)	EVM 트랜잭션 서명	~100ms	필수	대부분의 SE가 하드웨어 가속 지원
Schnorr (BIP-340)	BTC Taproot 서명	~100ms	필수	secp256k1 기반, SE 하드웨어 가속 가능 [HW-CONFIRM]
Ed25519	향후 체인 확장 (Solana, Cosmos)	~80ms	높음	Curve25519 하드웨어 지원 여부 [HW-CONFIRM]
SHA-256	WYSIWYS 해시, Merkle 검증, PSBT	~1ms/block	필수	SE 하드웨어 가속 표준
HMAC-SHA512	BIP-32 키 파생	~2ms	필수	SHA-512 하드웨어 지원 필요
AES-128-CCM	R3covery 카드 NFC 세션 암호화	~0.5ms/block	필수	SE 하드웨어 가속 표준
ECDH (secp256k1)	R3covery 카드 NFC 세션 키 교환	~100ms	필수	ECDSA와 동일 커브
TRNG	논스 생성, 키 생성	하드웨어 기반	필수	EAL5+ 요구사항
DRBG (CTR_DRBG)	결정적 난수 생성	~0.1ms	필수	TRNG 시드 기반

MuSig2 관련 추가 요구: - RFC 6979 확장 nonce 생성: HMAC-DRBG 기반, ~2ms - Schnorr 부분 서명(partial signature): ~100ms - Nonce 상태 관리: Secure Storage에 임시 저장(66B per session)

2.3. 저장 공간 분석¶

Phase 4/5에서 도출된 SE 저장 요구사항을 합산한다.

Phase 4 — WYSIWYS 설계 (wysiwys-design.md 섹션 6.2):

영역	크기	출처
토큰 테이블 (초기 5종)	2,048 bytes (2KB)	각 토큰: 주소 20B + decimals 1B + 심볼 8B + 체인 4B + 예비 = ~40B x 50개 최대
함수 셀렉터 DB	4,096 bytes (4KB)	최대 256개 x 16B (셀렉터 4B + 메타데이터 12B)

Phase 4 — HW 정책 엔진 (hardware-policy-engine.md 섹션 6.1):

영역	크기	출처
정책 규칙 데이터	256 bytes	4개 규칙 설정값 + 카운터
Merkle Root	32 bytes	화이트리스트 Merkle Tree Root
Admin 공개키 세트	512 bytes	최대 8개 Admin 공개키 (각 64B)
정책 버전/메타	64 bytes	버전 번호, 쿨다운 상태
서명 검증 임시 영역	256 bytes	정책 업데이트 서명 검증
정책 소계	~1,120 bytes (1.1KB)

Phase 5 — 펌웨어 서명 인터페이스 (firmware-signing-interface.md 섹션 2.1):

영역	크기	출처
Private Keys (HD derived)	~1,600 bytes	최대 10개 HD 계정 x 160B (키 + 체인코드 + 메타) [HW-CONFIRM]
서명 카운터	4 bytes	전역 서명 횟수
MuSig2 세션 상태	132 bytes	최대 2개 세션 x 66B (nonce pair)

총 SE 저장 공간 요구사항 합산:

카테고리	크기	비율
Private Keys + 체인코드	~1,600B	17.2%
토큰 DB	2,048B	22.0%
함수 셀렉터 DB	4,096B	44.0%
정책 데이터 (전체)	1,120B	12.0%
MuSig2 세션	132B	1.4%
서명 카운터 + 메타	68B	0.7%
예비 (10% 마진)	~930B	10.0%
합계	~9,994B (~9.8KB)	100%

일반적 SE 가용 공간 비교:

SE 등급	EEPROM (비휘발 저장)	가용 (앱릿 데이터용)	판정
엔트리 SE (EAL4+)	32-64KB	~16-32KB	충분
표준 SE (EAL5+)	64-256KB	~32-128KB	충분
프리미엄 SE (EAL6+)	256-1024KB	~128-512KB	충분

결론: ~9.8KB의 저장 요구사항은 EAL5+ 이상 SE에서 충분히 수용 가능하다. 다만, D'CENT X SE의 실제 가용 EEPROM 크기는 하드웨어 팀 확인이 필요하다. [HW-CONFIRM] SE EEPROM 총 용량 및 앱릿 데이터 가용 공간 확인.

2.4. 작업 메모리(RAM) 분석¶

SE 내부 작업 메모리(RAM)는 앱릿 실행 시 동적으로 사용되며, 여러 작업이 순차적으로 수행되므로 동시 사용량을 기준으로 분석한다.

작업	메모리 요구	동시성	최대 동시 사용
PSBT 파싱 (스트리밍)	8,192B (8KB)	배타적	8,192B
Merkle Proof 검증 (depth 20)	1,024B (1KB)	PSBT 후 순차	1,024B
서명 검증 임시 (ECDSA verify)	256B	정책 평가 중	256B
Schnorr/ECDSA 서명 생성	512B	서명 시	512B
CBOR 디코딩 버퍼	512B	수신 시	512B
디스플레이 렌더링 버퍼	1,024B	WYSIWYS 표시	1,024B

최대 동시 메모리 사용량 (서명 파이프라인):

단계 1 (CBOR 수신 + PSBT 파싱):  8,192 + 512 = 8,704B
단계 2 (WYSIWYS 해시 + 표시):    1,024 + 256 = 1,280B  (PSBT 버퍼 해제 후)
단계 3 (정책 평가 + Merkle):      1,024 + 256 = 1,280B
단계 4 (서명 생성):               512B

피크 사용량: ~8,704B (~8.5KB) — 단계 1에서 최대

일반적 SE RAM 비교:

SE 등급	RAM	가용 (앱릿용)	판정
엔트리 SE	8-16KB	~4-8KB	부족 가능성
표준 SE (EAL5+)	16-32KB	~8-16KB	충분
프리미엄 SE (EAL6+)	32-64KB	~16-32KB	충분

결론: 피크 ~8.5KB의 작업 메모리 요구는 표준 SE(EAL5+)에서 수용 가능하나, 여유가 크지 않다. PSBT 대용량 트랜잭션(다중 입력/출력)의 경우 스트리밍 파싱 전략이 필수적이다. [HW-CONFIRM] SE RAM 총 용량 및 앱릿 가용 RAM 확인.

2.5. 연산 성능 분석¶

서명 파이프라인 전체 지연 시간 추정:

단계	연산 내용	예상 소요 시간	출처
CBOR 디코딩	수신 데이터 파싱	~50ms	SE 프로세서 성능 추정
PSBT/RLP 파싱	트랜잭션 바이너리 디코딩	~500ms (BTC) / ~200ms (EVM)	복잡도 기반 추정
WYSIWYS 해시 생성	SHA-256(필드 정규화)	~10ms	하드웨어 가속
해시 비교 검증	SE_PARSE_HASH vs APP_HASH	~1ms	바이트 비교
화면 렌더링	트랜잭션 정보 표시	~200ms	디스플레이 컨트롤러
사용자 확인 대기	물리 버튼 승인	가변 (3-30초)	사용자 의존
Merkle Proof 검증	SHA-256 x 20 depth	~50ms	hardware-policy-engine.md
정책 평가 (4규칙)	uint64 비교 + 카운터	~5ms	hardware-policy-engine.md
키 파생	BIP-32 HD 키 유도	~100ms	HMAC-SHA512 체인
서명 생성	Schnorr/ECDSA	~100ms	SE 하드웨어 가속
카운터 업데이트	EEPROM 쓰기	~20ms	NV 메모리 쓰기

자동 처리 합계 (사용자 대기 제외):

체인	자동 처리 시간	목표	판정
BTC (단순 전송)	~1,036ms (~1초)	5초 이내	충족
BTC (MuSig2 Round 1)	~1,136ms (~1.1초)	5초 이내	충족
EVM (단순 전송)	~736ms (~0.7초)	2초 이내	충족
EVM (ERC-20 transfer)	~836ms (~0.8초)	2초 이내	충족

MuSig2 추가 성능:

연산	소요 시간	빈도
Round 1: Nonce 생성 + 저장	~110ms	서명 시작 시
Round 2: Partial Sig 생성	~120ms	Nonce 수신 후
Admin 쿼럼 서명 검증 (3-of-5)	~300ms	정책 변경 시만

3. 디스플레이 역량 분석¶

3.1. 화면 해상도¶

항목	추정 사양	근거
해상도	320 x 240 px (QVGA) 또는 유사	D'CENT 기존 제품 및 경쟁사(COLDCARD, Keystone) 참고 [HW-CONFIRM]
디스플레이 유형	OLED 또는 IPS LCD	에어갭 디바이스 표준 [HW-CONFIRM]
컬러 깊이	1-bit (흑백) 또는 16-bit (컬러)	흑백 OLED 시 폰트 렌더링 단순화 [HW-CONFIRM]
DPI	~120-160 DPI	화면 물리 크기 ~2.4-3.0 인치 추정 [HW-CONFIRM]

3.2. 표시 가능 문자 수¶

320x240px 기준 추정:

폰트 크기	영문 문자/줄	한글 문자/줄	표시 줄 수	화면당 최대 표시
16px (소형)	~20자	~13자	~15줄	영문 300자 / 한글 195자
20px (표준)	~16자	~10자	~12줄	영문 192자 / 한글 120자
24px (대형)	~13자	~8자	~10줄	영문 130자 / 한글 80자

WYSIWYS 화면 요구사항:

화면 유형	필요 표시 항목	최소 줄 수	폰트 요구
일반 서명 확인	수신자, 금액, 수수료, 체인	6-8줄	20px 표준
다중 수신자 (페이지)	수신자, 금액, 페이지 표시	5-6줄	20px 표준
경고 화면 (CAUTION)	경고 메시지, 컨트랙트, 셀렉터	8-10줄	16px 소형
경고 화면 (CRITICAL)	Raw Hex, 경고 문구, 버튼	10-12줄	16px 소형
정책 위반	위반 유형, 요청값, 한도값	6-8줄	20px 표준

3.3. 다중 페이지 네비게이션¶

WYSIWYS 설계(Phase 4)에서 최대 20페이지 네비게이션을 요구한다.

화면 요구사항:

요구사항	하드웨어 요구	실현 가능성
20페이지 네비게이션	페이지 인덱스 메모리 (~40B)	충분
페이지 전환 응답 시간	<200ms	일반적 디스플레이 컨트롤러 충족
승인 버튼 제어	마지막 페이지에서만 활성화	펌웨어 로직으로 구현
경고 레벨별 렌더링	4단계(NONE/INFO/CAUTION/CRITICAL)	펌웨어 UI 프레임워크로 구현

3.4. 디스플레이 컨트롤러¶

항목	추정	비고
폰트 렌더링 메모리	~4-8KB (비트맵 폰트 캐시)	MCU 측 RAM 사용 (SE 외부)
한글 폰트 지원	경고 메시지용 한글 비트맵 필요	완성형 2,350자 중 경고용 ~200자
화면 전환 응답 시간	<100ms	OLED 직접 구동 시
QR 코드 화면 표시	Version 12-15 QR 렌더링	320x240px에서 모듈 크기 ~8px 확보 가능

4. 입력 장치 분석¶

4.1. 물리 버튼¶

항목	추정	요구사항
버튼 수	최소 2개 (승인/거부)	[HW-CONFIRM] 정확한 버튼 구성 확인
추가 필요	페이지 네비게이션용 좌/우 또는 상/하	2+2 = 4버튼 또는 조이스틱
디바운스	하드웨어 또는 펌웨어 디바운스	~50ms 기본

4.2. 다단계 확인 입력¶

WYSIWYS 및 정책 엔진에서 요구하는 다단계 물리 버튼 확인:

상황	확인 횟수	입력 시퀀스	구현 가능성
일반 서명 (NONE)	1회	승인 버튼 1회	기본 기능
정책 변경	2회	변경 인지 확인 + 최종 승인	펌웨어 상태 머신
Unknown Contract (CAUTION)	2회	경고 확인 + 서명 승인	펌웨어 상태 머신
파싱 불가 (CRITICAL)	3회	경고 인지 + 위험 인지 + 서명 승인	펌웨어 상태 머신
펌웨어 업데이트	2회	업데이트 인지 + 최종 승인	펌웨어 상태 머신

결론: 다단계 확인은 물리 버튼 하드웨어 변경 없이 펌웨어 상태 머신으로 구현 가능하다. 단, 4방향 네비게이션(20페이지 WYSIWYS)을 위해 최소 4버튼(또는 조이스틱)이 필요하다. [HW-CONFIRM] 네비게이션용 추가 입력 장치 유무.

5. NFC 인터페이스 분석 (R3covery 카드 전용)¶

참고: NFC는 R3covery 카드(시드 백업/복구) 전용이다. 오프라인 앱 ↔ 콜드월렛 간 서명 통신은 USB-C로 수행한다. Bluetooth는 엔터프라이즈 모드에서 비활성화된다.

5.1. NFC 규격 (R3covery 카드 통신)¶

항목	추정 사양	요구사항	비고
규격	ISO 14443 Type A	R3covery 카드 SE-to-SE 통신 표준	[HW-CONFIRM] Type A 또는 B
동작 주파수	13.56 MHz	ISO 14443 표준
통신 속도	106-848 kbps	106 kbps 기본, 고속 모드 가능	[HW-CONFIRM] 지원 속도
통신 거리	2-5cm	보안상 근거리 필수
전원	리더기(본체 디바이스) 공급 또는 자체 배터리	[HW-CONFIRM] NFC 전원 모드

5.2. APDU 체이닝 지원 (R3covery 카드)¶

R3covery 카드 SE-to-SE 통신에서의 NFC APDU 커맨드셋 하드웨어 지원:

항목	Standard APDU	Extended APDU
최대 데이터 길이	255 bytes/APDU	65,535 bytes/APDU
체이닝 필요 여부	256B+ 페이로드 시 필수	대부분 단일 APDU 가능
SE 지원 여부	모든 SE 지원	[HW-CONFIRM] SE/NFC 칩 지원 확인 (R3covery 카드용)
권장	기본	Extended 지원 시 우선 사용

체이닝 성능 추정:

페이로드 크기	Standard APDU	Extended APDU	NFC 전송 시간 (106kbps)
500B	2 APDU	1 APDU	~40ms
2KB	8 APDU	1 APDU	~160ms
10KB	40 APDU	1 APDU	~800ms
50KB	200 APDU	1 APDU	~4초

5.3. 세션 키 교환¶

R3covery 카드 SE-to-SE NFC 세션 암호화:

요구사항	SE 지원 필요	추정
ECDH 키 교환 (secp256k1)	ECDH 연산	SE에서 지원 (ECDSA와 동일 커브)
HKDF-SHA256 키 유도	SHA-256 + HMAC	SE 지원
AES-128-CCM 암호화	AES-128 + CCM 모드	SE 하드웨어 가속 표준

5.4. NFC 안테나 성능 (R3covery 카드)¶

항목	요구사항	비고
인식 거리	2-10cm	[HW-CONFIRM] 실측 안정 거리
안정성	연속 40+ APDU 교환 시 끊김 없음	R3covery 카드 시드 전송 요구
금속 간섭	최소화	SE 실드와의 간섭 여부 [HW-CONFIRM]
동시 디바이스	1:1 통신만 지원	보안상 다중 연결 차단

6. 카메라/QR 인터페이스 분석¶

6.1. QR 스캐너 (카메라 입력)¶

항목	추정 사양	요구사항	비고
카메라 해상도	VGA (640x480) 이상	QR Version 15 인식 기준	[HW-CONFIRM] 정확한 해상도
초점 거리	고정 초점 10-30cm	QR 코드 인식 최적 거리
프레임 레이트	15-30 fps	Animated QR 인식 기준 10fps+	[HW-CONFIRM] 실측 fps
QR 디코딩	MCU 소프트웨어 디코딩	SE 외부에서 처리 후 데이터 전달
자동 초점	고정 초점 권장	자동 초점 시 지연 발생

Animated QR 인식 요구사항:

파라미터	요구	근거
프레임 캡처 속도	10+ fps	100ms 프레임 전환 대응
QR 디코딩 속도	<50ms/frame	실시간 Fountain 프래그먼트 수집
연속 인식 안정성	99%+ per frame	에러 보정 Level L 기준

6.2. QR 코드 디스플레이 (화면 출력)¶

D'CENT X 화면에서 QR 코드를 생성하여 표시하는 기능:

항목	320x240px 기준	비고
최대 QR 크기	240 x 240 px	화면 높이에 맞춤
모듈 크기 (V12, 65 모듈)	~3.7px	인식 한계 (최소 4px 권장)
모듈 크기 (V10, 57 모듈)	~4.2px	인식 가능
최대 데이터 용량 (V10, Level L)	~652 bytes	Animated QR 시 프레임당
Animated QR 프레임 전환	100ms 간격	MCU 타이머 기반

결론: 320x240px 디스플레이에서 QR Version 10 (최대)까지 안정적으로 표시 가능하다. 프레임당 ~500-650 bytes의 Fountain 코드 프래그먼트를 표시할 수 있다. [HW-CONFIRM] 화면 해상도에 따라 QR 표시 가능 범위 재산정 필요.

6.3. Animated QR 처리 성능¶

작업	MCU/SE 분담	예상 처리 시간	비고
QR 프레임 캡처	MCU (카메라 드라이버)	~30ms/frame	하드웨어 의존
QR 디코딩	MCU (소프트웨어)	~30-50ms/frame	zbar/quirc 라이브러리
Fountain 디코딩	MCU	~10ms/frame	LT 코드 XOR 연산
CBOR 디코딩	MCU → SE 전달	~5ms	SE 내부에서 최종 처리
QR 프레임 생성	MCU	~20ms/frame	비트맵 렌더링
QR 프레임 표시	MCU (디스플레이 드라이버)	~5ms/frame	직접 메모리 매핑

대용량 PSBT 수신 시간 추정:

PSBT 크기	Animated QR 프레임 수	수신 시간	비고
1KB	3-4 프레임	~0.5초	단순 BTC 전송
5KB	15-20 프레임	~2-3초	다중 입력 BTC
20KB	60-80 프레임	~8-10초	MuSig2 PSBT
50KB	150-200 프레임	~20-25초	배치 트랜잭션

7. 엔터프라이즈 기능별 하드웨어 제약 매트릭스¶

7.1. 기능별 하드웨어 요구사항 vs 제약사항¶

기능	핵심 요구사항	SE 리소스	하드웨어 제약	대응 전략	위험도
WYSIWYS 파싱 엔진	PSBT/RLP/ABI 파싱, 해시 비교	RAM 8KB, 저장 6KB (토큰+셀렉터)	SE RAM 부족 시 파싱 불가	스트리밍 파싱 (청크 단위)	중간
HW 정책 엔진	4규칙 평가, Merkle Root 검증	저장 1.1KB, RAM 1KB	SE 성능 한계 시 평가 지연	단락 평가(short-circuit)	낮음
MuSig2 서명	2라운드 프로토콜, 상태 관리	RAM 512B, 저장 132B (세션)	Schnorr HW 지원 필요	SW 폴백(성능 저하)	중간
화이트리스트 Merkle 검증	SHA-256 x 20 depth	RAM 1KB, 저장 32B (Root)	SHA-256 HW 가속 필수	가속 없으면 depth 제한 (10)	낮음
펌웨어 업데이트	바이너리 수신, 코드 서명 검증	Flash 파티션 관리	듀얼 파티션(A/B) 필요	[HW-CONFIRM] Flash 레이아웃	높음
다중 체인 키 관리	BIP-32/44/84/86 키 파생	저장 ~1.6KB (10 계정)	계정 수 증가 시 저장 부족	최대 계정 수 제한	낮음
WYSIWYS 디스플레이	다중 페이지, 경고 레벨, 한글	디스플레이 해상도	320x240 시 정보량 제한	페이지 분할, 축약 표시	낮음
Animated QR 처리	Fountain 코드, 연속 프레임	카메라 fps, MCU 성능	대용량 PSBT 수신 지연	USB-C로 앱→콜드월렛 전송 시 제약 없음	낮음

7.2. 제약사항 대응 전략 상세¶

SE 저장 공간 부족 시: - 함수 셀렉터 DB를 256개에서 128개로 축소 → 저장 2KB 절감 - 토큰 DB를 50개 최대에서 20개로 축소 → 저장 ~800B 절감 - 미등록 항목은 오프라인 앱에서 메타데이터 제공 (SE는 해시 검증만)

SE RAM 부족 시: - PSBT 스트리밍 파싱: 전체 PSBT를 메모리에 로드하지 않고 청크 단위로 순차 파싱 - 디코딩과 해시 계산을 동시 수행(single-pass) → 메모리 피크 감소 - 대용량 PSBT(>10KB)는 USB-C 채널로 전송 (앱↔콜드월렛 간 USB-C 연결이므로 용량 제약 없음)

Schnorr 하드웨어 미지원 시: - SE 소프트웨어 Schnorr 구현 (성능 저하: 100ms → ~500ms) - MuSig2 성능 목표 조정 필요 (5초 → ~8초) - Schnorr HW 지원 SE 칩 교체 권장

디스플레이 해상도 부족 시 (320x240px 미만): - WYSIWYS 페이지 수 증가 (정보 분산) - 주소 축약 규칙 강화 (앞 6자 + 뒤 4자) - QR 코드 표시 Version 축소 (V8, 프레임당 ~400B)

7.3. 위험 요소 식별¶

위험 ID	영역	설명	영향도	발생 확률	대응
HW-R01	SE RAM	PSBT 대용량(>8KB) 파싱 시 메모리 부족	높음	중간	스트리밍 파싱 필수 설계
HW-R02	SE 알고리즘	Schnorr 하드웨어 미지원	높음	낮음	SW 폴백 또는 칩 교체
HW-R03	디스플레이	한글 폰트 렌더링 메모리 과다	중간	중간	경고용 한글만 비트맵 포함
HW-R04	NFC (R3covery 카드)	Extended APDU 미지원 시 R3covery 카드 통신 지연	중간	중간	Standard APDU 체이닝 최적화
HW-R05	Flash	펌웨어 듀얼 파티션(A/B) 공간 부족	높음	낮음	단일 파티션 + 복구 모드
HW-R06	카메라	Animated QR 인식률 저하(저조도, 반사)	중간	중간	환경 가이드, Animated QR 속도 조절

8. 하드웨어 팀 확인 요청 사항 ([HW-CONFIRM] 항목 정리)¶

8.1. 우선순위 1 — 서명 기능 관련 (구현 착수 전 필수 확인)¶

ID	카테고리	확인 항목	확인 결과별 설계 영향
HW-C01	SE 칩	정확한 SE 칩 모델명 (Infineon SLE78/SLC37? STM ST33? Samsung?)	칩별 가용 EEPROM/RAM/알고리즘 결정
HW-C02	SE 인증	현재 CC 인증 수준 (EAL5+? EAL6+?)	EAL5+ 미만 시 칩 교체 필수
HW-C03	SE 저장	SE EEPROM 총 용량 및 앱릿 데이터 가용 공간	~9.8KB 요구 충족 여부 → 미충족 시 DB 규모 축소
HW-C04	SE RAM	SE RAM 총 용량 및 앱릿 가용 RAM	~8.5KB 피크 충족 여부 → 미충족 시 스트리밍 파싱 필수
HW-C05	SE 알고리즘	Schnorr(BIP-340) 하드웨어 가속 지원 여부	미지원 시 SW 폴백 설계 + 성능 목표 조정
HW-C06	SE 알고리즘	Ed25519 하드웨어 지원 여부	미지원 시 Solana/Cosmos 확장 일정 연기
HW-C07	SE 플랫폼	GlobalPlatform 버전 및 JavaCard 버전	앱릿 개발 환경 결정

8.2. 우선순위 2 — 정책 엔진 / USB-C / NFC(R3covery 카드) 관련¶

ID	카테고리	확인 항목	확인 결과별 설계 영향
HW-C08	USB-C	USB-C 인터페이스 사양 및 데이터 전송 프로토콜	앱↔콜드월렛 통신 프로토콜 확정
HW-C09	USB-C	USB-C 전원 공급 및 데이터 동시 지원 여부	서명 세션 중 충전 가능 여부
HW-C10	NFC (R3covery 카드)	NFC 안테나 안정 통신 거리 및 연속 APDU 교환 안정성	R3covery 카드 SE-to-SE NFC 통신 가능 여부
HW-C11	NFC (R3covery 카드)	NFC 전원 모드 (패시브/액티브/배터리)	R3covery 카드 세션 유지 시간 및 성능 영향
HW-C12	Flash	MCU Flash 총 용량 및 펌웨어 파티션 레이아웃	듀얼 파티션(A/B) 지원 가능 여부

8.3. 우선순위 3 — 디스플레이 / 카메라 관련¶

ID	카테고리	확인 항목	확인 결과별 설계 영향
HW-C13	디스플레이	정확한 화면 해상도 및 디스플레이 유형 (OLED/LCD)	WYSIWYS 화면 레이아웃 최종 설계
HW-C14	디스플레이	컬러 깊이 (흑백/16bit)	경고 레벨 시각적 구분 방식 (색상 vs 아이콘)
HW-C15	입력	물리 버튼 구성 (개수, 배치)	4방향 네비게이션 지원 여부 → 미지원 시 2버튼 네비게이션 UX
HW-C16	카메라	카메라 해상도 및 실측 프레임 레이트	Animated QR 인식 성능 기준 설정
HW-C17	카메라	초점 방식 (고정/자동) 및 최적 인식 거리	QR 스캔 UX 가이드라인

8.4. 확인 기한 권고¶

우선순위	항목 수	권고 기한	근거
P1 (서명 기능)	7건	펌웨어 개발 착수 2주 전	SE 리소스 확정 없이 앱릿 설계 불가
P2 (정책/USB-C/NFC)	5건	펌웨어 개발 착수 4주 전	USB-C 프로토콜 + NFC(R3covery 카드) 커맨드셋은 앱릿과 병행 개발 가능
P3 (디스플레이/카메라)	5건	펌웨어 개발 착수 6주 전	UI 렌더링은 후순위 개발 가능

부록 A: SE 리소스 버짓 요약 다이어그램¶

SE EEPROM 사용량 (추정 ~9.8KB / 목표 가용 32KB+)
├── Private Keys (HD)     ████████░░░░░░░  1.6KB (17%)
├── 함수 셀렉터 DB        ████████████████  4.0KB (41%)
├── 토큰 DB              ████████░░░░░░░  2.0KB (21%)
├── 정책 데이터           ████░░░░░░░░░░░  1.1KB (11%)
├── MuSig2 세션           █░░░░░░░░░░░░░░  0.1KB (1%)
├── 카운터/메타           █░░░░░░░░░░░░░░  0.1KB (1%)
└── 예비 마진             ███░░░░░░░░░░░░  0.9KB (9%)

SE RAM 피크 사용량 (추정 ~8.5KB / 목표 가용 8-16KB+)
├── PSBT 파싱 버퍼        ████████████████  8.0KB (94%)
├── CBOR 버퍼             █░░░░░░░░░░░░░░  0.5KB (6%)
└── (PSBT 해제 후 후속 단계 ~1.3KB)

본 문서는 Phase 6 Firmware Requirements의 첫 번째 산출물로, D'CENT X 하드웨어의 역량과 제약사항을 체계적으로 검증한다. Phase 4 WYSIWYS 설계(wysiwys-design.md) 및 HW 정책 엔진(hardware-policy-engine.md), Phase 5 펌웨어 서명 인터페이스(firmware-signing-interface.md)에서 도출된 SE 리소스 요구사항을 합산 분석하여 실현 가능성을 정량적으로 평가하였다. [HW-CONFIRM] 태그로 표시된 17건의 확인 필요 항목은 펌웨어 개발 착수 전 하드웨어 팀과 협의가 필수적이다.