콘텐츠로 이동

v0.2

Layer 1 핵심 서명 플로우 (Core Signing Flow)

1. Executive Summary

본 문서는 D'CENT Enterprise의 Layer 1 핵심 서명 플로우를 정의한다. Phase 12에서 확정된 3계층 레이어드 문서 구조(Layer 1 Core Flow / Layer 2 Segment Delta / Layer 3 Environment Annotation)의 첫 번째 레이어로서, 모든 시나리오(S1~S8)에 공통 적용되는 환경/세그먼트 중립 디지털 플로우를 상세 설계한다.

v0.0 airgap-signing-flow.md와의 관계:

v0.0에서 설계한 Request-Approve-Sign-Broadcast 4단계 파이프라인을 기반으로, 다음을 확장한다:

  • 4단계 파이프라인의 각 단계를 번호부 스텝(Step 1~9)으로 상세화
  • 3개 서명 프로토콜(MuSig2/Safe/MPC-TSS)별 절차 분기를 명시
  • WYSIWYS 하드웨어 검증을 독립 필수 스텝으로 격상 (Bybit 사건 교훈)
  • QR + USB-C 통신 변종(대용량 TX, 다수 서명자)을 프로토콜 수준에서 설계

본 문서는 v0.0 문서의 확장이지 대체가 아니다. v0.0의 상태 머신, 에러 핸들링, 컴플라이언스 매핑은 그대로 유효하며, 본 문서는 서명 실행 절차의 상세도를 높인다.

적용 범위: S1~S8 전체 시나리오. 물리 환경(콜드룸/비콜드룸)이나 고객 세그먼트(셀프 커스터디/수탁/토큰 발행)에 대한 언급은 포함하지 않는다. 물리 절차는 Layer 3 어노테이션(signing-coldroom-annotation.md, signing-noncoldroom-annotation.md)에서, 세그먼트 차이는 Phase 14의 Layer 2 델타에서 처리한다.

Step 참조 체계: 본 문서의 Step 1~9 번호는 Layer 2 델타와 Layer 3 어노테이션이 [Delta] Step N:, [CR Annotation] Before Step N:, [NCR Annotation] After Step N: 형식으로 참조하는 기준 번호이다.

2. 공통 서명 파이프라인

2.1. 파이프라인 개요

v0.0의 4단계 파이프라인을 9개 번호부 스텝으로 상세화한다.

REQUEST 단계        APPROVE 단계       SIGN 단계          BROADCAST 단계
┌─────────────┐    ┌─────────────┐    ┌──────────────┐    ┌─────────────┐
│ Step 1       │    │ Step 2       │    │ Step 3       │    │ Step 8       │
│ TX 생성      │───▶│ 정책 검증    │───▶│ 에어갭 전달   │    │ 서명 집계    │
│              │    │              │    │              │    │              │
│ Step 9       │    │              │    │ Step 4       │    │              │
│ 확인 및 완료  │◀───│              │    │ 오프라인 수신  │    │              │
└─────────────┘    └─────────────┘    │              │    └──────▲──────┘
                                      │ Step 5       │           │
                                      │ WYSIWYS 검증  │           │
                                      │              │           │
                                      │ Step 6       │           │
                                      │ SE 서명 실행  │───────────┘
                                      │              │  (via Step 7)
                                      │ Step 7       │
                                      │ 서명 반환     │
                                      └──────────────┘

2.2. 스텝별 요약

Step v0.0 단계 컴포넌트 역할 핵심 액션 데이터 흐름
Step 1 Request 온라인 대시보드 Initiator TX 생성 및 승인 요청 -> 미서명 TX
Step 2 Approve 온라인 대시보드 Approver x M 정책 검증 + 승인 결정 미서명 TX -> 승인된 TX
Step 3 Sign (준비) 온라인 대시보드 시스템 에어갭 전달용 QR 생성 승인된 TX -> QR 코드
Step 4 Sign (수신) 오프라인 서명 앱 Approver QR 스캔으로 TX 수신 + USB-C로 콜드월렛 전달 QR -> 서명 요청
Step 5 Sign (검증) D'CENT X 콜드월렛 Approver WYSIWYS 하드웨어 검증 서명 요청 -> SE 표시
Step 6 Sign (실행) D'CENT X 콜드월렛 Approver 물리 버튼 승인 + SE 서명 SE 표시 -> 부분 서명
Step 7 Sign (반환) 오프라인 서명 앱 -> 대시보드 Approver 서명 결과 에어갭 반환 부분 서명 -> QR -> 대시보드
Step 8 Broadcast 온라인 대시보드 시스템 서명 집계 + 블록체인 전파 M개 부분 서명 -> 완성 TX
Step 9 Broadcast 온라인 대시보드 시스템/Initiator 확인 대기 + 완료 처리 TX Hash -> CONFIRMED

Step 5(WYSIWYS 하드웨어 검증)는 모든 프로토콜에서 독립된 필수 스텝이다. 다른 스텝과 합쳐지거나 생략될 수 없다.

2.3. 스텝별 상세

Step 1: TX 생성 [대시보드] [Initiator]

  • 시작 조건: Initiator가 대시보드에 MFA 로그인 완료
  • 액션:
  • 출금 월렛 선택 (BTC / EVM / Warm 월렛 유형에 따라 프로토콜 자동 결정)
  • 수신 주소 입력 (화이트리스트 검증 자동 수행)
  • 금액 및 자산 유형 선택
  • 수수료 추정 (BTC: fee rate 기반, EVM: gas 추정)
  • TX 데이터 구성:
    • BTC: PSBT(BIP-174/370) 생성 -- UTXO 선택, 입출력 구성
    • EVM: EIP-712 TypedData 또는 RLP 인코딩 전 구조체 구성
    • Warm(MPC-TSS): 내부 TX 요청 객체 구성
  • M-of-N 서명자 풀 결정 (정책 기반 자동 배정)
  • 승인 요청 생성 + 승인자 알림 발송
  • 종료 조건: TX 상태 = PENDING_APPROVAL
  • 에러 처리: 화이트리스트 미등록 -> 즉시 차단 / 잔액 부족 -> 거부 / 중복 TX 감지 -> 경고 후 사용자 확인
  • 타임아웃: 해당 없음 (사용자 주도)

Step 2: 정책 검증 + 승인 [대시보드] [Approver x M]

  • 시작 조건: TX 상태 = PENDING_APPROVAL, 승인자에게 알림 도달
  • 액션:
  • 각 Approver가 대시보드에서 TX 상세 확인 (수신 주소, 금액, 수수료, 정책 검증 결과)
  • 승인/거부/보류 결정
  • 순차 모드: 지정 순서대로 승인 / 병렬 모드: 동시에 M개 승인 수집
  • M개 승인 도달 시 TX 상태 전이
  • 종료 조건: M개 승인 완료, TX 상태 = READY_TO_SIGN
  • 에러 처리: 승인 타임아웃 -> 자동 만료(기본 24시간) / 승인자 비가용 -> 대체 승인자 지정 또는 에스컬레이션
  • 타임아웃: 24시간 (설정 가능). 초과 시 TX 상태 = EXPIRED

Step 3: 에어갭 전달 준비 [대시보드] [시스템]

  • 시작 조건: TX 상태 = READY_TO_SIGN
  • 액션:
  • 서명 요청 데이터 패키징:
    • BTC MuSig2: PSBT + MuSig2 세션 컨텍스트(참여자 공개키 목록, 세션 ID)
    • EVM Safe: TX Hash + Safe 주소 + nonce + 서명자 목록
    • Warm MPC-TSS: (Step 3-7 에어갭 불필요, 별도 경로 -- 섹션 4.3 참조)
  • UR(Uniform Resources) 프레임워크로 인코딩:
    • CBOR 직렬화 -> UR 타입 래핑 -> Animated QR 시퀀스 생성
    • Fountain code 적용 (에러 복구 지원)
  • 대시보드 화면에 Animated QR 표시
  • 종료 조건: QR 코드가 화면에 표시되어 스캔 준비 완료
  • 에러 처리: QR 생성 실패 -> 재시도 / 페이로드 크기 초과 -> 분할 QR 또는 압축 적용
  • 타임아웃: QR 표시 후 30분 (스캔 미완료 시 세션 갱신 필요)

Step 4: 오프라인 수신 [오프라인 서명 앱] [Approver]

  • 시작 조건: 오프라인 서명 앱 실행, 카메라 활성화 + D'CENT X USB-C 연결
  • 액션:
  • 대시보드 화면의 Animated QR을 오프라인 앱 카메라로 스캔
  • UR 디코딩 -> CBOR 역직렬화 -> 서명 요청 데이터 복원
  • 오프라인 앱 화면에 TX 내용 표시 (수신 주소, 금액, 수수료 -- 1차 확인)
  • 오프라인 앱에서 D'CENT X 콜드월렛으로 서명 요청 전달:
    • 오프라인 앱 -> D'CENT X (USB-C 케이블 연결)
  • 종료 조건: D'CENT X가 서명 요청 데이터를 수신하여 처리 시작
  • 에러 처리: QR 스캔 실패 -> Animated QR 속도 조절 / USB-C 통신 오류 -> 케이블 재연결 / 데이터 무결성 실패 -> 재전송
  • 타임아웃: 10분 (스캔 미완료 시 오프라인 앱 세션 리셋)

Step 5: WYSIWYS 하드웨어 검증 [D'CENT X 콜드월렛] [Approver]

이 스텝은 독립된 필수 단계이다. 어떤 프로토콜에서도 생략하거나 다른 스텝과 합칠 수 없다.

  • 시작 조건: D'CENT X SE(Secure Element)가 서명 요청 데이터 파싱 완료
  • 액션:
  • D'CENT X 하드웨어 디스플레이에 TX 상세를 SE가 직접 렌더링:
    • 수신 주소 (전체 표시, 축약 금지)
    • 전송 금액 및 자산 유형
    • 네트워크 수수료
    • 체인 ID (EVM 계열)
    • 컨트랙트 정보 (스마트 컨트랙트 호출 시)
  • 서명자가 D'CENT X 디스플레이와 대시보드/오프라인 앱 화면을 독립적으로 대조 확인

  • "SE 표시 != 대시보드 표시"이면 즉시 서명 거부 (중간자 공격 의심)

  • WYSIWYS 4단계 경고 레벨 (v0.0 참조):

레벨 명칭 SE 파싱 범위 디스플레이 표시 사용자 안내
Level 0 완전 파싱 TX 전체 구조를 SE가 파싱 수신 주소, 금액, 수수료, 체인 전체 표시 "확인 후 승인"
Level 1 부분 파싱 주요 필드 파싱, calldata 미파싱 주소, 금액 표시 + "추가 데이터 포함" 경고 "추가 데이터 존재, 주의하여 확인"
Level 2 메타데이터 표시 TX 해시 + 기본 정보만 TX 해시 + 금액 표시 + "전체 파싱 불가" 경고 "외부 검증 권장"
Level 3 Raw Hex 파싱 불가 Raw 데이터 해시만 표시 "높은 위험: 반드시 외부 검증 후 서명"
  • Bybit 사건 교훈: 2025년 Bybit 해킹에서 공격자는 Safe UI를 위변조하여 서명자에게 정상 TX로 보이게 한 후, 실제로는 악의적 delegatecall을 실행시켰다. WYSIWYS는 이러한 공격을 방어하는 핵심 메커니즘이다:
  • 대시보드/앱 UI는 소프트웨어이므로 위변조 가능
  • D'CENT X SE는 하드웨어이므로 UI와 독립적으로 TX 내용을 파싱·표시

  • 서명자는 반드시 D'CENT X 디스플레이에 표시된 내용만 신뢰하고, SE 표시 내용이 기대와 다르면 서명을 거부해야 한다

  • 종료 조건: 서명자가 D'CENT X 디스플레이 내용을 확인 완료 (승인 또는 거부 결정 준비)

  • 에러 처리: 파싱 실패(Level 3) -> "외부 검증 필수" 경고 + 서명 거부 권장 / 디스플레이 장애 -> 해당 디바이스 서명 불가, 대체 디바이스 사용
  • 타임아웃: 5분 (확인 미완료 시 SE가 세션 초기화)

Step 6: SE 서명 실행 [D'CENT X 콜드월렛] [Approver]

  • 시작 조건: Step 5 WYSIWYS 확인 완료, 서명자가 승인 결정
  • 액션:
  • 서명자가 D'CENT X 물리 버튼으로 승인 (소프트웨어 승인 불가)
  • SE 내부에서 서명 알고리즘 실행:
    • BTC MuSig2: Schnorr 부분 서명 생성 (BIP-340 기반, 해당 라운드의 nonce 사용)
    • EVM Safe: ECDSA secp256k1 서명 (ecRecover 호환, v/r/s 생성)
    • Warm MPC-TSS: 해당 없음 (에어갭 경로 미사용)
  • 서명 결과를 SE 외부로 출력 (서명값만 출력, 프라이빗 키는 SE 내부에 잔류)
  • 종료 조건: 부분 서명 생성 완료
  • 에러 처리: 서명 거부(물리 버튼 취소) -> 거부 이유 기록 + 오프라인 앱에 거부 전달 / PIN 오류 -> 재입력(10회 한도, 초과 시 SE 자동 삭제) / SE 장애 -> 디바이스 교체 필요
  • 타임아웃: 2분 (물리 버튼 미입력 시 SE 세션 초기화)

Step 7: 서명 반환 [오프라인 서명 앱 -> 대시보드] [Approver]

  • 시작 조건: D'CENT X에서 부분 서명 생성 완료
  • 액션:
  • D'CENT X -> 오프라인 앱 USB-C 전송 (서명 결과)
  • 오프라인 앱이 부분 서명 데이터 수신 및 검증
  • 오프라인 앱 화면에 서명 결과 QR 표시 -> 대시보드 카메라 스캔
  • 대시보드가 부분 서명 수신, 공개키 매칭 검증, 저장
  • 종료 조건: 대시보드에 해당 서명자의 부분 서명 저장 완료
  • 에러 처리: USB-C 통신 실패 -> 케이블 재연결 후 재전송 / 서명 검증 실패 -> 해당 서명 폐기, 재서명 요청 / 통신 중단 -> 부분 서명은 D'CENT X에 잔류, USB-C 재연결로 재전송 가능
  • 타임아웃: 15분 (반환 미완료 시 해당 서명 세션 만료, 재서명 필요)

M명의 서명자에 대해: Step 3~7은 M명의 서명자가 각각 수행한다. 순차(릴레이) 방식 또는 병렬(동시) 방식 선택 가능. 상세는 섹션 5.3 참조.

Step 8: 서명 집계 + 블록체인 전파 [대시보드] [시스템]

  • 시작 조건: M개의 유효한 부분 서명이 대시보드에 수집 완료
  • 액션:
  • 프로토콜별 서명 집계:
    • BTC MuSig2: M개 부분 서명 -> 단일 Schnorr 집계 서명 생성 -> PSBT 완성
    • EVM Safe: M개 ECDSA 서명을 주소 오름차순 정렬 -> Safe 컨트랙트 호출 데이터 구성
    • Warm MPC-TSS: 부분 서명 집계 -> 표준 ECDSA/Schnorr 서명 복원
  • 최종 TX 무결성 검증 (해시 비교, 서명 유효성)
  • 블록체인 노드에 TX 전파 (다중 노드 제출 -- 안정성)
  • 종료 조건: TX가 mempool에 진입, TX 상태 = BROADCASTING
  • 에러 처리: 서명 집계 실패 -> 개별 서명 재검증 / 노드 연결 실패 -> 대체 노드 자동 전환 / TX 거부(nonce 충돌 등) -> 에러 분석 후 재구성
  • 타임아웃: 전파 시도 5분, 3회 재시도 후 BROADCAST_FAILED

Step 9: 확인 대기 + 완료 처리 [대시보드] [시스템/Initiator]

  • 시작 조건: TX가 mempool에 진입
  • 액션:
  • 블록 포함 대기:
    • BTC: 1-6 확인 (보안 수준별 설정)
    • EVM: 12-64 블록 (체인별 finality 기준)
  • CONFIRMED 상태 전이
  • 감사 로그 기록 (전체 라이프사이클: 생성 -> 승인 -> 서명 -> 전파 -> 확인)
  • 관련자 알림 발송 (Initiator, Approver, Admin)
  • 잔액 업데이트
  • 종료 조건: TX 상태 = CONFIRMED, 감사 로그 기록 완료
  • 에러 처리: 장시간 미확인 -> BTC: RBF 제안, EVM: gas 인상 제안 / TX 실패(revert 등) -> 실패 원인 분석 + 재시도 안내
  • 타임아웃: BTC 24시간, EVM 1시간 (초과 시 수수료 조정 권고)

3. WYSIWYS 하드웨어 검증 단계

3.1. WYSIWYS의 필요성: Bybit 사건 교훈

2025년 2월 Bybit 해킹 사건은 엔터프라이즈 서명 보안의 근본적 취약점을 드러냈다:

  • 공격자는 Safe{Wallet} UI 프론트엔드를 위변조하여, 서명자에게 정상적인 트랜잭션으로 보이도록 속임
  • 실제 서명된 TX는 악의적인 delegatecall로, 콜드월렛의 implementation 주소를 공격자 컨트랙트로 변경
  • 약 $1.4B 규모의 자산이 유출됨
  • 근본 원인: 서명자가 소프트웨어 UI만을 신뢰하고, 실제 서명 대상 데이터를 독립적으로 검증하지 않음

D'CENT Enterprise의 WYSIWYS 대응:

WYSIWYS(What You See Is What You Sign)는 서명 대상 TX의 내용을 소프트웨어(대시보드/앱)가 아닌 하드웨어(D'CENT X SE)가 독립적으로 파싱하여 디스플레이에 표시하는 메커니즘이다. SE는 네트워크에 연결되지 않으므로 원격 위변조가 불가능하며, 서명자는 하드웨어 디스플레이만을 신뢰 기준으로 사용한다.

3.2. Step 5 상세: WYSIWYS 필수 검증 항목

모든 프로토콜(MuSig2/Safe/MPC-TSS)에서 Step 5는 다음을 필수적으로 수행한다:

SE가 디스플레이에 표시하는 항목:

항목 BTC (MuSig2) EVM (Safe) 표시 방식
수신 주소 BTC 주소 전체 이더리움 주소 전체 (0x 포함) 축약 없이 전체 표시, 스크롤 지원
전송 금액 BTC 단위 (satoshi 병기) ETH/토큰 단위 (wei 병기) 자릿수 구분 표시
네트워크 수수료 fee rate (sat/vB) + 총 수수료 gas price + gas limit + 총 수수료 과도한 수수료 시 경고
체인 정보 메인넷/테스트넷 Chain ID + 네트워크명 테스트넷 시 명확한 경고
컨트랙트 정보 해당 없음 함수명 + 주요 파라미터 (파싱 가능 시) Level 0/1에서만 표시
TX 해시 PSBT 해시 TX 해시 (EIP-712 도메인 포함) 항상 표시 (외부 교차 검증용)

서명자 확인 절차:

  1. D'CENT X 디스플레이에 표시된 수신 주소를 독립적으로 확인 (대시보드 화면과 비교하되, 두 화면이 일치해도 D'CENT X 표시를 최종 기준으로 삼음)
  2. 금액과 수수료가 의도한 값인지 확인
  3. 체인 정보가 올바른지 확인 (메인넷/테스트넷 혼동 방지)
  4. Level 1 이상 경고 시 추가 검증 수행 여부 결정
  5. 모든 항목 확인 후 물리 버튼으로 승인 (또는 이상 발견 시 물리 버튼으로 거부)

"SE 표시 != 대시보드 표시" 원칙:

D'CENT X 디스플레이에 표시된 내용과 대시보드/오프라인 앱에 표시된 내용이 하나라도 다르면, 이는 중간자 공격 또는 소프트웨어 위변조의 징후이다. 서명자는 즉시 서명을 거부하고, 보안 사고 프로토콜을 발동해야 한다.

3.3. WYSIWYS와 프로토콜별 상호작용

프로토콜 WYSIWYS 시점 SE 파싱 대상 특이사항
BTC MuSig2 Round 2 (부분 서명 직전) PSBT 입출력 전체 다중 출력 TX 시 각 출력 별도 스크롤 확인
EVM Safe 서명 직전 EIP-712 TypedData 또는 Raw TX 스마트 컨트랙트 calldata 파싱 범위에 따라 Level 0~3 분기
Warm MPC-TSS 해당 없음 해당 없음 Hot zone 실행, D'CENT X 미사용

4. 프로토콜별 서명 절차 상세

4.1. BTC MuSig2 서명

MuSig2는 BIP-327 기반 Schnorr 다중 서명 프로토콜로, M-of-N 서명자가 2라운드 통신으로 단일 집계 서명을 생성한다.

4.1.1. 사전 조건

  • M-of-N 서명자 각각이 D'CENT X 콜드월렛을 보유
  • 각 D'CENT X SE에 개별 키 쌍이 생성되어 있음 (키 세레모니 완료)
  • 집계 공개키(Aggregated Public Key)가 대시보드에 등록되어 있음

4.1.2. MuSig2 2-라운드 서명 절차

Round 1: Nonce 교환

Step 3~4에서 수행:

  1. [대시보드] MuSig2 세션 시작, 세션 ID 생성
  2. [대시보드] PSBT + 세션 컨텍스트를 QR로 인코딩 (Step 3)
  3. [오프라인 앱] QR 스캔으로 수신 (Step 4)
  4. [오프라인 앱 -> D'CENT X] 서명 요청 전달 (USB-C)
  5. [D'CENT X SE] nonce 쌍 (R_i) 생성 (결정적 nonce, RFC 6979 기반 확장)
  6. [D'CENT X] nonce 커밋먼트를 QR로 출력
  7. [오프라인 앱] D'CENT X의 nonce QR 스캔
  8. [오프라인 앱 -> 대시보드] nonce 커밋먼트 QR 전달 (Step 7 경로)
  9. [대시보드] M명의 nonce 커밋먼트 수집 완료 대기
  10. [대시보드] Aggregated nonce(R) 계산

Round 2: 부분 서명 생성 (Step 5~7 포함)

  1. [대시보드] Aggregated nonce(R) + PSBT를 QR로 인코딩 (Step 3 반복)
  2. [오프라인 앱] QR 스캔 (Step 4 반복)
  3. [오프라인 앱 -> D'CENT X] Round 2 데이터 전달
  4. [D'CENT X SE] WYSIWYS 표시 (Step 5):
  5. PSBT의 모든 입출력을 SE가 파싱
  6. 수신 주소, 금액, 수수료를 하드웨어 디스플레이에 표시
  7. 서명자 확인 대기
  8. [D'CENT X] 물리 버튼 승인 (Step 6):
  9. SE가 부분 서명 s_i = k_i + H(R, P, m) * x_i 계산
  10. 부분 서명을 QR로 출력
  11. [오프라인 앱 -> 대시보드] 부분 서명 반환 (Step 7)

서명자 순서 독립성: MuSig2에서 각 서명자의 nonce 커밋먼트와 부분 서명은 순서에 독립적이다. M명의 서명자가 어떤 순서로 참여하든 동일한 집계 서명이 생성된다. 다만 Round 1(nonce 교환)은 M명 모두 완료되어야 Round 2로 진행할 수 있다.

4.1.3. MuSig2 서명 집계 (Step 8)

  1. [대시보드] M개 부분 서명 {s_1, ..., s_M} 수집 확인
  2. [대시보드] 집계 서명 S = sum(s_i) 계산
  3. [대시보드] 최종 Schnorr 서명 (R, S)를 PSBT에 삽입
  4. [대시보드] PSBT 완성 (finalize) -> Raw TX 추출
  5. [대시보드] 블록체인 노드에 전파

4.2. EVM Safe 서명

Gnosis Safe(현 Safe{Wallet})는 스마트 컨트랙트 기반 다중 서명으로, 각 서명자가 독립적으로 ECDSA 서명을 생성하고, Safe 컨트랙트가 온체인에서 검증한다.

4.2.1. 사전 조건

  • M-of-N Safe 컨트랙트가 배포되어 있음
  • 각 서명자의 EOA 주소가 Safe 소유자(owner)로 등록되어 있음
  • 각 서명자가 D'CENT X에 해당 EOA의 프라이빗 키를 보유

4.2.2. Safe 서명 절차

Step 3~7에서 수행:

  1. [대시보드] Safe TX Hash 계산:
  2. safeTxHash = keccak256(encodeTransactionData(to, value, data, operation, safeTxGas, baseGas, gasPrice, gasToken, refundReceiver, nonce))
  3. EIP-712 TypedData 구성 (domain: Safe 주소 + chainId)
  4. [대시보드] safeTxHash를 QR로 인코딩 (Step 3)
  5. [오프라인 앱] QR 스캔 (Step 4)
  6. [오프라인 앱 -> D'CENT X] 서명 요청 전달
  7. [D'CENT X SE] WYSIWYS 표시 (Step 5):
  8. EIP-712 데이터에서 to, value, data 파싱
  9. 수신 주소, 금액 표시
  10. calldata가 알려진 함수 시그니처와 매칭되면 함수명 + 파라미터 표시 (Level 0)
  11. 매칭 불가 시 Level 1~3 경고 표시
  12. [D'CENT X] 물리 버튼 승인 (Step 6):
  13. SE가 ECDSA 서명 (v, r, s) 생성
  14. ecRecover(safeTxHash, v, r, s) = 서명자 EOA 주소 확인 가능
  15. [오프라인 앱 -> 대시보드] 서명 반환 (Step 7)

서명 순서 제약: Safe 컨트랙트의 checkNSignatures 함수는 서명을 서명자 주소 오름차순으로 정렬하여 검증한다. 따라서 서명 수집은 순서 무관하나, Step 8에서 집계 시 주소 순서로 재배열해야 한다.

4.2.3. Safe 서명 집계 및 실행 (Step 8)

  1. [대시보드] M개 ECDSA 서명 {(v_1, r_1, s_1), ..., (v_M, r_M, s_M)} 수집
  2. [대시보드] 서명자 주소 오름차순으로 정렬
  3. [대시보드] 서명을 연결하여 signatures 바이트 배열 구성
  4. [대시보드] Safe 컨트랙트의 execTransaction(to, value, data, operation, safeTxGas, baseGas, gasPrice, gasToken, refundReceiver, signatures) 호출
  5. [온체인] Safe 컨트랙트가 checkNSignatures로 M개 서명 검증 -> 통과 시 TX 실행

4.3. Warm MPC-TSS (CGGMP21) 서명

MPC-TSS(Multi-Party Computation Threshold Signature Scheme)는 CGGMP21 프로토콜 기반으로, Warm 월렛(5-15% 자산, 신속 처리용)에 적용된다.

4.3.1. 핵심 차이: 에어갭 미사용

Warm MPC-TSS는 Hot zone에서 실행되므로, Step 3~7의 에어갭 QR + USB-C 통신이 불필요하다. 대신 mTLS(상호 TLS) 채널로 서명 노드 간 통신한다.

  • D'CENT X 콜드월렛을 사용하지 않음 -> WYSIWYS 하드웨어 검증 미적용
  • 키 셰어는 서명 노드의 HSM 또는 TEE에 저장
  • Step 1(TX 생성) -> Step 2(승인) -> MPC 서명 프로토콜 -> Step 8(전파) -> Step 9(확인)

4.3.2. CGGMP21 서명 절차

  1. [대시보드] TX 생성 + 정책 검증 + M개 승인 (Step 1~2 동일)
  2. [대시보드] MPC 서명 세션 시작, 참여 노드 선택 (t-of-n 임계값)
  3. [서명 노드 x t] 사전 서명 프로토콜 (Pre-Signing):
  4. 각 노드가 로컬 랜덤 값 생성
  5. mTLS 채널로 상호 교환
  6. Paillier 암호화 기반 연산 수행
  7. [서명 노드 x t] 부분 서명 생성:
  8. 각 노드가 자신의 키 셰어로 부분 서명 계산
  9. 부분 서명을 코디네이터에게 전송
  10. [코디네이터] 부분 서명 집계 -> 표준 ECDSA 서명 복원
  11. [대시보드] 서명된 TX 블록체인 전파 (Step 8~9)

4.3.3. Warm 월렛 보안 보상 통제

WYSIWYS 하드웨어 검증이 없으므로 다음 보상 통제를 적용한다:

보상 통제 설명
금액 상한 Warm 월렛 단일 TX 상한 설정 (예: $50K)
일일 한도 Warm 월렛 일일 누적 한도 설정
화이트리스트 필수 Warm 월렛 출금은 화이트리스트 주소만 허용
지연 전파 일정 금액 이상 TX는 대기 시간 적용 (예: 1시간)
이상 탐지 패턴 이탈 TX에 대한 자동 알림 + 수동 확인
Cold 자동 리밸런싱 Warm 잔액이 상한 초과 시 Cold로 자동 이체

5. 에어갭 통신 프로토콜 변종

5.1. 표준 QR (UR 프레임워크)

적용 범위: 단일 TX, 1-2명 서명자. 가장 일반적인 사용 패턴.

기술 스택: - Blockchain Commons UR(Uniform Resources) v2 - CBOR(Concise Binary Object Representation) 직렬화 - Fountain code 기반 Animated QR (에러 복구)

표준 QR 통신 절차:

  1. 송신 측: TX 데이터 -> CBOR 인코딩 -> UR 타입 래핑 -> QR 시퀀스 분할 -> Animated QR 표시
  2. 수신 측: 카메라로 QR 시퀀스 스캔 -> Fountain code 복원 -> UR 디코딩 -> CBOR 역직렬화 -> TX 데이터 복원

성능 기준:

항목 값
단일 QR 용량 ~300 bytes (JSON) / ~600 bytes (binary)
Animated QR 프레임 수 일반 TX: 3-10 프레임
스캔 시간 3-15초 (프레임 수에 비례)
Fountain code 오버헤드 ~10% (에러 복구용 중복 프레임)

5.2. 대용량 TX 변종

적용 범위: 복수 UTXO 입력 BTC TX, 복잡한 스마트 컨트랙트 calldata, 배치 트랜잭션.

대용량 TX의 특성:

TX 유형 예상 페이로드 크기 QR 프레임 수 예상 스캔 시간
BTC 단일 입출력 200-500 bytes 3-5 프레임 3-5초
BTC 10+ UTXO 입력 2-5 KB 15-30 프레임 15-30초
BTC 50+ UTXO 배치 10-20 KB 50-100 프레임 1-2분
EVM 단순 전송 200-400 bytes 3-5 프레임 3-5초
EVM 복잡 calldata 2-10 KB 15-50 프레임 15-50초
EVM 다중 출력 배치 5-20 KB 30-100 프레임 30초-2분

대용량 TX QR 전송 한계:

  • 30 프레임 초과 시 Fountain code 중복률 증가 권장 (에러 복구율 향상)
  • 100 프레임 초과 시 분할 QR 세션 또는 압축 적용 필수 (QR 스캔 신뢰성 저하)
  • 앱↔콜드월렛 구간은 USB-C 연결이므로 대용량 TX 전송에 제약 없음

대용량 QR 최적화 기법:

  1. 프레임 속도 조절: 기본 10fps -> 대용량 시 5fps로 감속 (스캔 안정성 향상)
  2. Fountain code 중복률 증가: 기본 10% -> 대용량 시 20% (에러 복구율 향상)
  3. 분할 전송: 하나의 대용량 TX를 복수 QR 세션으로 분할 (극단적 경우)
  4. 압축: CBOR 인코딩 자체의 바이너리 효율 + 선택적 zlib 압축

5.3. 다수 서명자 변종

적용 범위: 3-of-5 이상 서명자 구성.

5.3.1. 순차 서명 (디바이스 릴레이)

하나의 오프라인 앱으로 서명자가 차례로 서명하는 방식:

  1. 서명자 1이 오프라인 앱에서 TX 수신 -> D'CENT X로 전달 -> WYSIWYS 확인 -> 서명 -> 오프라인 앱에 부분 서명 저장
  2. 서명자 2가 같은 오프라인 앱에서 자신의 D'CENT X로 전달 -> WYSIWYS 확인 -> 서명 -> 부분 서명 추가 저장
  3. M명 완료 시 오프라인 앱에서 대시보드로 M개 부분 서명 일괄 반환

장점: 오프라인 앱 1대면 충분, QR + USB-C 세션 수 = 2M+2 (각 서명자 2회 USB-C + 최초 QR 수신 + 최종 QR 반환) 단점: 총 소요 시간 = M * (단일 서명 시간), 서명자가 물리적으로 같은 위치에 있어야 효율적

5.3.2. 병렬 서명 (각자 오프라인 앱)

각 서명자가 자신의 오프라인 앱으로 독립 서명하는 방식:

  1. 대시보드에서 M명 각각에게 서명 요청 QR 제공 (동일 TX, 동일 세션 ID)
  2. 각 서명자가 자신의 오프라인 앱 + D'CENT X로 독립 서명 수행 (Step 3~7)
  3. 각 서명자가 자신의 부분 서명을 개별적으로 대시보드에 반환

장점: 총 소요 시간 = max(개별 서명 시간), 서명자가 다른 위치에 있어도 가능 단점: 오프라인 앱 M대 필요, 각 서명자가 독립적으로 에어갭 통신 수행

5.3.3. MuSig2 nonce 라운드의 다수 서명자 처리

MuSig2에서는 Round 1(nonce 교환)에서 M명 모두의 nonce가 필요하다:

  • 순차 모드: 서명자 1 nonce 제출 -> 서명자 2 nonce 제출 -> ... -> M명 완료 -> aggregated nonce 계산 -> Round 2 시작
  • 병렬 모드: M명이 동시에 nonce 제출 -> 대시보드에서 M개 nonce 수집 -> aggregated nonce 계산 -> Round 2 시작

Round 2(부분 서명)는 순차/병렬 모두 가능하며, 각 서명자의 부분 서명은 순서에 독립적이다.

주의: MuSig2의 nonce는 한 번만 사용 가능하다(nonce reuse = 키 유출). 서명 세션이 중단되면 새 nonce로 세션을 재시작해야 한다.

5.3.4. Safe의 다수 서명자 처리

Safe에서는 각 서명자의 ECDSA 서명이 완전히 독립적이므로:

  • nonce 라운드 불필요
  • M명이 순차/병렬 어떤 순서로든 서명 가능
  • 대시보드에서 M개 서명 수집 후 주소 순서로 정렬하여 execTransaction 호출

5.4. USB-C 디바이스 통신 채널

적용 범위: 오프라인 앱 ↔ D'CENT X 콜드월렛 간 모든 서명 통신.

5.4.1. USB-C 통신 사양

항목 사양
표준 USB 2.0/3.0, USB-C 커넥터
연결 방식 유선 (USB-C 케이블)
전송 속도 USB 2.0: 480 Mbps / USB 3.0: 5 Gbps
페이로드 제한 무제한 (USB 대역폭 내)
전원 공급 USB-C를 통해 콜드월렛 충전 가능

참고: D'CENT X는 엔터프라이즈 모드에서 Bluetooth를 비활성화한다. NFC는 R3covery 카드 전용이다.

5.4.2. USB-C 사용 시나리오

시나리오 설명
서명 요청 전달 오프라인 앱 → D'CENT X로 서명 요청 페이로드 전달
서명 결과 반환 D'CENT X → 오프라인 앱으로 부분 서명 데이터 반환
대용량 TX PSBT 다중 입력 등 대용량 페이로드도 제약 없이 전송
정책 동기화 오프라인 앱 → D'CENT X로 정책 업데이트 전달
펌웨어 업데이트 오프라인 앱 → D'CENT X로 서명된 펌웨어 바이너리 전달

5.4.3. USB-C 보안 고려사항

위협 대응
USB 데이터 가로채기 오프라인 전용 디바이스에서만 연결, 네트워크 격리 환경
악성 USB 디바이스 SE 독립 검증 (서명 데이터 무결성), WYSIWYS 하드웨어 표시
USB 프로토콜 공격 SE가 수신 데이터를 독립 파싱·검증, 외부 소프트웨어 신뢰하지 않음

5.4.4. 통신 채널 배치 정리

에어갭 경계 통과 (대시보드 ↔ 오프라인 앱):
  └── QR (Animated QR, UR 표준) — 시각적 관찰 가능, 물리 격리 보장

오프라인 서명 유닛 내부 (오프라인 앱 ↔ 콜드월렛):
  └── USB-C (유선 연결) — 빠르고 안정적, 대용량 제약 없음

R3covery 카드 통신 (본체 SE ↔ 카드 SE):
  └── NFC — SE-to-SE 상호 인증, 시드 백업/복구 전용

5.5. 에러 복구

5.5.1. QR 스캔 실패 복구

실패 유형 복구 절차
부분 프레임 누락 Fountain code 자동 복구 (중복 프레임으로 재구성)
전체 스캔 실패 Animated QR 속도 감속(10fps -> 5fps) 후 재시도
반복 실패 (3회) Animated QR 속도 감속(5fps) + 재시도 안내
데이터 무결성 오류 QR 재생성 요청 (세션 유지, 데이터 재전송)

5.5.2. USB-C 통신 실패 복구

실패 유형 복구 절차
연결 끊김 USB-C 케이블 재연결 (세션 유지 시 이어서 전송)
데이터 오류 해당 데이터 블록 재전송
SE 무응답 D'CENT X 재시작 후 USB-C 재연결
케이블 불량 USB-C 케이블 교체 후 재시도

5.5.3. 프로토콜별 타임아웃 및 재서명

항목 MuSig2 Safe MPC-TSS
Nonce 유효 시간 세션 종료 시까지 (최대 4시간) 해당 없음 해당 없음
부분 서명 유효 시간 세션 종료 시까지 48시간 (Safe nonce 기준) 세션 종료 시까지
세션 타임아웃 4시간 48시간 1시간
타임아웃 시 조치 새 nonce로 세션 재시작 (nonce 재사용 금지) 새 safeTxHash 생성 (nonce 변경 가능성) 새 세션 시작
부분 서명 분실 해당 서명자 재서명 (다른 서명자 영향 없음) 해당 서명자 재서명 전체 세션 재시작

5.5.4. 정족수 미달 복구

M명 중 일부 서명자의 서명을 수집하지 못한 경우:

  1. 대시보드에서 미서명 서명자 목록 확인
  2. 미서명 서명자에게 추가 알림 발송
  3. 서명 기한 연장 (관리자 승인 필요)
  4. 대체 서명자 지정 (N명 풀에서 다른 서명자 선택, 사전 설정 시)
  5. 기한 초과 시 TX 만료 -> 새 TX 생성 필요

6. 타임아웃 및 에러 처리 통합

6.1. 프로토콜별 타임아웃 정책 비교

Step 타임아웃 MuSig2 특이사항 Safe 특이사항 MPC-TSS 특이사항
Step 1 (TX 생성) 없음 -- -- --
Step 2 (승인) 24시간 -- -- --
Step 3 (QR 준비) 30분 nonce 세션 시작 -- 해당 없음
Step 4 (수신) 10분 -- -- 해당 없음
Step 5 (WYSIWYS) 5분 PSBT 전체 파싱 calldata Level 분기 해당 없음
Step 6 (서명) 2분 부분 Schnorr 서명 ECDSA 서명 해당 없음
Step 7 (반환) 15분 nonce 재사용 불가 주의 -- 해당 없음
Step 8 (집계) 5분 집계 서명 검증 주소 순서 정렬 부분 서명 집계
Step 9 (확인) BTC 24h / EVM 1h -- -- --

6.2. 에러 유형별 복구 절차 매트릭스

에러 유형 영향 범위 복구 절차 재서명 필요 여부
서명 거부 (Step 6) 해당 서명자만 거부 사유 기록, 다른 서명자 정상 진행. N풀에서 대체 서명자 지정 가능 거부 서명자만 재서명 (또는 대체)
통신 실패 (Step 3-4, 7) 해당 서명자만 QR 재시도(대시보드↔앱), USB-C 재연결(앱↔디바이스) 아니오 (부분 서명은 SE에 잔류)
WYSIWYS 불일치 (Step 5) 전체 세션 즉시 중단, 보안 사고 프로토콜 발동, 모든 서명 폐기 원인 해결 후 전체 재서명
정족수 미달 (Step 8) 전체 TX 추가 서명 수집 또는 대체 서명자 미서명자만
집계 실패 (Step 8) 전체 TX 개별 서명 재검증, 무효 서명 식별 후 해당 서명자 재서명 무효 서명자만
전파 실패 (Step 8) 전체 TX 대체 노드 전환, nonce/UTXO 충돌 시 TX 재구성 아니오 (서명 유지)
nonce 만료 (MuSig2) 전체 MuSig2 세션 새 nonce로 세션 재시작 (nonce 재사용 = 키 유출 위험) 전원 재서명
SE PIN 잠금 (Step 6) 해당 디바이스 대체 디바이스 사용, 잠긴 디바이스 복구 절차 해당 서명자만 (대체 디바이스로)

6.3. 보안 사고 트리거 조건

다음 조건 발생 시 자동으로 보안 사고 프로토콜을 발동한다:

트리거 심각도 즉시 조치
WYSIWYS 불일치 (SE 표시 != 대시보드 표시) Critical 전체 서명 세션 중단, 모든 서명 폐기, 보안팀 알림
동일 nonce 재사용 시도 Critical 해당 세션 즉시 종료, 키 손상 조사 시작
PIN 10회 연속 실패 (SE 자동 삭제) High 디바이스 격리, 백업 복구 절차 시작
미등록 디바이스 attestation 실패 High 서명 거부, 디바이스 인벤토리 확인
서명자 동시 거부 (M명 중 과반 거부) Medium 세션 중단, TX 내용 재검토

7. Phase 14/15 참조 가이드

7.1. Layer 2 (세그먼트 델타) 참조 방식

Phase 14에서 작성할 Layer 2 세그먼트 델타 문서는 본 문서의 Step 번호를 다음과 같이 참조한다:

[SC Delta] Step 2: 셀프 커스터디 기업의 정책 검증 오버라이드
    금액별 티어: <$50K = 2-of-5, $50K-$200K = 3-of-5, >$200K = 4-of-5
    (Layer 1 Step 2의 "M-of-N 서명자 풀 결정"을 세그먼트별로 상세화)

[CSP Delta] Step 2: 수탁 사업자의 고객사 승인 참여 Level에 따른 서명자 풀 구성
    Level 0: 내부 Approver만 (고객 미참여)
    Level 1: 고객 1인이 M명 중 1인으로 참여
    ...

참조 규칙: - [XX Delta] Step N: 형식으로 해당 Step의 세그먼트별 변형을 기술 - 차이가 없는 Step은 생략 (Layer 1이 그대로 적용) - Layer 1의 Step 순서를 변경하지 않음 (삽입/삭제 없이 오버라이드만)

7.2. Layer 3 (환경 어노테이션) 참조 방식

본 Plan의 후속 문서인 signing-coldroom-annotation.md와 signing-noncoldroom-annotation.md는 본 문서의 Step 번호를 다음과 같이 참조한다:

[CR Annotation] Before Step 1: 콜드룸 입장 절차
    듀얼 컨트롤 기반 2인 이상 동시 입장, 신원 확인, CCTV 녹화 시작...

[CR Annotation] Before Step 3: 디바이스 반출 및 체인-오브-커스터디
    금고에서 D'CENT X 반출, 봉인 확인...

[NCR Annotation] Before Step 1: 개인 서명 환경 준비
    보안 등급별 디바이스 반출 절차, 봉인 확인...

참조 규칙: - [XX Annotation] Before/After Step N: 형식으로 물리 절차 삽입 - Layer 1의 디지털 플로우를 변경하지 않음 (물리 절차 삽입만 허용) - 보안 등급별(Grade A/B/C/콜드룸) 분기가 있으면 등급별로 표기 - 보완 조치 ID(CC-PHY-xx, CC-PROC-xx, CC-TECH-xx, CC-ORG-xx) 인라인 참조

7.3. Phase 15 도입 여정에서의 서명 플로우 참조

Phase 15의 도입 여정(Day-0/Day-1/Day-N) 문서는 Day-N(안정 운영) 단계에서 본 문서의 서명 플로우를 참조한다:

  • Day-N 일상 운영의 "출금 트랜잭션 서명" = 본 문서의 Step 1~9 전체
  • Day-1 설정의 "테스트 트랜잭션" = 본 문서의 Step 1~9를 테스트넷에서 실행
  • Day-0 평가의 "서명 플로우 데모" = 본 문서의 Step 5(WYSIWYS) 중심 시연

본 문서는 Phase 13 서명 플로우 설계의 Layer 1으로, v0.0 airgap-signing-flow.md의 4단계 파이프라인을 환경/세그먼트 독립 상세 플로우로 확장한다. Layer 3 환경 어노테이션(signing-coldroom-annotation.md, signing-noncoldroom-annotation.md)과 함께 모든 시나리오(S1~S8)의 서명 단계를 완전히 커버한다.

관련 문서