ハクソク

世界を動かす技術を、日本語で。

LinuxとSecure Boot証明書の有効期限切れ

312日前原文(lwn.net)

概要

  • Secure Boot に必要な Microsoft のキーが 2024年9月に期限切れ
  • 新しいキーの導入には多くのシステムでファームウェア更新が必要
  • fwupd や LVFS によるアップデート対応
  • 一部システムでは Secure Boot 無効化が唯一の対策となる可能性
  • Linux ディストリビューションとユーザーへの影響拡大の懸念

Secure Boot キー有効期限切れ問題とLinuxへの影響

  • 多くの Linux ユーザーが Secure Boot 機能を利用中

  • Secure Boot の信頼の根拠となる Microsoft キーが 2024年9月 に期限切れ

  • 新しい Microsoft キー（2023年発行）が必要だが、多くのシステムで未導入

  • 新キー導入にはハードウェアベンダーによる ファームウェアアップデート が必要

  • アップデート未対応の場合、Secure Boot 環境で新規インストール不可となる懸念

    • 既存ディストリビューションは独自キーで引き続き起動可能
    • インストールメディアは新しい shim（新キーで署名）が必須
    • 一部システムは旧キーのみ、新キーのみ、両方対応など多様な状況

  • LVFS （Linux Vendor Firmware Service）と fwupd によるファームウェア更新支援

  • fwupd の最新バージョンで多くの問題に対応、影響緩和を目指す

  • ファームウェア更新には「 key exchange key (KEK)」アップデートも利用可能

    • KEKアップデートの成功率は高いが、失敗例も一定数発生
    • 失敗時は BIOS リセットや再起動で回避可能な場合あり
    • 古い BIOS ほど失敗リスク増大

  • ベンダーが更新を提供しない場合、 Secure Boot の無効化 が唯一の解決策となる場合あり

  • 一部メーカーではプラットフォームキー（PK）紛失による深刻な問題も報告

  • KEKアップデートは前例がなく、BIOSベンダーの対応ミスの可能性も指摘

Secure Boot運用の今後と課題

  • 2011年キーの期限切れ後、ファームウェアが有効期限を厳密にチェックするかは不明
  • 既存の信頼チェーンが維持されれば、旧shimで起動可能な場合も
  • ただし、shimのセキュリティ更新は旧キーでは署名不可となり、実質的な対応困難
  • セキュリティ上、 既知の脆弱性を持つshimの継続利用は推奨されない
  • Linuxコミュニティはベンダー依存の状況下で最善策を模索
  • Secure Bootの信頼の根幹がベンダー（Microsoft・ハードウェアメーカー）に依存
  • 古いハードウェアサポートを続けるLinuxディストリビューションと、最新機種志向のベンダーとの間で緊張関係
  • 今後も滑らかな移行ができるかはベンダーの対応次第

まとめと推奨事項

  • Secure Boot利用者は自身のハードウェアが新キーに対応しているか確認が必要
  • fwupdとLVFSによるファームウェア更新を積極的に活用
  • ベンダーからのアップデートがない場合はSecure Bootの無効化も検討
  • ディストリビューション提供側も最新情報の周知とサポート体制強化が求められる
  • 今後もSecure Boot運用の複雑化に注意が必要

Hackerたちの意見

Microsoftを通さないと、サードパーティのコンピュータでOSを動かすためのサインができないなんて、全くクレイジーだよね。しかも、Microsoftがこれを簡単に勝ち取ったのも、真剣に挑戦されなかったからだと思う。

└

変わるのは法律的な要件だけだね。今はmokutilが十分に良くて、Linuxユーザーはブート時に登録を自動化するための良いツールを作れると思う。これで少しは楽になるはず。でも、他は本当にごちゃごちゃしてて、法律的な要件がまだ必要だね。

└

基本的に、ほとんどのx64コンピュータはWindowsを動かせるように作られてるから、MSが関わらざるを得なかったんだろうね。お金を持ってる他の誰も、この負担を背負いたくなかったんじゃないかな。私の知る限り、ほとんどのUEFIファームウェアでセキュアブートを無効にして、好きなもの（嫌なものも）をブートできるよ。

└

それをそのまま見るともっと理解しやすいよね：正直なサティアの証明書機関。マイクロソフトはPKIを半分はちゃんと運営できることを示した。終わり。もしLinuxの人たちが早い段階で行動を起こして、Secure Bootをコンピュータのアンチクリストみたいに子供じみた反応をしなかったら、話は違ってたかもしれない。でも、そうはならなかった。shimがあるのは、Red Hatの人たちが協力する常識を持ってたからだよ。

└

でも、オフにするか、自分のキーを登録することもできるよ。

└

ただのデフォルトだよ。自分のプラットフォームキーで上書きできる。

└

そんなことしないよ。俺は自分のシステムからMicrosoftのキーを全部削除して、自分のキーを登録してる。

ちょっと気になったんだけど、今のセキュアブートの体験ってどうなの？NVIDIAのドライバーやVirtualBoxのモジュールのせいで、インストールした全ての環境で無効にしちゃったんだ。一般的に、Arch系のディストロはセキュアブートの設定にはあまり優しくない印象があるな。

└

モジュールの署名管理は完全に自動化できるよ。登録には、一度だけちょっと intimidating なインターフェースを使って新しいPKIを受け入れる必要があるけど、物理的に管理してるシステムには問題ない。データセンターのリモート環境では、外部の動機がない限り、やる気にならないな。

└

1997年からLinuxを使ってる私の経験では（だから、昔の難しい時代の悪い習慣が残ってるけど）、黄金の道から外れるとちょっと混乱することがある。でも、黄金の道を歩いてると、セキュアブートがオンになってることに気づかないよ。例えば、DellからLinuxプリインストールのノートパソコンをもらったけど、普通に動いたしね。UbuntuのLTSバージョン（16-24）を何度もアップグレードしたマシンは、最初にセキュアブートをオンにしたときにちょっと変だったけど、それは特殊なケースだから納得できる。最近Debianをインストールしたマシンは問題なかったけど、ソフトウェアRAIDアレイからブートしたときにちょっと問題があったのは、2つの同じドライブを使ってたからUEFIブート設定で混乱しちゃったんだ。NVIDIAやVirtualBox、他のカーネル外モジュールが入ったマシンでは使ったことないけどね。

└

数年ごとにMSがマルチブートやデュアルブートを壊すアップデートをしてるよね。もうこれは意図的だと思うし、「セキュアブート」がその手段だと確信してる。子供のゲーム用にはまだWindowsだけ使ってるけど、もう千年も前からLinuxユーザーだよ。

└

Fedoraを使ってて、Secure Bootは有効にしてる。カーネルのアップデートがあるたびに、vmwareのドライバーを再コンパイルして署名するためのスクリプトを実行しなきゃいけない。いつかdkmsでやり方を見つけられるかもしれない。たまに、カーネルの変更が大きすぎてvmwareのドライバーが動かなくなることがあるから、新しいパッチを入手しなきゃならない。

└

この体験を6.5/10と評価するかな。Ubuntuみたいなメジャーなディストロを使ってるなら、Secure Bootはそのままで動くことが多いよ。「machine owner keys」とか面倒なことをしなくても済むし。Ubuntuには「linux-modules-nvidia-550-generic」みたいなパッケージがあって、canonicalのキーで署名されたnvidiaの550ドライバーが含まれてる。運が良ければそのパッケージがインストールされて、Secure Bootでも動くnvidiaドライバーが手に入る。さらに、別の仕組みもあって、「machine owner key」（MOK）を設定すると、ソフトウェアのアップデートが自動的に新しいnvidiaカーネルモジュールをビルドして、dkmsを使って署名するから、Secure Bootでも動くようになる。ただ、このプロセスはちょっと不安定なことがある。MOKの設定プロセスでは再起動して「MOK Manager」という、1980年代のものみたいなインターフェースを通らなきゃいけない。これを知らなかったり、何のためのものか分からなかったり、英語が苦手だと、間違ったボタンを押してMOKを設定できないことがある。しかも、これが表示されるのは一度のブートだけで、特殊なターミナルコマンドを知らないと次回からは出てこない。設定中に何か問題が起きたら、PCが起動しないからスマホで修正方法を調べる羽目になる。一方で、Secure Bootをオフにするのは簡単だし（BIOSが何か分かっていれば）、毎回うまくいく。だから「nvidiaドライバーの設定方法」ガイドの多くはそれを勧めてる。文句は言ってるけど、カーネルモジュールを動的にコンパイルして署名する仕組みがここまでうまく動くのはすごいと思う。特に、ボランティアが多くの部分を維持していて、彼らはBIOSでSecure Bootをオフにすることもできたはずなのに、無私の精神で時間を捧げてるからね。

└

Archでは、sbctl [0] がリリースされてからSecure Bootを使ってるけど、問題はゼロだよ。まあ、Nvidiaのハードウェアは使ってないけどね。[0] https://github.com/Foxboron/sbctl

└

https://en.m.wikipedia.org/wiki/Intel_Management_Engine

└

初期設定のままでも結構うまく動くよ。ただし、LinuxとNvidiaハードウェアを組み合わせようとするとちょっと面倒。Nvidiaハードウェアでも、動かすのにそんなに手間はかからないけど、いつものようにNvidiaは余分な手順が必要だね。Linuxが本当に足りないのは、自分のキーを登録するためのユーザーフレンドリーな方法で、これがあればNvidiaやファームウェアのアップデーター、カスタムブートローダーの問題が一瞬で解決するんだ。コマンドラインツールは少しずつ使いやすくなってきてるけど、ガイド付きの手順がないのが残念。

└

Archを使ってるけど、セキュアブートの設定はすごく簡単だったよ。なんでそれがフレンドリーじゃないと思うのか分からない。UKIを使ってるから、ブートローダーは全く使ってないし、私のUKIはUEFIにインストールした自分のキーで署名されてる。署名プロセスのほとんどはsystemdが処理してるから、基本システムにすでに統合されてるんだ。

└

UbuntuをカスタムDKMSモジュールで使うとき、インストール中にチェックボックスが一つあるだけ。それだけで、もう5年以上。

Linuxだけじゃなくて、2026年にはWindowsの署名用証明書にも影響があるよ。 https://support.microsoft.com/en-us/topic/windows-secure-boo... https://techcommunity.microsoft.com/blog/windows-itpro-blog/... これらの証明書に有効期限があるのは間違いだと思う。 compromised signing key に対しては一応保護になるかもしれないけど、15年待たないとその鍵が無効にならないのはあまり役に立たないよね！心配しないで、MSの新しい証明書は2038年に期限切れになるから（32ビットUnix時間のロールオーバーの数ヶ月後）。

└

それって本当にミスなのかな？それともマイクロソフトはもう意図通りに動かないコンピュータに興味がないだけなのかも。これがその証拠になるとは思わないけど…

└

有効期限については、伝統に従う流れなのかなって感じてる。TLS証明書は期限が切れるし、それがセキュリティ機能の一部だから、Secure Bootの証明書も同じようにする理由があるよね？もちろん、ルート証明書の発行者にとっては大きな権力を持つことになるし、マイクロソフトの視点から見れば良いことだと思う。でも、もしマイクロソフトが本当にセキュリティを気にしてるなら、ユーザーが承認していないアプリが何かをするのを許可すべきじゃない（例えば、データを暗号化するウイルスをインストールすることとか）。これが実際にはユーザー体験とセキュリティを向上させるかもしれない。でも、Secure Bootがあるおかげで、少なくともWindowsのカーネルが改ざんされてないことは確実だから、ウイルスが正しく動作することはないよね :)

└

https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Proces...

└

本当に、これらの証明書に有効期限を設けるのは間違いのように思える。特に、ほとんどの関連する攻撃は、攻撃者がシステムクロックを制御しているシナリオで発生するから。

└

災害復旧計画って楽しそうだね。「A店から新しいマシンを持ってきて、B箱に入ってるWindowsのCDを使って、そして…」って感じで。

セキュアブートの歴史を調べてみたら、IntelとAMDのプロセッサにはIntel Management Engine [1]やAMD Platform Security Processor [2]を通じてバックドアがあることがわかった。どちらもクローズドソースで、これまでにいくつかの脆弱性があったんだ。要するに、バックドアみたいなもんだね。これらの「機能」を無効にするのはほぼ不可能みたいだ。

これから私のノートパソコンがどうなるのか気になるな。Lenovoは、UEFIファームウェアインターフェースにアクセスする前に、Microsoftに署名されたNvidiaのブロブを読み込むことにしたみたい。自分のセキュアブートキーをインストールしようとした人たちは、変更を元に戻すためにファームウェア設定インターフェースにすら入れないことを痛感したみたい。公式の回避策は、標準のLinuxユーティリティではなく、ファームウェアインターフェースを通じてのみセキュアブートキーを読み込むことなんだけど、これだとNvidiaファームウェアに署名するために使われた証明書を消去することを拒否するんだ。でも、その回避策もその証明書が期限切れになったら当然使えなくなるよね。

└

AMD 7840U搭載のFrameworkラップトップは、Microsoftのキーなしでも完璧に動くよ。今使ってるラップトップでは、--tpm-eventlogを使ってsbctl enroll-keysでOptionROMのハッシュをホワイトリストに登録できるかも。

記事には、誰かが自分が影響を受けているかどうかをテストするための非常に明確な方法を含めるべきだよ。どうやって（すごく明確で簡単な方法で）ある任意のシステムが9月にこの問題に直面するかを確認するの？

└

時計を12月に合わせて再起動して、何が起こるか見てみて。

MSキーを使った「セキュアブート」は本当のセキュアブートじゃない。「Microsoftが何をブートできるか決める」ってこと。自分のキーを登録するのが標準的な運用方法であるべきだよ。shimは冗談みたいなもん。

更新が来ないかもしれないものは、証明書をチェックするときに現在の日付/時間を使うべきじゃないよ。代わりに、ファームウェアがコンパイルされた日にはその証明書が有効だったかどうかを確認すべき。つまり、時間が経っても動作は変わらないってこと。

└

期限切れの証明書は、せいぜいスキップできる警告であるべきだよ。誰も証明書の期限切れに頼ってセキュリティを保ってるわけじゃないから。もしそうなら、盗まれた証明書の期限切れを待つのに何年もかかるかもね - 笑！ それはただの「そういえば証明書が切れたから、更新を確認してね」っていう軽いお知らせなのに、いろんなシステムが証明書の期限切れを世界の終わりみたいに扱ってるのはおかしいよ。

└

それは期限切れの意味をほぼ完全に無にしてるね。署名されたオブジェクトに安全なタイムスタンプサービスでタイムスタンプを付けることを要求すれば、もう少しマシになるかも。でも、その場合、デフォルトの証明書を使ったセキュアブートが防ごうとしている脅威モデルを真剣に考えるべきだよ。

マイクロソフトがこんな風にLinuxのブートプロセスに入り込むなんて、イライラするわ。道徳的に言って、Linuxを起動する時にマイクロソフトの署名されたキーなんて使うべきじゃないよ。

└

シムを使う必要はないよ。これに従えばいいさ。https://www.rodsbooks.com/efi-bootloaders/controlling-sb.htm...

└

Libreオペレーティングシステムは、マイクロソフトのハードウェア基準や適合テスト（Windows HLK）に従った機械で動くようにコーディングされてるんだ。LinuxがWindowsのブートプロセスに入り込んでるんであって、その逆じゃないよ。たとえLinuxがプリインストールされた機械でもね。「道徳的にクリーンでいたい」とか言うなら、FSFは独自のハードウェア基準を作って、OEMにそれに従わせる必要があるね。頑張って。

マイクロソフトの気分次第でLinuxを起動できるSecure Bootの証明書が期限切れになるなんて、気づかなかったよ。だから、マイクロソフトがエンドユーザーのLinuxを潰すためにやることは…何もしないことなんだ。どうしてこんな状況になっちゃったんだろう？マイクロソフトがサンバやLinux VFATを使ってる人たちを訴えるぞって脅してたのに、オープンソースを「癌」って呼んでたのに。