~$410만 손실: Taiko, SecondFi 익스플로잇

지난 한 주(2026/06/22 - 2026/06/28) 동안 주목할 만한 보안 사고 2건이 확인되었으며, 총 약 410만 달러의 손실이 발생한 것으로 확인되었습니다.

날짜	사고	유형	추정 손실
2026/06/22	Taiko	키 탈취 및 부적절한 유효성 검증	~$1.7M
2026/06/23	SecondFi	암호화 구현 결함	~$2.4M

Taiko: 공격자는 노출된 SGX 엔클레이브 서명 키와 불완전한 어테스테이션 정책을 결합하여 악성 프루버를 인가된 인스턴스로 등록하였으며, 이를 통해 포괄적인 속성 적용 없이는 유효한 어테스테이션만으로는 충분하지 않음을 입증하였습니다.
SecondFi: 암호화 구현 결함으로 인해 공격자가 공개 트랜잭션 데이터만을 이용하여 주소 수준의 서명 키를 복구할 수 있었으며, Ed25519 사양에서 겉보기에는 사소해 보이는 편차가 어떻게 완전한 키 탈취로 이어질 수 있는지를 보여주었습니다.

주간 하이라이트: Taiko 사고

Taiko 사고가 하이라이트로 선정된 이유는 이 공격이 두 가지 독립적인 보안 취약점(노출된 엔클레이브 서명 키와 불완전한 어테스테이션 정책)을 결합하여 SGX 기반 증명 검증 시스템을 침해했기 때문입니다. 이 사고는 TEE 신뢰 체인의 각 레이어가 독립적으로 보안 속성을 적용해야 하며, 유효한 어테스테이션 서명 체인이 확인되지 않은 런타임 속성을 보완할 수 없음을 보여줍니다.

2026년 6월 22일, Taiko의 SGX 기반 증명 검증 흐름이 이더리움에서 악용되어 약 170만 달러의 손실이 발생했습니다 [1]. 공격자는 공개 GitHub 저장소에 커밋된 노출된 엔클레이브 서명 개인 키를 사용하여 DEBUG 모드로 실행된 프루버 엔클레이브의 SIGSTRUCT에 서명하였습니다. 온체인 어테스테이션 컨트랙트가 DEBUG 엔클레이브를 거부하지 않았기 때문에, 공격자는 인가된 인스턴스로 등록하고 위조된 증명 데이터를 제출하여 L1 컨트랙트가 존재하지 않는 L2 상태를 수락하고 브리지 자금을 방출하도록 유도하였습니다.

배경

Taiko는 이더리움 Layer-2 롤업으로, 주어진 L2 상태 또는 크로스체인 메시지의 수락 여부를 결정하는 증명 시스템에 의존하는 브리지를 보유하고 있습니다. 이 증명 시스템의 일부로, Taiko는 SGX 프루버를 사용합니다. SGX 프루버는 물리적 머신의 SGX 엔클레이브 내에서 실행되는 오프체인 프로그램으로, 엔클레이브에 의해 보호되는 키로 증명 결과에 서명합니다.

오프체인 (물리적 머신)                온체인 (이더리움)
┌─────────────────────────┐                ┌────────────────────────────────────┐
│  SGX 프루버 엔클레이브  │                │  SgxVerifier                       │
│  - 증명 생성            │── DCAP 쿼트 ─→│  ├─ registerInstance()             │
│  - 인스턴스 키 보유     │                │  │  └─ AutomataDcapV3Attestation   │
│                         │── 서명된 증명→│  └─ verifyProof()                  │
└─────────────────────────┘                └────────────────────────────────────┘

SGX 및 DCAP 개요

SGX의 핵심 개념은 엔클레이브입니다. 엔클레이브는 CPU에 의해 격리된 프로그램 실행 환경입니다. MRENCLAVE는 엔클레이브의 초기 코드, 데이터, 페이지 레이아웃 및 관련 메타데이터의 측정값으로, 엔클레이브 빌드의 해시로 근사할 수 있습니다. MRSIGNER는 엔클레이브 서명 공개 키의 해시로, 게시자 신원을 나타냅니다.

엔클레이브 서명 개인 키는 MRENCLAVE, ISVPRODID, ISVSVN, ATTRIBUTES 등의 엔클레이브 메타데이터를 포함하는 SGX SIGSTRUCT에 서명합니다. 이 서명은 온체인 컨트랙트에 의해 검증되지 않으며, 엔클레이브가 초기화될 때 EINIT 단계에서 SGX 하드웨어에 의해 검증됩니다. CPU는 SIGSTRUCT 서명이 유효한지, 그리고 내부의 MRENCLAVE가 실제로 로드된 엔클레이브의 측정값과 일치하는지 확인합니다. 이 검증이 성공한 후에야 엔클레이브가 초기화되고 후속 리포트와 쿼트를 생성할 수 있습니다.

Intel SGX DCAP v3 쿼트는 세 부분으로 구성된 원격 어테스테이션 패키지입니다:

header: 쿼트 버전, 어테스테이션 키 유형, QE/PCE SVN, 벤더 등의 메타데이터.
localEnclaveReport: MRENCLAVE, MRSIGNER, ATTRIBUTES, ISVPRODID, ISVSVN, reportData를 포함한 어테스테이션된 애플리케이션 엔클레이브의 신원. reportData는 리포트를 생성할 때 엔클레이브가 작성하는 64바이트 값입니다. Taiko는 reportData의 처음 20바이트에 프루버 인스턴스 주소를 저장합니다.
v3AuthData: 쿼트 서명, 어테스테이션 키, QE 리포트, QE 리포트 서명, PCK 인증서 체인을 포함한 쿼트의 진위 증명.

온체인 어테스테이션

온체인 어테스테이션 컨트랙트(AutomataDcapV3Attestation, 원격 어테스테이션 담당)는 Intel DCAP 인증서 체인을 통해 쿼트의 진위를 검증합니다. 인증서 체인의 발급자 공개 키는 외부에서 제출된 쿼트의 일부로 제공되지만, 컨트랙트는 체인을 단계별로 검증하며 최종 발급자 공개 키 해시가 컨트랙트에 고정된 Intel SGX Root CA 공개 키 해시와 일치하도록 요구합니다 [2]. 이 체인을 통해 컨트랙트는 쿼트 서명이 적용된 localEnclaveReport가 calldata에서 임의로 수정되지 않았음을 확인합니다.

Taiko 프루버 등록

SGX 프루버 인스턴스는 먼저 SgxVerifier.registerInstance()를 통해 등록되어야 합니다. 등록 시 호출자는 DCAP 쿼트를 제출합니다. SgxVerifier는 쿼트 유효성 검증을 AutomataDcapV3Attestation.verifyParsedQuote()에 위임합니다. 쿼트가 통과하면 SgxVerifier는 localEnclaveReport.reportData의 처음 20바이트를 인스턴스 주소로 읽어 인가된 인스턴스 집합에 추가합니다.

서명 검증 흐름은 세 개의 레이어로 단순화할 수 있습니다:

SGX CPU는 EINIT 중에 SIGSTRUCT 서명을 검증하여 엔클레이브의 MRENCLAVE와 서명자 신원을 확인합니다.
DCAP 인증서 체인과 QE 리포트는 쿼트 서명 키를 인증합니다. 그런 다음 AutomataDcapV3Attestation은 해당 키를 사용하여 쿼트 서명을 검증하고 localEnclaveReport에 대한 신뢰를 수립합니다.
Taiko의 증명 검증기는 등록된 인스턴스 주소를 사용하여 이후 증명 서명을 검증하고 해당 L2 상태 또는 크로스체인 메시지의 수락 여부를 결정합니다.

취약점 분석

이 사고의 근본 원인은 운영상의 실패와 컨트랙트 수준의 취약점의 조합입니다. 공격이 성공하기 위해서는 두 가지 모두 필요했습니다.

운영상의 실패: 노출된 엔클레이브 서명 키. Taiko/Raiko가 SGX SIGSTRUCT에 서명하는 데 사용하는 엔클레이브 서명 개인 키가 공개 GitHub 저장소에 커밋되었습니다. MRSIGNER는 해당 서명 공개 키의 해시입니다. 이 개인 키를 획득한 누구든지 프루버 엔클레이브의 SIGSTRUCT에 서명할 수 있으며, 이로 인해 결과 쿼트의 MRSIGNER가 Taiko의 허용 목록과 일치하게 됩니다.

컨트랙트 취약점: ATTRIBUTES 검사 누락. 일치하는 MRSIGNER(노출된 키를 통해 허용 목록 통과)를 사용하여 공격자는 MRENCLAVE를 변경하지 않고 동일한 승인된 엔클레이브를 DEBUG 모드로 실행할 수 있었습니다(DEBUG 플래그는 MRENCLAVE의 일부가 아닙니다). 어테스테이션 정책이 이를 감지해야 했지만, AutomataDcapV3Attestation (0x5e46...dd72)은 애플리케이션 엔클레이브의 localEnclaveReport.attributes를 확인하지 않았습니다. DEBUG 엔클레이브는 호스트 또는 디버거가 엔클레이브 메모리를 읽거나 수정할 수 있게 하므로, SGX 엔클레이브에 의해 보호되어야 했던 인스턴스 서명 키가 더 이상 안전하지 않습니다.

이 두 가지 조건이 결합되면, 누구든지 동일한 프루버 엔클레이브 코드를 DEBUG 모드로 실행하고(합법적인 빌드와 동일한 MRENCLAVE 생성), 노출된 서명 키를 사용하여 MRSIGNER가 Taiko의 허용 목록과 일치하는 SIGSTRUCT에 서명할 수 있습니다. 결과 쿼트는 MRENCLAVE와 MRSIGNER 허용 목록을 모두 만족하면서 확인되지 않은 DEBUG 속성을 포함합니다. AutomataDcapV3Attestation이 DEBUG 속성을 거부하지 않기 때문에, 이러한 쿼트는 verifyParsedQuote()를 통과하며, 이후 SgxVerifier는 인스턴스 주소를 인가된 인스턴스 집합에 등록합니다.

DEBUG 모드 엔클레이브는 호스트 또는 디버거로부터 메모리를 보호하지 않습니다. 따라서 엔클레이브 내부에서 생성된 인스턴스 개인 키를 추출할 수 있습니다. 해당 키를 보유한 자는 L1 컨트랙트가 수락하는 임의의 증명 데이터에 서명하여 위조된 L2 상태 전환을 가능하게 하고 금고(0x9962...15ab)에서 브리지 자금을 무단으로 방출할 수 있습니다.

공격 분석

공격자는 여러 트랜잭션을 제출하였습니다. 다음 분석은 두 가지 대표적인 트랜잭션을 기반으로 합니다: 첫 번째는 공격자를 인가된 인스턴스로 등록한 트랜잭션(0x2f44dc...277260)이며, 두 번째는 위조된 증명을 실행하여 자산을 탈취한 트랜잭션(0x017292...ae35ee)입니다.

1단계: 노출된 엔클레이브 서명 키를 사용하여 SIGSTRUCT에 서명하고, 쿼트의 MRSIGNER가 허용 목록과 일치하도록 합니다.
2단계: DEBUG 속성으로 엔클레이브를 실행합니다. DEBUG는 MRENCLAVE를 변경하지 않지만 localEnclaveReport.attributes에 반영됩니다.
3단계: registerInstance()를 호출하고 실제 SGX 쿼트를 제출합니다. 쿼트의 attributes = 0x07...에는 DEBUG 비트(0x02)가 포함되어 있었지만, AutomataDcapV3Attestation이 이 필드를 확인하지 않아 verifyParsedQuote()가 true를 반환했습니다.

4단계: SGX 엔클레이브 메모리에서 인스턴스 개인 키를 추출하고(DEBUG 모드가 메모리 보호를 비활성화하므로 가능), 이를 사용하여 악성 증명 데이터에 서명합니다.
5단계: 조작된 증명을 제출하여 L1 컨트랙트가 존재하지 않는 L2 상태를 수락하도록 하고 금고에서 자산을 탈취합니다.

결론

완전한 SGX 어테스테이션 정책은 최소한 다음을 수행해야 합니다:

프로덕션 배포에서 SGX_FLAGS_DEBUG를 거부합니다.
MRENCLAVE, MRSIGNER, ISVPRODID, ISVSVN을 확인합니다.

DEBUG 쿼트가 수락되면 하드웨어가 여전히 올바르게 동작하고 있을 수 있지만, 더 이상 예상되는 메모리 보호 의미론을 제공하지 않습니다. 엔클레이브 서명 키는 절대 공개 저장소에 커밋되어서는 안 됩니다. 노출된 서명 키는 누구든지 일치하는 MRSIGNER를 가진 바이너리를 생성할 수 있게 하여, 어테스테이션 정책의 나머지 장벽을 MRENCLAVE 및 속성 적용으로만 축소시킵니다.

더 넓은 관점에서, TEE에 의존하는 모든 시스템에서 어테스테이션은 서명 체인이 유효하고 측정값이 허용 목록에 있음을 확인하는 것에서 멈출 수 없습니다. 신뢰 체인의 각 레이어는 독립적으로 보안 속성을 적용해야 합니다.

참고 자료

[1] Phalcon 경보: Taiko 브리지 익스플로잇 감지
[2] Intel SGX 개발자 가이드

이번 주 추가 사고

SecondFi 사고

2026년 6월 23일, EMURGO가 개발한 Cardano 지갑인 SecondFi(구 Yoroi)는 Ed25519 서명 구현에서 심각한 취약점을 공개하였습니다 [1]. 지갑의 서명 구현은 공개 트랜잭션 메시지만을 사용하여 서명 논스를 계산하였으며, 필수 비밀 입력값을 누락하였습니다. 이로 인해 디지털 서명이 단일 방정식 문제로 축소되어 공격자가 온체인 공개 데이터로부터 주소 수준의 개인 키를 복구할 수 있었습니다. 두 명의 별개 공격자가 이 취약점을 악용하여 374개의 지갑에서 약 240만 달러(1,600만 ADA)를 탈취하였습니다 [2].

배경

SecondFi는 2026년 4월 Yoroi에서 리브랜딩된 Cardano 블록체인의 자기 수탁 지갑입니다. Cardano의 세 창립 주체 중 하나인 EMURGO가 개발한 Yoroi는 이전에 100만 명 이상의 사용자를 보유하고 있었습니다.

Ed25519는 Cardano가 트랜잭션 승인에 사용하는 디지털 서명 체계입니다. 서명자는 서명 스칼라 $k_{L}$ (특정 주소의 개인 키)과 동일한 키 자료와 연관된 비밀 논스 접두사 $k_{R}$ 을 보유합니다. 주어진 메시지 $M$ (트랜잭션 페이로드)에 대해, 서명 논스는 $r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L$ 로 계산됩니다. $k_{R}$ 이 비밀이기 때문에, $M$ 이 브로드캐스트 후 공개되더라도 $r$ 은 관찰자에게 알려지지 않습니다.

논스 점 $R = r \cdot B$ (여기서 $B$ 는 고정된 Ed25519 기저점)와 서명 스칼라 $s \equiv r + H \cdot k_L \pmod{L}$ (여기서 $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ 은 논스, 공개 키, 메시지를 바인딩함)이 최종 서명 $(R, s)$ 을 형성합니다. 이 체계의 보안은 $r$ 의 예측 불가능성에 달려 있습니다. 관찰자가 $r$ 을 계산할 수 있다면, 서명 방정식은 $k_{L}$ 에 대해 풀 수 있는 단일 미지수 선형 방정식이 됩니다.

취약점 분석

이 취약점은 스마트 컨트랙트가 아닌 SecondFi의 지갑 서명 소프트웨어에 존재합니다.

기존 분석 [2]과 자체 조사를 결합한 결과, v10.0.3부터 v10.0.6까지의 버전(2026년 6월 8일부터 적용; v10.0.6.2에서 수정됨)이 영향을 받는 것으로 확인되었습니다. 취약한 구현은 서명 논스를 다음과 같이 계산하였습니다:

r = \operatorname{SHA-512}(M) \bmod L

올바른 방식 대신:

r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L

이로 인해 논스 도출에서 유일한 비밀 입력값( $k_{R}$ )이 제거되었습니다. $M$ 이 공개되어 있으므로, 영향을 받는 주소가 서명한 모든 트랜잭션에 대해 누구든지 $r$ 을 재계산할 수 있습니다.

$r$ 이 알려지면, 서명 방정식 $s \equiv r + H \cdot k_L \pmod{L}$ 을 풀 수 있습니다:

k_L \equiv (s - r) \cdot H^{-1} \pmod{L}

우변의 모든 값은 온체인 서명 및 트랜잭션 데이터에서 공개되거나 계산 가능합니다. 이는 해시를 역산하거나 $A = k_L \cdot B$ 에서 이산 로그를 푸는 것이 아닙니다. 결함 있는 구현이 $r$ 을 직접 노출시켜 키 복구를 간단한 모듈러 산술로 축소시켰습니다.

영향은 주소 범위의 키 탈취입니다. 취약한 구현을 통해 서명을 생성한 모든 주소는 탈취된 것으로 처리해야 합니다.

패치된 지갑에 동일한 니모닉을 가져오는 것은 이미 노출된 주소를 보호하지 않습니다. 취약한 서명 구현을 통해 한 번도 서명하지 않은 새로 생성된 키로 자금을 이동해야 합니다.

공격 분석

이 공격은 추적 가능한 스마트 컨트랙트 상호작용이 있는 일반적인 온체인 익스플로잇 순서를 따르지 않습니다. 취약점이 공개 데이터와 서명 키 사이의 결정론적 관계를 노출하기 때문에, 키 복구는 오프라인으로 수행됩니다.

1단계: SecondFi v10.0.3부터 v10.0.6을 사용하여 트랜잭션에 서명한 대상 주소를 식별합니다.
2단계: 각 대상에 대해 트랜잭션의 공개 서명 구성 요소( $R$ , $s$ )를 검색하고 온체인 트랜잭션 페이로드에서 메시지 $M$ 을 재구성합니다.
3단계: 취약한 서명 구현이 비밀 논스 접두사 $k_{R}$ 을 누락했다는 사실을 활용하여 서명 논스 $r = \operatorname{SHA-512}(M) \bmod L$ 을 계산합니다.
4단계: 챌린지 스칼라 $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ 을 계산합니다.
5단계: 서명 스칼라를 풉니다: $k_L \equiv (s - r) \cdot H^{-1} \pmod{L}$ .
6단계: 복구된 $k_{L}$ 을 사용하여 탈취된 주소에서 임의의 트랜잭션에 서명하고 공격자가 제어하는 지갑으로 자금을 이체합니다.

두 명의 별개 공격자가 독립적으로 이 취약점을 악용하였습니다. 한 명은 두 차례에 걸쳐 171개의 지갑을 탈취하였고, 다른 한 명은 별도의 스윕으로 203개의 지갑을 탈취하여 총 약 1,600만 ADA(~$2.4M)를 추출하였습니다 [2]. 이후 EMURGO는 공격자들이 해당 자금에 접근하기 전에 추가로 1억 2,900만 ADA를 구조하였습니다.

결론

근본 원인은 Ed25519 논스 도출에서 비밀 논스 접두사를 제거하여 서명 논스를 공개 데이터의 결정론적 함수로 축소시킨 암호화 구현 결함이었습니다. 영향을 받는 모든 서명은 단일 방정식 키 복구 문제가 되었습니다.

이 사고는 지갑 개발자들이 커스텀 서명 구현 대신 충분히 감사된 표준 Ed25519 라이브러리를 사용해야 함을 강조합니다. 사양에서의 어떠한 편차도, 단일 해시 입력을 누락하는 것처럼 사소해 보일지라도, 전체 키를 탈취할 수 있습니다. 프로덕션 서명 소프트웨어는 배포 전, 특히 키 도출 및 서명 작업을 처리할 때 독립적인 암호화 감사를 받아야 합니다.

참고 자료

[1] SecondFi 사고 후 공개 보고서
[2] Tibane Labs: SecondFi Cardano 포렌식 분석

BlockSec 소개

BlockSec은 풀스택 블록체인 보안 및 암호화폐 컴플라이언스 제공업체입니다. 저희는 고객이 코드 감사(스마트 컨트랙트, 블록체인, 지갑 포함), 실시간 공격 차단, 사고 분석, 불법 자금 추적, AML/CFT 의무 이행을 프로토콜 및 플랫폼의 전체 생애주기에 걸쳐 수행할 수 있도록 돕는 제품과 서비스를 구축합니다.

BlockSec은 유수의 학술 컨퍼런스에서 다수의 블록체인 보안 논문을 발표하였으며, DeFi 애플리케이션의 여러 제로데이 공격을 보고하였고, 2,000만 달러 이상을 구조하기 위해 여러 해킹을 차단하였으며, 수십억 달러 상당의 암호화폐를 보호하였습니다.