リーナス・トーバルズ、セキュアブート鍵をカーネルに含めることを一蹴、曰く「おめーら、フェラ大会じゃねーんだぞ」

まず、Red HatのDavid Howellsが、マイクロソフトによって署名されたセキュアブート鍵をカーネルに含めてくれるよう、MLで要請した。

ようリーナス。

このパッチセットをpullしてくんね？

セキュアブートモードで動くカーネルに、鍵を動的に追加する機能。鍵をロードするには、新しい鍵はすでに持っていて、信頼されている鍵で署名されている必要がある。この「すでに持っている」ところの鍵は、カーネルに組み込まれているものや、UEFIデータベースにあるものや、あるいは暗号ハードウェアのものが含まれる。

で、"keyctl add"は署名されたX.509認証を受け付けるのだけど、マイクロソフトの署名サービスは、EFI PEバイナリしか署名してくれないんだ。

LKML: David Howells: [GIT PULL] Load keys from signed PE binaries

これに対するリーナスの返事。

もっと議論を深めてからでないとダメだ。

ぶっちゃけ、これはクソすぎんだろ。全体的な設計からして、ドアホな設計のためにクソバカなインターフェース。なんでそんなことしなくちゃなんねーんだ？

すでにあるX.509パーサーですら気に食わんのに、このクソミソ変態インターフェースときた日にゃ、もうお手上げだぜ。

リーナス

LKML: Linus Torvalds: Re: [GIT PULL] Load keys from signed PE binaries

これに、Red HatのMatthew Garrettが返事。

唯一の認証局で、しかもPEバイナリしか署名しないんだ。

LKML: Matthew Garrett: Re: [GIT PULL] Load keys from signed PE binaries

これに対してリーナス、とうとうブチキレたらしく。

おめーら、フェラ大会じゃねーんだぞ。

PEバイナリをパースしたきゃ、やりゃいいだろ。

Red HatがMicrosoftのをしゃぶりたきゃ、そりゃテメーの勝手だ。俺の保守するカーネルには何も関係ねーことだ。オメーらにしちゃ、署名マシンでPEバイナリをパースして、署名を検証して、自前の鍵で結果の鍵を署名することぐらいどうってことないだろ。オメーはすでにコード書いてるしな。このクソpullリクエストはなんだコラ？

何でこの俺が気にかけなくちゃなんねーんだよ？　なんでカーネルが「おれらPEバイナリしか署名しないもんねー」とかいうド低能に付き合わなきゃなんねーんだよ？　X.509はサポートしてる、署名の規格だもんな。

これはtrusted machineのユーザーランドでやれ。カーネルでやる理由は一切ない。

リーナス

LKML: Linus Torvalds: Re: [GIT PULL] Load keys from signed PE binaries

これに対し、David Howellsが説明するが

それには問題があるんだよ。

1. マイクロソフトの認証破棄は、PEバイナリのハッシュに対して行われるのであって、鍵ではない。
2. 再署名により、鍵はマイクロソフトの鍵ではなく、我々のマスターキーに依存するようになる。すると、マイクロソフトの認証破棄は無意味になる。
3. この時点で、マイクロソフトができることは、我々のマスターキーを破棄することしかなくなる。

David

LKML: David Howells: Re: [GIT PULL] Load keys from signed PE binaries

リーナスの返事。

お前はいまだに根本的な問題が分かってない。

• なんでカーネルがやらなきゃならねーんだ？
• なんでMSによるLinuxのカーネルモジュールの鍵署名を気にかけなきゃなんねーんだ？

お前の議論は、このキチガイな前提条件を受け入れなきゃ成り立たない。俺はまっぴらごめんだ。

リーナス

LKML: Linus Torvalds: Re: [GIT PULL] Load keys from signed PE binaries

この話の背景には、Linuxのセキュアブートへの対応方法がある。

Trusted Computing、もといTreacherous Computingは、身元が保証されたバイナリしか実行しない。暗号的にこれを可能にするのが、署名だ。例えば、私があるバイナリを私の身元証明とともに、認証局の秘密鍵で署名してもらい、配布したとする。バイナリを実行する側は、公開鍵で署名を検証することにより、バイナリが署名された時点から一切改変されていないことを保証できる。もちろん、これはソフトウェアが悪意ある動作をしないかどうかの保証ではない。あくまで、バイナリの身元と改変されていないことを保証するだけである。さて、バイナリが悪意ある動作をすることが判明した。その場合、バイナリの作成者である私の悪事がバレたことになる。なぜならば、そのバイナリを作成できるのは、私しかいないのだから。認証局は、そのバイナリの身元である私の認証を破棄できる。これにより、私の身元で署名されたバイナリのみ、実行を拒否することができる。

実際には、私の鍵を盗んだ者のしわざである可能性もある。しかしそのような場合でも、私の鍵で署名されたバイナリの認証をすべて破棄できる。

署名によるトレチャラス・コンピューティングは、ソフトウェアが悪意ある動作をするかどうかを保証するのではなく、ソフトウェアの身元を保証する。身元バレするソフトウェアに悪意ある挙動を仕込みたくはないし、仮に悪意ある挙動を仕込んだとしても、一度バレたら即座に認証破棄され、すべてのバイナリの検証が失敗するので、大規模に広げることも出来ない。

これは、SSLと同じ方法であり、暗号理論的にも正しい方法である。Verisignの認証には、現実の住所が必要になる。たとえ郵送の転送を何度も繰り返したとしても、結局最後は現実の住所が必要になり、そこから足がつく。事実、国家による諜報機関であっても、Verisignからの認証を大真面目に受けるのではなく、他人の認証を盗んで使っている。

さて、これには信頼できる認証局が必要となる。セキュアブートの場合、マイクロソフトがその認証局となる。マイクロソフトとVeriSignが信頼できるとしたならば、マイクロソフトの認証のもとに、あらゆるバイナリの身元が信頼できる。

さて、Linuxをセキュアブートに対応させるには、まずマイクロソフトによってバイナリを署名してもらわなければならない。カーネルのアップデートのたびに署名するのは極めて面倒なので、Linux陣営はまず、簡易ブートローダーをマイクロソフトに署名させ、ブートローダーより後は、自前の鍵で署名するという方法を取っている。そして、すべてのカーネルとカーネルモジュールのバイナリを、自前の鍵で署名、検証する。つまり、Linuxカーネルとカーネルモジュールは、Linux側のマスターキーで署名検証され、マイクロソフトに署名してもらう必要がない。もし検証しなければ、それはどんなバイナリでも読み込めるブートローダーであり、マイクロソフトはそのようなブートローダーの存在を許すはずがなく、ブートローダーへの署名を破棄する。

とまあ、いろいろあるのだが、そのマイクロソフトの署名の規格が、PEバイナリしか受け付けなかったりと、いろいろとド低脳なことになっている。今回の問題は、Red Hatのために署名されたバイナリをカーネルに取り込むpullリクエストであり、リーナスとしては、そんな馬鹿げたことはカーネルの仕事じゃねーッ！、ユーザーランドでやれ、ユーザーランドでッ！　ということだ。