ハードウェアは盗難を防ぐが、悪用は防がない：SSH 鍵から秘密鍵のセキュリティへ

TL;DR

秘密鍵をハードウェアに入れて解決するのは「盗まれること」であって、「借用されること」ではない。マシンを掌握した攻撃者でも YubiKey の中の鍵は持ち出せない。しかし鍵が挿さったままで、タッチも求められないなら、攻撃者はそれで何にでも署名できる。SSH がこの残余リスクを許容できるのは、悪用 1 回の上限がログイン 1 回だからだ。ウォレットはそうはいかない。署名 1 回がそのまま最終結果になる。

• 関門は一つではなく四つ。 エクスポート不可、在席確認、本人確認、署名内容の確認。ハードウェアが標準で与えるのは一つ目だけで、二つ目と三つ目は自分で選ぶもの、四つ目は SSH には不要で、ウォレットには欠かせない。
• 「デバイスに紐づく」と「デバイスに常駐する」は違う。 YubiKey の ed25519-sk の秘密鍵はデバイスから出ない。TPM 方式の秘密鍵は実はディスク上にあり、TPM で暗号化されているだけで、しかもシステムの状態を確認しない。
• タッチ不要のハードウェア鍵は、取引所のホットウォレットと同じ形をしている。 鍵はハードウェアから漏れていないが、署名を要求するサービスを握った者は誰でも署名できる。10 月の Binance の件で示された暫定的な根本原因は、まさにこれだった。
• 冗長化には二つのやり方がある。 SSH は互いに独立した鍵を複数登録し、一本なくしたら一行消すだけ。シングルシグのウォレットは鍵が一本しかなく、バックアップはその複製しかない——シードフレーズはエクスポート可能な完全な秘密鍵だ。
• 量子の前では、エクスポート不可は堀にならない。 公開鍵がすでに公開されている鍵は盗む必要がない。GitHub は全ユーザーの SSH 公開鍵を github.com/<ユーザー名>.keys で公開しており、Ethereum のアカウントは最初の送金以降、署名から公開鍵を復元できる。OpenSSH の標準のポスト量子方式が守るのはセッションの鍵合意であって、署名ではない。
• これからの秘密鍵のセキュリティは「いつでも差し替えられる鍵の組」であって、「もっと盗みにくい一本の鍵」ではない。 差し替えには変更できる認可層が要る。authorized_keys は最初からそうなっているが、シングルシグのアドレスはそうなっておらず、マルチシグとスマートアカウントがそれを取り戻した。

本稿は infected.systems の 2026-11-04 のブログ記事を出発点にしている。著者はディスク上の SSH 秘密鍵をすべて削除し、YubiKey、TPM、Apple Secure Enclave の三つのハードウェア方式に移行した。操作の詳細は原文と各ツールのドキュメントに従う。四つの関門という枠組み、ウォレットとの対照、量子の節は私が加えたもの。三つの方式を自分で一つずつ試したわけではない。

1. ハードウェアは何を変えたのか

従来のやり方は、パスフレーズ付きの秘密鍵ファイルをディスクに置くことだ。OpenSSH は bcrypt で導出した鍵でそれを暗号化するので、ファイルだけが漏れても大きな問題ではない。しかし ssh-agent が復号すると、秘密鍵はセッションが終わるまで平文のままメモリに載る。root を取った攻撃者はそれをメモリから抜き取れる——そうなればオフラインで、無期限に、どこからでも使える。

ハードウェア方式が変えたのはまさにこの点だ。秘密鍵はセキュリティチップの中で生成され、チップは「それで署名する」インターフェースは提供するが、「読み出す」インターフェースは提供しない。root を取った攻撃者もこのインターフェースは呼べるが、使えるのは攻撃者がそのマシンを掌握し、かつデバイスが挿さっている間だけだ。

つまりハードウェアはリスクを「永久的な窃取」から「オンライン中の借用」へと縮めた。これは確かな前進だが、同時にハードウェアがやらないことも示している。署名すべきかどうかは判断しないし、何に署名しているかも知らない。

2. 一つにまとめられがちな四つの関門

最初の二つは「誰かがいるか」、三つ目は「本人か」、四つ目は「何のためか」に答える。SSH の署名はログインのチャレンジに応えるだけで、署名する内容そのものに意味はないので、四つ目の関門は存在しない。ウォレットは違う。署名そのものが送金であり、承認であり、コードの委任であって、内容がすべてだ。

3. 三つの方式はいくつの関門を与えるか

生成コマンドはどれも短い：

ssh-keygen -t ed25519-sk -O resident -O verify-required
ssh-tpm-keygen -N "<PIN>"
sc_auth create-ctk-identity -l "<ラベル>" -k p-256-ne -t bio

表で最も見落とされやすいのは TPM の列だ。デバイスに紐づくこととデバイスに常駐することは別物だ。 ディスク上の .tpm ファイルはその TPM から離れれば役に立たないが、鍵の素材は確かにディスク上にある。さらに PCR を見ないので、同じマシンで別の OS を起動しても、PIN がなければそのまま使える。TPM があるなら使えばよいが、PIN は設定しておくこと。

4. タッチ不要のハードウェア鍵は、ホットウォレットの形をしている

原文は無人で動かす必要がある場面に触れている。起動時にリモートのディレクトリを自動マウントするが、そばで YubiKey にタッチする人はいない。解決策は no-touch-required の鍵を作り、サーバーの authorized_keys の該当行の先頭に同名のオプションを明示的に付けることだ——付けなければ OpenSSH は標準で拒否する。

この時点で、四つの関門は一つ目しか残っていない。鍵はやはり盗めないが、そのホストを掌握した者なら誰でも気づかれずに呼び出せる。

取引所のホットウォレットの署名サービスは、この形をしている。 秘密鍵は HSM や MPC の中にあってエクスポートされない。しかし署名の要求はあるサービスから出され、1 件ずつ確認する人はいない。攻撃者は鍵を盗む必要はなく、「署名を要求してよい」アイデンティティになれば足りる。

本サイトの 10 月の記事は Binance が示した暫定的な根本原因を整理している。DevOps エンジニアのノートパソコンが侵害され、攻撃者はそこからサービスコンテナに入り、不正な出金を送信した。発表は秘密鍵の漏洩は見つかっていないとしている。矛盾はない——秘密鍵はそもそも漏れる必要がなかった。

個人への教訓はこうだ。どうしてもタッチ不要にしなければならない鍵があるなら、それを別の一本にし、別に権限を絞る。authorized_keys の各行には制限を付けられる：

no-touch-required,restrict,from="10.0.0.5" [email protected] AAAA... nas-mount

from= は接続元アドレスを固定し、restrict はポート転送、エージェント転送、端末の割り当てを無効にする。必要なら command= を加えて単一のコマンドに縛る。こうすれば気づかれずに呼び出されても、できることはわずかだ。ホットウォレットで対応するのは上限額、許可リスト、遅延で、原理は同じだ。この鍵は誰も見ていないときに使われると認めたうえで、何に使えるかを制限する。

5. 冗長化：複数の鍵か、一本の鍵の複製か

ハードウェア鍵の最も現実的な問題は紛失だ。デバイスが壊れたり、なくなったり、買い替えたりすれば、中の秘密鍵は失われる。そもそもエクスポートできないのだから。

SSH の解決策はきれいだ。authorized_keys には何行でも書ける。普段使いの YubiKey、引き出しにしまった予備の YubiKey、Mac の Secure Enclave——互いに独立した三本を、すべて登録する。一本なくしたら、その行を消せば、残りはそのまま使える。この過程で、どの秘密鍵も一度も複製されていない。

シングルシグのウォレットにはこの構造がない。一つのアドレスに鍵は一本で、バックアップするにはその鍵自体を複製するしかない——それがシードフレーズだ。ハードウェアウォレットは日常の使用では秘密鍵をデバイスの外に出さないが、その横にある 24 語を書いた紙は、完全な、エクスポート可能な秘密鍵だ。本当のセキュリティ境界はその紙であって、デバイスではない。 構造としては、ハードウェアウォレットとシードフレーズの組み合わせは YubiKey 方式より TPM 方式（鍵の素材がデバイスの外にあり、別のもので守られている）に近い。

本サイトの Coldcard のシードのリスクについての記事（中国語）は、この境界が崩れたときの帰結——シードの生成、エントロピー源、シングルシグの単一障害点——を扱っている。

マルチシグとスマートアカウントは SSH の構造を取り戻した。独立した複数の鍵を閾値で認可し、一本なくしたらその一本を差し替える。そして Secure Enclave と多くのパスキーが使うのは、まさに P-256 曲線だ——RIP-7212 によって複数の L2 が P-256 の署名検証をネイティブに扱えるようになり、Ethereum メインネットに対応する提案は EIP-7951 だ。原文で Mac に置かれた SSH 鍵と同じ種類の鍵が、そのままスマートアカウントの署名者の一つになれる。

同期型のパスキー（iCloud キーチェーン、Google パスワードマネージャー）は別の道を行く。秘密鍵は暗号化されて自分の他のデバイスに同期され、1 台なくしても鍵は失われない。これはエクスポート不可を回復可能性と引き換えにするもので、ただではない——信頼する境界が一つのチップから同期の仕組み全体へと広がる。

6. 四つ目の関門：SSH には不要、ウォレットには欠かせない

SSH 鍵が悪用されても、最悪の場合は攻撃者がセッションを得るだけだ。ひどい話だが、ログが残り、取り消せ、被害を止められる。

ウォレットの鍵が悪用されれば、署名 1 回で資産が持ち出され、取り消せない。だからウォレットは四つ目の関門に向き合わなければならない。確認を押すとき、自分が何に署名しているか分かっているか。

2025 年 2 月の Bybit の件は、この関門が破られた例だ。Safe のフロントエンドが改ざんされ、その発端は Safe の開発者の一人のコンピュータへの侵入だった。マルチシグの署名者たちはハードウェアウォレット上で、画面の表示とはまったく違うトランザクションを承認した。ハードウェアはそこにあり、確認は押され、本人確認も通った——最初の三つの関門はすべて通過し、四つ目だけが破られた。

この関門は人の層だけの話でもない。本サイトの Binance の件の記事では、EIP-7702 の Type-4 トランザクションを取り上げた。to はウォレット自身、金額は 0、データは空で、calldata だけを解析するポリシーエンジンには無害な自己送金に見える。機械が「見ている」ものさえ間違いうる。

二つの件にはもう一つ共通点がある。どちらもエンジニアのコンピュータから始まった。開発マシン上の SSH 秘密鍵、クラウドの認証情報、署名サービスを呼び出せるトークンは、同じ攻撃経路の上にある輪だ。ディスク上の秘密鍵を消すのは、SSH のためだけではない。

7. 量子：エクスポート不可が防ぐのは物理的な抽出で、数学ではない

原文の三つの方式はすべて楕円曲線を使う。Ed25519 と P-256 だ。Bitcoin と Ethereum が使う secp256k1 も同じだ。十分に大きな量子コンピュータで Shor のアルゴリズムを動かせば、公開鍵から秘密鍵を直接計算できる。

そうなればエクスポート不可は意味を失う——攻撃者はデバイスに触れる必要がなく、公開鍵さえあればよい。だから本当の問題はこうなる。あなたの公開鍵はすでにどこまで公開されているか。

OpenSSH は 9.0 から鍵合意にハイブリッドのポスト量子アルゴリズムを標準で使い、10.0 からは ML-KEM ベースのハイブリッド方式に切り替えた。これが防ぐのは「いま通信を記録して、将来復号する」攻撃で、守るのはセッションの内容だ。ログインに使う署名鍵は変わっておらず、いまも楕円曲線だ。 主流の FIDO2 ハードウェアも、まだポスト量子署名に対応していない。

量子がいつ来るかを本稿は予測しない。本サイトの 4 月の記事（中国語）は Google Quantum AI の推計を整理している。50 万量子ビット未満で、数分以内に攻撃を完了できる。Google はこれを受けて、自社のポスト量子移行の予定を 2029 年に前倒しした。

予定がどうであれ、両者の立場は大きく違う：

• SSH の移行はほとんどただだ。 鍵はいつでも差し替えられ、authorized_keys は単なるリストだ。ポスト量子署名がハードウェアに入れば、新しい鍵を作り、登録し、古いものを消す。午後一つで終わる作業だ。いま収集された GitHub の公開鍵が役に立つのは、そのときまでその鍵がまだ信頼されている場合だけだ。
• シングルシグのアドレスの移行は引っ越しと同じだ。 鍵を替えるとは、資産を新しいアドレスへ移すことだ。公開鍵がすでに露出した古いアドレスは、量子が来る前に移さなければ標的になる。そしてプロトコルレベルのポスト量子署名は、本稿の知る限り、Bitcoin と Ethereum のメインネットではまだ提案と研究の段階にある。
• スマートアカウントはその中間にある。 署名を検証するロジック自体がコードなので、署名アルゴリズムを替えるのは認可層のアップグレードであって、資産を移す必要はない。

8. では、これからの秘密鍵のセキュリティはどんな形か

これまでの節を合わせると、向かう方向は一致している。もっと盗みにくい一本の鍵ではなく、いつでも差し替えられる鍵の組と、変更できる認可層だ。

• エクスポート不可はハードウェアに任せる。
• 在席確認と本人確認は標準で有効にし、どうしても無効にする一本は別に権限を絞る。
• 署名内容の確認：署名の前にデバイスの画面でデコードされた内容を見て、ブラインド署名は拒否する。
• 冗長化は独立した複数の鍵で行い、一本の複製には頼らない。
• 認可層を変更できるようにしておく。そうすればアルゴリズムの変更、デバイスの交換、侵害された一本の差し替えのどれも、ゼロからやり直す必要がない。

SSH の authorized_keys はずっと前からこの構造を持っているが、それをセキュリティ設計のお手本として扱う人は少ない。マルチシグ、スマートアカウント、パスキーの署名者は、ウォレットが同じ教訓に追いつこうとしている姿だ。

9. 個人がすぐにできること

• SSH：各サーバーに少なくとも 2 本のハードウェア鍵を登録する（普段使いと、オフラインで保管するもの）。生成時に verify-required を付ける。どうしてもタッチ不要にする一本は別に作り、from= と restrict で権限を絞る。
• TPM のある Linux マシン：使ってよいが、秘密鍵は暗号化されてディスク上にあり、システムの状態には紐づかないことを知っておき、必ず PIN を設定する。
• クラムシェルモードで使う Mac：Secure Enclave の指紋方式はそのまま失敗する。Touch ID 付きの外付けキーボードを使うか、YubiKey 5C Nano を挿す。
• GitHub：公開鍵は公開されている。ポスト量子署名が使えるようになるまでは問題ないが、使えるようになったら早めに入れ替える。
• ウォレット：大きな額はマルチシグかスマートアカウントで持ち、署名者を別々のハードウェアに分散させる。シードフレーズを唯一の冗長化にしない。ハードウェアの画面で読めない署名は決してしない。
• 開発マシン：攻撃経路の出発点だ。ディスク上に平文の秘密鍵を置かず、クラウドの認証情報と署名サービスのトークンも同じように扱う。

10. この記事で分からないこと

• 実際には試していない。 三つの方式のコマンドと動作は原文と各ツールのドキュメントに従っており、システムのバージョンによって違う可能性がある。
• ハードウェアにも脆弱性はある。 2024 年に公開されたサイドチャネル EUCLEAK は、ファームウェア 5.7 より前の YubiKey 5 シリーズに影響し、悪用には物理的な接触と専用の機器が必要だ。本稿は特定のチップの安全性を評価しない。
• 量子の時期は予測しない。 引用した推計は本サイトの以前の記事によるもので、本稿の判断ではない。
• セキュリティ監査ではない。 どの方式が合うかは脅威モデル次第だ。原文の著者自身も、パスフレーズ付きのディスク上の鍵で多くの人には十分だと書いている。

結論。 あのブログ記事の題は「SSH 鍵をすべて削除した」だが、より正確に言えば、著者はすべての鍵を盗めないものに置き換えた。これは正しい第一歩だ。第二歩は、盗めない鍵でも借用はされうると認めること——だから在席確認、本人確認、権限の制限が要る。第三歩は、鍵はなくなり、アルゴリズムは古くなると認めること——だから複数の鍵、差し替え可能であること、変更できる認可層が要る。SSH は一つのテキストファイルで後の二つを実現している。ウォレットは長い年月をかけて、マルチシグとスマートアカウントでそれを取り戻した。

資料：I deleted all my SSH keys（infected.systems、2026-11-04）、ssh-tpm-agent。本サイト内のリンクは本文中にある。本稿は技術的な整理であり、セキュリティ監査ではない。