2013-03-27

セキュアブートと制限ブートの違いについて

mjg59 | Secure Boot and Restricted Boot.

Red Hat社員で有名なLinux開発者のMatthew Garrettが、セキュアブートと制限ブートの混同について警鐘を鳴らしている。

今週末、LibrePlanetでセキュアブートと制限ブートについての発表を行った。動画はここから手に入る。

いずれカンファレンスのWebサイトにも上げられるはずだ。スペインである団体が今朝、欧州委員会に苦情申し立てをし、Microsoftのx86クライアントPC市場におけるセキュアブートの強制は反競争的であると訴えた。この動きが成功することはないだろうと思うが、というのも、委員会はすでに発表したように、現在の実装はEU法に適合しているとの見解だからだが、私は来たるべき本当の戦いの論点を見失う危険性を懸念しているのだ。

セキュアブートの意味は、人により様々である。思うに、自由ソフトウェア財団の定義が分かりやすい。セキュアブートとは、ブート時の検証方法であり、最終的な支配権は、デバイスの所有者に帰する。一方、制限ブートとは、ブート時の検証方法であり、最終的な支配権が第三者の手に帰する。Microsoftがx86 Windows 8デバイスに要求する要件は、セキュアブートに分類される。OEMがマイクロソフトの要件を正しく実装したならば、利用者はセキュアブートを無効にすることができるし、あるいはセキュアブートを有効にするが、信頼するキーとバイナリは自分の意志により選択できる。もし、自由ソフトウェア財団が彼らの定義する自由に合致するオペレーティングシステムの署名サービスをたちあげれば、Microsoft要件ならば、利用者にシステムを設定して、不自由ソフトウェアの実行を拒否するようにできる。現に筆者のシステムは、Fedoraか自分がローカルでビルドしたものしか信頼しないように設定されている。MicrosoftがOEMに実装するよう要求したから実現した環境である。Microsoft要件を満たしたシステムは、コンピューター所有者の自由を尊重し、コンピューターのブートにおける制限についてユーザーが選択権を持つものである。

とはいえ、現状が理想なわけではない。ハードウェアベンダー間の共通のUIやキーフォーマットがない現状では、ユーザーが自由の権利を行使するために必要な手順を、OSベンダーがドキュメント化するのは難しい。Microsoftが主要な信頼キーの権威として君臨することは、果たしてMicrosoftは自社の製品と他者の製品を等しく取り締まるかどうかということに疑問を抱く余地が十分にある。一部のシステムにおける実装の不具合により、正しく署名されたオペレーティングシステムがブートしないこともあり、利用者にWindows以外のOSをインストールしたければ、ファームウェアのアップデートを強いることもある。

しかし、この些細な問題のみに注力するのでは、もっと大きな問題を見逃してしまう。x86市場は、利用者が実行するものを自分の意志で決められる環境を維持するだろうが、x86市場は縮小している。利用者はタブレット等のARMベースの極小ポータブル機を購入している。一部の利用者は、携帯電話を最優先のコンピューティングデバイスとして利用している。x86市場と違い、MicrosoftのARM市場における意向は、利用者の自由を制限することである。Windows PhoneとWIndows RTデバイスは、署名バイナリのみをブートし、利用者に署名検証の機能を無効にしたり、独自のキーをインストールすることができないよう、要件付けられている。内部の技術は同等であるものの、この違いにより、MicrosoftのARM実装は、制限ブートに分類される。ハードウェアベンダーとMicrosoftのみが、システムで実行されるべきソフトウェアを決定するのだ。利用者に決定権はない。

そして、残念なことに、これは独りMicrosoftだけではない。Appleというこの市場の最大のベンダーも、同等の制限を実装している。極一部のAndroidベンダーは、アンロック可能なブートローダーを搭載しているが、その他は、会社の意向か携帯キャリアの意向かはともかく、プラットフォームを囲い込んでいる。利用者が購入したデバイスは、セキュリティホールを利用するのでなければ、改変したシステムの実行を拒否するようになっているのだ。たとえ、システムが自由ソフトウェアを用いて作られたものであったとしても、利用者が自由の権利を行使できる保証はない。

なぜこれが問題になるのか。特定のプラットフォーム(特にWindows RTやiOSや特定のAndroidベースのデバイスだが)では、未署名のアプリケーションの実行すら拒絶するのだ。利用者は、まず厄介な制限を伴う契約に同意しなければ、自分でソフトウェアを書いて他人に配布することが不可能になるのだ。たまたま不幸の国に住んでいる利用者は、その機会すら禁止されるだろう。ベンダーは自社の製品と競合するアプリケーションをブロックし、もってイノベーションを阻害するのだろう。システムの詳細を学び、変更する機会が制限され、ユーザーが近代的なオペレーティングシステムの動作について学ぶことを困難にする。私の所有するまだ完璧に動作する携帯電話であっても、ベンダーによるアップデートが廃止されればそれで終わり、悪意あるWebサイトから攻撃を受けたり、パスワードや銀行クレジットカード等の暗証番号の漏洩の危険に晒される。しかも、たとえ他人にカネを払おうとも、問題を修正することは出来ないのだ。

利用者はこの制限により直接の被害を被る。

制限ソフトウェアに利点なしとは言わない。出荷されるデバイスのデフォルトの設定が制限されたものであってもかまわない。ただし私は、デバイス所有者には、囲い込みを受けるかどうかの選択の自由が、絶対に保証されていなければならないことを強く主張する。自由とセキュリティの間に、強制があってはならないのだ。

セキュアブートに反対する者は、我々の選択の自由を危険に晒す者である。セキュアブートに反対するものは、制限ブートにより我々の自由をさらに奪う危険を無視するものである。旧来のPC市場は廃れつつあるのだ。我々が行動を起こさなければ、自由ソフトウェアは、注意深く利用者の自由を尊重する珍しいデバイスをわざわざ探して使う少数派に成り下がってしまう。我々は10年前から、制限ブートに反対すべきだったのだ。これ以上、実際には利用者の自由を尊重する実装と戦って時間を浪費してはならない。

Microsoftのx86向けのセキュアブートの要件は、理想ではないにせよ、利用者の自由を尊重するものである。結局、出荷されるハードウェアにデフォルトで入っている公開鍵に対する秘密鍵を持つ、署名サービスの権威がMicrosoftというだけであり、Microsoft要件を正しく実装したハードウェアならば、セキュアブートを無効にしたり、あるいはMicrosoftの署名を拒否し、自分の選択する鍵だけを信頼するように設定できる。これにより、Microsoftが署名したバイナリの実行を拒否し、自由なソフトウェアのみを実行するデバイスにもできるのだ。

真に反対すべきなのは、ARMデバイスで主流の制限ブートである。これはデバイス所有者に当然あるべき、制限ブートを無効にしたり、あるいは信頼するキーを変更する自由を与えない。つまり、デバイス所有者はデバイスを支配していないのだ。かわりに、デバイスの提供者に一方的な支配力を与えるものである。このような邪悪なデバイスには、断固として反対しなければならない。

No comments:

Post a Comment

You can use some HTML elements, such as <b>, <i>, <a>, also, some characters need to be entity referenced such as <, > and & Your comment may need to be confirmed by blog author. Your comment will be published under GFDL 1.3 or later license with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.