Cabinet
テクノロジーインサイト一覧へ戻る
2026.09.01

Ledger、Ethereumアプリの`signEIP712HashedMessage`を廃止——LedgerJS全体が非推奨、DMKへの移行が必須に

Ledger、Ethereumアプリの`signEIP712HashedMessage`を廃止——LedgerJS全体が非推奨、DMKへの移行が必須に

何が起きたか

Ledgerの開発者ポータル（最終更新2026年8月31日）は、2026年9月中にEthereumデバイスアプリがsignEIP712HashedMessageのサポートを落とすと告知している。これはEIP-712の「ハッシュ／ブラインド署名」版のAPIで、ホスト側が型付きデータそのものではなくドメインセパレータとメッセージのハッシュをデバイスへ渡し、デバイスはその値に署名するという経路である。

ポータルは、この削除が@ledgerhq/hw-app-ethの「最後の動作経路」を奪うと明記している。そのうえで、hw-app-*およびhw-transport-*というLedgerJSパッケージ群が、その日付をもってすべて非推奨になると宣言した。移行先はDevice Management Kit（DMK）で、対応表も同ページに示されている。@ledgerhq/hw-app-ethは@ledgerhq/device-signer-kit-ethereumへ、hw-app-btcはdevice-signer-kit-bitcoinへ、hw-app-solanaはdevice-signer-kit-solanaへ。トランスポート側はhw-transport-webhidがdevice-transport-kit-web-hid、hw-transport-web-bleがdevice-transport-kit-web-ble、hw-transport-node-hidがdevice-transport-kit-node-hidへ移る。

告知されているのは「2026年9月中」であり、日付は指定されていない。これは後述するように、実務上は緩和ではなく難点として働く。

なぜブラインド署名を切るのか

EIP-712は、構造化されたデータに人間が読める形で署名するための規格である。本来の意図は、ユーザーが「何に署名するのか」を理解したうえで承認できることにある。ところがsignEIP712HashedMessageは、その構造をデバイスに渡さない。デバイスが表示できるのは32バイトのハッシュ二つであり、署名者はドメイン、型、フィールド値のいずれも確認できない。

この経路が長く残ったのは実装上の都合による。型付きデータの完全なパースをデバイスのファームウェア上で行うには、限られたメモリで任意の型定義を処理する必要があり、対応が遅れた。その間、ウォレットやdAppはハッシュ版を使って機能を提供し続けた。

結果として何が起きたかは、この数年の被害パターンが示している。無制限のトークン承認、NFTの一括移転を許すオーダー、リレーヤ経由の権限委譲——これらはいずれもEIP-712の署名一つで成立し、ユーザーの画面には意味のない16進数だけが出る。ハードウェアウォレットの安全性の根拠は「デバイス画面で最終確認できること」だが、ブラインド署名はその根拠を無効化する。Ledgerが開発者ポータルにClear Signing（明確な署名）の節をdApp向け・ウォレット向けの双方に設けていることからも分かるとおり、今回の削除はこの一連の方針の帰結である。設計の選択としては、「後方互換のために安全性の根拠を残し続けない」という判断にあたる。

「表示できること」を成立させる条件

明確な署名を実際に成立させるには、デバイス側が型付きデータを解釈するだけでは足りない。Permitのような広く使われる構造であれば標準的な表示が用意されるが、独自の型定義を持つコントラクトの場合、フィールド名と値を人間が理解できる文言に対応づけるための情報が別途必要になる。つまり、デバイス側の対応とアプリケーション側のメタデータ提供の両方が揃って初めて、ユーザーは「無制限のUSDCを0x…に承認する」という意味を読めるようになる。

この構造は、責任の所在をハードウェアベンダーからdApp・ウォレット側へ一部移す。従来は「Ledgerが対応していないから読めない」で済んでいた説明が、今後は「自社が表示情報を用意していないから読めない」に変わる。Ledgerが開発者ポータルでdApp向けとウォレット向けの両方にClear Signingの節を設けているのは、この分担を明示するためである。

移行のもう一つの側面は、トランスポートの扱いである。非推奨リストにはhw-transport-webhid、hw-transport-web-ble、hw-transport-node-hidが含まれる。これらはブラウザのWebHID、Web Bluetooth、Node.jsのHIDという、実行環境ごとに異なる接続手段を抽象化するパッケージ群で、移行先もそれぞれ別のパッケージになる。ブラウザ拡張、デスクトップアプリ、CI上の署名バッチのように複数の実行環境を持つプロダクトは、環境ごとに移行と回帰試験が必要になると見ておくべきである。

想定される落とし穴

第一に、壊れるのはあなたのパッケージのバージョンではなく、ユーザーの手元のデバイスアプリである。JavaScript側のライブラリをいくら固定しても、デバイスのEthereumアプリが更新された時点でハッシュ版の経路は消える。そして更新のタイミングはユーザーが決める。つまり、ある日時に一斉に壊れるのではなく、ユーザーごとに順次壊れる。サポート窓口には「昨日まで動いていた」という報告が断続的に届き、原因の切り分けがデバイスアプリのバージョン依存になる。

第二に、DMKへの移行はパッケージ名の置換ではない。DMKはデバイス管理とトランスポート、署名機能を分離したアーキテクチャで、接続の確立、デバイス状態の購読、署名要求の発行がそれぞれ別のレイヤーに分かれている。既存のhw-app-ethベースのコードは、呼び出し規約が対応表のとおりに一対一で写るわけではないため、移行にはリファクタリングの工数を見込む必要がある。

第三に、非推奨の範囲がEthereumに限られない点を見落としやすい。トリガーはEthereumアプリのAPI削除だが、宣言されているのはhw-app-*とhw-transport-*の全体である。Bitcoin用やSolana用のLedgerJSパッケージしか使っていないチームも、同じ期限で移行対象に含まれる。

第四に、移行後に「表示できないので署名できない」ケースが出る。明確な署名は、デバイスが型付きデータを解釈して表示できることを前提とする。自社のコントラクトが独自の型構造を持つ場合、表示のためのメタデータが用意されていなければユーザー体験が悪化するか、署名自体が拒否される可能性がある。移行と同時に、自社が署名を求めている型付きデータの一覧を作り、それぞれがデバイス上でどう表示されるかを実機で確認する作業が要る。

【技術インサイトとアクション】

  1. この廃止は、ハードウェアウォレットの安全性の根拠が「秘密鍵がデバイスの外に出ないこと」ではなく「署名対象をデバイス画面で確認できること」にあるという再定義である。鍵の隔離だけを根拠に安全性を説明している自社のドキュメントや脅威モデルは、同じ理由で更新が必要になる。 ［プロダクト側・セキュリティ担当］ 今月中に、自社が署名を要求する全データ型を棚卸しし、デバイス上で内容が読めないまま署名させている箇所を特定する。
  2. 期限がデバイスアプリの更新に紐づくため、障害は「フラグデー」ではなく「ユーザーごとの順次発生」として現れる。同種の構造は、ユーザー環境にインストールされたコンポーネントに依存するすべての統合（ブラウザ拡張、モバイルアプリ、ファームウェア）で再現する。 ［インテグレーター・サポート］ 2週間以内に、デバイスアプリのバージョンをテレメトリまたはエラーログから識別できるようにし、署名失敗の問い合わせをバージョン別に切り分けられる体制を作る。
  3. 期限が「2026年9月中」と月単位でしか示されていないことは、猶予ではなくリスクである。日付が決まっていない削除は、自社の検証スケジュールを外部の裁量に委ねることになる。 ［コントラクト開発者・フロントエンド］ 日付の確定を待たず、9月中の早い時点でDMKへの移行ブランチを検証環境に投入し、旧経路が消えた状態を模したテストを通す。

【引用：出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。