[{"data":1,"prerenderedAt":22},["ShallowReactive",2],{"blog-content-ko-what-is-blind-signing":3},{"slug":4,"title":5,"excerpt":6,"description":7,"bodyHtml":8,"faqItems":9},"what-is-blind-signing","블라인드 서명이란? 읽을 수 없는 것에 절대 서명하면 안 되는 이유","블라인드 서명은 지갑이 사람이 읽을 수 있는 형태로 보여주지 못하는 트랜잭션이나 메시지를 승인하는 것입니다 — 원시 calldata, 불투명한 16진수 덩어리, 혹은 해시 하나뿐인 경우죠. eth_sign을 절대 승인해서는 안 되는 이유, 드레이너가 읽을 수 없는 요청에 의존하는 방식, 그리고 클리어 서명과 시뮬레이션이 어떻게 서명 전에 읽을 수 있게 해주는지 정리했습니다.","블라인드 서명 해설: 불투명한 calldata, eth_sign, 해시만 보여주는 하드웨어 화면, 드레이너가 읽을 수 없는 요청에 의존하는 이유, 클리어 서명과 시뮬레이션이 이를 어떻게 해결하는지, 그리고 WATS의 비수탁형 서명이 어디에 자리하는지.","\u003Cblockquote>\u003Cp>\u003Cstrong>블라인드 서명\u003C\u002Fstrong>은 지갑이 사람이 읽을 수 있는 형태로 표시하지 못하는 트랜잭션이나 메시지를 승인하는 것입니다 — 서명이 무엇을 승인하는지 평문으로 알려주는 대신 원시 calldata, 불투명한 16진수 덩어리, 또는 32바이트짜리 해시 하나를 보여주는 경우죠. 암호학의 실패가 아닙니다. 서명 자체는 완벽히 유효하고 온체인에서 온전한 권한을 갖습니다. 그래서 읽을 수 없는 데이터에 서명한다는 것은 한 번도 살펴본 적 없는 권한을 내주는 일이며, 거의 모든 지갑 드레이너가 바로 이 지점을 중심으로 설계되는 이유이기도 합니다. 해법은 \u003Cem>클리어 서명\u003C\u002Fem>입니다 — 지갑이 요청을 확인 가능한 문장으로 해독해 보여주고, 시뮬레이션으로 실제 어떤 자산이 움직일지 미리 보여주는 것 — 여기에 어떤 소프트웨어도 대신해 줄 수 없는 습관 하나가 더해져야 합니다. 읽을 수 없는 것은 거부하기. 그리고 서명이야말로 권한이 넘어가는 바로 그 순간이기 때문에, 그 서명을 만들어내는 키가 오직 당신의 것인지도 중요합니다. \u003Ca href=\"\u002Fhot-wallet\">WATS Hot Wallet\u003C\u002Fa>은 Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana, TON에 걸쳐 비수탁형이며, 당신이 직접 승인한 서명 없이는 아무것도 움직이지 않습니다.\u003C\u002Fp>\u003C\u002Fblockquote>\n\n\u003Ch2>블라인드 서명이란?\u003C\u002Fh2>\n\u003Cp>블라인드 서명은 요청과 그 표시가 서로 어긋난 모든 승인을 말합니다. 체인은 서명된 바이트가 말하는 대로 실행하고, 당신의 의도와 실제 내용을 견줘볼 수 있는 곳은 화면뿐입니다. 화면에 16진수가 뜨는 순간 그 대조는 불가능해지고, 공격자는 바로 그 불가능함을 겨냥해 설계합니다.\u003C\u002Fp>\n\u003Cp>이 간극은 수학의 문제가 아니라 정보의 문제입니다. 서명은 \"USDC 100개를 스왑하는 데 동의했다\"를 담지 않습니다. 담는 것은 \"이 키가 이 바이트들을 승인한다\"입니다. 그 바이트가 스왑을 뜻하는지, 무제한 승인을 뜻하는지, 아니면 당신의 NFT를 헐값에 넘기는 오프체인 주문을 뜻하는지는 인터페이스만이 답할 수 있는 질문이고, 블라인드 서명은 인터페이스가 그 답을 내놓기를 거부할 때 벌어지는 일입니다.\u003C\u002Fp>\n\n\u003Ch2>블라인드 서명은 어디에서 나타나는가\u003C\u002Fh2>\n\u003Cp>블라인드 서명은 하나의 기능이 아니라, 표시가 데이터를 따라가지 못하는 상황들의 집합입니다. 흔히 마주치는 경우들은 이렇습니다.\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\u003Cth>요청 유형\u003C\u002Fth>\u003Cth>보통 보이는 것\u003C\u002Fth>\u003Cth>위험\u003C\u002Fth>\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\u003Ctd>eth_sign\u003C\u002Ftd>\u003Ctd>원시 해시 또는 16진수 덩어리\u003C\u002Ftd>\u003Ctd>치명적 — 설계상 검증 불가능하므로 언제나 거부\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>원시 타입 데이터(EIP-712)\u003C\u002Ftd>\u003Ctd>spender, 금액, 만료 시각 같은 구조화된 필드\u003C\u002Ftd>\u003Ctd>의미가 불분명하면 높음 — 읽히는 필드가 곧 이해된 필드는 아님\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>컨트랙트 트랜잭션\u003C\u002Ftd>\u003Ctd>해독된 동작, 또는 지갑이 해독하지 못할 때는 원시 calldata\u003C\u002Ftd>\u003Ctd>전적으로 지갑의 해독 능력에 달림\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>해시만 보여주는 하드웨어 화면\u003C\u002Ftd>\u003Ctd>기기 화면에 해시 하나뿐\u003C\u002Ftd>\u003Ctd>높음 — 기기는 당신이 그 자리에 있었음을 확인할 뿐, 이해했음을 확인하지 않음\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>네 줄을 관통하는 패턴은 하나입니다. 위험은 가독성을 따라 움직입니다. 렌더링이 얇아지는 곳마다 위험은 두꺼워집니다.\u003C\u002Fp>\n\n\u003Ch2>eth_sign은 왜 그토록 위험한가?\u003C\u002Fh2>\n\u003Cp>서명 방식 가운데 \u003Cem>eth_sign\u003C\u002Fem>은 이 문제의 가장 순수한 형태입니다. 임의의 32바이트 값에 서명하라고 지갑에 요구하면서, 그 값을 원시 16진수로 보여주고, 어떤 데이터를 \"그저 메시지\"라고 표시해 주는 접두사조차 붙이지 않습니다. 입력에 도메인 구분이 없기 때문에 그것은 무엇이든 될 수 있습니다 — 당신의 계정에서 자산을 빼내는 트랜잭션의 해시일 수도 있고요. 아무리 신중한 전문가라도 그 프롬프트만 보고 요청을 검증할 방법은 없습니다. 설계상 검증이 불가능한 것이죠. 주요 지갑들이 이 메서드를 폐기하거나 아예 제거한 이유가 여기 있고, 실무 규칙에 예외가 없는 이유도 같습니다. 2026년 현재 eth_sign을 요구하는 사이트는 위험할 만큼 낡았거나 적극적으로 악의적이거나 둘 중 하나이며, 어느 쪽이든 답은 거부입니다.\u003C\u002Fp>\n\n\u003Ch2>하드웨어 지갑은 실제로 무엇을 보여주는가?\u003C\u002Fh2>\n\u003Cp>하드웨어 지갑은 키를 오프라인에 두고, 멀웨어가 조작할 수 없는 화면에 요청을 표시합니다 — 하지만 그 화면은 거기에 무엇이 렌더링되느냐만큼만 유용합니다. 기기가 이해하지 못하는 컨트랙트 상호작용에 대해, 많은 기기들이 오랫동안 해시 하나만 표시하는 쪽으로 물러섰습니다. 설정에 말 그대로 블라인드 서명이라는 이름이 붙은 토글 뒤에서요. 신뢰할 수 있는 화면에서 해시를 확인하는 것은 당신이 버튼을 눌렀다는 사실만 증명할 뿐, 무엇을 승인했는지에 대해서는 아무것도 증명하지 않습니다. 하드웨어 보안의 약속은 \u003Cem>보이는 것이 곧 서명하는 것\u003C\u002Fem>이라는 데 있는데, 보이는 것이 32바이트의 잡음일 때 그 약속은 조용히 무너집니다. 하드웨어 격리가 지키는 것은 키이지, 결정이 아닙니다.\u003C\u002Fp>\n\n\u003Ch2>드레이너는 블라인드 서명을 어떻게 악용하는가?\u003C\u002Fh2>\n\u003Cp>드레이너 키트는 무엇보다 먼저 서명 경험을 겨냥한 공격입니다. 사이트는 민팅 페이지나 에어드랍 클레임, 혹은 고객지원 포털처럼 보이고, 거기서 날아오는 요청은 무제한 토큰 승인이거나, NFT 컬렉션 전체를 아우르는 setApprovalForAll이거나, 나중에 추가 프롬프트 없이 자산을 옮기는 오프체인 Permit 또는 주문 서명입니다. 이 모두가 공유하는 것은 표현 방식입니다. 피해자는 읽을 수 없는 요청에 — 또는 읽었지만 이해하지 못한 요청에 — 서명했고, 그 뒤에 탈취가 이어졌습니다. 전체 시나리오는 \u003Ca href=\"\u002Fblog\u002Fwhat-is-a-wallet-drainer\">월렛 드레이너란 무엇인가\u003C\u002Fa>에서 다루고, 승인 메커니즘은 — 가스 없는 서명 하나가 어떻게 토큰 잔고를 비울 수 있는지를 포함해 — \u003Ca href=\"\u002Fblog\u002Ftoken-approvals-and-permit-explained\">토큰 승인과 Permit 해설\u003C\u002Fa>에서 다룹니다. 둘 다 같은 근본 원인에 도달합니다. 도난은 서명하는 순간에 일어나고, 블라인드 서명은 공격자가 그 순간을 무사히 빠져나가게 해주는 장치라는 것입니다.\u003C\u002Fp>\n\n\u003Ch2>클리어 서명이란 무엇이고, 지금 어디까지 왔는가?\u003C\u002Fh2>\n\u003Cp>업계의 답은 \u003Cstrong>클리어 서명\u003C\u002Fstrong>입니다 — 지갑은 서명을 요구하기 전에 모든 요청을 사람이 검증할 수 있는 말로 번역해야 한다는 원칙이죠. 2026년 현재 이는 두 가지 메커니즘 위에 서 있습니다. \u003Cem>해독\u003C\u002Fem>: 지갑이 호출되는 컨트랙트와 함수를 알아보고 이를 문장으로 렌더링합니다 — 토큰 X를 spender Y에게 무제한 금액으로 승인, 이런 식으로요. ERC-7730 같은 시도들은 공개 메타데이터 레지스트리를 구축해, 하드웨어 지갑 화면조차 해시 대신 사람의 언어로 컨트랙트 호출을 표시할 수 있게 하려 합니다. \u003Cem>시뮬레이션\u003C\u002Fem>: 지갑이, 또는 지갑이 호출하는 서비스가, 서명 전에 현재 체인 상태를 상대로 트랜잭션을 실행해 결과를 미리 보여줍니다 — 어떤 자산이 나가고, 어떤 것이 들어오고, 어떤 승인이 바뀌는지. 시뮬레이션은 예측이지 보장이 아닙니다 — 미리보기와 블록 포함 사이에 상태가 달라질 수 있고, 적대적인 컨트랙트는 채굴된 뒤 다르게 행동할 수 있습니다 — 그러나 당신의 NFT가 모르는 주소로 빠져나가는 미리보기 한 장이면 대부분의 탈취는 그 자리에서 멈춥니다. 2026년 현재에도 지갑과 체인에 따라 도입 수준이 고르지 않으니, 경고를 믿고 맡기기 전에 당신의 지갑이 일상적인 동작에 대해 실제로 무엇을 보여주는지 확인해 두세요.\u003C\u002Fp>\n\n\u003Ch2>실전 규칙: 읽을 수 없다면 신뢰하지 않는다\u003C\u002Fh2>\n\u003Cp>안전하려고 calldata를 읽을 줄 알 필요는 없습니다. 필요한 것은 읽을 수 없는 요청이 자동으로 막히도록 만드는 습관입니다.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>eth_sign 요청은 절대 승인하지 마세요.\u003C\u002Fstrong> 지금 남아 있는 정상적인 주류 용도는 없습니다 — 그 요청 자체를 위험 신호로 취급하세요.\u003C\u002Fli>\n\u003Cli>\u003Cem>해독과 시뮬레이션을 제공하는 지갑을 쓰세요.\u003C\u002Fem> 일상적인 동작에 원시 16진수를 보여주는 지갑이라면, 그건 갈아탈 만한 지갑의 문제입니다.\u003C\u002Fli>\n\u003Cli>\u003Cem>중요한 필드를 읽으세요\u003C\u002Fem> — 타입 데이터 요청에서 spender, 금액, 만료 시각, operator. 무제한 금액이나 정체 모를 spender는 정지 신호입니다.\u003C\u002Fli>\n\u003Cli>\u003Cem>하드웨어의 블라인드 서명 모드는 꺼 두세요.\u003C\u002Fem> 특정 트랜잭션 하나에 그것이 왜 필요한지 정확히 아는 경우가 아니라면요 — 그리고 쓴 뒤에는 다시 꺼 두세요.\u003C\u002Fli>\n\u003Cli>\u003Cem>연결은 의도적으로.\u003C\u002Fem> 나쁜 요청은 대개 성급한 연결을 통해 들어옵니다 — \u003Ca href=\"\u002Fblog\u002Fhow-to-connect-wallet-to-dapp\">지갑을 dApp에 안전하게 연결하는 방법\u003C\u002Fa>의 절차가 현관을 지켜 줍니다.\u003C\u002Fli>\n\u003Cli>\u003Cem>읽을 수 없다면 신뢰할 수 없습니다.\u003C\u002Fem> 서명을 거부하는 비용은 다시 시도하는 수고뿐입니다. 잘못된 서명 하나는 전부를 앗아갈 수 있습니다. 이 비대칭이 답을 정해 줍니다.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2>WATS는 어디에 자리하는가\u003C\u002Fh2>\n\u003Cp>블라인드 서명은 표시의 문제입니다. 해독과 시뮬레이션은 요청을 읽을 수 있는 말로 보여줄 수 있지만, 그 요청이 정말 당신이 원하는 것인지는 어떤 지갑도 — WATS를 포함해 — 대신 결정해 줄 수 없습니다. 지갑이 확실히 정하는 것은, 그 결정을 권한으로 바꾸는 키를 누가 통제하느냐입니다. \u003Ca href=\"\u002Fhot-wallet\">WATS Hot Wallet\u003C\u002Fa>은 완전한 비수탁형입니다. 키는 당신이 보유하고, WATS는 어떤 키도 보유하지 않으며, Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana, TON에서 당신이 승인한 서명 없이는 어떤 전송도 계정을 떠나지 않습니다. 이로써 위험 한 범주가 통째로 사라집니다 — 아무도 당신을 대신해 서명할 수 없으니까요 — 다만 위에서 말한 읽는 훈련은 여전히 온전히 당신의 몫으로 남습니다.\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"\u002Fnfc-card\">WATS NFC Metal Card\u003C\u002Fa>도 같은 자리에 정직하게 놓여 있습니다. 이 카드는 개인 키를 저장하지 않고 calldata를 해독하지도 않습니다. 고유한 카드 ID를 지니고 정확히 한 대의 기기에만 페어링되며, WATS 앱 안에 있는 키에 대해 탭으로 인증하는 장치입니다. 그래서 물리적 요소가 하나 더해집니다 — 화면 위에만 있는 무언가가 아니라 손에 쥔 무언가가요 — 하지만 읽을 수 없는 요청을 읽을 수 있게 만들어 주지는 못합니다. 프롬프트 자체 말고는 그 무엇도 그렇게 할 수 없습니다.\u003C\u002Fp>\n\u003Cp>그러니 두 절반을 따로 다루세요. 읽는 절반은 습관입니다. 읽을 수 없는 것에는 절대 서명하지 말고, 맨 16진수로 날아오는 것은 거부하세요. 수탁의 절반은 한 번 내리는 선택입니다. 키는 비수탁형 지갑에 두고, 서명 권한은 있어야 할 자리에 두세요. \u003Ca href=\"\u002Fhot-wallet\">WATS Hot Wallet\u003C\u002Fa>을 설치해 읽을 수 없는 프롬프트는 자동 거부로 만들고, WATS 앱 안의 키에 대해 당신을 인증해 줄 물리적 요소를 원한다면 \u003Ca href=\"\u002Fnfc-card\">WATS NFC Metal Card\u003C\u002Fa>를 기기에 페어링하세요.\u003C\u002Fp>",[10,13,16,19],{"q":11,"a":12},"블라인드 서명은 eth_sign과 같은 말인가요?","아닙니다 — eth_sign은 블라인드 서명의 가장 극단적인 사례입니다. 블라인드 서명은 무엇을 승인하는지 읽을 수 없는 모든 승인을 말합니다. 원시 calldata, 불투명한 타입 데이터, 해시만 보여주는 하드웨어 화면이 모두 여기 해당합니다. eth_sign은 원리상 검증이 불가능하다는 점에서 한 걸음 더 나아가며, 그래서 주요 지갑들이 이를 폐기하거나 제거했습니다. 모든 eth_sign 요청은 블라인드 서명이지만, 평범한 트랜잭션 프롬프트에서도 블라인드 서명은 얼마든지 일어납니다.",{"q":14,"a":15},"하드웨어 지갑을 쓰면 블라인드 서명에서 보호받나요?","부분적으로만 그렇습니다. 하드웨어 지갑은 키를 오프라인에 두고 멀웨어가 손댈 수 없는 화면에 요청을 표시합니다 — 그러나 기기가 컨트랙트 호출을 해독하지 못하면 해시만 보여줄 수 있고, 해시를 확인하는 것은 무엇을 승인했는지에 대해 아무것도 알려주지 않습니다. 2026년 현재 클리어 서명 메타데이터 표준이 기기 화면까지 도달하면서 보호 수준은 나아지고 있습니다. 하드웨어는 키를 격리할 뿐, 그 자체로 트랜잭션을 설명해 주지는 않습니다.",{"q":17,"a":18},"비수탁형 지갑을 쓰면 블라인드 서명에서 보호받나요?","지켜주는 것은 키이지 결정이 아닙니다. 비수탁형이라는 말은 오직 당신만이 서명을 만들어낼 수 있다는 뜻입니다 — WATS Hot Wallet이 그 예로, 키는 당신이 보유하고, WATS는 어떤 키도 보유하지 않으며, Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana, TON에서 당신의 승인 없이는 아무것도 움직이지 않습니다. 이는 다른 누군가가 당신을 대신해 서명할 위험을 없애 주지만, 당신이 직접 승인한 서명은 여전히 구속력을 가지므로 승인 전에 요청을 읽는 일은 계속 당신의 몫입니다. WATS NFC Metal Card는 WATS 앱 안에 있는 키에 대해 탭으로 인증하는 물리적 요소를 더해 줍니다 — 카드는 개인 키를 저장하지 않고 calldata를 해독하지도 않습니다.",{"q":20,"a":21},"지갑이 원시 16진수만 보여줄 때는 어떻게 해야 하나요?","거부하세요. 읽을 수 없는 서명 요청은 평가할 수 없는 요청이고, 거부에 드는 비용은 다시 시도하는 수고뿐입니다. 그런 다음 확인하세요. 그 dApp이 진짜인지, 당신의 지갑이 해당 체인에서 해독과 시뮬레이션을 지원하는지, 그 동작이 정말 그 메서드를 필요로 하는지. 해독된 프롬프트나 시뮬레이션 미리보기처럼 읽을 수 있는 경로가 있다면 그것을 쓰세요. 그런 경로가 전혀 없다면 그 요청은 신뢰할 수 없는 것으로 보고 자리를 뜨세요.",1786059448629]