Linux%3A%20Canonical%28Ubuntu%29%E3%81%A8Red%20Hat%E3%82%82Secure%20Boot%E3%82%92%E6%8E%A1%E7%94%A8%E3%81%8B

Linux: Canonical(Ubuntu)とRed HatもSecure Bootを採用か

linux-foundation

最近、Secure Bootというものが話題になっている。それは、ハードウェアがオペレーティングシステムの立ち上げ過程を検証することによって、マルウェアを防ぎコンピュータのセキュリティを向上させる、という仕組みだ。UEFIの規格(日本語記事)の一部であるSecure Bootは、多くのユーザにとっておなじみの老いたるBIOSに置き換わることにより、無署名のオペレーティングシステムのロードと実行を禁ずる。Microsoftは、OEMが”Designed for Windows 8″のロゴを使いたい場合にはSecure Bootのアクチベーションを必須の要件としている。この技術の本質、およびMicrosoftの推奨実装は、システム全体のコントロールをエンドユーザから取り上げ、とくに、この(Microsoftの)構成によるSecure Bootは、フリーソフトのオペレーティングシステムをロードさせないかもしれない。

例によって、こういうことで真っ先に騒ぐのはSlashdotだが、騒ぎが収まってみんな冷静になると、UEFI Secure Bootの規格を詳しく勉強するようになった。それは、従来のBIOSからの相当抜本的な変化だ。公開鍵暗号を使うので、複雑な仕組みでもある。しかし、Secure Bootそのものに、フリーソフトウェアを排除する機構があるわけではない。

Linux Foundationが、”Making UEFI Secure Boot Work With Open Platforms“(オープンプラットホームにおけるUEFI Secure Bootへの対応)と題する研究論文をリリースした。筆者は、LFのTechnical Advisory BoardのメンバーJames Bottomley(Parallelsのサーバ仮想化部門CTO)とJonathan Corbet(LWN.netの編集者)だ。これと並行してBottomleyは、CanonicalのテクニカルアーキテクトJeremy KerrやRed HatのシニアソフトウェアエンジニアMatthew Garretらと共に、”UEFI Secure Boot Impact on Linux“(‪UEFI Secure BootのLinuxへの影響)と題するもう一つの研究論文もまとめた。

Making…のほうのドキュメントはわずか4ページで、現在の状況を大まかに分析している。その中では、ハードウェアを私企業オペレーティングシステムとフリーソフトウェアのオペレーティングシステムの両方で使えるためのいくつかの方法–その概念–を、OEMに対して推奨している。…Impact onのほうのドキュメントは、8ページもあって技術的に詳しい。OEMに対する推奨事項も、より具体的だ。

公開暗号鍵の基礎知識のない人にとっては、しかしなかなか難しい話題だ。Platform Keys、Key Exchange Keys、シグネチャデータベース、…。こんなもの、価値よりもトラブルのほうが大きいのでは? 本誌としてLinux Foundationにいくつか質問をぶつけてみたら、James Bottomleyが答えてくれた。

TechCrunch: 何よりもまず、エンドユーザにとってどんなメリットがあるのか? ドキュメントを読むと、すごく難しそうな技術だが、ユーザもシステムを”Setup”モードにしたままで使い、SecureBootを避けるのではないか?

James Bottomley: システムをセットアップモードのままにすると、現状と同じだ(セキュアなブートはない)。しかしMicrosoftのブログによると、Windows 8をプレインストールしたPCを買うとセットアップオプションがないから、ほかに選択肢がない。しかも、オープンソースのオペレーティングシステムをインストールしたい者にも、単なるセットアップではなく、よりセキュアなユーザモードでそれをやるか、あるいは’素(す)’のままでいくか、という選択が与えられるべきだ。出荷時にセットアップモードにするのは、その選択と、それに伴う複雑な作業を、オペレーティングシステムのインストールやシステムの起動の時点に置きたいからであり、それがベストの場所だとわれわれは信ずる。Secure Bootの普及初期における問題は、時間が解決してくれることを期待したい。そうすれば、エンドユーザの価値観においても、安全にブートすることのほうが上回るだろう。

TC: 公開鍵の完全なインフラを導入するのはいいが、それを今のハードウェアメーカーにやらせるのは、技術的に無理ではないか。ハードウェアの仕事ではないのでは?

JB: ハードウェアのメーカーがやるのではなく、セキュリティの専門技術は有能なサードパーティにアウトソースすべきだ。MicrosoftのWindows 8のロゴの場合は、OEMが鍵交換鍵のリストを管理しなければならないが、おそらくその技術能力は彼らにない。セキュリティ専門のサードパーティに鍵の管理をまかせたほうが、エラーが少なくなるだろう。

TC: 公開鍵証明書を発行する認証局が不正行為の被害を受けることもありえる。DigitNotarの最近の事件が、そのことを指摘している。セキュリティの緩いハードウェアメーカーが被害に遭ったら、エンドユーザにはどんな影響が及ぶか?

JB: だから、それが問題だ。UEFIのシステムには証明書を無効化する仕組みがある(DigiNotarの侵入を治すために同じ仕組みがインターネットで使われた)。しかし、信任のパスに無効化された鍵を使う部分があったら、ブートしなくなったり、セキュアモードを抜け出るかUFIをアップデートして状況を解決する必要が生じたりするだろう。しかしそういう被害に遭う可能性は、OEMの鍵が被害に遭う可能性に比べて低い(そういう被害に遭わないことが認証局の仕事の中心だから)。だから問題の厄介さは、認証局というものがない場合と同じか、むしろ少ない。

“普及初期における問題”という言葉は、憂鬱な響きを持っている。でもどんな新技術にも、それはつきものだ。Secure Bootが、エンドユーザにとっても良いものであることが、実証されてほしいね。

[原文へ]
[jpTechCrunch最新記事サムネイル集]
[米TechCrunch最新記事サムネイル集]
(翻訳:iwatani(a.k.a. hiwa))

広告

blog comments powered by Disqus
フォロー

新しい投稿をメールで受信しましょう。

Join 118 other followers