v0.0

WYSIWYS(What You See Is What You Sign) 하드웨어 검증 기능 설계서

1. Executive Summary

WYSIWYS(What You See Is What You Sign)는 사용자가 하드웨어 디바이스 화면에서 직접 확인한 트랜잭션 내용과 실제 서명되는 트랜잭션이 정확히 일치함을 보장하는 보안 메커니즘이다. 이는 블라인드 사이닝(Blind Signing) 공격에 대한 근본적인 방어 수단으로, D'CENT 엔터프라이즈의 핵심 차별화 기술이다.

1.1. 블라인드 사이닝의 위협

블라인드 사이닝이란 사용자가 트랜잭션의 실제 내용을 확인하지 못한 채 서명하는 상황을 말한다. 이는 다음과 같은 공격 벡터를 발생시킨다:

공격 유형	시나리오	피해 규모
주소 치환	소프트웨어가 표시하는 수신 주소와 실제 서명에 포함된 주소가 다름	전액 탈취
금액 조작	표시된 금액보다 큰 금액이 실제 트랜잭션에 포함	초과분 탈취
컨트랙트 위장	단순 전송으로 표시하나 실제로는 악성 컨트랙트 호출	approve() 무제한 승인 등
수수료 폭등	비정상적으로 높은 Gas Fee 설정	수수료 착취

1.2. WYSIWYS의 해결 원리

D'CENT X 콜드월렛의 Secure Element(SE)가 트랜잭션 원본 데이터를 직접 파싱하여 디바이스 화면에 표시한다. 오프라인 앱이 전달한 트랜잭션 데이터와 SE 내부 파싱 결과를 비교 검증함으로써, 소프트웨어 계층의 어떤 조작도 하드웨어에서 탐지 가능하다.

아키텍처 제약조건 AC-TX-02: "모든 서명은 WYSIWYS 확인 후 물리 버튼 승인"

---

2. 체인별 트랜잭션 파싱 범위 정의

2.1. Bitcoin (PSBT — BIP-174/BIP-370)

D'CENT X SE 펌웨어는 PSBT(Partially Signed Bitcoin Transaction) 바이너리를 직접 파싱하여 다음 항목을 추출하고 화면에 표시한다.

필수 표시 항목:

항목	파싱 소스	표시 방식	검증 포인트
수신 주소	PSBT Output scriptPubKey	전체 주소 (축약 표시 + 전체 확인 옵션)	오프라인 앱 제공 주소와 일치 여부
전송 금액	PSBT Output value (satoshis)	BTC 단위 + sats 단위 병행 표시	금액 정합성
네트워크 수수료	입력 합계 - 출력 합계	BTC 단위 + sats/vB 수수료율	비정상 수수료 탐지
UTXO 입력 수	PSBT Input count	"N개 입력 사용"	UTXO 투명성
Change 주소	PSBT Change Output (BIP-44 경로 매칭)	"Change → [주소]" 또는 "잔금 반환"	Change 주소 탈취 방지

선택 표시 항목:

항목	조건	표시 방식
OP_RETURN 데이터	OP_RETURN 출력 존재 시	Hex 또는 UTF-8 디코딩 (80바이트 제한)
Locktime	nLockTime > 0 시	"잠금 해제: 블록 [N] / 시간 [T]"
RBF 표시	nSequence < 0xFFFFFFFE 시	"RBF(수수료 인상) 가능"
MuSig2 참여자 정보	BIP-373 필드 존재 시	"다중 서명 참여자 N명 중 K번째"

PSBT 파싱 범위: - PSBTv0 (BIP-174): 전체 지원 - PSBTv2 (BIP-370): 전체 지원 (Creator/Constructor/Signer 역할 분리) - BIP-373 확장 필드: MuSig2 participant public keys, public nonces, partial signatures 파싱

2.2. EVM 체인 (EIP-712 Structured Data)

EVM 트랜잭션은 EIP-712 구조화 데이터 또는 Raw Transaction으로 전달되며, SE가 RLP 디코딩 및 ABI 디코딩을 수행한다.

필수 표시 항목:

항목	파싱 소스	표시 방식	검증 포인트
수신 주소	to 필드	전체 주소 (EIP-55 체크섬 포함)	주소 치환 방지
전송 금액	value 필드 (wei)	ETH 단위 변환 표시	금액 정합성
Gas Fee	maxFeePerGas × gasLimit	최대 수수료 (Gwei + ETH 환산)	비정상 Gas 탐지
체인 ID	chainId 필드	네트워크명 표시 (Ethereum, Polygon 등)	잘못된 체인 서명 방지
Nonce	nonce 필드	"트랜잭션 #[N]"	리플레이 방지 확인

컨트랙트 호출 시 추가 표시:

항목	파싱 방식	표시 방식
함수 Selector	calldata 앞 4바이트	함수명 표시 (알려진 셀렉터) 또는 "0xABCDABCD"
ERC-20 transfer	ABI 디코딩: transfer(address,uint256)	"토큰 전송: [수량] [심볼] → [주소]"
ERC-20 approve	ABI 디코딩: approve(address,uint256)	"승인: [수량] [심볼] → [spender]" + 무제한 경고
Safe execTransaction	ABI 디코딩: Safe 멀티시그 실행	"Safe 다중 서명 실행: [수신자] [금액]"
알 수 없는 함수	셀렉터 미등록	Unknown Contract Warning (섹션 3.3 참조)

SE 내부 함수 셀렉터 데이터베이스: - 사전 등록: ERC-20 (transfer, approve, transferFrom), ERC-721 (safeTransferFrom), Safe (execTransaction, addOwnerWithThreshold, changeThreshold) - 업데이트: 관리자 쿼럼 승인을 통한 에어갭 펌웨어 업데이트 시 추가 가능 - 용량 제한: SE 저장 공간 내 최대 256개 셀렉터 등록

2.3. ERC-20 스테이블코인 (USDT/USDC)

스테이블코인은 EVM 체인의 ERC-20 컨트랙트 호출이지만, 엔터프라이즈에서 가장 빈번하게 사용되므로 특화 파싱을 적용한다.

필수 표시 항목:

항목	파싱 방식	표시 방식	특이사항
토큰 심볼	컨트랙트 주소 → SE 내 등록 토큰 매핑	"USDT" / "USDC"	알려진 컨트랙트 주소 사전 등록
수신 주소	ABI 디코딩 transfer(address,uint256)	전체 주소	EIP-55 체크섬 검증
전송 금액	ABI 디코딩 uint256 → 소수점 변환	"1,000.00 USDT"	decimals: USDT=6, USDC=6
approve 경고	approve(address,uint256) 감지	"경고: 토큰 사용 승인" + 금액	무제한 승인 시 특별 경고

소수점 처리: - SE 내부에 토큰별 decimals 값 사전 등록 (USDT: 6, USDC: 6, DAI: 18, WBTC: 8) - 미등록 토큰: decimals 0으로 처리 + "소수점 미확인" 경고 표시 - 표시 형식: 천 단위 구분(1,000.00), 소수점 이하 최대 8자리

SE 내부 등록 토큰 목록 (초기):

토큰	체인	컨트랙트 주소	Decimals
USDT	Ethereum	0xdAC17F958D2ee523a2206206994597C13D831ec7	6
USDC	Ethereum	0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48	6
USDT	Tron	TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t	6
DAI	Ethereum	0x6B175474E89094C44Da98b954EedeAC495271d0F	18
WBTC	Ethereum	0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599	8

토큰 목록 업데이트는 관리자 쿼럼 승인 + 에어갭 경유 펌웨어 업데이트를 통해 수행한다.

2.4. 향후 체인 확장 인터페이스

새로운 체인 추가 시 SE 파싱 모듈을 확장할 수 있는 표준 인터페이스를 정의한다.

Chain Parser Interface:

ChainParser {
  chain_id: uint32          // SLIP-0044 coin type
  parse(raw_tx: bytes) → ParsedTransaction
  validate(parsed: ParsedTransaction, expected: ExpectedFields) → ValidationResult
  format_display(parsed: ParsedTransaction) → DisplayPages[]
}

ParsedTransaction {
  recipients: [{address: string, amount: BigInt, asset: string}]
  fee: {amount: BigInt, unit: string}
  metadata: {chain: string, nonce: uint64, memo: string?}
}

DisplayPage {
  title: string             // 페이지 제목 (e.g., "수신자 1/3")
  fields: [{label: string, value: string, warning: WarningLevel?}]
}

WarningLevel: NONE | INFO | CAUTION | CRITICAL

확장 대상 체인 (우선순위):

체인	TX 포맷	파싱 복잡도	도입 시기
Solana	Borsh/Anchor IDL	높음 (프로그램 ID 기반)	Phase 2 출시
Cosmos (ATOM)	Protobuf (amino/direct)	중간	Phase 2 출시
Polkadot	SCALE 인코딩	높음	Phase 3 출시
Tron	Protobuf	중간	Phase 1 출시 (USDT 수요)

---

3. 디바이스 화면 표시 요구사항

3.1. 필수 vs 선택 표시 항목

필수 표시 항목 (서명 전 반드시 화면에 표시):

항목	중요도	미표시 시 동작
수신 주소	최고	서명 불가
전송 금액 + 자산 유형	최고	서명 불가
네트워크 수수료	높음	서명 불가
체인/네트워크 정보	높음	서명 불가
경고 메시지 (해당 시)	높음	경고 단계에 따라 차등

선택 표시 항목 (사용자 요청 시 추가 페이지로 표시):

항목	조건
UTXO 입력 상세	사용자가 "상세" 버튼 선택 시
Change 주소	BTC 트랜잭션에서 Change 출력 존재 시
OP_RETURN 데이터	데이터 포함 시
컨트랙트 소스 주소	EVM 컨트랙트 호출 시
Nonce/Locktime	비기본값 설정 시

3.2. 주소 축약 표시 규칙

D'CENT X 디바이스의 화면 크기 제약(예상: 320×240px 또는 유사 해상도)에 따른 주소 표시 전략:

기본 축약 규칙:

전체 주소: 0x742d35Cc6634C0532925a3b844Bc9e7595f2bD14
축약 표시: 0x742d35...f2bD14  (앞 8자 + ... + 뒤 6자)

체인별 축약 규칙:

체인	주소 길이	축약 규칙	예시
Bitcoin (Bech32)	42-62자	앞 10자 + ... + 뒤 6자	bc1qxy2kg...p4q0ssp
Ethereum (Hex)	42자	앞 8자 + ... + 뒤 6자	0x742d35...f2bD14
Tron (Base58)	34자	앞 8자 + ... + 뒤 6자	TR7NHqje...Lj6t

전체 주소 확인 방식: 1. 축약 표시 상태에서 "전체 보기" 버튼 → 주소 전체를 스크롤 표시 2. QR 코드로 주소 표시 → 오프라인 앱에서 스캔하여 대조 (선택적) 3. 앞 8자 + 뒤 6자 이외에도 중간 일부를 번갈아 표시하는 "Rotating Display" 옵션

3.3. 다중 수신자 트랜잭션 페이지 네비게이션

다중 출력(Multi-Output) 트랜잭션의 화면 표시:

┌─────────────────────────────┐
│  트랜잭션 확인  [1/3]        │
│                              │
│  수신자 1:                   │
│  0x742d35...f2bD14           │
│  금액: 1.5 ETH               │
│                              │
│  ◀ 이전    다음 ▶            │
│                              │
│  [거부]        [승인]         │
└─────────────────────────────┘

페이지 구성: 1. 페이지 1: 요약 (총 수신자 수, 총 금액, 총 수수료) 2. 페이지 2~N: 각 수신자별 상세 (주소, 금액, 자산) 3. 마지막 페이지: 최종 확인 (총 금액 + 수수료 합계)

제약: - 최대 표시 가능 수신자: 20명 (이상 시 "20+ 수신자" 경고 + 개별 확인 불가 → 서명 거부 권장) - 각 페이지 자동 넘김 없음 — 사용자가 명시적으로 다음 버튼 선택 - 마지막 페이지에서만 "승인" 버튼 활성화 (모든 수신자 확인 후)

3.4. Unknown Contract Warning (알 수 없는 컨트랙트 경고)

SE 내부 함수 셀렉터 데이터베이스에 등록되지 않은 컨트랙트 호출 시:

┌─────────────────────────────┐
│  ⚠ 경고: 알 수 없는 컨트랙트  │
│                              │
│  컨트랙트: 0xAbCd...EfGh     │
│  함수: 0x12345678            │
│  데이터: 128 bytes           │
│                              │
│  이 트랜잭션의 내용을         │
│  완전히 파싱할 수 없습니다.   │
│                              │
│  [Raw 데이터 보기]            │
│                              │
│  [거부] (권장)   [위험 승인]  │
└─────────────────────────────┘

경고 레벨 체계:

레벨	조건	화면 표시	승인 절차
NONE	알려진 함수 + 정상 파싱	일반 확인 화면	물리 버튼 1회
INFO	알려진 함수 + 비정상 파라미터	파라미터 경고	물리 버튼 1회
CAUTION	알 수 없는 함수	Unknown Contract Warning	물리 버튼 2회 (경고 확인 + 서명 승인)
CRITICAL	파싱 실패 (데이터 손상)	Raw Hex 표시 + 서명 거부 권장	물리 버튼 3회 (경고 확인 + 위험 인지 + 서명 승인)

---

4. WYSIWYS 검증 플로우

4.1. 검증 아키텍처

오프라인 앱                          D'CENT X 콜드월렛
┌──────────────┐                    ┌──────────────────────┐
│ TX 데이터     │                    │      SE 영역          │
│ + 메타데이터  │──QR/USB-C────────▶│                       │
│              │                    │  1. TX 바이너리 수신   │
│              │                    │  2. 독립 파싱 수행     │
│              │                    │  3. 파싱 결과 화면 표시 │
│              │                    │  4. 물리 버튼 대기     │
│              │                    │                       │
│              │                    │  ┌───────────────┐   │
│              │                    │  │ 해시 비교 검증  │   │
│              │                    │  │               │   │
│              │                    │  │ App Hash      │   │
│              │                    │  │   vs          │   │
│              │                    │  │ SE Parse Hash │   │
│              │                    │  └───────────────┘   │
│              │◀──QR/USB-C────────│                       │
│ 서명 결과    │                    │  서명 / 거부          │
└──────────────┘                    └──────────────────────┘

4.2. 상세 검증 플로우

[1] 오프라인 앱에서 TX 데이터 수신 (QR/USB-C)
     │
     ▼
[2] SE 내부 트랜잭션 파싱
     ├─ BTC: PSBT 바이너리 디코딩
     ├─ EVM: RLP 디코딩 + ABI 디코딩
     └─ 스테이블코인: 토큰 컨트랙트 매핑 + decimals 적용
     │
     ▼
[3] 파싱 결과 해시 생성
     ├─ SE 파싱 결과에서 핵심 필드 추출
     │   (수신 주소, 금액, 수수료, 체인 ID)
     └─ SHA-256 해시 생성 → SE_PARSE_HASH
     │
     ▼
[4] 오프라인 앱 제공 해시와 비교
     ├─ 오프라인 앱이 동일 필드로 생성한 APP_HASH 수신
     └─ SE_PARSE_HASH == APP_HASH ?
     │
     ├─── 일치 ──▶ [5] 정상 WYSIWYS 표시
     │                  │
     │                  ▼
     │              [6] 물리 버튼 승인 대기
     │                  │
     │                  ├─ 승인 → SE 내부 서명 수행
     │                  └─ 거부 → 서명 거부 반환
     │
     └─── 불일치 ──▶ [7] 해시 불일치 처리 (아래 4.3)

4.3. 해시 불일치 시 동작

해시 불일치는 중간자 공격(MITM) 또는 데이터 변조 가능성을 의미한다.

해시 불일치 감지
     │
     ▼
┌─────────────────────────────────┐
│  ⛔ 보안 경고                    │
│                                  │
│  트랜잭션 데이터 불일치 감지!     │
│                                  │
│  오프라인 앱이 전달한 내용과      │
│  디바이스가 파싱한 내용이         │
│  다릅니다.                       │
│                                  │
│  중간자 공격 가능성이 있습니다.   │
│                                  │
│  서명이 차단되었습니다.           │
│                                  │
│  [확인]                          │
└─────────────────────────────────┘

동작 규칙: 1. 서명 즉시 거부 — 사용자 선택 없이 자동 차단 2. 보안 경고 화면 표시 — 5초 이상 유지 (즉시 닫힘 방지) 3. 감사 이벤트 생성 — 불일치 상세(기대 해시, 실제 해시) SE 로그에 기록 4. 위반 사유 코드 반환 — 오프라인 앱으로 WYSIWYS_HASH_MISMATCH 에러 코드 전달 5. 연속 불일치 감지 — 3회 연속 불일치 시 해당 월렛의 서명 기능 24시간 잠금

4.4. 파싱 불가 트랜잭션 처리

SE가 트랜잭션 데이터를 파싱할 수 없는 경우 (미지원 체인, 손상된 데이터, 알 수 없는 인코딩):

파싱 실패 감지
     │
     ▼
[1] Raw Hex 표시
     ├─ 트랜잭션 바이너리의 처음 256바이트를 Hex로 표시
     └─ 전체 바이트 수 표시
     │
     ▼
[2] 강화 경고 표시
     │
     ▼
┌─────────────────────────────────┐
│  ⚠ 트랜잭션 파싱 불가            │
│                                  │
│  이 트랜잭션의 내용을 해석할      │
│  수 없습니다.                    │
│                                  │
│  Raw 데이터: 0x02f901...         │
│  크기: 342 bytes                 │
│                                  │
│  서명 시 의도치 않은 자산 이동    │
│  위험이 있습니다.                │
│                                  │
│  [거부] (권장)   [위험 승인]     │
└─────────────────────────────────┘

사용자 선택: - 거부 (권장): 서명 거부 + WYSIWYS_PARSE_FAILED 에러 코드 반환 - 위험 승인: 물리 버튼 3회 순차 확인 (경고 인지 → 위험 인지 → 최종 서명 승인) 후 서명 수행 - 감사 로그에 "파싱 불가 상태에서 사용자가 위험 승인" 기록 - 정책 설정에서 "파싱 불가 트랜잭션 서명 금지" 옵션 제공 (Admin 설정)

---

5. 경쟁사 대비 차별화 포인트

5.1. 차별화 비교 매트릭스

항목	D'CENT Enterprise	Fireblocks	BitGo	Ledger Enterprise
서명 전 TX 검증	하드웨어 SE 파싱	소프트웨어만	소프트웨어만	제한적 하드웨어
검증 위치	SE 내부 (변조 불가)	서버 + 클라이언트	서버	SE + 제한적 파싱
블라인드 사이닝 방어	완전 방어	방어 불가	방어 불가	부분 방어
멀티체인 파싱	BTC + EVM + 확장	해당 없음 (SW)	해당 없음 (SW)	BTC + ETH 제한
Unknown Contract 경고	경고 레벨 체계	알림만	알림만	기본 경고
해시 불일치 대응	자동 서명 거부	해당 없음	해당 없음	기본 경고

5.2. Fireblocks 대비 핵심 차별화

Fireblocks는 전체 트랜잭션 검증을 소프트웨어(MPC-CMP 서버)에서 수행한다. 서버가 침해될 경우 트랜잭션 내용 조작이 가능하며, 사용자는 실제 서명 내용을 하드웨어 수준에서 확인할 방법이 없다.

D'CENT은 SE가 트랜잭션을 직접 파싱하므로, 소프트웨어 계층 전체가 침해되어도 하드웨어 화면에 정확한 트랜잭션 내용이 표시된다.

5.3. Ledger Enterprise 대비 차별화

Ledger Enterprise는 제한적 WYSIWYS를 제공하지만: - EVM 컨트랙트 호출의 상세 파싱이 제한적 (많은 경우 블라인드 사이닝 허용) - 엔터프라이즈 멀티체인 환경에서의 파싱 범위가 좁음 - Unknown Contract 경고가 단순 경고에 그침 (경고 레벨 체계 없음)

D'CENT은 ABI 기반 함수 셀렉터 데이터베이스와 경고 레벨 체계를 통해, 알 수 없는 컨트랙트에 대해서도 단계적이고 명확한 사용자 안내를 제공한다.

---

6. 펌웨어 요구사항 요약 (Phase 6 FW-03 연계용)

6.1. SE 펌웨어 요구사항

ID	요구사항	우선순위	연계
FW-WYSIWYS-01	PSBT (BIP-174/370) 바이너리 파싱 엔진	필수	섹션 2.1
FW-WYSIWYS-02	EVM RLP 디코딩 + ABI 디코딩 엔진	필수	섹션 2.2
FW-WYSIWYS-03	토큰 컨트랙트 매핑 테이블 (초기 5종)	필수	섹션 2.3
FW-WYSIWYS-04	함수 셀렉터 데이터베이스 (초기 10종, 최대 256개)	필수	섹션 2.2
FW-WYSIWYS-05	SHA-256 해시 비교 검증 로직	필수	섹션 4.2
FW-WYSIWYS-06	경고 레벨 체계 (4단계) 화면 렌더링	필수	섹션 3.4
FW-WYSIWYS-07	다중 페이지 네비게이션 UI (최대 20 페이지)	필수	섹션 3.3
FW-WYSIWYS-08	Chain Parser Interface 구현 (확장용)	높음	섹션 2.4
FW-WYSIWYS-09	주소 축약/전체 표시 전환	높음	섹션 3.2
FW-WYSIWYS-10	해시 불일치 시 자동 서명 거부 + 잠금 로직	필수	섹션 4.3

6.2. SE 리소스 요구사항

항목	요구 사양	비고
파싱 메모리	최소 8KB 작업 메모리	PSBT 대용량 트랜잭션 파싱 시
저장 공간	토큰 테이블 2KB + 셀렉터 DB 4KB	최대 256 셀렉터 × 16바이트
화면 렌더링	한글/영문 혼합 폰트 지원	금액, 주소, 경고 메시지
처리 시간	파싱 + 검증 3초 이내	사용자 체감 지연 최소화

---

7. Phase 3 연계 사항

본 문서는 Phase 3 airgap-signing-flow.md의 Stage 3: Sign 단계에서 정의된 "WYSIWYS 표시 → 물리 버튼 승인" 절차를 상세화한 것이다.

Phase 3 정의	본 문서 상세화
"WYSIWYS 확인 후 물리 버튼 승인" (AC-TX-02)	체인별 파싱 범위, 표시 항목, 검증 플로우, 경고 체계 전체 설계
"수신 주소 전체 표시"	축약 표시 규칙 + 전체 확인 방식 + 체인별 규칙
"WYSIWYS 불일치 → 서명 거부 + 보안 경고"	해시 비교 검증 로직, 자동 차단, 잠금 메커니즘, 감사 로그

Phase 5 System Architecture Design에서 SE-앱 간 데이터 포맷(UR/CBOR 스키마)과 해시 비교 프로토콜의 바이트 수준 명세가 추가로 필요하다.

---

본 문서는 Phase 4 Differentiation & Extended Architecture의 일부로, D'CENT 엔터프라이즈의 핵심 차별화 요소인 하드웨어 수준 트랜잭션 검증을 설계한다. Phase 3 에어갭 서명 플로우(airgap-signing-flow.md)의 WYSIWYS 요구사항을 상세화하며, Phase 6 펌웨어 요구사항(FW-03)의 입력 문서가 된다.

---

관련 문서

• 하드웨어 레벨 정책 엔진 설계서 -- 시스템 아키텍처
• MPC-TSS 웜 월렛 계층 설계서 -- 시스템 아키텍처
• 온프레미스 / 제로클라우드 아키텍처 설계서 -- 시스템 아키텍처
• 셀프 커스터디 / 벤더 락인 제로 구조 설계서 -- 시스템 아키텍처
• 티어드 커스터디 아키텍처 설계서 -- 시스템 아키텍처