Appearance
第9章 裏口から忍び込む
Xboxに対して実行可能な攻撃の全容は、本書に収めるには余りに多すぎる。XboxはPCアーキテクチャをベースとしており、そのアーキテクチャは複雑で進化を重ねてきたが、もともとセキュリティを意識せずに設計されたものだ。スマートカードのハッカーが悪用する古典的なハードウェアセキュリティホール——電源変調、サイドバンド攻撃、クロックグリッチなど——の多くは、僕の知る限りXboxではまだ手がつけられていない。（これらのセキュリティ上の弱点については、Lecture Notes in Computer Scienceシリーズ（Springer-Verlag）所収のCryptographic Hardware in Embedded Systems（CHES）会議の論文集でより詳しく知ることができる。）
残念ながら、ゲームコンソールやセキュアPCのメーカーはハードウェアセキュリティの弱点をさほど問題視していない。ハードウェア攻撃は「一般消費者には難しすぎて実行できない」ため、脅威が少ないと見なされているからだ。攻撃手法を研究するには正しいツールを持つ熟練のハッカーが必要だというのは事実だが、いったん攻撃手法を実装すること自体は非常に安価で簡単にできる。ある整備士の話を思い出す。重要な機械の修理に呼ばれた整備士が1時間かけて状況を観察し、まさに正しい場所を叩くだけで機械を直した。1,000ドルの請求書を受け取った機械の所有者たちが、なぜ叩くだけでそれほどの費用がかかるのかと尋ねると、整備士はこう答えた——「叩くこと自体は10セントです。どこを叩くかを知っているのが999.90ドルなんです」。この話の教訓は、具体的な手順が示されれば誰でもその「叩く」動作を実行できる、ということだ。
セキュリティ攻撃も多くは同じだ——解明するのは難しくても、共有して実装するのは簡単だ。セキュアなハードウェアのメーカーは、ハッカーの侵入に対して事後対応型のポリシーを採用することにも警戒すべきだ。多くのハッカーは秘密裏に活動し、ベンダーが適切な対策を講じられないよう手法と成果を非公開にしている。また既知の攻撃とバックドアのライブラリを保持し、一度に一つずつしか公開しない。そのため事後対応型のセキュリティポリシーを持つベンダーは、常に後手に回ることになる。
📦 コラム：用語について
ハッキングコミュニティはしばしば重要な概念に独自の用語を作り出す。その用語はコミュニティごと、また業界標準用語とも異なることがある。以下はXbox-Linuxコミュニティで受け入れられている用語の一覧だ。本書の用語との相違点はそのつど注記する。
- X-code（エックスコード）: ジャムテーブルのオペコードのこと。サウスブリッジ（MCPX）内のシークレットブートROMがXboxのハードウェアを初期化するために使うオペコード群だ。
- 2BL（ツービーエル）: セカンドブートローダ（Second Boot Loader）。シークレットブートROMによって復号されるコードのことだ。カーネルイメージの復号と解凍が主な役割であることから「セカンドブートローダ」と呼ばれる。
- FBL（フラッシュブートローダ）: バージョン1.1セキュリティでは、シークレットブートROMと2BLの間に位置する中間ブートローダ。FBLは、シークレットブートROM内にハードコードされた値に対して軽量ハッシュで検証される。そのためFBLはMCPXシリコンを変更しない限り書き換えられない。フラッシュROMの重要な領域すべてのデジタル署名を検証する役割を担う。
- カーネル: XboxのOSカーネルコード。フラッシュROMに圧縮・暗号化された状態で格納されている。
- バージョン1.0セキュリティ: 2BLにRC-4暗号を使ったXboxの初代セキュリティシステム。
- バージョン1.1セキュリティ: TEAハッシュを使ってフラッシュROMの特定領域を検証するXboxの第2世代セキュリティシステム。バージョン1.1セキュリティを搭載したXboxで確認されている最も早い製造日は2002年8月頃だ。
前章では、最終的にサウスブリッジチップ内の秘密情報として隠されていたRC-4鍵を取り出した、Xboxセキュリティメカニズムへの盗聴攻撃を説明した。本章では、仲間たちが考案したXboxへのその他の攻撃、および改訂されたXboxセキュリティスキーム（ここではセキュリティバージョン1.1と呼ぶ）への攻撃を紹介する。
バックドアとセキュリティホール
Xboxへのバックドア攻撃の一形態として、シークレットブートコードによるハードウェア初期化の根本的な弱点を突く手法がある。
図9-1: フラッシュROMの構成と、ジャムテーブルのオペコードの位置関係。
この弱点の根本的な原因は、ハードウェア初期化を担う強力なジャムテーブル用オペコードインタープリタが、その命令群を検証されていない平文で保持していることだ。
ヴァイザーのジャムテーブル攻撃
Xboxへの攻撃の一形態として、ハードウェア初期化シーケンスを改ざんする手法がある。Xboxのハードウェア初期化は、フラッシュROMの「ジャムテーブル」と呼ばれる暗号化されていない領域に格納された命令群をオペコードインタープリタが読み込む仕組みで行われる（図9-1参照）。ジャムテーブルのエントリは <オペコード, 引数1, 引数2> の組として、フラッシュROMの最も低いアドレス付近に格納されている。利用可能なオペコードには、x86アーキテクチャのすべてのアドレス空間に対するメモリの読み書き機能が含まれる。ジャムテーブルは暗号化されておらず、改ざん検証も行われていないため、フラッシュROM内の2BLをRC-4で復号する前に、不正な命令や変更されたハードウェア状態をXboxのメモリに「仕込む」オペコードをジャムテーブルに挿入できる。
ジャムテーブルの改ざんを応用すると、RC-4鍵を知らずともカーネルの平文を取り出すことができる。「Visor」という名前しか知られていないハッカーが、この手法を最初に僕に教えてくれた。Visorのアプローチを要約すると次のようになる。
- Xboxを通常どおり起動する。通常の起動プロセスの中で、復号済みのカーネルイメージがメインメモリに展開される。
- Xboxへの電源を維持しながら、フラッシュROMのジャムテーブルを、メインメモリの特定領域をフラッシュROMのバスなど監視しやすい場所にコピーする別テーブルに切り替える。
- XboxのCPUをソフトリセットする。これにより、メインメモリを消去せずにハードウェアを再初期化できる。
- 改ざんされたジャムテーブルプログラムが実行される間、メインメモリの内容を記録する。
手順2で必要となるフラッシュROM内容の動的切り替えは、ROMエミュレータを使うか、余分なアドレスビットを複数のスイッチに配線した大容量ROMを使うことで実現できる。
Visorはさらに、XboxのCPUの命令ポインタ（IP）を掌握する精巧なハックの一部としてジャムテーブルを利用する方法も説明した。このハックをより深く理解するために、無効なフラッシュROMイメージに対してシークレットブートコードがどう振る舞うかを詳しく見てみよう。
フラッシュROMイメージ内の2BLを復号した後、シークレットブートコードは2BLの末尾付近にある特定のマジックナンバーを確認する。無効なフラッシュROMイメージの場合、このマジックナンバーが一致しないため、CPUは 0xFFFF.FFFA にある短い命令列へジャンプする。この命令列は物理メモリの最後のアドレス 0xFFFF.FFFF まで続く。CPUがこの無効なROMイメージの最後の命令を実行すると、IPが 0xFFFF.FFFF から 0x0000.0000 にロールオーバーする際にコードセグメント境界エラーが発生してクラッシュするはずだ。しかし実際にはそうならず、CPUは 0x0000.0000 にある命令が有効であれ無効であれ、そのまま実行しようとする。通常この命令は無効であり、命令フォルトによってCPUは停止する。だが、ジャムテーブルのメモリ書き込みオペコードを使えば、Xboxのジャムテーブル初期化シーケンス中に有効な命令を 0x0000.0000 に置くことができる。
つまり、暗号化されたフラッシュROMイメージを破損または消去し、ジャムテーブルを改ざんしてフラッシュROM内の独自の非暗号化コードへのジャンプ命令を挿入することで、著作権で保護された著作物へのアクセスを有効に制御する暗号技術やそれに類する技術的手段に一切触れることなく、XboxのCPUの命令ポインタを制御できる。したがって、このハックはDMCA（デジタルミレニアム著作権法）のもとで合法かもしれない。「かもしれない」と言うのは、DMCAには曖昧な規定が多く、解釈を明確にする判例がほとんどないからだ。このアプローチの合法性の根拠は、Microsoftの著作権で保護されたコードが実質的に復号・実行されないという事実にある。唯一の例外は、サウスブリッジのシリコンにハードワイヤードされているために実行されるシークレットブートROMの一部だ。今日のハッキングコミュニティが直面する法的問題については、第12章「注意せよハッカーよ」でより詳しく論じる。
MISTプリマチュア・アンマップ攻撃1
ハッカーがXboxを制御した場合に備え、サウスブリッジチップ内のシークレットブートコードは、終了する直前に自身をアンマップ（メモリマップから除外）する。つまり、実行が終わった時点でシステムから永久に隠れてしまう。そのため、メモリ上位512バイトにアクセスしようとするユーザプログラムには、シークレットブートコードの代わりにフラッシュメモリのデコイブロックが見える。Xbox-LinuxプロジェクトのリードであるMichael Steilは、この機能を逆手に取る方法を発見した。
アンマップ処理はPCI設定空間のハードウェアレジスタ 0x8000.8008 への書き込みによって行われる。基本的な戦略は、初期化シーケンスが完了する前に 0x8000.8008 に書き込んでシークレットブートコードをアンマップするジャムテーブルオペコードを追加することだ。この時点ではキャッシュがオフになっているため、プロセッサはデコイブロックから命令をフェッチして実行し始める。デコイブロックはフラッシュROMの一部なので自由に変更できる。問題は、ジャムテーブルインタープリタが 0x8000.8008 への書き込みをブロックしている点だ。しかし、サウスブリッジチップセットのPCI設定空間デコーダにバグがあり、アンマップ命令が複数のエイリアスアドレスに反応してしまう。具体的には、「function」ビットフィールドが無視されるため、0x8000.8X08（Xが0以外）への書き込みでも同様の効果が得られ、このアドレスへの書き込みはジャムテーブルインタープリタにブロックされない。つまり、MISTハックでCPUの命令ポインタを制御するには、フラッシュROM内のデコイブロックを自分のコードで書き換え、ハードウェア初期化中にシークレットブートROMをアンマップする適切なジャムテーブルオペコードを追加すればよい。
Microsoftの反撃
セキュリティホールが発見されると、Microsoftがすぐにセキュリティスキームを刷新するという憶測が広まった。2002年8月、オーストラリアで静かに新しいマザーボードを搭載したXboxが出回り始めた。新セキュリティシステムに関する公式情報は意外な情報源からもたらされた——Xboxのチップセットを製造するnVidiaだ。2002年第2四半期の振るわない決算を受けて、nVidiaの広報担当者はその理由の一つとして次を挙げた。
「Xboxについて言えば、ボリュームディスカウントのマイルストーンに達し、利益率がさらに低下した。また、MITのハッカーによってMSFTが新しいセキュリティコードに移行した際に使えなくなったXbox MCPの在庫評価損と、Athlonベースのパソコン需要を見込んで製造したnForceチップセットの余剰在庫のQ2における評価損を計上した。」 — Derek Perez、nVidia広報ディレクター2
Xboxセキュリティバージョン1.1のリバースエンジニアリング3
セキュリティコードの変更内容の詳細は、2002年10月まで明らかにされなかった。その月、Andy Greenというハッカーが英国で入手できた最初のバージョン1.1 Xboxの調査を始めた。マザーボード上でのXboxバージョン1.1と1.0の外観上の違いは微妙なものだった。GPUのファンが大型ヒートシンクに置き換わり、USBサブカードがマザーボードに統合され、PLLクロックシンセサイザチップが省略されていた。あちこちのフィルタキャパシタも削除されていたが、大きな変化はないように見えた。しかしさらに調査すると、MIST攻撃に使われた脆弱性はふさがれているものの、ジャムテーブルのオペコードは変更されていないことがわかった。XboxへのアクセスのキーとなるLPCバスも変更されていなかった。
AndyはAsteriskという仲間のハッカーが考案した手順を使い、1日でMCPX ROMを取り出すことができた。この手順は、以前に特定されていたセキュリティホールとバックドアの非公開の組み合わせを活用したものだ。ROMの内容を初期解析したところ、セキュリティが根本的に異なる方式で実装されていることが明らかになった。バージョン1.1 Xboxを大まかに調べると、旧来のセキュリティ・バイ・オブスキュリティの仕組みが廃棄され、公開鍵暗号の強度に基づくスキームに置き換えられていた。
図9-2: Xboxセキュリティバージョン1.1。MCPXシリコンを交換しなければ変更できない領域はグレーで示されている。
しかし、Microsoftによる新セキュリティスキームの実装はやや直感に反するものだった。MCPXに内蔵されたシークレットブートROMのサイズが引き続き512バイトのままだったため、フル公開鍵デジタル署名アルゴリズムをシークレットブートROM内に収めることができなかった。そこでMicrosoftは、シークレットブートROM内では軽量ハッシュを使い、FBL（フラッシュブートローダ、Flash Boot Loader）と呼ばれるフラッシュROMの領域を検証することにした。FBLには、フラッシュROMのデジタル署名検証に必要なコード——RSA暗号、SHA-1ハッシュ、MicrosoftのPublic Key、ドライバプログラム——が含まれている。FBLはそのハッシュ値がシークレットブートROM内の定数と一致した場合にのみ実行される。つまりFBLは、変更可能なフラッシュROMに格納されているとはいえ、理論上はシークレットブートROMと同等の不変性を持つ。
このスキームはかなり堅牢に思えたが、ハッキングコミュニティは諦めなかった。シークレットブートROMのハッシュを詳しく調べた結果、ケンブリッジ大学コンピュータ研究所のDavid WheelerとRoger NeedhamによるTEA（Tiny Encryption Algorithm、超軽量暗号アルゴリズム）に基づいていることを突き止めた。協力者のFranz Lehnerは、TEAハッシュの弱点についてニュースグループsci.cryptに問い合わせを送った。
金曜午後、10月11日に回答が届いた。John Kelsey、Bruce Schneier、David Wagnerが執筆しCRYPTO 1996で発表された論文は、TEA暗号の鍵スケジューラに弱点があることを指摘していた——すべての鍵には、特定のビットペアを反転することで生成できる3つの関連鍵が存在するという弱点だ（この弱点とTEA暗号については第7章でより詳しく説明している）。翌土曜日、Andy GreenはXboxHacker.netに次の投稿を行った。
ああ、僕は所詮ただの人間で、確かに弱点もある。
OK、この領域の最初の5バイトを公開する程度なら問題ないと思う。
ffffd400: E9 83 01 00 00
これはrelative longbranchで 0xffffd588 へ飛ぶ。
DWORDとして b31 をフリップすると（そのDWORDアドレス+1 のビットも同様にフリップ）、代わりに 0x7fd588 へ分岐する……それは何だ、8M上、どこへ……どこへ……
RAMがある
Xcodes.. Visorのramプッシュメソッド……（MCPXでRAM Write X-Codeを探す）
X-Codeオペコード 3 … 無制限
帽子をしっかり被っておけ！テストの時間だ！
（mviz、なんと素晴らしいタイミングのひらめきだ。不思議な見えない力が助けてくれているような気がして、本当に感謝している！）4
つまり、TEA暗号の関連鍵の弱点により、FBL内で隣り合うダブルワードのペアは、最上位ビット1ビットを変えるだけで結果のハッシュ値を変えずに改変できる。この弱点により、Andyとそのチームは単一のジャンプ命令のターゲットをメインメモリ上の特定アドレスに書き換えるだけの余地を得た。
👤 プロフィール：Andy Green
自己紹介と、ハッキングとの出会いを教えてください。
37歳、英国のイーストミッドランズ地方ケタリング近郊に住んでいます。妻、4人の子供、2匹の猫と暮らしています。
12歳頃から、兄がCommodore Petを買ったことをきっかけにコンピュータに興味を持ちました。この1MHz 6502マシンで何ヶ月も熱中しました。最初は雑誌のBASICコードを打ち込んでいましたが、やがてゲームを作るようになり、最終的には機械語で素晴らしいキャラクターセル版スペースインベーダーを作りました。機械語とはCPUを直接16進数で命令するものです。今でも6502の一般的なオペコードを16進数で覚えています。これほど大変な作業だったので、次のプロジェクトは機械語で書いたアセンブラにしようと決めました。1978年当時はインターネットがなく、商用アセンブラを買う余裕もなかったし、それをコピーしてくれる知り合いも周りにいませんでした。
できあがったアセンブラはかなり貧弱なものでしたが、十分機能しました。これで正しいツールを持つことの価値を学びました。アセンブラで書けばはるかに速く開発できるし、相対ブランチを手作業で計算するようなミスも完全になくなります。次はBBC Model Bを手に入れ、またツールとゲーム作りに熱中しました。名門校の奨学金のオファーがありましたが断り、代わりに16歳で高校を中退しました。自分が興味を持ったことは何でも独学できると確信していたからです。
このマシンと、もう一つの6502プラットフォームOricでゲームをいくつか売り、そのお金でアセンブラやその他の開発ツールを作る会社を立ち上げました。途中でCとC++を習得するたびに、バグや時間の無駄が大量に消えていきました。
「人類の進化」の絵みたいです。ネアンデルタール人的な相対ブランチ計算から、仮想関数を扱うホモ・エレクトゥスの段階まで。
同時に、デジタルハードウェア設計も独学で探求し始めました。ハードウェアとソフトウェアは同じコインの両面であることに気づきました。教育の場では完全に別物として扱われますが、ある論理関数をソフトウェアで実装するかハードウェアで実装するか、あるいは両者の組み合わせにするかは実装上の詳細にすぎません。両方に足をかけているとデザインの本質がより深く見えてきます——たとえばC++は、インターフェースの重要性という面でエレクトロニクスから多くの概念を借用していると言えます。
Xboxに興味を持つ少し前は、オックスフォードにオフィスを持つ米国系企業で多くの仕事を担当していましたが、最後の仕事はスマートカードのシリコン設計でした。設計は面白く、現場には素晴らしい人たちもいましたが、経営陣の政治問題にますます落胆していきました。英国に拠点を置いているというだけで、サンノゼのスタッフの3分の2の給料しかもらえないのも問題でした。無報酬で特許を取られた件については話したくもありません。2001年12月、誠実さはお金より大事だと気づいて退職し、再び自分で仕事をすることにしました。
この会社を辞めたことでいくつかの辛い経験をして、それを消化している間に、知的財産に関わる普通の企業の醜い、貪欲で支配的な本能と、GPLプロジェクトの性格や特許・著作権法の厳格さを緩和しようとする人々の姿勢との大きな落差に気づきました。次第にMicrosoftと以前の会社を同じ目で見るようになっていきました。
そんな時期に、Slashdotでbunnieのハックについて読みました。複雑な気持ちでbunnieの手法を読みました。主な感想は、bunnieが使ったFPGAを1989年から使っていたので自分にもできたはずという思い、攻撃の簡潔さへの感嘆、そして自分が同じくらいクールで面白い——自分の哲学的な信念とも合致する——ことをやっていなかったことへの自己嫌悪でした。代わりにコーヒーを飲みながらSlashdotを読んでいるだけで、何も貢献していなかったのです。（余談ですが、これは多くのSlashdot読者に共通する経験だと思います。誰かのクールなハックを読んで少し嫉妬し、刺激を受ける、あの感覚です。なぜそんなことをしたいのかと常にやじを飛ばす背景ノイズの正体はこれだと思います。）
その後数週間で、Xboxの内部についてできるだけ多くの情報を集めました。xboxhacker.netが非常に役立ちました。そこでXbox Linuxプロジェクトが始まったばかりの頃にMichael Steilと出会いました。間もなく、たとえばMilksopプロジェクトのように自分が貢献できる面白いプロジェクトを見つけることができました。Surferdude氏の助けも借り、リセットなしにXboxを起動して動かし続けることができた最初のクリーンなROMを完成させることができました。これが後にcrom 1MB LinuxとCromwell（Xbox Linux向けクリーンROM）の基礎になりました。最初のハックと設計が済んだあとは、ほぼXbox Linuxのゴールに向けた作業に集中しました。
なぜXboxをハックするのですか？
理由は人それぞれですが、僕の場合はMicrosoftの目に余る独占禁止行為への怒りが大きかった——何でも否定する、何でも上訴する、何でも引き延ばす、その間に市場にコストを下回る価格でMicrosoft専用PCであるXboxを何百万台と投入する——というものです。欧州や米国の代表者がこれをさほど問題視しない以上（おそらく、EUでも最近あったように、彼らはMicrosoftのもとへ行ってご褒美をもらうつもりなのかもしれない）、GPLとLinuxという武器を使ってこの肥大した独占企業の邪悪な計画に風穴を開けることの一端を担えるなら光栄だと思います。目をつむって株のことだけ考えている人のことはわかっています。でも、そこで働く誠実な人々——そしてMicrosoftの大部分の社員は誠実なはずです——が、そんな怪物のために働くのはつらいことでしょう。
2002年を通じていくつかの契約を得ることができ、年後半は最初のLinuxカーネルをcromで動かし、CromwellでXboxの主要周辺機器をコントロールしてHDDまたはCDからLinuxを起動できるようにすることに専念できました。その後、プロジェクトAの賞金（寄付者Michael Robertson氏に感謝します）の自分の取り分のおかげで、少なくともあと数ヶ月はフルタイムで活動を続けられます。
最後に何かアドバイスはありますか？
最後に伝えたいのは、特に若い人たちへのメッセージです。興味が湧いたことについては、自分の脳の声に耳を傾けてほしい。気になることを掘り下げて理解しようとすることを恐れないでください。何かを理解したいという気持ち、あの渇望感は、「この知識はいつか役に立つかもしれない」と脳が教えてくれているサインです。その声に十分耳を傾けていれば、いつか何か小さな違いを生み出すための正しい知識を正しいタイミングで持てる可能性が高まります。
そのアドレスには、先に述べたジャムテーブルコードを使って、任意のユーザコードへのジャンプ命令があらかじめ書き込んでおける。Xboxハッキングコミュニティはひとつになって英雄的な努力を重ね、3日間でXboxセキュリティバージョン1.1を解析しきった。同様に勇敢な別のチームXecuterも、同じ時間枠でセキュリティを解析していた。
この話の最初の教訓は、セキュリティはその最も脆弱な部分の強さで決まる、ということだ。RSA暗号とSHA-1ハッシュのデジタル署名としての堅牢さに疑いの余地はほとんどないが、それらはセキュリティシステムの唯一の要素ではなかった。フラッシュROMへのブートROMの信頼を引き継ぐために使われたTEA暗号には、ハッカーが強力なデジタル署名アルゴリズムを迂回できる弱点があった。
第二の教訓はこうだ——複雑さは弱点を生む。複雑なシステムは設計・テスト・分析が難しい。Xboxバージョン1.1のセキュリティはおそらく短期間で実装されたため、弱点を分析するための十分な時間がなかったのだろう。あるいは、MicrosoftはTEAの弱点を知っていながら、FBLをシリコンに固定するリスクを軽減するためにこのバックドアを意図的に組み込んだのかもしれない。Microsoftが意図的にこのバックドアを入れたというのはかなり考えにくい話だ。MCPXシリコンを変更するのは非常に高コストだからだ（そのコストは最終的にnVidiaのバランスシートに計上されたけれど）。一方で、複雑さを完全に避けることも難しい。MITでの僕の指導教員であるTom Knightは、かつてこう言っていた——「この世のデザインには2種類ある。役に立つものと、正しいことを形式的に証明できるもの、だ」。ある意味では、現実のシステムのセキュリティを確保する唯一の方法は、その詳細を公開し（セキュリティ・バイ・オブスキュリティはなし！）、あらゆる角度から分析にさらすことだ。ある意味、Xboxセキュリティの徹底的な分析は、ハッキングコミュニティのおかげでMicrosoftに費用を一切かけることなく実施されている。
もしMicrosoftがシークレットブートROMにより強力なハッシュ関数を使っていたとしても、Xboxにはまだ試されていない有効な攻撃手法がいくつかある。HyperTransportバスに対して、精密にタイミングを合わせたパルスで信号を過剰駆動する中間者攻撃を仕掛けることができる（第8章参照）。各HyperTransportバスの配線にはマザーボードの部品面から見えるテストポイントがあるため、この攻撃はかなり簡単に実装できる。完全なハードウェアソリューションとしては、ポゴピンを使ったベッド・オブ・ネイルズ方式のテストコネクタを備えた基板にFPGAを搭載する形が考えられる。この基板ははんだ付け不要でテストポイントに押し当てるだけで使える。もう一つの攻撃は、CHES会議でAdi Shamirが僕に提案したものだ——CPUのクロックや電源に時限グリッチを加えてジャンプターゲットアドレスの計算を乱す手法だ。この種の攻撃は暗号スマートカードのプロセッサで実際に成功している。こちらの攻撃もユーザが取り付けられるモジュールとして安価に実装できる。（セキュリティを一回だけ突破して秘密鍵や重要コードのブロックを取り出すことが目的の場合、ハッカーが使える攻撃の幅はずっと広くなることを念頭に置いてほしい。）
バックドアの脅威
この章で示したとおり、バックドアを探すことは暗号によって保護されたハードウェアへの攻撃として実用的な手法だ。Xboxでバックドアが比較的高い確率で見つかった理由の一つは、XboxがベンダーによってコンピュータをPC上で暗号技術によって保護しようとした最初の重要な試みだったからだ。
👤 プロフィール：Franz Lehner
Franz Lehner（29歳）は、オーストリアにガールフレンドと住んでいます。電気工学を5年間学び、現在はISPを運営しながら「自動化ソリューション」のプログラミングをしています。余暇には、楽しく教育的なプロジェクトを探しています。
bunnieのXboxハッキング文書を見つけた後、sourceforge.netでXbox-Linuxチームと出会い、チームプログラミング、Linuxカーネルのハッキングとデバッグ、暗号システムについて学ぶためにXbox-Linuxプロジェクトに参加しました。Palladiumなどの関連システムへの理解を深める目的でもプロジェクトに加わりました。
Xbox経験から得た教訓にもかかわらず、将来のセキュアPC実装は依然としてハードウェアセキュリティの弱点を抱えるリスクがある。PCのレガシーがオープンで安全でないハードウェアアーキテクチャだからだ。
PCハードウェアは複雑でありながら脆弱であり、それを基盤に信頼の連鎖を構築することは難しい。根本的な問題として、PC内の各コンポーネントはその物理環境を「信頼する」設計になっている。市販の集積回路コンポーネントの仕様書には、動作が保証される温度・電圧・周波数などの条件範囲が明記されている。この最大定格を超えると、デバイスの動作は「未定義」となり、何が起きるかわからない。ほとんどのチップエンジニアは、通常の動作条件でチップを動作させることだけでも十分難しいため、範囲外の条件から回路がうまく回復するような設計をしようとすら考えない。しかも、コンシューマ向け製品はコスト感度が高く、堅牢なフォールトトレランス対策を組み込むと価格競争力を失ってしまう。
そのため、チップは通常、内部エラーチェックなしで実装される。算術論理演算装置、つまりALU（Arithmetic Logic Unit）——CPUの演算の「頭脳」——が2つの数を誤って計算しても、その問題は症状としてしか現れない。エラーを引き起こした出来事からずっと後になって、その影響が観測されるだけだ。範囲外の条件によって誘発された故障を利用する攻撃は、ソフトウェア世界のバッファオーバーランの類似物だと考えることができる。
PCアーキテクチャのもう一つの問題は、プロセッサがコード環境を信頼しすぎることだ。Pentiumプロセッサアーキテクチャには、安全でないコードと安全なコードを区別するためのハードウェア機構がない。バグや誘発された障害によって命令ポインタが安全でないコードセグメントに紛れ込んでも、プロセッサは気にせずそのコードを実行してしまう。
NOTE
ハードウェアセキュリティレベルに基づくコードの区画化は、サンドボックス化とは異なる技術だ。サンドボックス化は、ユーザプログラムが秘密情報や保護されたコード・データから指示を受けたり相互作用したりする必要がある状況には、十分な解決策を提供しない。最近では、データタグによってセキュリティ監査ログのような仕組みを埋め込むことでこの問題を解決できる新しいプロセッサアーキテクチャが提案されている。4
バックドアのもう一つの発生源は、複雑なチップには必ずと言っていいほど存在する設計上のバグだ。既知のバグ（エラータとも呼ばれる）を抱えたままチップを出荷することはよくある慣行だ。たとえば、Intel i860 XPプロセッサ（1991年に最初にリリースされたもので、Pentium 4プロセッサ向けに最近リリースされたi860チップセットとは別物）は、プロセッサのデータシートに匹敵するほどのエラータ集を抱えて出荷された。身近な例では、MISTプリマチュア・アンマップ攻撃を可能にしたnVidia MCPXのアドレス空間デコーダのバグがある。ほとんどのエラータには簡単なワークアラウンドがあるか、通常の動作条件では機能に軽微な影響しか与えない。しかし、キャッシュコヒーレンシ、アドレスデコーディング、メモリ管理に関連するエラータの中には、重大なソフトウェアセキュリティホールにつながるものもある。
Xboxの場合、ハードウェアのバックドアがビジネスに与える影響はおそらく小さい。Microsoftがゲーム売上の一部を失うかもしれないが、海賊行為による損失はXboxのハードウェア販売でMicrosoftが被る損失に比べれば微々たるものだ。また、Xboxは単なるゲームコンソールにすぎない——Xboxのセキュリティ上の弱点によっておばあちゃんの銀行口座が空になったり、クレジットカード番号が盗まれたりはしない。しかし、信頼されるPCが普及すれば、ゲームの売上以上のものが危険にさらされる。トラステッドPCアーキテクチャが従来のPCからの根本的な変革でなければ、人々は知らないうちに金融の秘密情報や個人データのセキュリティを信頼できないハードウェアに委ねることになる。
人生のほとんどのことと同様に、最初の一歩は学ぶことだ。ゲームコンソールをいじる行為を含めても、ハードウェアセキュリティについて学べば学ぶほど、明日のセキュリティシステムは良くなる。さあ、次のレッスンへ……
注
Andy Greenの第19回カオスコミュニケーションコングレスにおけるXboxセキュリティハッキング発表より。
The Inquirerの記事より（http://www.theinquirer.net/?article=4735）。
Andy Greenの第19回カオスコミュニケーションコングレスにおけるXboxセキュリティハッキング発表より。
http://www.xboxhacker.net "Xbox Hacker BBS -> Xbox Hacking (TECHNICAL) -> BIOS/Flash ROM/Firmware -> Xbox LinuxチームのニュースよりMSが'ハッシュをめちゃくちゃにした'、内部が明らかに" スレッドの投稿より。
http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-15.pdf。「A Minimal Trusted Computing Base for Dynamically Ensuring Secure Information Flow」by Tom Knight and Jeremy Brown.
*著者*: Andrew "bunnie" Huang | *出版*: No Starch Press
*日本語訳・レビュー*: ニコ技深圳コミュニティ / 高須正和（@tks） — [https://takasumasakazu.net](https://takasumasakazu.net) — CC BY-NC-SA 1.0
*注記*: 本翻訳は、原著の Creative Commons ライセンス条件に従って公開する翻訳コントリビューションであり、著者 bunnie からも歓迎のコメントをいただいています。出版社による公式日本語版ではありません。