Linuxとセキュアブート証明書の有効期限切れ（2025年）

Secure Bootを有効にしているLinuxユーザーは、知らず知らずのうちにMicrosoftの鍵に依存していますが、この鍵は9月に期限切れとなります。それ以降、Microsoftはこの鍵を使って、LinuxディストリビューションがSecure Bootでカーネルを起動するために使用するshim初期段階UEFIブートローダーに署名することはありません。しかし、2023年から利用可能な代替の鍵は、多くのシステムにインストールされていない可能性があり、さらに悪いことに、ハードウェアベンダーがシステムファームウェアの更新を発行する必要があるかもしれません。これが行われるかどうかは不明です。大多数のシステムは混乱に巻き込まれないようですが、ディストリビューターとユーザーには追加の作業が必要となるかもしれません。 Mateus Rodrigues Costaは7月8日にFedora develメーリングリストでこの問題を提起しました。彼は「今月のWindows 11累積アップデート」に付属する警告に気づき、2026年6月から期限切れになる予定のSecure Boot証明書について述べられていました。これらの特定の証明書は、はるかに早く期限切れとなるshim用とは別のものでした。いずれにしても、証明書の期限切れの問題は、Linuxの世界が取り組む必要があるものです。 状況はかなり複雑です。Daniel P. Berrangéは、Linux Vendor Firmware Service (LVFS) サイトの、この問題を説明するページを指摘しました。LVFSは、Linuxからシステムファームウェアを更新するために使用されるfwupdやその他のツールの本拠地です。LVFSとfwupdについては、2020年のLWNの記事で取り上げられています。 この問題には複数の可動部分があります。LinuxカーネルへのSecure Bootを行うためには、UEFIブートプロセスにおいて、初期段階のブートローダーが、期限切れになっていないファームウェアデータベース内の鍵で署名されている必要があります。これらの鍵は、有効期限や署名などの他の情報を含む証明書に含まれています。証明書の期限切れは、主にSecure Bootシステムに新しいディストリビューションをインストールする際にのみ問題となるはずです。インストールされるshimには、ディストリビューション固有の鍵が含まれ、それらの鍵を使用して他のプログラム（例：GRUB）を実行するための信頼の根源として機能します。 現在、shimは2011年のMicrosoftの鍵で署名されており、9月11日に期限切れとなります。それを過ぎると、更新されたshim（Microsoftの2023年UEFI第三者用鍵で署名されたもの、Windowsアップデートで言及された特定の鍵とは異なります）がない限り、インストールメディアは起動しなくなります。インストール済みのディストリビューションは、自身の鍵で署名されたブートローダーを持っているはずなので、引き続き起動します。しかし、Microsoftの新しい鍵が欠けているファームウェアデータベースを持つシステムが多く存在し、古い鍵と新しい鍵の両方を持つものもあれば、新しい鍵しか持たず、現時点ではLinuxインストールメディアをSecure Bootでまったく起動できないものもあるでしょう。 ベンダーは（そしてほとんどがそうすることを期待していますが）、新しい鍵を追加するファームウェアアップデートを提供でき、それによって署名されたshimを含むインストールメディアを作成できますが、これらのアップデートはシステムにインストールされる必要があります。ここでLVFSとfwupdが登場します。LVFSは様々な種類のベンダーファームウェアアップデートのリポジトリであり、fwupdやその他のツールを使用して、Linuxからファームウェアに必要な部品をインストールできます。Berrangéは、古いバージョンのfwupdではすべての問題を解決できなかったが、「最近のリリースでは、Linuxユーザーが見る必要のあるアップデートを処理するために強化されており、最悪の影響を軽減するはずです」と述べました。しかし、まだ少し不安定な道のりかもしれません：「ユーザーはトラブルの可能性を『認識』すべきですが、最悪の『心配』の部分はOSベンダーとメンテナーによって処理されることを願っています。」 LVFSの作成者でありメンテナーであるRichard Hughesも同意し、人々のシステムが更新されたSecure Boot機能を取得できる様々な方法があることを指摘しました。完全なファームウェアアップデートがベンダーによって提供される可能性があり、それは（おそらく）新しいMicrosoftの鍵を含む新しいデータベースを追加するでしょう。もう一つの方法は、「鍵交換鍵」（KEK）アップデートで、これはMicrosoftの鍵で署名されたベンダー固有の鍵であり、fwupdによって新しい鍵でデータベースを更新するために使用できます。しかし、いくつかの注意点があります：KEKアップデートは約98%の成功率、dbアップデートは約99%の成功率で展開されていますが、1%でも数百万人に適用されると、かなりの数の展開失敗が発生します—「failed to write efivarfs」というものです。これを一部の人にとって修正するのは、再起動してBIOSを工場出荷時の設定にクリアすることです—これにより、利用可能なefivarスペースの「デフラグメンテーション」がトリガーされ、アップデートをデプロイするのに十分な連続したスペースが確保されます。BIOSが古いほど、これに遭遇する可能性が高くなります。Hughesは、新しいEFI変数用のスペースに関する既知の問題に言及しています。 ベンダーがアップデートを提供しないシステムでは、Secure Bootを無効にすることが新しいインストールを許可する唯一の選択肢となるかもしれません。あと数ヶ月で、すべての既存のインストールイメージとメディアはSecure Bootでインストールできなくなります—新しい鍵しか持たないシステムでは、すでにそうなっているかもしれません。Secure Bootでのインストールは、それだけ複雑になりました。 しかし、それ以上に、ベンダーアップデートでの間違いや問題の可能性もあります。Hughesは、少なくとも1つのメーカーが、製造時にハードウェアに焼き付けられるベンダー固有の鍵であるプラットフォーム鍵（PK）のプライベート部分へのアクセスを失ったことを指摘しました。これは、ハードウェア内のプラットフォーム鍵を変更する必要があることを意味し、これは未知の領域であり、「認証の観点からはひどいアイデア」です。さらに、Gerd Hoffmanが指摘するように、KEKアップデートプロセスも新しいものです：「KEKアップデートはこれまで行われたことがないので、BIOSベンダーが物事を台無しにしてKEKのアップデートが機能しない可能性もあります」。 このスレッドには、様々なハードウェアモデルにおけるSecure Boot証明書に関する複数のレポートや、KEKとデータベースへのアップデートに関するレポートがあります。完全に明らかではないことの一つは、ファームウェア実装が2011年の鍵の有効期限を実際に強制するかどうかです。その鍵に基づく機能的な信頼チェーンを持つ動作中のシステムは、9月以降もその鍵で署名されたshimで動作し続けるかもしれません。しかし、例えばセキュリティ問題のためのshimのアップデートは、古い鍵では署名できなくなります—Microsoftは期限切れの鍵を使用して署名することはありません。Adam Williamsonが述べたように、これはある種の「解決策」につながるかもしれません： 理論的には、そのような場合のために古いshimを出荷するという選択肢もあるのではないでしょうか？チェーン全体が古ければ機能するはずですよね？もちろん、古いMS証明書を使っているかどうかを判断するためのヒューリスティックが必要になり、古いshimをインストールすることになります… 彼は、それは実際には意味がなく、ユーザーはSecure Bootを無効にするべきだと言いました。Hoffmanはこれらすべてに同意しましたが、shimのアップデートに関する問題を指摘しました：「既知のセキュリティバグがあるshimを実行し続けることは、Secure Bootを有効にする意味を（ある意味）なくします」。 全体として、Linuxの世界は状況下でできる限りのことをしているようです—これは、主にWindowsを気にするベンダーからのハードウェアに関する場合にしばしば見られることです。Secure Bootの信頼の根源となる鍵（プラットフォーム鍵と署名鍵の両方）がベンダー—Microsoftとハードウェアメーカー—の管理下にあることを考えると、常に追いつくのは少し困難でしょう。Linuxとディストリビューションが古いハードウェアを明示的にサポートする一方で、他のベンダーはとっくの昔に最新の輝かしいものに移行しているため、そこには明らかに何らかの緊張が生じることになります。この道のりができるだけスムーズであることを願うばかりです。 コメントを投稿するにはXを押してください Posted Jul 16, 2025 18:31 UTC (Wed) by bluca (subscriber, #118303) [Link] (4 responses) > ファームウェア実装が2011年の鍵の有効期限を実際に強制するかどうかは、完全に明らかではありません。 長年見てきた経験からすると、ほとんどのファームウェアはこれをチェックしないのではないかという疑念があります。 コメントを投稿するにはXを押してください Posted Jul 16, 2025 19:39 UTC (Wed) by kraxel (subscriber, #49444) [Link] (2 responses) tianocore edk2は設定します