디지털 서명 표준(EIP-712) 도입이 피싱 공격 예방에 미치는 효과

📅 5월 7, 2026 👤 Stephen

EIP-712: 단순한 ‘서명’이 아닌, ‘의미 있는 동의’의 기술적 혁명

대부분의 사용자와 심지어 많은 개발자조차 EIP-712를 ‘더 복잡한 서명 방식’ 정도로 오해합니다. 이는 치명적인 착각입니다. 피싱 공격의 근본적인 취약점은 기술적 암호학이 아니라, 사용자가 ‘무엇’에 서명하는지 전혀 인지하지 못하는 ‘인지적 결함’ 에 있습니다, eip-712는 이 인간-머신 인터페이스의 위험한 간극을 데이터 구조 수준에서 해체하는 표준입니다. 기존의 불투명한 16진수 해시 서명이 ‘빈 종이에 서명하는 것’이라면, EIP-712는 모든 조항이 명확히 기재된 계약서에 서명하는 것과 같습니다. 승부는 서명의 암호학적 강도가 아니라, 서명 전에 사용자에게 제공되는 ‘정보의 투명도와 구조화 수준’에서 결정납니다.

기존 서명(EIP-191 등)의 치명적 결함: 문맥의 상실

MetaMask나 다른 지갑에서 “이 트랜잭션에 서명하시겠습니까?”라는 알림과 함께 나타나는, 읽을 수 없는 0x로 시작하는 긴 문자열을 본 적이 있을 것입니다. 사용자는 이것이 USDT 10개를 전송하는 것인지, 아니면 모든 NFT의 운영권을 양도하는 것인지 전혀 알 수 없습니다. 공격자는 이 ‘문맥 상실’을 이용합니다.

  • 피싱 시나리오: 사용자는 합법적인 DeFi 프로토콜과 유사한 가짜 사이트에 연결됩니다. 사이트는 ‘승인(approve)’ 트랜잭션을 요청한편, 서명 팝업에는 “Permission to access your funds” 같은 모호한 메시지만 표시됩니다. 실제 서명 데이터는 악의적인 스마트 컨트랙트에 대해 무제한 권한(approve(attacker, type(uint256).max))을 부여하는 코드입니다.
  • 사용자의 심리: 사용자는 인터페이스의 UI를 믿습니다. “이 프로토콜을 사용하려면 승인이 필요하지”라고 생각하며, 기술적 세부 사항을 확인할 수 없는 불투명한 서명에 ‘동의’합니다.

EIP-712의 핵심 메커니즘: 구조화된 데이터의 인간 가독성 변환

EIP-712는 마법 같은 새로운 암호화 방식을 도입한 것이 아닙니다, 기존의 서명 알고리즘(예: secp256k1)을 그대로 사용합니다. 혁신은 서명될 데이터(메시지)를 기계가 처리하기 쉬운 동시에 인간이 이해할 수 있는 형태로 구조화하는 방법에 있습니다. 이는 다음 세 가지 핵심 요소로 구성됩니다.

1. 타입화된 구조체(TypeHash)의 위력

모든 서명 요청은 미리 정의된 ‘형식(Type)’을 따릅니다. 이 형식은 프로그래밍의 구조체(Struct)와 같아서, “from(보내는 사람), to(받는 사람), amount(금액), nonce(일회용 번호)”와 같은 필드와 그 데이터 타입(string, address, uint256)을 명확히 규정합니다. 이 형식 정보는 ‘타입 해시(TypeHash)’로 계산되어 서명 데이터의 일부가 됩니다. 따라서, 서명은 특정 ‘양식’에 대한 서명이 되며, 이 양식 자체가 의미를 담보합니다.

2. 도메인 분리(Domain Separator): 서명의 고유성 보장

가장 중요한 보안 장치 중 하나입니다. 도메인 분리자는 이 서명이 특정한 컨트랙트나 특정한 네트워크에서만 유효하도록 ‘네임스페이스’를 생성합니다. 이는 한 DApp에서의 서명이 다른 DApp에서 재사용되는 것을 물리적으로 불가능하게 만듭니다. 도메인 분리자는 다음 정보를 포함합니다.

필드의미보안적 역할
nameDApp 이름 (예: “Uniswap V3”)사용자가 어디에 서명하는지 명시적 확인
version컨트랙트 버전 (예: “1”)버전별로 서명 영역을 분리, 업그레이드 후 재서명 유도
chainId네트워크 ID (예: 1 for Ethereum Mainnet)이더리움 메인넷 서명이 테스트넷에서 사용되지 않도록 차단
verifyingContract검증 컨트랙트 주소가장 중요. 서명이 정확히 이 주소의 컨트랙트에서만 유효함을 보장. 피싱 사이트의 가짜 컨트랙트에서는 무효화.

도메인 분리자가 없다면, 한 프로토콜의 ‘거래 승인’ 서명이 악의적으로 다른 프로토콜의 ‘자산 이전’ 명령으로 해석될 수 있습니다. EIP-712는 이를 근본적으로 차단합니다.

3. 인간 가독형 메시지 표시

기술적 구조의 궁극적 목표는 사용자 경험(UX) 향상입니다. EIP-712를 지원하는 지갑(예: MetaMask)은 서명 요청 팝업에서 아래와 같이 구조화된 정보를 표 형태로 명확히 보여줍니다.

필드값 (예시)
MessageToken Permit
From0x1234…abcd
To0x5678…ef01 (Uniswap V3: Router)
Amount100.0 USDC
Deadline2023-12-31 23:59:59 UTC
Nonce5

사용자는 암호학을 몰라도, 자신이 ‘누구에게’, ‘무엇을’, ‘얼마나’, ‘언제까지 허용하는지’를 직관적으로 이해할 수 있습니다, 피싱 사이트가 이를 위조하려면, 지갑이 신뢰하는 도메인 분리자(특히 verifyingcontract)를 위조해야 하는데, 이는 기술적으로 불가능에 가깝습니다.

실전 분석: EIP-712 도입 전후의 공격 성공률 시뮬레이션

데이터는 거짓말을 하지 않습니다. EIP-712의 효과를 공격자의 관점에서 수치화해보면 그 위력이 명확해집니다.

공격 벡터EIP-191 (기존 불투명 서명)EIP-712 (구조화 서명)공격 성공률 변화
무제한 Approve 피싱지갑에 “Contract Interaction”만 표시. 사용자는 UI를 신뢰하여 서명.지갑에 “Approve spender: [악성주소], amount: Unlimited” 명시적 표시. verifyingContract 불일치 경고 가능성 높음.극히 높음 → 극히 낮음
서명 재사용(Replay) 공격서명에 네트워크/컨트랙트 문맥 없음. 다른 네트워크나 유사 컨트랙트에서 재사용 가능.도메인 분리자에 chainId, verifyingContract 포함. 다른 조건에서 서명 재사용 시 검증 실패.가능 → 불가능
권한 위임(Delegation) 피싱“이 프로토콜에서 투표 권한을 위임하세요”라는 UI 아래, 실제 서명은 모든 자산에 대한 광범위한 권한.지갑에 “Delegate voting rights to [위임주소] for protocol [프로토콜 이름]” 명확 표시. 권한 범위 한정.중간 → 매우 낮음
메타데이터 조작서명 해시만 검증하므로, 원본 메시지(예: 금액)를 중간에서 조작 가능(일부 구현 한정).전체 구조화 데이터의 해시를 서명. 한 필드라도 변경하면 서명 무효화.이론적 가능 → 불가능

표에서 알 수 있듯, EIP-712는 공격자의 유효 타겟 면적(Target Surface)을 극적으로 축소시킵니다. 공격자는 더 이상 암호학을 뚫을 필요가 없습니다. 그들은 사용자의 ‘주의력’과 ‘정보의 명확성’이라는 새로운 벽에 직면하게 되며, 이는 공격 비용을 기하급수적으로 상승시킵니다.

개발자와 사용자를 위한 실전 전략: EIP-712 보안을 최대화하는 법

EIP-712는 완벽한 은탄환은 아닙니다. 올바르게 구현하고 사용해야 그 효과가 100% 발휘됩니다.

개발자 측: 구현의 디테일이 보안을 가른다

  • 도메인 분리자 철저히 적용: `verifyingContract` 필드를 반드시 현재 배포된 컨트랙트 주소로 하드코딩하거나 설정해야 합니다. 이를 생략하면 표준의 가장 큰 장점이 사라집니다.
  • 타입 해시 일관성 유지: 컨트랙트 내부에서 계산하는 타입 해시와 프론트엔드에서 생성하는 타입 해시가 정확히 일치해야 합니다, 한 단어의 오타도 모든 서명을 무효화시킵니다.
  • 만료시간(deadline) 필수화: 모든 서명 가능 메시지에 `deadline`(타임스탬프) 필드를 포함시켜, 서명이 영원히 유효하지 않도록 해야 합니다. 이는 유출된 서명의 피해 범위를 시간적으로 제한합니다.
  • Nonce 관리: 각 사용자 계정별로 증가하는 nonce를 사용하여, 동일한 서명의 재생을 방지하십시오.

사용자 측: 새로운 인터페이스에서 승률 높이기

EIP-712 환경에서도 사용자의 경계심은 필요합니다. 하지만 이제 맹목적인 신뢰 대신, 확인 가능한 데이터를 기반으로 판단할 수 있습니다.

  • 팝업의 첫 줄을 읽으십시오: “Sign this message”가 아닌, “Permit 100 DAI for Uniswap”과 같은 구체적인 행위가 제목에 표시되는지 확인하세요.
  • 표(Table)의 데이터를 스캔하십시오: ‘To’ 또는 ‘Spender’ 필드의 주소가 신뢰하는 프로토콜의 공식 주소인지, 금액(Amount)이 예상과 일치하는지 2초만 들여 확인하세요. 지갑이 주소에 대한 레이블(예: ‘Uniswap V3 Router’)을 표시해 줄 것입니다.
  • verifyingContract 주소에 주목하십시오: 고급 사용자라면, 이 주소가 해당 DApp의 공식 문서나 블록 탐색기에서 확인된 주소와 일치하는지 최종 점검할 수 있습니다. 불일치 시 즉시 거절하세요.
  • 네트워크(ChainId)를 확인하십시오: 메인넷(1)에서 작업 중인데, 서명 요청에 테스트넷(5)이 표시된다면 이는 명백한 위험 신호입니다.

이 행동들은 EIP-712 미지원 환경에서는 불가능했거나 매우 어려웠습니다. 이제 당신에게는 검증할 수 있는 무기가 생긴 것입니다.

결론: 보안은 사용자 교육이 아닌, 시스템 설계의 문제다

“서명하기 전에 잘 확인하세요”라는 교육은 한계가 명확했습니다. 인간의 주의력은 유한하고, 피싱 사이트의 UI는 점점 정교해집니다. EIP-712는 이 난제에 대한 패러다임 전환적 해법입니다. 보안 책임을 사용자의 ‘경계심’에서 시스템의 ‘투명한 데이터 제공 구조’로 이전시키는 것입니다. 이 표준이 광범위하게 채택될수록, 공격자는 사회공학적 기만보다 훨씬 더 어려운 기술적 취약점을 찾아야 하는 상황에 처하게 됩니다. 아직 모든 DApp과 지갑이 완벽하게 지원하는 것은 아니지만, 방향은 명확합니다. 데이터의 구조화와 인간 가독성 제공은 더 이상 선택이 아닌, 웹3 생태계의 생존을 위한 필수 보안 인프라입니다. 다음번 지갑에 서명 요청이 뜰 때, 그것이 불투명한 16진수 문자열인지, 아니면 이해할 수 있는 구조화된 데이터 테이블인지 확인하십시오. 그 차이가 바로 여러분의 자산을 지킬 최전방 방어선입니다.

관련 기사