ハクソク

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

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

2025年7月18日原文(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のドライバーが動かなくなることがあるから、新しいパッチを入手しなきゃならない。

Hacker Newsで議論の続きを見る