기존 공격
- 개인키 탈취
- 피싱
- 악성코드
- 직접 침투
DPRK 대응 중심의 서명 전 보안 레이어
자산이 움직이기 전, 위험한 서명을 멈춥니다
SignPath는 디지털자산이 이동하기 전에 트랜잭션 의도, 실행 경로, 서명자 권한, 정책 맥락을 검증합니다.
서명자 조작과 운영 워크플로 공격에 노출된 거래소, 커스터디, 금융기관, DeFi 프로토콜, Treasury 팀을 위해 설계되었습니다.
서명으로 이어지는 경로를 보호합니다 — 키만이 아니라.
- 요청
- 승인
- SignPath Gate
- 서명
- 자산 이동
- Transaction Intent
- Execution Path
- Signer Authority
- Policy Context
SignPath Gate
- ALLOW
- HOLD
- REJECT
왜 지금인가
공격자는 더 이상 키만 훔치지 않습니다
정당한 서명자와 신뢰받는 시스템조차 조작된 경로를 통해 위험한 트랜잭션을 승인할 수 있습니다.
새로운 공격
- 정당한 승인자
- 조작된 서명 요청
- 위조된 UI
- 침해된 개발자 환경
- 유효한 서명
- 자산 탈취
Bybit 15억 달러 사고
정상적인 승인 절차를 통과한 것처럼 보였던 대규모 자산 이동이 결국 치명적인 손실로 이어졌습니다.
공격 대상이 확대되고 있습니다
거래소, DeFi 서비스, 브리지, RPC 노드 운영자, 분석 업체, VASP.
취약점은 경로에 있습니다
키는 안전하더라도, 서명자에게 도달하는 요청은 그렇지 않을 수 있습니다.
핵심 관점
서명은 마지막 순간입니다
유효한 서명이 생성되는 순간, 예방은 끝나고 사고 대응이 시작됩니다.
- 개입 가능
- 되돌릴 수 없음
- 요청
- 승인
- 서명 전 검증
- 서명point of no return
- 브로드캐스트
- 정산
SignPath는 자산이 움직이기 전의 마지막 통제 지점입니다.
제품 정체성
SignPath는 지갑을 대체하지 않습니다
SignPath는 HSM, MPC, Fireblocks, Safe, Squads 및 내부 서명자 앞에 위치하여 서명 요청의 경로와 의도를 검증합니다.
- 트랜잭션 요청
- SignPath GateALLOWHOLDREJECT
- Existing signers
- HSM
- MPC
- Fireblocks
- Safe
- Squads
- 내부 서명자
- 서명
Gate decisionALLOWHOLDREJECT
- 대체 없음
- 서명 전 Gate
- Runtime Provenance
- 트랜잭션 의도
- 서명자 측 강제
- Fail-Closed
우리는 키를 보관하는 회사가 아닙니다. 키가 사용되기 직전, 경로를 검증합니다.
고객
누구에게 SignPath가 필요한가요?
디지털자산을 이동하거나 온체인 권한 작업을 실행하는 모든 조직은 위험한 서명 리스크에 노출될 수 있습니다.
거래소
출금 및 지갑 이동 전, 독립적인 검증.
커스터디 & 금융기관
기관 자산을 위한 감사 대응형 서명 통제.
DeFi 프로토콜
admin, oracle, treasury, vault, governance 실행을 보호.
지갑 & 인프라 제공자
이미 운영 중인 서명 워크플로에 서명 전 Gate를 추가하세요.
사용 사례 · 거래소
거래소를 위해: 출금 전에 검증합니다
거래소의 가장 큰 리스크는 정상적인 승인 절차를 통과한 것처럼 보이는 대규모 자산 이동입니다.
Where exchanges are exposed
- 비정상적인 서명 경로를 동반한 일상적인 cold→hot 이동
- 화이트리스트 변경 직후의 대규모 출금
- 침해된 운영자
- 조작된 출금 요청
- MPC/HSM 정책 우회
ALLOWHOLDREJECT
자금이 움직이기 전, SignPath는 트랜잭션, 서명자, 경로, 정책 맥락을 독립적으로 검증합니다.
Where SignPath sits in the withdrawal flow
- 01내부 출금 요청
- 02SignPath 검증
- 03HSM/MPC 서명
- 04온체인 전송
- 05감사 로그
사용 사례 · DeFi 프로토콜
DeFi를 위해: 권한 작업이 서명되기 전에 보호합니다
감사는 컨트랙트를 보호합니다. SignPath는 권한 트랜잭션이 서명되기 전의 운영 경로를 보호합니다.
Ethereum/EVM
Privileged operations protected before signing
- Safe tx
- 프록시 업그레이드
- Admin 함수
- Oracle 업데이트
- 리스크 파라미터
- 컨트랙트 allowance
- Governance 실행
SignPath는 멀티시그 실행 전에 권한 EVM 트랜잭션을 해석합니다.
ALLOWHOLDREJECT
사용 사례 · 커스터디·금융기관
커스터디를 위해: 기관 자산을 위한 감사 대응형 서명 통제
기관의 디지털자산 운영은 서명이 실행되기 전에 증거, 책임성, 통제를 필요로 합니다.
What institutional teams gain
- 01자산 보호
- 02감사 증거
- 03정책 강제
- 04보험 대응 준비
- 05규제 신뢰
작동 방식
모든 서명 전에 던지는 세 가지 질문
요청, 경로, 서명자가 모두 검증되었을 때에만 트랜잭션이 서명됩니다.
요청이 변경되지 않았는가?
- 정규화된 트랜잭션 페이로드
tx_payload_hash- 페이로드 무결성
신뢰할 수 있는 경로를 통해 들어왔는가?
- 런타임 이벤트 윈도우
- 프로세스 체인
- 파일 접근
- 네트워크 송신
runtime_provenance_digest
서명자가 이를 실행할 권한이 있는가?
signer_idpolicy_hash- 결정 아티팩트
- Replay/TTL 검증
Pre-sign decision
ALLOWHOLDREJECT
- 모두 검증됨ALLOWthe request is signed
- 검토 필요HOLDthe request waits for review
- 위험/조작됨REJECTthe request is stopped
신뢰할 수 있는 경로가 없으면, 서명도 없습니다.
결정 결과
허용. 보류. 차단. 서명 전에.
SignPath는 트랜잭션이 브로드캐스트된 후가 아니라, 서명자 실행 전에 결정합니다.
ALLOW - 신뢰할 수 있는 요청
- 검증된 경로
- 권한 있는 서명자
- 정책 통과
신뢰할 수 있는 요청이며 경로가 검증되었습니다.
HOLD - 추가 검토
- 새로운 수신자
- 비정상적인 런타임 경로
- 고위험 메서드
- 정책 예외
실행 전 수동 검토가 필요합니다.
REJECT - 페이로드 불일치
- 유효하지 않은 결정 아티팩트
- 알 수 없는 서명자
- Runtime provenance 불일치
- 위험한 맥락
위험한 맥락 또는 조작이 감지되었습니다.
신뢰가 확인되지 않으면 기본적으로 Fail-Closed로 동작합니다.
도입 전과 후
SignPath 도입 전 vs 도입 후
SignPath 도입 전
- 승인자 확인됨
- 서명자 확인됨
- 정책 확인됨
- 실행 경로는 확인되지 않음
- 런타임이 결속되지 않음
- 증거가 분산됨
위험한 요청이 서명자에게 도달할 수 있습니다.
SignPath 도입 후
- 요청 검증됨
- 경로 검증됨
- 서명자 검증됨
- 정책 검증됨
- 결정 아티팩트 생성됨
- 감사 기록됨
위험한 요청은 서명 전에 보류됩니다.
차이는 누가 서명하느냐가 아닙니다. 차이는 그 경로를 신뢰할 수 있는가입니다.
아키텍처
Runtime Provenance 기반 서명 통제
SignPath는 트랜잭션 페이로드, runtime provenance, 서명자 신원, 정책 맥락을 하나의 서명 인가 결정으로 결합합니다.
End-to-end signing flow
- 트랜잭션 요청
- Payload Canonicalizer
- Runtime Collector
- Provenance Builder
- Policy / Decision Service
- 서명자 측 강제
- 서명자
- Audit Sink
Layer 1: 트랜잭션 요청
- Raw tx
- Safe tx
- Squads tx
- Fireblocks 콜백
- HSM/MPC 요청
- 내부 서명자 요청
Layer 2: Payload Canonicalizer
- 정규화된 페이로드
- tx_payload_hash
- 체인별 정규화
Layer 3: Runtime Collector
- exec
- open/openat
- connect
- 프로세스 체인
- 파일 접근
- 네트워크 송신
Layer 4: Provenance Builder
- 이벤트 윈도우 다이제스트
- runtime_provenance_digest
- collector_id
- 선택적 collector_signature
Layer 5: Policy / Decision Service
- signer_id
- policy_hash
- 리스크 규칙
- ALLOW/HOLD/REJECT
- 서명된 결정 토큰
Layer 6: 서명자 측 강제
- 공개키 검증
- TTL/replay 검사
- 서명자 불일치 검사
- Fail-Closed 중단
Layer 7: Audit Sink
- 결정 기록
- 실행 결과
- 해시 체인 감사 로그
- 증거 내보내기
통합 모델
기존 서명 인프라 앞에 위치하도록 설계되었습니다
대체 없음. 마이그레이션 없음. 이미 사용 중인 워크플로에 서명 전 Gate를 추가하세요.
Local Signer Proxy
내부 signer 또는 핫월렛 signer 워크플로용.
HSM/MPC Adapter
서명 API 호출 또는 MPC 서명 요청 직전에 검증.
Fireblocks Callback
콜백 승인 전에 트랜잭션 페이로드와 맥락을 평가.
Safe Module/Guard
Safe 트랜잭션에 대한 서명 전·실행 전 검증.
Squads/Solana Adapter
실행 전에 Solana instruction과 권한 변경을 해석.
Custom API / Enterprise Gateway
거래소, 커스터디 플랫폼, 내부 지갑 시스템용.
위협 브리프
DPRK 유형의 Web3 공격에 대응하도록 설계
DPRK 연계 공격자는 컨트랙트뿐 아니라 사람, 개발자, 인프라, 서명 워크플로를 점점 더 많이 노립니다.
- TV-01
위장 채용
악성 저장소, 위장 인터뷰, 개발자 환경 침해.
- TV-02
위장 투자자/파트너
투자·파트너십·실사 대화를 가장한 사회공학 공격.
- TV-03
개발자 침해
계정 탈취, CI/CD 악용, 패키지·배포 경로 조작.
- TV-04
서명자 조작
정상 서명자가 조작된 요청에 서명하도록 유도.
- TV-05
운영 워크플로 악용
출금 요청, 멀티시그 승인, admin 작업, treasury 이동을 정상 운영으로 위장.
SignPath는 위협 인텔리전스를 서명 전 통제로 전환합니다.
감사 증적
모든 서명 결정은 설명 가능해야 합니다
SignPath는 요청이 왜 허용, 보류, 또는 차단되었는지를 기록합니다.
ALLOW - 1수신됨
- 2페이로드 검증됨
- 3경로 검증됨
- 4정책 통과
- 5서명 허용됨
HOLD - 1리스크 신호
- 2수동 검토
- 3승인 맥락 요청됨
- 4서명자로부터 격리됨
REJECT - 1페이로드 불일치
- 2유효하지 않은 결정 아티팩트
- 3알 수 없는 서명자
- 4Runtime provenance 불일치
Evidence left behind
- EV-01
결정 증거
- EV-02
실행 기록
- EV-03
검토 워크플로
- EV-04
컴플라이언스 내보내기
- EV-05
해시 체인 감사 로그
감사 증거는 부차적인 것이 아닙니다. 서명 결정의 일부입니다.
파일럿 프로그램
하나의 핵심 서명 워크플로부터 시작하세요
SignPath 파일럿은 운영 환경을 중단하지 않고 shadow 모드로 시작할 수 있습니다.
- 1
서명 워크플로 매핑
- 2
Shadow 모드 연동
관찰만, 차단 없음
- 3
리스크 검토 대시보드
- 4
통제된 강제 적용
Shadow 모드로 시작하세요. 고객이 준비되었을 때에만 강제 적용합니다.
문의
SignPath 보안 상담을 요청하세요
귀사의 서명 워크플로를 알려주세요. 자산이 움직이기 전, SignPath가 위험한 서명 리스크를 어디에서 줄일 수 있는지 평가를 도와드립니다.