안전한 보관을 넘어, 제1부: 안전한 결제 및 서명 워크플로 설계

Binance가 공개한 2026년 10월 30일 사고의 예비 설명에 따르면, 도난당한 배포 토큰을 통해 내부 서명 서비스에 접근하고 정상적인 출금 절차를 벗어난 거래가 이루어졌습니다 [1]. 공개된 이 경로에서 공격자는 지갑의 개인 키를 먼저 읽지 않고도 서명을 요청할 수 있었습니다.

여기서 공격자가 노린 것은 시스템의 서명 능력입니다. 암호화와 하드웨어 격리를 포함한 안전한 보관은 키를 보호할 수 있지만, 지급에 유효한 업무상 승인이 있는지는 판단할 수 없습니다. 따라서 다음과 같은 질문이 제기됩니다. 승인되지 않은 작업은 어떻게 유효한 서명을 얻는가?

이 질문에 답하려면 업무 요청이 어떻게 서명·실행된 거래로 이어지는지 추적해야 합니다. 지갑을 통해 실행되는 지급은 업무상 승인, 거래 구성, 서명, 실행 및 정산 단계를 거칩니다 [2, 3]. 아래 그림은 이 워크플로의 악용과 함께, 암호화 구현 결함을 이용해 키를 복구하는 또 다른 서명 능력 확보 경로를 보여줍니다.

Beyond Secure Storage 시리즈는 실제 사고에서 이러한 위험에 대응하기 위한 설계 및 구현 원칙을 도출합니다. 제1부 안전한 지급 및 서명 워크플로 설계에서는 공격자가 개인 키를 얻지 않고 원래 시스템의 서명 능력을 오용하는 방식을 살펴봅니다. 제2부 지갑 암호화의 안전한 구현에서는 공격자가 키를 복구해 독자적으로 서명할 수 있게 하는 구현 결함을 살펴봅니다. 어느 경로도 보호 대상 비밀정보를 직접 훔칠 필요는 없습니다.

제1절에서는 실제 사고를 통해 지급 워크플로 전반의 위험과 간과하기 쉬운 가정을 살펴보고, 이에 대응할 설계 및 구현 점검 항목을 도출합니다. 제2절에서는 이러한 점검으로도 승인되지 않은 작업을 막지 못했다고 가정하고, 그에 따른 손실을 제한하는 방법을 살펴봅니다. 제3절에서는 설계 검토, 감사, 침투 테스트 및 훈련을 통해 예방과 손실 억제를 모두 검증하는 방법을 설명합니다.

1. 승인되지 않은 작업을 방지하기 위한 설계

동일한 지급 워크플로가 서로 다른 업무 목적에 사용될 수 있습니다. 아래 그림은 대표적인 수탁 업무 세 가지를 보여줍니다. 입금은 계정의 자산 권리를 확정하고, 출금은 고객의 지시에 따라 이루어지며, 자금 운용 이체는 기관의 자금 배분 결정을 실행합니다.

검증된 입금은 계정에 잔액을 부여할 뿐, 자동으로 지급을 지시하지는 않습니다. 출금에는 별도의 고객 요청과 승인이 필요하며, 자금 운용 이체는 기관의 자금 배분 결정에서 시작됩니다. 두 작업 모두 거래 구성, 서명, 실행 및 정산 단계를 거칩니다. 통합 수탁에서는 고객별 전용 주소에 자산을 계속 보관하지 않아도 장부에 고객의 자산 권리를 기록할 수 있습니다.

대표적인 수탁 업무 세 가지. 기능이 분리되어 있다는 사실만으로 독립적인 신원이나 권한 경계가 확립되는 것은 아닙니다.

이 작업들은 자금을 이동하는 이유가 서로 다릅니다. 다른 업무도 같은 단계를 따를 수 있지만, 필요한 증빙이나 승인은 다를 수 있습니다. 각 단계의 보안상 핵심 질문은 지급 근거, 거래, 서명 권한의 사용 및 정산이 여전히 의도한 작업과 일치하는지입니다.

각 단계는 공격자가 서명되거나 실행되는 내용에 영향을 미치는 지점이 될 수 있습니다. 위조된 요청은 지급 의무가 있는 것처럼 보이게 할 수 있고, 거래 구성 과정에서는 승인되지 않은 작업으로 바뀔 수 있습니다. 권한이 침해되면 서명 접근 권한이 노출될 수 있으며, 실행 또는 정산에 실패하면 원치 않는 권한이 계속 사용 가능하게 남거나 정당한 근거가 없는 지급이 이루어질 수 있습니다.

아래 표는 각 위험을 해당 워크플로 단계 및 이를 살펴보는 데 사용한 사례에 연결합니다.

워크플로 단계	보안상 질문	검토 사례
1.1 · 지급 근거 및 승인	지급에 진정한 요청, 자금 사용 권리 및 유효한 승인이 뒷받침되는가?	Bitget의 위조된 출금 요청 [4]; BigONE의 계정/위험 관리 로직 침해 [5, 6]
1.2 · 거래 구성 및 검증	전체 페이로드가 승인된 작업을 나타내는가?	Bybit의 기만적인 이체에서 통제권 탈취로 이어진 경로 [7, 8]; Kiln/SwissBorg의 변조된 거래 응답 [9, 10]
1.3 · 서명 승인 및 키 사용	누가 서명할 수 있으며, 누가 서명 허용 대상을 변경할 수 있는가?	Resolv의 키 정책 통제권 탈취 [11]; Binance가 보고한 서명 서비스 접근 [1]
1.4 · 실행 및 정산	서명으로 부여된 권한은 언제 실행될 수 있으며, 다음 지급은 무엇을 근거로 정당화되는가?	Drift의 지연 실행과 Chainflip의 잘못된 환불 [12, 13, 14]

1.1 지급 근거 및 승인

지급이 거래 구성과 서명 단계로 진행되기 전에, 기관은 진정한 요청이 있는지, 요청자에게 해당 자금을 이동할 권리가 있는지, 지정된 작업에 유효한 승인이 있는지 확인해야 합니다. 고객 잔액이나 인증된 내부 요청만으로는 이 세 가지가 모두 입증되지 않습니다.

실패 사례: 조작된 지급 근거

Bitget의 2026년 9월 24일 사고에서 공격자는 타사 보안 제품을 악용해 높은 수준의 내부 자격 증명을 획득했습니다. Bitget의 공식 설명에 따르면, 이 자격 증명은 지갑 시스템에 허위 출금 명령을 보내는 데 사용되었고, 그 결과 기존 위험 관리 조치를 우회한 이체가 이루어졌습니다 [4]. 이 명령은 내부 접근 권한을 통해 지급 절차에 도달했지만, 그러한 접근만으로 정당한 고객 지시나 자금 운용 결정이 입증되지는 않았습니다.

BigONE은 2025년 7월 16일에 승인되지 않은 핫월렛 자금 이동을 공개하면서 개인 키는 안전하게 유지되었다고 밝혔습니다. BigONE Eurasia는 글로벌 플랫폼에서 발생한 이 사고의 원인을 운영 환경의 계정 및 위험 관리 로직 변경으로 지목했습니다 [5, 6]. 이는 관련된 또 다른 우려를 보여줍니다. 지급을 정당화하는 데 사용되는 기록과 규칙 자체가 변경될 수 있다는 점입니다. 공개된 설명에는 상세한 요청 기록이나 서명 API가 나와 있지 않으므로, Bitget과 동일한 공격 메커니즘이었다고 단정할 수는 없습니다.

이 사례들은 내부 접근 권한이나 계정 기록만으로 지급 근거가 충분하다고 판단할 때의 위험을 드러냅니다. 공격자가 그 판단의 근거가 되는 자격 증명, 기록 또는 규칙을 변경할 수 있기 때문입니다.

검증할 통제 조치

따라서 설계 및 구현 검토에서는 각 요청을 진정한 업무상 근거까지 추적할 수 있는지, 요청 제출자가 이를 뒷받침하는 기록을 조작하거나 해당 요청을 승인할 수도 있는지 확인해야 합니다.

요청의 출처, 무결성 및 승인 여부를 확인합니다. 모든 지급은 진정한 고객 지시, 업무상 사건 또는 기관의 결정으로 거슬러 올라갈 수 있어야 하며, 자금 사용 권리와 승인에 대한 증빙이 있어야 합니다. 요청 및 이를 뒷받침하는 기록의 변경 사항을 계속 추적할 수 있는지 확인하고, 조작되거나 변경된 증빙이 내부 서비스에서 왔거나 계정 잔액과 일치한다는 이유만으로 승인의 근거가 될 수 없도록 해야 합니다.
검증과 승인을 요청 생성으로부터 독립적으로 유지합니다. 요청 제출자가 이를 뒷받침하는 증빙을 조작하거나 해당 요청을 승인할 수도 있어서는 안 됩니다. 운영 권한과 관리 권한 모두에서 이러한 분리를 유지해야 합니다. 수동 예외 처리와 복구 절차를 포함해 기록, 승인 규칙 또는 역할 할당을 변경함으로써 한 당사자가 요청과 이를 거부하기 위한 점검 절차를 모두 통제할 수 있게 되는지 확인해야 합니다.

지급 근거가 독립적으로 확립되었다면, 다음 질문은 거래가 승인된 작업을 나타내는지입니다.

1.2 거래 구성 및 검증

지급 요청이 승인되면 거래 구성 요소는 이를 서명을 위해 제출할 미서명 데이터로 변환합니다. 목적지, 금액, 작업 및 지갑 통제권에 대한 변경 사항을 포함한 전체 페이로드가 승인된 요청을 나타내야 합니다. 이체 승인이 추가 작업까지 허용하는 것은 아닙니다. 검증할 때는 인터페이스에 표시된 설명만이 아니라 실제로 서명할 데이터를 살펴봐야 합니다.

실패 사례: 서명된 작업이 승인 내용에서 벗어남

Bybit는 콜드 월렛에서 웜 월렛으로 ETH를 전송하려 했습니다. 공식 업데이트에 따르면, 침입은 유출된 Safe 개발자 자격 증명에서 시작됐습니다. 공격자는 이를 이용해 서비스 제공업체의 인프라에 접근하고 서명자들을 속였습니다 [7]. Safe는 execTransaction를 통해 to, value, data, operation 등을 포함한 트랜잭션 필드에 대한 서명을 검증합니다 [15]. 그러나 침해된 인터페이스는 예정된 전송처럼 보이게 하면서 서명 전에 악의적인 필드로 바꿔치기했습니다. 서명은 그렇게 바뀐 바이트에 대해서는 유효했습니다 [7].

그 결과 발생한 트랜잭션은 DELEGATECALL을 사용해 월렛의 구현을 변경했고, 공격자는 원래 소유자들의 새로운 승인 없이 자산을 빼낼 수 있게 됐습니다 [7, 8]. 승인된 업무상 작업은 전송이었지만, 서명된 작업은 월렛을 통제할 수 있는 주체를 바꿨습니다. 화면에 표시된 수신자나 트랜잭션의 즉각적인 전송 금액을 확인하는 것만으로는 전체 작업이 승인 내용과 일치하는지 확인할 수 없었습니다.

Kiln/SwissBorg 사건은 실행 중인 트랜잭션 구성 서비스를 수정하는 방식으로도 악의적인 트랜잭션이 끼어들 수 있음을 보여줍니다. Kiln은 유출된 GitHub 토큰이 CI 워크플로를 거쳐 프로덕션 자격 증명에 대한 접근으로 이어졌다고 보고했습니다. 공격자는 배포된 이미지를 변경하지 않은 채 실행 중인 Kubernetes 파드를 수정해, 정상적인 Solana 스테이크 비활성화 트랜잭션과 함께 출금 권한 변경 트랜잭션을 반환하도록 했습니다. 고객의 수탁 서명자들은 추가된 트랜잭션을 승인했습니다. Kiln에 따르면 서명은 8월 31일에, 탐지는 2025년 9월 8일에 이루어졌습니다 [9]. SwissBorg 역시 트랜잭션 변조의 원인을 서비스 제공업체의 인프라로 지목했습니다. 당시 이용할 수 있었던 디코딩 도구의 사용성과 통합 여부에 대해서는 당사자들의 의견이 달랐습니다 [10].

검증할 통제 조치

Bybit와 Kiln/SwissBorg 사례는 트랜잭션이 서명자가 승인하려던 내용과 어떻게 달라질 수 있는지 보여줍니다. 승인 범위는 전체 작업에 결부되도록 설계해야 하며, 검증 시에는 트랜잭션을 구성하거나 표시한 서비스와 독립적으로 실제 트랜잭션을 확인해야 합니다.

승인을 전체 작업에 결부합니다. 승인은 자산 통제권의 변경이나 실행 권한의 위임을 포함해 트랜잭션의 모든 효과를 포괄해야 합니다 [16]. 그 범위를 벗어나는 변경에는 새로운 승인이 필요합니다. 바꿔치기되거나 추가된 작업이 정상적인 지급에 대한 승인을 그대로 적용받을 수 없는지, 재시도로 인해 하나의 승인이 추가 지급을 승인하는 데 재사용될 수 없는지 검증해야 합니다.
트랜잭션과 그 효과를 독립적으로 검증합니다. 서명을 위해 실제 제출된 데이터를 승인된 업무상 작업과 비교하고, 일괄 처리에 포함된 모든 트랜잭션과 자산 및 권한에 미치는 효과를 확인해야 합니다. 검증은 트랜잭션을 구성하거나 표시하는 서비스와 독립적이어야 합니다. 해당 서비스가 검증기를 변경하거나 검증 절차를 우회할 수 있는지, 오해를 유발하는 표시나 수정된 트랜잭션이 거부되는지 확인해야 합니다.

위의 점검은 트랜잭션이 승인된 요청과 일치하는지를 다룹니다. 서명 단계에서는 또 다른 질문이 제기됩니다. 누군가가 직접 또는 접근 권한을 변경하는 방식으로 필요한 업무상 승인 없이 키를 사용할 수 있을까요?

1.3 서명 승인과 키 사용

검증된 트랜잭션은 승인된 호출자를 통해 서명 서비스에 전달되어야 합니다. 키 정책과 관리 역할은 관련 키를 누가 사용할 수 있고, 그 접근 권한을 누가 변경할 수 있는지 결정합니다. 서명을 호출할 권한이 있다고 해서 모든 트랜잭션이 승인되는 것은 아니며, 서비스를 관리할 권한이 검증되지 않는 서명 경로를 만들어서도 안 됩니다. 따라서 이 단계는 승인된 작업을 위한 키 사용과 키 접근 권한에 대한 통제권을 모두 다룹니다.

실패 사례: 침해된 서명 접근 권한

Resolv의 2026년 3월 22일 사건은 키 접근 정책을 변경하면 서명 경로가 열릴 수 있음을 보여줍니다. 토큰 발행 절차에서는 사용자가 담보를 예치하고 승인된 오프체인 서비스가 발행을 완료해야 했습니다. 공식 사후 분석에 따르면, 공격자는 저장소와 클라우드에 접근한 뒤 더 높은 권한을 가진 역할에 도달했고, 앞선 접근 시도가 거부되자 서명 키의 접근 정책을 변경했습니다. 이 변경으로 공격자는 신원 수준의 권한과 키 수준의 접근 정책을 모두 요구하는 클라우드 키 관리 서비스에서 서명 권한을 얻었습니다 [11].

서명할 수 있는 주체를 바꾸면서 공격자는 원래 서명자를 설득하지 않고도 의도된 담보 관계 밖에서 발행을 승인할 수 있었습니다. 이 설명이 입증하는 것은 원본 개인 키 자료의 추출이 아니라 서명 권한에 대한 통제입니다.

Binance의 2026년 10월 30일 사건에 관한 예비 업데이트는 서명 권한에 이르는 또 다른 경로를 설명합니다. Binance에 따르면, 침해된 직원 기기와 내부 AI 도구를 통해 월렛 엔지니어들의 기기에 접근할 수 있게 됐습니다. 이후 공격자는 탈취한 컨테이너 배포 토큰을 사용해 컨테이너를 배포하고 악성 스크립트를 실행했습니다. 공격자는 내부 월렛 서명 서비스에 무단으로 접근해 정상적인 출금 절차 밖에서 트랜잭션을 시작했습니다 [1]. 이 설명은 배포 권한과 서명 서비스 접근 사이의 연관성을 보여주지만, 어떤 내부 권한 검사를 우회했는지는 정확히 공개하지 않습니다. Resolv가 보고한 키 정책 변경과 달리, 여기서 공개된 진입 경로는 서명 서비스의 운영 환경을 거칩니다.

검증할 통제 조치

이 사례들은 의도된 업무 워크플로 밖에서 서명 접근 권한을 획득하거나 사용할 위험을 드러냅니다. 검토 시에는 정책 변경이나 배포 권한을 통해 열린 경로를 포함해 모든 서명 경로에서 업무상 승인이 강제되는지 확인해야 합니다.

모든 서명 경로에서 업무상 승인을 강제합니다. 키를 사용할 권한이 있다고 해서 특정 작업에 대한 승인이 성립하는 것은 아닙니다 [17, 18, 19]. 키 사용을 승인된 업무 범위로 제한하고, 다른 호출자나 직접 접근으로 그 제한을 우회할 수 없는지 검증해야 합니다. 임의의 서명 요청을 제출할 수 있는 호출자와 독립적으로 승인 요건이 강제되어야 합니다. 어떤 경로에서 이 요건을 강제할 수 없다면 그 공백을 기록하고 2절에 따라 결과를 평가해야 합니다.
서명 권한의 변경을 통제합니다. 처음에는 해당 신원으로 서명할 수 없더라도 관리 및 배포 권한을 통해 서명 접근 권한을 만들 수 있습니다 [20, 21, 22]. 키 사용 권한과 서명 정책, 신원 또는 배포된 코드를 변경할 권한을 분리하고, 그러한 변경에는 독립적인 승인을 요구해야 합니다. 어느 당사자도 자신이 가진 권한들을 결합해 스스로 서명 접근 권한을 부여하거나 그 접근을 통제하는 업무상 검사를 제거할 수 없는지 검증해야 합니다.

승인 검사는 서명이 발급되는 시점에 끝나서는 안 됩니다. 트랜잭션은 여전히 승인된 조건 안에서 실행되어야 하며, 그 결과도 올바르게 정산되어야 합니다.

1.4 실행과 정산

승인은 서명 후에도 유효해야 하며, 관련 업무 기록과 잔액 예약의 브로드캐스트, 실행 및 정산에 이르기까지 유지되어야 합니다. 서명은 지급이 완료됐다는 증거가 아닙니다. 실행은 승인 범위와 유효 조건 안에서 이루어져야 하고, 정산에서는 어떤 의무가 이행됐으며 추가 지급이 실제로 필요한지 확정해야 합니다. 기존 서명이나 관찰된 전송만으로는 새로운 지급 의무가 성립하지 않습니다.

실패 사례: 서명된 권한의 오용과 정산 피드백

Drift 사례는 오해를 유발하는 서명 요청이 나중에 사용할 수 있는 권한을 남길 수 있음을 보여줍니다. 2026년 4월 1일 사건에서 미리 확보한 승인들은 Solana의 durable nonce 트랜잭션에 보존됐다가, 나중에 관리 권한을 탈취하기 위해 제출됐습니다 [12]. durable nonce는 트랜잭션의 유효성을 제어하며, 암호학적 서명에 사용되는 비밀 nonce와는 다릅니다. 일반적인 최근 블록 해시의 만료 없이 오프라인 제출이나 지연 제출을 지원하지만, 계정 또는 프로그램 상태가 바뀌면 실행이 막힐 수 있습니다. durable nonce를 다음 값으로 진행시키면 이전 값에 연결된 트랜잭션이 무효화됩니다 [23].

Drift는 4월 16일 복구 업데이트에서 전용 서명 기기, 기본 서명 인터페이스 외부에서의 검증, 중요한 관리 작업에 대한 타임록, 서명자의 durable nonce 사용 중단을 제안했습니다 [24]. 이러한 조치는 서명자가 무엇을 승인하는지와 서명된 작업이 언제 실행될 수 있는지를 모두 다룹니다. 이는 복구 계획으로 발표된 것이며, 해당 업데이트만으로는 조치들이 배포됐다고 확인할 수 없습니다.

Chainflip은 고객 스왑, 유동성 공급자(LP) 출금, 그리고 fetch라고 하는 내부 입금 수집 작업을 구분합니다 [25]. Tron에서는 트랜잭션 메모에 스왑 지시를 담을 수 있습니다. Chainflip이 2026년 9월 12일 사고에 관해 9월 15일에 발표한 설명에 따르면, 공격자는 검증인이 서명한 fetch를 제출하면서 자신이 제어하는 잘못된 형식의 메모를 포함했습니다. 관측 계층은 이를 실패한 스왑으로 잘못 해석해 정상적인 LP 출금에 더해 환불을 실행했고, 그 결과 출금 6건의 금액이 두 번 지급되었습니다 [13, 14].

이 오류로 내부 자산 이동이 새로운 고객 지급 의무의 근거로 취급되었습니다. Chainflip은 금고로 들어오는 전송이 다른 컨트랙트 호출 안에 포함된 경우에도 메모를 해석해 왔습니다. 이를 수정하기 위해 스왑 메모 해석 대상을 단순 TRX 전송 또는 직접적인 TRC-20 전송으로 제한하고, 다른 호출에 포함된 전송은 제외했습니다 [14]. 유효하게 서명된 fetch에는 고유한 목적이 있었으며, 그 실행이 추가 환불을 정당화하지는 않았습니다.

검증할 통제 조치

서명된 트랜잭션은 예상보다 오래 실행 가능한 상태로 남을 수 있고, 실행 결과에 관한 정보가 새로운 지급 의무로 오인될 수 있습니다. 따라서 검토 시에는 실행 조건이 실제로 강제되는지, 각 지급 또는 환불이 실제로 존재하고 아직 이행되지 않은 의무에 대응하는지 확인해야 합니다.

승인된 실행 조건을 강제합니다. 서명된 트랜잭션에도 승인된 범위, 유효 기간, 취소 조건이 계속 적용되어야 합니다. 만료, 취소 또는 권한 변경 후에도 오래된 트랜잭션이 실행될 수 있는지 확인합니다. 관련 조건을 서명된 작업에 결부하고, 체인 규칙이나 지갑 실행 로직이 이를 강제하는지 검증합니다. 비즈니스 시스템의 기록만으로는 충분하지 않습니다.
실제로 존재하고 아직 이행되지 않은 의무에 대해서만 지급합니다. 각 지급 또는 환불은 이미 이행되지 않은 실제 의무에 대응해야 합니다. 최초 비즈니스 이벤트, 지급 시도, 확인된 결과 사이의 연결을 보존합니다. 재시도, 중복 알림, 결과가 불확실한 경우 또는 내부 전송으로 인해 정당하지 않은 지급이 발생하지 않는지, 실행 증거를 해석하는 규칙을 변경해 이러한 검사를 우회할 수 없는지 확인합니다.

2. 손실 제한과 사고 대응을 위한 설계

1절에서는 사고 증거를 바탕으로 워크플로 위험과 이를 해결하는 데 필요한 설계 및 구현 검사를 파악했습니다. 여기서는 누락, 구현 오류 또는 우회로 인해 이러한 검사가 무단 작업을 막지 못했다고 가정합니다. 이 경우 설계는 공격자가 이동시킬 수 있는 자산의 규모를 제한하고, 계속 위험에 노출된 자금을 파악하며, 남용을 탐지하고 추가 유출을 중단할 수 있는 능력을 유지해야 합니다. 이러한 손실 억제 조치는 예방 통제 조치와 함께 사고 전에 설계하고 테스트해야 합니다.

다음 표는 손실을 제한하고 사고 대응을 가능하게 하기 위한 세 가지 설계 목표를 요약합니다.

설계 목표	보안 질문	검증 중점
2.1 · 독립적으로 강제되는 지출 한도	무단 지급이 발생할 때 시스템이 누적 유출액에 상한을 둘 수 있는가?	독립적인 강제 적용, 일관된 누적액 산정, 한도 변경 또는 우회 방지
2.2 · 보유 자산, 재충전 및 서명된 미이행 트랜잭션	공격을 억제하기 전까지 얼마나 많은 손실이 발생할 수 있는가?	접근 가능한 잔액과 이후 유입 자금, 재충전 제약, 아직 유효한 서명 권한에 노출된 자금
2.3 · 독립적인 모니터링 및 사고 대응	시스템이 무단 작업을 탐지하고 추가 유출을 중단할 수 있는가?	신뢰할 수 있는 증거, 조치 가능한 알림, 효과적이고 독립적으로 사용할 수 있는 대응 통제 조치

2.1 독립적으로 강제되는 지출 한도

무단 지급이 앞선 검사를 통과하더라도, 시스템은 해당 지급과 후속 지급으로 이동시킬 수 있는 자산의 규모에 상한을 두어야 합니다. 이를 위해서는 공격자가 제어할 수 있다고 가정하는 범위 밖에서 강제되는 예산이 필요하며, 개별 트랜잭션과 누적 지출을 모두 포괄해야 합니다. 침해된 승인 서비스나 서명자가 설정된 한도를 비활성화하거나 우회할 수 있다면, 그 한도는 손실의 상한이 되지 못합니다.

지급 승인과 독립적으로 한도를 강제합니다. 승인 검사를 통과한 지급에도 공격자가 제어할 수 있다고 가정하는 범위 밖에서 강제되는 지출 한도가 적용되어야 합니다. 대체 실행 경로 [26, 27]를 포함한 모든 서명 및 실행 경로가 이 한도를 준수하는지, 공격자가 한도 적용을 변경하거나 비활성화할 수 없는지 확인합니다. 독립적인 한도를 강제할 수 없다면 설정된 예산을 손실의 상한으로 제시해서는 안 됩니다.
개별 지급뿐 아니라 누적 지출도 제한합니다. 완료된 지급액과 예약된 금액을 일관되게 산정할 수 있도록 각 예산의 범위, 기간, 평가 기준을 정의합니다. 반복 요청, 동시 실행, 재시도로 인해 지출이 총한도를 초과하거나 예약이 조기에 해제되지 않는지 확인합니다. 한도가 자산 가격에 따라 달라진다면 조작되었거나 오래되었거나 확인할 수 없는 가격 때문에 허용 지출액이 늘어나지 않는지 확인합니다.

2.2 보유 자산, 재충전 및 서명된 미이행 트랜잭션

다음 질문은 기관이 공격을 탐지하고 억제하는 동안 어떤 자금이 계속 위험에 노출되는가입니다. 지갑 잔액, 재충전, 아직 유효한 서명 권한이 노출 규모를 결정하며, 여기에는 사고가 시작된 뒤 유입되는 자금도 포함됩니다. 이를 2.1절의 강제 가능한 한도와 함께 평가해야 합니다. 현재 잔액만으로는 손실 규모를 추정할 수 없습니다.

공격자가 접근할 수 있는 자금을 제한합니다. 다른 지갑, 체인, 컨트랙트를 포함해 영향을 받은 서명 권한이 다룰 수 있는 자산의 전체 범위를 평가합니다. 기존 잔액과 이후 유입 자금을 모두 포함합니다. 재충전에는 독립적인 승인과 누적 한도가 적용되어야 합니다. 반복적인 유출이 자금 관리 부문으로부터 계속 재충전을 유발하지 않는지, 계속 들어오는 입금을 놓치지 않으면서 새로운 자금 공급을 다른 곳으로 돌리거나 중단할 수 있는지 확인합니다.
아직 유효한 서명 권한에 노출된 자금을 포함합니다. 새로운 서명을 중단한다고 해서 이미 발행된 트랜잭션이나 권한이 반드시 무효화되는 것은 아닙니다. 동일한 자산을 두 번 계산하지 않으면서, 그러한 트랜잭션이나 권한으로 여전히 이동시킬 수 있는 자금을 파악합니다. 확인된 지급은 지출로 기록하고 관련 예약 금액을 대조·정리하는 한편, 실행되지 않은 트랜잭션의 예약은 더 이상 실행될 수 없다는 점이 신뢰할 수 있는 증거로 확인될 때까지 유지하는지 검증합니다. 로컬 시스템의 시간 초과나 취소 요청만으로 기록된 노출 규모를 줄여서는 안 됩니다.

2.3 독립적인 모니터링 및 사고 대응

한도와 자금 공급 통제는 잠재적 손실을 제한하고, 모니터링과 대응은 공격자가 얼마나 오래 작업을 계속할 수 있는지를 결정합니다. 기관에는 지급 서비스가 해당 작업을 유효한 것으로 취급하더라도 남용을 드러내는 증거가 필요합니다. 또한 정상 운영 환경을 사용할 수 없거나 그 환경이 침해되었을 때도 이용할 수 있는 대응 경로가 필요합니다.

Binance의 예비 설명은 애플리케이션을 종료하는 것만으로는 왜 충분하지 않을 수 있는지 보여줍니다. 애플리케이션을 종료해도 기존 EIP-7702 위임은 해제되지 않았습니다. 위임을 철회하려면 온체인 트랜잭션이 필요했고, 해당 MPC 배포 환경에서는 별도로 설계된 절차도 필요했습니다 [1]. 이는 해당 배포 환경의 제약이지, MPC에 본질적으로 권한 철회 기능이 없다는 뜻은 아닙니다. 따라서 탐지와 억제는 별도로 검증해야 합니다. 신뢰할 수 있는 증거가 실제로 손실 경로를 차단하는 조치로 이어져야 합니다.

독립적으로 보호되는 증거를 사용해 무단 활동을 탐지합니다. 비즈니스 승인 내역을 서명 활동 및 실행 결과와 비교하고, 권한과 통제 규칙의 변경을 모니터링합니다. 영향을 받은 서비스가 모니터링의 근거가 되는 증거를 다시 쓸 수 있어서는 안 됩니다. 로컬 기록이 누락되거나 조작되었더라도 워크플로에서 수락한 작업이 비즈니스 승인과 일치하지 않으면 조치 가능한 알림을 발생시킬 수 있는지 확인합니다.
대응 통제 조치를 이용 가능하고 효과적인 상태로 유지합니다. 새로운 서명과 자금 공급을 중단할 수 있는 독립적인 권한을 유지하고, 지원되는 경우 미이행 트랜잭션을 무효화하거나 지속되는 권한을 철회할 수 있도록 합니다. 일반적인 운영 접근 수단을 사용할 수 없거나 침해된 경우에도 대응이 가능한지, 해당 조치가 실제로 추가 유출을 차단하는지 확인합니다. 남은 노출 규모와 외부 기관과의 공조 필요성을 파악합니다. 애플리케이션을 중단하는 것만으로는 서명을 통해 부여된 권한이 철회되지 않으며, 자산을 회수할 수 있다고 가정해서도 안 됩니다.

3. 설계 및 구현 검증

앞선 절에서는 워크플로 검사가 승인되지 않은 작업을 방지하는지, 방지하지 못했을 때 손실을 제한할 수 있는지 살펴봤습니다. 검증에서는 자금 흐름 전반에서 통제 장치들이 어떻게 상호작용하는지를 포함해, 배포된 시스템에서 이 두 목표를 모두 조사해야 합니다. 다음 방법들은 서로 보완적인 근거를 제공합니다.

아키텍처 및 보안 설계 평가는 자금 흐름, 권한 경계, 통제 장치 간 의존관계가 의도한 예방 및 손실 억제 목표를 뒷받침하는지 확인합니다. 통제 장치의 독립성과 손실 한도에 관한 전제를 명확히 해야 합니다.
코드 및 설정 감사는 배포된 코드, 설정, 권한이 의도한 검사를 구현하는지 검증합니다. 여기에는 검사를 우회할 수 있는 예외와 대체 경로도 포함됩니다.
침투 테스트는 애플리케이션과 인프라 전반의 취약점을 결합해 승인 절차나 손실 통제를 우회할 수 있는지 조사합니다. 테스트 범위는 개별 구성요소에서 멈추지 않고 전체 자금 경로를 따라야 합니다.
공격·대응 훈련은 모니터링이 적시에 조치로 이어지는지, 지출 한도와 일시 중지 및 권한 취소가 함께 작동하는지 검증합니다. 훈련을 통해 위험에 남아 있는 자금의 범위와 손실을 효과적으로 억제하기까지 걸리는 시간을 확인해야 합니다.

각 검증 시나리오에서는 가정한 공격자의 능력과 함께, 거부되어야 할 작업이나 억제되어야 할 손실을 명시해야 합니다. 관찰된 결과, 남아 있는 위험 노출, 주장하는 손실 한도가 성립하는 조건을 기록해야 합니다. 코드, 설정 또는 권한이 중대하게 변경된 후에는 관련 검사를 반복해야 합니다.

외부 보안팀이나 전문가는 이러한 평가, 감사, 테스트, 훈련에서 내부팀을 보완할 수 있습니다. 외부 검토에서는 결제 로직, 서명 인프라, 운영 권한이 어떻게 상호작용하는지 다루고, 시스템의 예방 및 손실 억제 능력에 관한 근거를 제공해야 합니다.

4. 결론

여기서 살펴본 공격들은 최초 결제 요청부터 트랜잭션 구성, 서명, 실행, 정산에 이르기까지 발생하는 승인 실패를 드러냅니다. 또한 공격자가 방어를 뚫었을 때 시스템이 손실을 제한하려면 무엇이 필요한지도 보여줍니다. 여기서 도출한 설계 원칙은 예방과 손실 억제, 그리고 실제로 두 가지를 평가하는 데 필요한 테스트를 포괄합니다.

핵심 결론은 개인키를 보호하는 것만으로는 서명된 작업이 승인된 작업임을 보장할 수 없다는 것입니다. 실제로 실행되는 작업은 진정한 업무상 결정과 일치해야 하며, 워크플로 검사가 승인되지 않은 작업을 막지 못할 때는 독립적인 통제 장치가 그 결과를 제한해야 합니다. 이를 위해서는 검사를 변경할 수 있는 권한과 추가 손실을 탐지하고 중단하는 데 필요한 도구를 포함해 전체 워크플로를 검토해야 합니다.

이 분석은 원래 시스템의 서명 기능을 악용하는 데 초점을 맞췄습니다. 제2부 지갑 암호화 기술의 안전한 구현에서는 다른 경로를 다룹니다. 공격자가 보호된 비밀정보를 직접 훔치지 않고도 구현상의 결함을 이용해 개인키를 예측하거나 복구한 다음, 원래 워크플로 밖에서 서명하는 경로입니다.