Patent-D 시리즈 D-4 | Signer 경계 독립 재검증 프로토콜
난이도: ★★★★ | #신뢰경계 #승인증명 #이중검증 #제로트러스트
문제: 오케스트레이터가 해킹당하면?
Custody 시스템 구조를 단순화하면 이렇다: 클라이언트 – 오케스트레이터 – Signer(서명자) – 블록체인. 오케스트레이터는 정책을 평가하고, 승인을 확인하고, 서명자에게 이 트랜잭션에 서명해라고 요청한다.
무서운 가정: 만약 오케스트레이터가 해킹당한다면? 공격자가 오케스트레이터 코드를 조작하면 정책 검사를 건너뛰고 서명자에게 직접 서명 요청을 보낼 수 있다. Signer는 오케스트레이터가 보낸 요청이니까 OK라고 서명해버린다.
이것이 단일 신뢰 경계(Single Trust Boundary)의 문제다. 기존 KMS/HSM 특허들은 암호화 알고리즘에 집중했다. 서명 계층이 승인 증명을 독립적으로 재검증하는 구조는 없었다.
핵심 아이디어: 4-tuple 승인 증명 번들
Signer 계층이 오케스트레이터와 독립된 경로로 승인 증명을 직접 재검증한다. 서명 요청에 (approval_bundle_id, policy_decision_id, chain_id, deadline) 4개 필드가 포함되어야 한다. Signer는 이 4개를 별도 approval 저장소에 직접 조회해서 유효성을 확인한다.
이중 검증 흐름
[오케스트레이터 계층] [Signer 계층]
정책 평가 to 승인 저장소 기록 서명 요청 수신
서명 요청 전송 ─────────────────► SignerBoundaryVerifier.verify(
{tx_data, approvalBundleId, approvalBundleId,
policyDecisionId, policyDecisionId,
chainId, deadline} chainId, deadline)
|
approval 저장소 직접 조회 (독립 경로)
4개 필드 모두 유효?
YES: 서명 실행 / NO: 서명 거부
검증 실패 케이스
| 케이스 | 판단 | 의미 |
|---|---|---|
| approvalBundleId 없음 | 거부 | 승인 절차를 거치지 않은 요청 |
| policyDecisionId 상태 비정상 | 거부 | 정책 평가가 취소되었거나 거부됨 |
| chainId 불일치 | 거부 | 다른 체인용 승인으로 위장한 요청 |
| deadline 만료 | 거부 | 시간 재사용(replay) 공격 방지 |
오케스트레이터 침해 공격 시나리오
공격자 to Signer.sign({tx_data, malicious_bundle_id, ...})
verify(malicious_bundle_id, fake_decision_id, "ETH", deadline)
→ approval 저장소 직접 조회
→ malicious_bundle_id 없음
→ 서명 거부 → 공격 실패
오케스트레이터가 뚫렸음에도 Signer 계층에서 구조적으로 차단된다.
핵심 요약
- Zero Trust를 코드 아키텍처로 강제: Signer는 오케스트레이터를 신뢰하지 않는다
- 4-tuple 승인 증명 번들로 독립 재검증
- deadline 필드로 replay 공격 차단
- 암호화 알고리즘이 아닌 시스템 아키텍처 차원의 보안
다음 편: D-5 AWS KMS DER 서명을 EVM 65바이트로 변환하는 법
About the Author
