調査ノート（2026年9月3日）。本稿では、確認済みの事実、ベンダーの声明、オンチェーン上の推計、および筆者ら自身の分析を明確に区別する。本稿執筆時点で、Coinkiteによる正式な技術的事後検証報告書はまだ公表されていなかった。調査者が追加の取引を関連付けるにつれて損失総額も変動しているため、以下の数値は最終集計ではなく、各時点でのスナップショットである。

2026年7月、Coldcardハードウェアウォレットによって鍵が保護されていると考えていた所有者の数千件のアドレスから、Bitcoinが失われた。最初に訂正すべき最重要点は、この事件の本質を最もよく示している。すなわち、デバイスがリモートから乗っ取られたわけではない。一部のウォレットが作成された際に使われた乱数性が、ファームウェアの不具合によって弱められていた。攻撃者は別の場所で縮小した鍵空間を探索し、秘密鍵の候補を復元し、そこから導出したアドレスを公開Bitcoinブロックチェーンと照合して、一致する資金をハードウェアに触れることなく移動できた。

堅牢な物理構造を備えた金庫であっても、内部に収められた秘密が当初から予測可能であれば破綻し得る。

だからこそ、この事件は単一のベンダーをはるかに超える重要性を持つ。「ハードウェアなら安全」「部品が多いほど保護も強い」「機能一覧が長いほど保証水準も高い」という安心感を与える短絡的な見方に、疑問を突きつけるからである。これらはいずれも脅威モデルではない。セキュリティは、エントロピー、ファームウェア、ハードウェア、ビルド工程、配布、インターフェース、バックアップ、運用者の行動、物理的安全性から成るシステム全体と、その主張を外部者が検証できる証拠によって成立する。

Coldcardで何が起きたのか

Coinkiteの公式勧告によれば、影響を受けたファームウェアでは、不具合のあるシード生成経路が使われていた。Mk2またはMk3でファームウェア4.0.1から4.1.9を使って作成されたウォレットシードは、十分な量の、非公開かつ独立したサイコロ由来のエントロピーが追加されていた場合、または強力で一意なBIP39パスフレーズが追加の障壁となっていた場合を除き、危険にさらされていた。この勧告は、修正版のstandardまたはEdgeリリースより前にMk4、Mk5、Qで生成されたシードも対象としている。後者のデバイスについて、Coinkiteは意図された128ビットではなく、約72ビットのエントロピーだったと報告している。

この不具合は2021年3月にリリースされたファームウェアに端を発し、何年もの間、潜在したままだった。ハードウェアの保護機構は、与えられた秘密に対しては機能していた。問題は、秘密の生成過程が期待された不確実性を備えていなかったことにある。攻撃者が現実的なコストで候補シードを列挙できるようになると、公開ブロックチェーンが完全な照合手段となった。すなわち、アドレスを導出し、資金の有無を調べ、復元できた鍵で署名すればよい。フィッシングの画面表示、USB接続、盗難された配送物、物理アクセスはいずれも必要なかった。

弱いエントロピーが破局的な結果を招く理由

ウォレットシードは、人間の目にランダムに見えるから安全なのではない。敵対者が、その基礎となる可能性の集合を現実的に識別も列挙もできないときに安全なのである。エントロピーが1ビット増えるごとに探索空間は2倍になる。128ビットから72ビットへの低下は、シードが「少し弱くなる」という程度ではない。必要な作業量の倍増を56回分失うことを意味する。実効探索空間がさらに小さければ、天文学的に不可能だった探索が工学的プロジェクトへと変わる。

リカバリーワードは構文上有効なままである。アドレスも通常どおりに見える。ハードウェアは正常に署名する。バックアップからも正しく復元できる。これは静かな障害であり、目に見える一連の手順がすべて成功しても、その時点ですでにセキュリティの前提が崩壊していることがある。まさにそのため、乱数生成には、接続経路を対象とする決定論的テスト、エントロピー源を対象とする実機上の計測、そしてレビュー済みソースと出荷済みファームウェアを結び付けるリリース証拠が必要である。

窃取は複数の波に分かれて進行した

7月30日、最初に報告された一斉移動では、約25分のうちに約500件のアドレスからおよそ594 BTCが移された。その後、取引の帰属判定が進むにつれて事件の範囲は拡大した。8月5日に公表されたTRM Labsの評価では、4回の波を通じて5200件を超えるアドレスから約1816 BTC、その時点の換算で約1億1600万米ドルに達したという暫定集計が示された。他の調査者は異なる確認基準を用い、その後、やや異なる総額を報告している。したがって、これらの数値は、確定した最終台帳ではなく、規模を示す証拠として読むべきである。

Coinkiteの現行のセキュリティ状況ページには、正式な事後分析がなお進行中であることが明記されており、報告された損失のすべてが個別に本件へ帰属されたとは主張していない。この不確実性は、事件を過小評価する理由にはならない。検証済みのメカニズム、観測された取引、分析上の帰属、最終的なフォレンジック結論を区別し続けるべき理由である。

ファームウェアを更新しても古いシードは修復されない

これは、影響を受ける利用者が決して見落としてはならない運用上の事実である。修正版ファームウェアは今後のシード生成を是正できるが、すでに存在するシードへ遡及的にエントロピーを加えることはできない。そのシードから新しいハードウェア上に復元したウォレットも、同じ脆弱な秘密によって制御され続ける。金属製の筐体を交換しても、モバイルアプリを導入しても、リカバリーワードを別のブランドへ移しても、鍵は変わらない。資金は、新たに生成され、独立して保護されたシードから導出したアドレスへ移さなければならない。

2026年9月3日に確認した時点で、Coldcardのステータスページは、推奨standardリリースとしてMk4/Mk5 standard 5.6.1とQ standard 1.5.1Qを掲載していた。修正済みの最小バージョンは、Mk2/Mk3が4.2.0以降、Mk4/Mk5 standardが5.6.0以降、Q standardが1.5.0Q以降、Mk4/Mk5 Edgeが6.6.0X以降、Q Edgeが6.6.0QX以降であった。リリース系統の違いは重要である。数値が大きいEdgeバージョンであっても、修正済みのstandardリリースと自動的に同等になるわけではない。

影響を受けている可能性がある場合

  1. 筐体を頼るのをやめる。モデル、リリース系統、シード生成時に使用したファームウェア、そして公式に示された独立サイコロの例外条件が明確に当てはまるかを確認する。判断できない場合は、そのシードが影響を受けているものとして扱う。

  2. 公式の手順だけを使用する。Coldcardの勧告とセキュリティ状況ページを直接開き、署名済みファームウェアと公開ハッシュを検証し、一方的に持ちかけられる「移行支援」は拒否する。正当な支援者がリカバリーフレーズを必要とすることはない。

  3. 修正済みの環境で、まったく新しいシードを作成する。古いフレーズの単語を編集、並べ替え、追加してはならない。新しいウォレットには新しいエントロピーが必要である。多額の残高については、1社のシード生成経路だけが唯一の信頼の起点とならないよう、独立した実装または適切に設計されたマルチシグ方針を検討する。

  4. 入金前に復元を検証する。バックアップを非公開で記録し、管理された手順で復元して、想定される公開フィンガープリントまたは受取アドレスを確認する。一度も試験していないバックアップは、単なる仮定にすぎない。

  5. まず少額を試験送金し、その後で残額を移す。全額を移す前に、送金先が正しいことと、試験送金が承認されたことを確認する。焦って場当たり的な対応をしてはならないが、落ち着いた手順を踏むことを、露出したシードへの対処を遅らせてよい理由と取り違えてはならない。

  6. 古いシードを廃止する。ファームウェアの更新や、後から追加した強力なパスフレーズで修復することはできない。税務上または法的に必要な記録は保持しつつ、秘密の不要な複製は残さない。

Coinkiteによれば、影響を受ける「Add Dice Rolls」ワークフローで、公正かつ独立して非公開に行われたサイコロ振りを少なくとも50回加えた場合、サイコロだけから少なくとも128ビットが得られ、99回以上なら約256ビットが得られた。正確な条件が重要である。出目の列が記録または観察されていた、偏っていた、独立していなかった、あるいは状況が不確かであるなら、回数だけを根拠に安全だと決めつけてはならない。以前から使っていた強力なBIP39パスフレーズは追加の障壁になり得るが、それでもCoinkiteは移行を勧告しており、パスフレーズがシードを修復するとは説明していない。

デバイスはハッキングされていなかった――そこに、より深い警告がある

あらゆる損失を「ハードウェアウォレットのハッキング」と呼ぶと、性質の異なる複数の障害類型が1つの劇的な表現に押し込められる。その結果、有効だったはずの対策が見えにくくなる。Coldcard事件で、攻撃者は各被害者が所持する筐体、キーパッド、USB制御、セキュアエレメントを破ったのではない。根幹の秘密が列挙可能だったため、デバイスそのものを迂回したのである。

セキュリティ境界が保護できるのは、その境界を通過するものだけである。セキュアエレメントへ入る鍵が弱い場合、悪意あるファームウェアが署名を通じて鍵を漏えいさせる場合、画面が攻撃者の指定した送金先を表示する場合、または人が送金承認を強要される場合、専用ハードウェアが存在するという事実だけでは、その攻撃への答えにならない。

ハードウェアウォレットの損失は、すべて同じ形で起こるわけではない

記録に残る複数の事件と実証研究は、なぜこの分類に精密さが必要なのかを示している。これらは、ハードウェアウォレットが役に立たないことを証明するものではない。ハードウェアは、リスクをチップ、ファームウェア、サプライチェーン、ホストソフトウェア、署名プロトコル、バックアップ、人間の手順から成る別のシステムへ移すことを示している。

1. フォールトインジェクションと物理的なシード抽出

2020年、Kraken Security Labsは、Trezor OneとModel Tに対する電圧グリッチ技法を開示した。Krakenの報告によれば、約15分の物理アクセスで暗号化されたシード情報を抽出できる可能性があり、その後、短いPINを総当たりで破ることができた。実務的な緩和策は、デバイスに保存しない強力なBIP39パスフレーズだった。Krakenは、KeepKeyに対しても同類の攻撃を記録している。

これはColdcardとは異なる脅威である。標的デバイスを入手し、実験室型のフォールトインジェクションを行う必要がある。この事例は、耐タンパー性が採用したマイクロコントローラとストレージ設計に依存し、PINが必ずしも高エントロピーの暗号化秘密ではないことを示している。

2. 正規のハードウェア署名器を取り巻くソフトウェアの侵害

2023年12月、Ledger Connect Kitのサプライチェーン事件では、侵害されたパッケージを読み込んだdAppに悪意あるコードが注入された。Ledgerによれば、そのコードはEVM利用者を欺き、資金を流出させるトランザクションへ署名させた。ハードウェアデバイスが自発的にシードを明かしたのではない。デバイスを取り巻くシステムが、正規の署名者に悪意ある意図を提示したのである。

この障害類型が示すとおり、「鍵がデバイスから出なかった」ことは必要条件だが、十分条件ではない。利用者、ホスト、または画面が署名対象を確実に理解できない場合、安全な鍵であっても、誤ったトランザクションを忠実に承認し得る。明確なトランザクション解析、信頼できる表示、限定的な権限、依存関係の管理、ブラインド署名への耐性は、カストディのセキュリティを構成する要素である。

3. 通常の署名を通じて秘密を漏えいさせる悪意あるファームウェア

Blockの研究者らは、実証的な攻撃研究を公表している。そこでは、侵害されたウォレットファームウェアが、一見すると正常な署名の中へ秘密情報を密かに符号化する。その脅威モデルは、サプライチェーン侵害、内部者の行為、ビルドシステムの侵害、署名鍵の侵害といった経路によるファームウェア侵害を想定している。署名済みトランザクション自体が流出経路になるなら、エアギャップは役に立たない。

ここで、再現可能ビルド、複数の独立したビルダー、固定された依存関係、セキュアブート、実装の異なるマルチシグが意味を持つ。これらは、連鎖の中の特定の結節点に対処する。設計、ソース、運用者を魔法のように認証するものではない。

4. バックアップの露出、アドレスの差し替え、強要

現実の窃盗の多くは、半導体を攻略することすらない。攻撃者はシードのバックアップを盗むか撮影し、受取アドレスを差し替え、サポート担当者になりすまし、購入・配送過程を侵害し、弱いPINとともにデバイスを入手し、または所有者に協力を強要する。リカバリーフレーズは設計上、持ち運び可能なマスター認証情報である。これを入手した者は、元のデバイスがどこにあろうと、別の場所でウォレットを復元できる。

複雑さを増すほどセキュリティが悪化し得る理由

複雑さが正当化される場合もある。独立した画面は、トランザクション確認の信頼性を高められる。セキュアエレメントは、物理的な抽出のコストを引き上げられる。マルチシグは、単一の鍵が障害点となる状況を解消できる。しかし、追加される仕組みはすべて、インターフェース、状態、更新経路、依存関係、復旧手順、前提条件も生み出す。問うべきなのは「複雑かどうか」ではない。「各構成要素はどの脅威を制御し、どのような新たな障害モードを持ち込むのか」である。

SaltzerとSchroederによる古典的原則である機構の簡潔性（economy of mechanism）は、検査と理解を可能なまま保つため、保護設計を可能な限り単純かつ小規模にすべきだとする。現代のNISTシステムセキュリティ指針も同様に、攻撃対象領域の縮小と、大規模で分析の難しい多機能コンポーネントを、アーキテクチャ上の論点として扱っている。単純さとは、対策が存在しないことではない。挙動を説明、試験、適切に運用できない対策を追加しないことである。

  • コードが増えるほど、潜在的な欠陥も増える。さらに、完全なレビューのコストが増し、相互作用について推論することも難しくなる。

  • モードが増えるほど、構成リスクも高まる。standardとEdgeのファームウェア、複数のシード生成手順、パスフレーズ付きウォレット、USB経路とエアギャップ経路、各種バックアップは、それぞれ単独では安全でも、組み合わせると混乱を招くことがある。

  • インターフェースが増えるほど、意味伝達のリスクも高まる。ハードウェア画面、ホストアプリ、QR形式、microSDの手順、ブラウザコネクタ、ネットワークバックエンドのすべてが、利用者が何を承認しているのかについて完全に一致しなければならない。

  • 手順が増えるほど、遵守されにくくなる。安全な経路が難しければ、人は検証を省き、更新を先延ばしし、バックアップを使い回し、あるいは緊急時の指示を理解しないまま実行する。

  • 過信が強まるほど、損失も拡大し得る。「コールド」「エアギャップ」「ハッキング不可能」と宣伝される製品は、利用者に、より多くの価値を1つのシードへ集中させる誘因を与え得る。集中は、1つの隠れた欠陥を破局的な結果へ転化させる。

多層防御は、各層が独立しているときに価値を持つ。同じ実装、同じエントロピー源、同じベンダー、または同じ復旧用秘密を重ねても、独立した防御にはならない。

オープンソース、監査、再現可能ビルド、AIレビューは同義ではない

Coldcardの事例は、とりわけ示唆に富む。ファームウェアが公開され、再現可能ビルドの文書も存在していた一方で、脆弱な経路が何年にもわたりリリースに残存したからである。これは、公開性が無益だという意味ではない。証拠を入手できることと、検証すべき性質を実際に調査することは別だと示している。

  • オープンソースとは、外部者が実装を調査できるという意味である。誰かがセキュリティ上重要なすべての経路をレビューしたことも、公開ソースツリーからインストール済みバイナリが生成されたことも、それだけでは立証されない。

  • 独立監査は、範囲を限定した業務である。その価値は、明示されたレビュー担当者、正確なコミットまたはバージョン、脅威モデル、検証した性質、除外事項、所見、是正の証拠に依存する。範囲の提示を伴わない「監査済み」は標語にすぎない。

  • 再現可能ビルドでは、独立したビルダーが公開済みの手順に従い、出力を比較できる。一致すれば、ソースとリリース成果物を結び付けられるが、ソースが正しいことまでは証明しない。

  • App Storeの審査とコード署名は、配布とプラットフォームの統制を確立する。それだけで、App Storeのバイナリが公開リポジトリとビット単位で同一であることを証明するものではない。

  • AI支援レビューでは、大規模なコードベースを探索し、敵対的な仮説を生成し、不変条件を比較して、人間の分析を加速できる。一方、モデルは文脈を見落とし、誤った前提を受け入れ、もっともらしいが不正確な所見を示すこともある。AIレビューは、認証機関ではなく、もう1つの観点である。

Coldcardの現行ステータスページは、適切な範囲記述の模範を示している。実機上で対象を絞ったRNG計測、ソースレビュー、ホットフィックスのレビュー、再現可能ビルドとサイコロ入力経路のトレースを挙げたうえで、それらの検査はすべてのファームウェアバイナリに対する完全な監査ではなく、欠陥が存在しないことも保証しないと明記している。この一文には、条件を付さない認証バッジより大きな価値がある。

Apertureが誠実に主張できること

Apertureは、専用ハードウェア署名器ではなく、ソースコード公開型のiPhone/iPadアプリという異なるカストディ設計を採用している。公開リポジトリでは、MITライセンスの下でモバイルクライアントとビルド手順を公開している。また、公開済みのセキュリティモデルには、ウォレットの秘密がアプリ専用のiOS Keychainを通じて、このデバイスのみ（this-device-only）の保護を用いて保存される一方、ローカルデータベースにはリカバリーフレーズや秘密鍵ではなく、不透明な参照のみを保持すると記載されている。トランザクションはデバイス上で構築・署名され、その後、署名済みデータがネットワーク基盤へ送信される。

Appleのプラットフォームセキュリティ文書には、必須のコード署名、身元を確認された開発者、自動および人手によるApp Store審査、サンドボックス化、実行時の署名検証が記載されている。また、Keychainに関する文書には、項目単位の保護と、Keychainの鍵処理におけるSecure Enclaveの関与が記載されている。これらは実際に備わっているプラットフォーム上の保護策である。ただし、Apertureのブロックチェーン秘密鍵そのものがSecure Enclaveの鍵であるという主張ではなく、Apertureもそのようには主張していない。

Apertureは製品の機能範囲も意図的に絞っている。カストディ口座も会社が保有する復旧用コピーも運用せず、ウォレットを売買窓口、スワップエンジン、汎用の内蔵ブラウザへ変えることを中核設計で避けている。バージョン2.40.12では、利用者がサイコロ、コイン投げ、数字からエントロピーを構築する際に、極端な反復、偏り、予測可能な周期を検出する物理乱数の健全性チェックを追加した。これらの検査は明白な異常パターンを検出できるが、物理的な過程が公正だったことも、非公開だったことも証明できない。

Apertureはハードウェアウォレットより安全になり得るか

一部の脅威モデルでは、そう言える。しかし普遍的な主張としては、そうではない。電話上のウォレットは、専用デバイスの製造・配送経路を回避し、高額資産を自己管理していることを外形的に示す物品を減らし、迅速な署名付き更新と成熟したサンドボックス機構を持つプラットフォームを利用できる。また、調査可能な実装を、利用者が正しく操作しやすい慣れたインターフェースに収められる。機能面を狭くすれば、ブラウザ、スワップ、承認、デバイス間の意味変換に伴うリスクを、類型ごと取り除くこともできる。

別の脅威モデルでは、適切に設計された独立署名器が重要な境界となる。電話のオペレーティングシステムまたはウォレットプロセスが侵害された場合、物理的な分離と、独立して信頼できる画面により、ネットワーク接続されたホストが鍵を取得または悪用するのを防げる。機関投資家の資産や人生を左右する規模の価値に対しては、1台の電話と1台のハードウェア機器を競わせるのではなく、独立した実装、独立したエントロピー、離れた保管場所、文書化された復旧手順を用いる、慎重に試験されたマルチシグ方針のほうが強固なアーキテクチャになり得る。

したがって、「ハードウェア」という語で分析を終えてはならない。iPhoneもハードウェアである。重要な違いは、どのコードが実行されるか、どのようにビルド・配布されたか、どこで秘密が利用可能になるか、利用者は何を検証できるか、トランザクションがどのように表示されるか、更新がどのように行われるか、そしてどの単一障害によって資金が移動し得るかである。

Apertureにも証拠の境界がある

ApertureのWebサイトは現在、アプリが独立監査を受け、再現可能な方法でビルドされていると記載している。その公開監査レジストリは、レビュー担当者名、正確な対象範囲、日付、レビュー対象バージョン、報告書、所見、是正、ハッシュ、再現性資料を掲載する正式な場所と位置付けられている。公開時点で、そのレジストリには、これらの具体的な成果物がまだ表示されていなかった。公開GitHubリポジトリにも、App Storeバイナリとの一致を独立に再現検証する際の比較対象となるリリース成果物はなかった。

したがって本稿は、「App Storeバイナリの全行が安全であると証明済みである」とも、複数の企業があらゆる挙動を認証したとも、AIがアプリケーション全体を検証したとも主張しない。そのような主張は、公開されている証拠の範囲を超える。技術的に正確な区別は、ソースコードがGitHubで公開される一方、Appleは署名済みのコンパイル済みバイナリをApp Storeから配布しているという点にある。両者を結び付けるには、公開ビルド手順、変更不能なソースリビジョン、依存関係のロック、取得済みのApp Store成果物、Appleの署名による影響を正規化する手順、一致結果、独立した証明が必要である。

検証は、懐疑的な第三者が再現するのに十分な証拠を主張に伴わせたとき、最も強力になる。Apertureも、あらゆるハードウェアウォレットベンダーと同じ厳格さで、この基準に照らして評価されるべきである。

大学水準の検証パッケージに含めるべきもの

研究者、監査人、ジャーナリスト、機関の評価担当者にとって、信頼できるウォレットセキュリティの主張は、認証バッジの羅列ではなく、追跡可能な証拠の連鎖であるべきだ。最低限、次の事項を求める必要がある。

  1. 正確な脅威モデル。リモート侵害、物理的抽出、悪意ある更新、ビルドシステム侵害、弱いエントロピー、トランザクション差し替え、バックアップ窃取、強要、可用性を、それぞれ個別に明示する。

  2. 変更不能な、レビュー済みリビジョン。対象範囲に含まれたコミット、依存関係グラフ、コンパイラとSDKのバージョン、ビルドフラグ、エンタイトルメント、構成を特定する。

  3. 実施者が明示された独立報告書。レビュー担当者、方法論、日付、除外事項、重大度基準、所見、および各是正を完了と判断するために用いた証拠を公開する。

  4. ソースからバイナリへの再現性。正確な公開リリースに対応付けられた完全な手順と、独立したビルド結果を提供する。非決定的な差異または署名によって生成された差異は、すべて説明する。

  5. エントロピー経路の証拠。実機上でエントロピー源を試験し、障害時の挙動を検証し、黙示的なフォールバックを認めず、リリースビルドが使用した正確な経路を追跡する。出力に対する統計検定だけでは、生成器が正しく接続されていたことを証明できない。

  6. 敵対的条件下のトランザクションテスト。受取人の差し替え、手数料操作、敵対的なメタデータ、ブラインド署名の境界、ブロードキャストの中断、すべての表示器と署名器の間で生じるパーサーの不一致を試験する。

  7. 復旧・更新訓練。情報が不完全な状況、旧バージョン、移行、デバイス紛失、更新では既存の秘密を修復できない可能性を含め、現実的な時間的切迫の下で手順を試験する。

  8. 継続的かつ多様なレビュー。決定論的テスト、静的解析、人間の専門家、ファジング、実機試験、AI支援レビューを相補的な手法として用いる。各手法が何を立証し、何を立証しなかったかを記録する。

脅威は画面の外にも及ぶ

セルフカストディはカストディ事業者を排除できる一方で、人を最終的な承認境界にすることもある。暗号技術を破れない窃盗犯は、代わりに所有者、家族、自宅、職場、または公に知られた身元を標的にする可能性がある。専用ハードウェアは、その人が資産管理を重視していると目に見える形で知らせたり、攻撃者が発見を期待する物品を作ったりすることで、標的化を容易にする場合もある。電話も、残高が表示されていれば保有資産を明らかにし得る。どちらの形態も強要を解決しない。

2024年の査読付き研究である「レンチ攻撃の調査：暗号資産ユーザーを標的とする物理攻撃」では、インタビュー、フォーラム、146本のニュース記事を分析した。絞り込み後のニュースデータセットには物理攻撃の事件が105件含まれ、そのうち主要な報告行為が誘拐だった事例は24件、殺人だった事例は6件だった。著者らは過少報告を強調し、経験豊富なセキュリティ実務家も被害を免れていなかったことを明らかにした。これらの数値が表すのは同研究のデータセットであり、世界全体の発生率でも、特定のウォレット形態が各犯罪を引き起こした証拠でもない。

危険は理論上のものではない。2024年、米国司法省は、監視、住居侵入、誘拐、暴行、脅迫を用いて被害者に暗号資産口座から資金を流出させた共謀事件で、有罪判決が下されたことを公表した。ここから得るべき教訓は、恐慌に陥ることでも、正当な支援を避けることでもない。運用上のプライバシーと人身の安全を、ウォレット設計の一部として扱うことである。

人命の安全は資産の回収に優先する

  • 残高や保管の詳細を公言しない。公開アドレス、スクリーンショット、会議での会話、ソーシャルメディアへの投稿、配送記録、廃棄した梱包材は、身元、所在地、推定される資産規模を結び付ける手掛かりになり得る。

  • 日常用資金と準備資産を分ける。支出用ウォレットから、長期保有分の全体が見えたり、全体を操作できたりしてはならない。すべての資産と復旧経路を、直ちにアクセス可能な1つの秘密の背後へ集約することは避ける。

  • 多額の価値には独立した承認を用いる。適切に設計されたマルチシグは、盗まれた1台のデバイスまたは強要された1か所だけで十分となる事態を防げる。ただし、鍵、実装、復旧資料が真に分離されている場合に限る。

  • インターフェースが明かす情報を保護する。アプリロックとアプリ切替画面のプライバシー制御を使い、公共の場で全残高を表示することを避け、無関係な保有資産を露出させずに受取人を検証する。

  • 適切な資格を持つ地域の専門家とともに計画する。リスクの高い個人や機関は、自らの法域と個別事情を理解する専門家とともに、適法な物理セキュリティ、渡航、インシデント対応、相続、家族の安全に関する手順を策定すべきである。

  • ウォレットのために命を危険にさらしてはならない。リカバリーフレーズ、デバイス、トランザクション、金額のいずれも、身体を傷つけてまで守る価値はない。差し迫った脅威の下では人命の安全を優先し、安全に連絡できる状況になってから地域の緊急通報機関へ連絡する。

教訓は証拠であり、陣営への忠誠ではない

Coldcardの障害は、現行のColdcardがすべて安全でないこと、あらゆるハードウェアウォレットが見せかけにすぎないこと、またはすべての電話ウォレットが優れていることを証明しない。Coinkiteは修正版リリース、移行ガイダンス、対象を絞った独立検証、そして、それらの検査で何を立証できるかについての明示的な限界を公表している。責任ある分析では、事件の重大性と是正の実績の双方を認めるべきである。

同様に、Apertureも、別のアーキテクチャを批判するだけで信頼を得られるわけではない。公開ソース、限定的なカストディモデル、Appleのプラットフォーム制御、ローカル署名、レビュー可能性には意味がある。その信頼性は、明示された第三者が対象範囲と所見を公開し、研究者が変更不能なソースから配布済みバイナリを再現でき、AI支援レビューが決定論的テストおよび説明責任を負う人間の判断と組み合わされたとき、さらに強くなる。

長期にわたって有効な結論は、より単純である。すなわち、セキュリティを決めるのは箱の材質ではなく、秘密の質、システム全体の挙動、防御の独立性、インターフェースの明瞭さ、そして重要な主張の一つひとつを検証するために利用できる証拠である。複雑さが必要な場合もあるが、制御する脅威ごとに、その複雑さを採用する価値があることを示さなければならない。

Apertureの以下のガイドも参照されたい。物理的な乱数からエントロピーを構築する方法、BIP39パスフレーズ、セルフカストディのセキュリティモデル、およびアプリのパスコードとプライバシー制御。

一次資料および技術資料

Apertureは、Coldcard、Coinkite、Trezor、Kraken、Ledger、Block、または引用した研究者との提携関係になく、これらから推奨も受けていない。製品名および企業名は、それぞれの所有者に帰属する。本稿はセキュリティ教育を目的とするものであり、個別の金融、法律、緊急時対応に関する助言ではない。リカバリーフレーズ、秘密鍵、ウォレットのパスフレーズ、アプリのパスコード、バックアップ用パスワードを、Webサイト、サポート担当者、研究者、AIアシスタントへ決して提供してはならない。