Zero Trust 서명 재검증: Signer 독립 검증 프로토콜

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 저장소에 직접 조회해서 유효성을 확인한다.

이중 검증 흐름

              
정책 평가 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바이트로 변환하는 법