Verifiable Transaction Payload (VTX) はコールドウォレットの署名セキュリティをどのように向上させるか？

お知らせ
Table of Contents

概要

この記事では検証可能なトランザクションペイロード（Verifiable Transaction Payload (VTX) 1）について紹介します。

コールドウォレットやマルチシグウォレットからの不正な資金流出が発生しています。これらの中の注目すべきケースとして、アドレスポイズニングによるもの(DMM 20242)や、EVMチェーンのトランザクションをデコードできない問題に起因するもの(Bybit 20253, Radiant Capital 20244)があります。

※注意: DMM 20242では類似したアドレスが利用されたことは判明していますが、具体的にアドレスポイズニングが原因だったかどうかは不明です

これらの共通の発生原因は、トランザクション署名者自身が正確にトランザクションの内容を把握せずに署名してしまったことにあります。しかし、署名デバイスの計算能力とネットワークの制約上、特にEVM系ではトランザクションの内容を要約して署名責任者に表示することが難しいです。
Bitcoinの場合にはディスクリプターウォレット56という仕組みがあり、ある程度複雑ではあるものの、署名者が一定の条件ではスクリプト内で署名しようとしている内容を確認できるような仕組みがあります。しかし、そうだとしても、ディスクリプターウォレットの仕組みを強制するだけでは DMM Bitcoinへ行われたようなアドレスポイズニング攻撃に対する対策にはならないです。

また、多くの攻撃において、公式発表前に外部から「不審な出金がある」として指摘されているのも特徴です。
これらを踏まえて、コールドウォレットのトランザクションの正当性検証の補助的な情報を得るために、コールドウォレット外部のシステムに協力してもらう仕組みが Verifiable Transaction Payload (VTX) 1として考案されています。

VTXの概要

多くの場合、ハードウェアウォレットではトランザクション自体の正当性検証ではなく、署名作業の安全性のみを担保しています。例えばRadiant Capitalの例ではSafe Walletフレームワークのフロントエンドのソースが攻撃者によって改変されていたため、ハードウェアウォレット上で確認しなければ攻撃を防げませんでした。しかしそもそもハードウェアウォレット上ではトランザクションの中身をユーザーに意味のある形で提示していなかったため、結果としてハードウェアウォレット上で確認はできず、署名を許してしまいました。

VTXでは、通常のトランザクションに加えて、以下の シミュレーションと検証の仕組みを導入します。

署名の図

sequenceDiagram
    autonumber
    participant U as User
    participant SI as Signing Interface
    participant VP as Verification Provider
    participant HWW as Hardware Wallet

    U->>SI: 取引を開始
    SI->>VP: txデータを送信（解析依頼）

    rect rgb(245,245,245)
    note over VP: 検証プロバイダ側の処理
    VP->>VP: シミュレーション（挙動・リスクの把握）
    VP->>VP: バリデーション（悪意/有害性の評価）
    VP->>VP: VTX= { tx, simulation, validation } を生成
    VP->>VP: VTXに暗号学的署名
    end

    VP-->>SI: 署名済みVTXを返却
    SI-->>U: シミュレーション/検証結果を表示
    U->>SI: 承認

    SI->>HWW: tx + 署名済みVTX を送付
    HWW->>HWW: 検証プロバイダ公開鍵でVTX署名を検証

    alt 署名検証 NG
        HWW-->>U: 警告して取引を不信扱い（中断）
    else 署名検証 OK
        HWW->>U: 正確なプレビュー提示 / 検証結果に基づく警告
        U->>HWW: 最終確認
        HWW-->>SI: 取引に署名
    end

    note over HWW: ハードウェア側でVTX整合性を独立検証するため<br/>署名インターフェースの改ざんに耐性

署名の流れ

  1. 署名インターフェースがトランザクションを検証プロバイダへ送信します:

    • ユーザーがトランザクションを開始すると、署名インターフェースはトランザクションデータを検証プロバイダに送信し、以降の処理を委ねます。

  2. 検証プロバイダによるシミュレーションとバリデーション:

    • 検証プロバイダはトランザクションをシミュレーションして、その挙動を予測し、ユーザーの意図に合致していることを確認します。このシミュレーションは、想定外の結果やリスクを可視化します。
    • 次に、プロバイダはバリデーションを実施し、トランザクションが悪意を含む可能性やユーザーに不利益を与える可能性を分析します。
    • その後、検証プロバイダは検証可能なトランザクション・ペイロード（VTX）を生成します。VTX には、①トランザクション、②シミュレーション結果、③バリデーション結果の三要素がすべて含まれます。

  3. VTX の暗号学的署名:

    • VTX が用意できたら、検証プロバイダはペイロードに暗号学的署名を施します。この署名により、トランザクション・シミュレーション・バリデーションの各結果が改ざんされていないことが保証され、完全性が保たれます。
    • 署名済みの VTX は署名インターフェースへ返送され、ユーザーは（シミュレーションおよびバリデーション結果に基づき）詳細を確認します。
    • ユーザーがトランザクションを承認すると、最終的な検証と署名のためにハードウェアウォレットへ送られます。

  4. ハードウェアウォレットによる VTX の検証:

    • VTX を受信すると、ハードウェアウォレットは検証プロバイダの公開鍵を用いて暗号学的署名を検証し、その完全性を確認します。
    • この検証により、送信中にトランザクションが改ざんされていないことが保証されます。
    • 署名が一致しない場合、ハードウェアウォレットはユーザーに警告し、そのトランザクションを信頼できないものとして扱います。

  5. 最終的なトランザクション署名:

    • 署名が検証されると、ハードウェアウォレットはそのトランザクションがシミュレーションおよびバリデーション結果と一致していることを完全に信頼できます。これにより (i) シミュレーションがトランザクションを正確に反映していることを前提に、ユーザーに正確なプレビューを提示すること (ii) バリデーション結果を参照してトランザクションが悪意あるものかを検知し必要に応じてユーザーに警告すること、が可能になります。
    • これらの機能により、ユーザーは自分が署名するトランザクションが署名インターフェースで閲覧したものと同一であり、かつ無害で有利であることを確認できます。
    • ユーザーは、そのトランザクションが改ざんされておらず、安全性について検証済みであることを確信したうえで、署名できます。

VTXによってどのような攻撃が防げるか

  • Radiant Capitalで発生したような、ウォレットのフロントエンドを改ざんされた場合でも、適切なシミュレーション結果をハードウェアウォレット上で表示しユーザーに影響を警告することができます。
  • BybitのケースもRadiant Capitalと同様です。
  • DMM Bitcoinで発生したようなアドレスポイズニングについて、アドレスポイズニングの可能性を外部から事前に検知して警告できます。

VTXによって攻撃が防げないケース

  • 署名者がVTXの忠告を無視して署名を強行した場合
  • 正しいトランザクションであるにもかかわらず影響が複雑で、攻撃されていないのにシミュレーションが失敗してしまうため、そもそも導入ができない場合
  • シミュレーションのプロバイダが攻撃者に掌握されている場合
  • シミュレーションが攻撃の影響を見逃してしまう場合

VTXの改善点

  • そもそもVTXは規格化されておらず、単にblockaidという会社が概念を提案しているだけの段階です。何らかの規格として標準化することで複数ウォレットベンダーに受け入れられやすくなりそうです。
  • EVMを念頭に作られているが、EVMだけではなく、ディスクリプターウォレットを使ったBitcoinでも導入できるため、複数チェーンに最初から対応した方が良さそうです。
  • シミュレーションを実施するプロバイダは複数人設定できる方がよいです。
  • 緊急時などプロバイダの情報を無視した方が良い状況もありえそうなので、VTXの検証をパスすることをトランザクション署名時に強制せず、補助的な情報として表示するだけの方が良いかもしれません。

参考文献

  1. Transaction Verification: A Solution to Blind Signing in Hardware Wallets https://www.blockaid.io/blog/transaction-verification-a-solution-to-blind-signing-in-hardware-wallets ↩ ↩

  2. DMMビットコインの不正流出（2024/5/31） https://note.com/valuesharing/n/ncfdf4ddfa0b6 ↩ ↩

  3. In-Depth Technical Analysis of the Bybit Hack https://www.nccgroup.com/research-blog/in-depth-technical-analysis-of-the-bybit-hack/ ↩

  4. Radiant Capital Post-Mortem https://medium.com/@RadiantCapital/radiant-post-mortem-fecd6cd38081 ↩

  5. ディスクリプターウォレットを使ってバックアップ機能付きビットコインウォレットを作ってみる https://tech.hashport.io/4855/ ↩

  6. Miniscript https://bitcoin.sipa.be/miniscript/ ↩

タイトルとURLをコピーしました