この記事はTUT (powered by LinuxClub) Advent Calendar 2025 10日目です。

導入

ここ15年くらいに製造されたUEFIでブートされるコンピュータには、SecureBootと呼ばれる機能が搭載されており、大抵の場合で有効にされています。
Windowsをインストールして使用している分には意識することはないと思いますが、Linuxなどをインストールしたことがある人なら「あぁ、なんかUEFIの設定画面で無効にするやつ？」というイメージを持っているかもしれません。

この「SecureBoot」という機能が何のために存在していて、どんな仕組みで動いているのかを、簡単に紹介したいと思います。(あまり詳しい話はしません)
また、基本的にこの記事は、Windowsがプリインストールされているか、Windowsがインストールされることが前提となっている、x86_64アーキテクチャのパーソナルコンピュータを対象にしています。(サーバ機や組み込みなどは対象としていません)

後半では来年に起こりうる阿鼻叫喚な予測を書いています。
知らないと致命傷ですが、知っていれば回避できる(はず)ですので、この記事を読んだ人は身の回りの人に「来年やばいかも？」と教えてあげてください。

SecureBootとは

実際にSecureBootとは何を目的とした機能なのか、一言でまとめると
「これから起動しようとするOSが正規のソフトウェアか判断する」
となります。

もうちょっと小難しく言うと、OSに起動段階からマルウェアなどが混入することを防止するために、ブートローダやカーネル、その他UEFIアプリケーションの電子署名を検証して、改竄されていないかを確認するための機能です。

市井で一般的に販売されているWindowsマシンでは、Microsoftの電子証明書がプリインストールされておりWindows 7以降は、その証明書の鍵で署名されています。(Windows 7は64bit版のみ署名されてた)
また、MicrosoftはWindows 8以降がプリインストールされるマシンでは、SecureBootを有効にすることを必須要件としています。

Windows以外の場合もSecureBootは使えます(使えるはずです……)
RHELやFedora、AlmaLinux、Ubuntu、Debian GNU/Linuxなどでは、UEFIとGRUBなどのブートローダの間に、shimという中間ローダが存在しています。各プロジェクトは自身で用意したCAを入れてビルドしたshimをshimプロジェクトに申請してMicrosoft UEFI CAで署名してもらい、ブートローダやカーネルなどはプロジェクト自身のCAで署名することで、SecureBootが使えるようになっています。

UEFIがshimの署名を確認する(Microsoft UEFI CAで署名)
↓
shimが起動する
↓
shimがブートローダの署名を確認する(各プロジェクトのCAで署名)
↓
GRUBなどのブートローダが起動する
↓
ブートローダがカーネルの署名を確認する(各プロジェクトのCAで署名)
↓
カーネルが起動する

RAIDカードの仮想ボリューム上からの起動など、起動時にオプションROMの支援が必要な場合は、それらオプションROMにも署名が必要です。

ここまでで、Windowsの場合、Windows以外の場合、オプションROMの場合の3つを挙げました。
それら3つはそれぞれ別のCAがMicrosoftによって運用されています。

1. Microsoft Windows Production PCA / Windows UEFI CA
   Windowsのブートローダを署名するために使用されている。
2. Microsoft UEFI CA
   Windows以外のブートローダ、カーネル、その他UEFIアプリケーションなど3rd Partyのバイナリを署名するために使用されている。
3. Microsoft Option ROM UEFI CA
   RAIDカードなどのオプションROMを署名するために使用されている。
   (2011年当初はMicrosoft UEFI CAと共通でしたが、それではオプションROMを許可すると同時に、Windows以外の起動を許してしまう事から、2023年に発行された証明書では独立したCAになった。)

これらCAはUEFIにはデータベースの形で登録されており、それをUEFIでは「db」と呼んでいます。

また、電子署名の失効情報をまとめたデータベースとして「dbx」が存在しています。

dbやdbxは未来永劫プリインストールのままということはなく、何かのタイミングで追加・更新が発生することが想定されています。
UEFIが新たに登録されようとしているdbやdbxが正規のデータかを判断するためのCAも存在し、それは「KEK」(Key Enrollment Key)と呼ばれており、これもMicrosoftが運用しています。(Microsoft Corporation KEK CA)

ここまで見ていると一つ気づくことがあると思います。

「あれ？これ全部Microsoftが牛耳ってね？」

はい、SecureBootはMicrosoftの意向が存分に反映された(というよりMSの意向しかない)仕組みです。

ですが、大体のコンピュータではMicrosoft以外のCAを信頼する設定もできるようになっています。(コンピュータベンダがちゃんと実装していれば)

細かい手順は書きませんが、自分で作ったCAの証明書をUEFIの設定画面などからインストールして、そのCAでブートローダやカーネルを署名することで、MicrosoftのCAを使わずに起動できます。
また、この手順をサポートするためのツールとしてsbctlなどのプロジェクトもあります。
(このときにコンピュータベンダなどMicrosoft以外が発行したCAを一緒に消してしまうと文鎮化したり、診断ツールなどが起動できないなど悲惨なことになるので、気をつけましょう。)

SecureBootで起きた・起きる問題

SecureBootはOS起動前にマルウェアを差し込まれるリスクを低減する機能として、一定の効果があることは、お分かりいただけたかと思います。
が、SecureBootはいいことばかりではなく、負の側面があることも認識しなければなりません。

ここではSecureBootが原因で起きた・起きるであろうトラブルについて記していこうと思います。

Windows以外のOSが起動できない？

この問題はSecureBoot導入当初から特にOSSコミュニティで議論されています。
現在、大体のPCではSecureBootの無効化や独自CAの登録が可能になっている他、shimのようなSecureBoot用中間ローダの存在で解決していますが、当初は「今後販売されるPCはWindows以外起動できなくなるのではないか」といった問題が議論されていました。
また、現在でも完全に解決しているわけではありません。Windows以外のOSを起動するときにはUEFIで一定の操作が必要なコンピュータや、そもそもMicrosoft UEFI CAが登録されていないコンピュータが存在しています。

Windows Update後にコンピュータが起動しなくなった

2025年6月に配信されたWindows Updateでコンピュータが起動しなくなる問題が発生しました。
2015〜2018年あたりに製造されたGIGABYTE、富士通、マウスコンピュータなどのコンピュータで発生していたようです。
原因として、dbxの容量の増加が指摘されていて、それまで8KB程度であったdbxがその配信では24KBまで増加していました。UEFI側の設計容量を超えたdbxが登録操作されたときの挙動が定義されておらず、バグが発生してしまい、UEFI BIOSが起動しなくなる→コンピュータが起動しないという状態になったと推察されます。
(Microsoftやコンピュータベンダが悪いというより、BIOSベンダであるInsydeのUEFI BIOS実装が悪いのでは？)

証明書の期限切れ

SecureBootでは電子証明書の仕組みを使っているため、当然Webで使用されているTLS証明書のように各証明書に有効期限が存在しています。

現在、SecureBootで使用されているMicrosoftの証明書は、2025年12月現在では2011年と2023年に発行されたものが利用されています。そのうち2011年に発行された証明書の有効期限が来年に迫っています。

KEKはdb及びdbxを登録するときの署名確認なので、失効してもすぐには影響はありませんが、dbが失効することは非常に大きい影響があると考えられます。UEFI BIOSの実装にもよりますが、有効期限後には以下の事象が発生する可能性があります。

• OSの起動が止まってSignature Invalidなどのエラー画面が表示される
• エラー画面すら出ずにUEFI BIOSの設定画面が表示される
• Bitlockerの回復キーを求められる
• TPMが使えない
• RAIDカードの設定画面が開けない

実際には他にも様々な事象が発生する可能性が考えられます。

この事に対してコンピュータベンダやMicrosoftも対応を行っています。
各コンピュータベンダはUEFI BIOSファームウェアアップデートの際に、2023年発行の証明書をインストールしています。
また、Microsoftも対応しています。Windows Updateで2023年発行の証明書を配布しており、UEFI BIOSの実装がまともであれば、自動的にインストールされます。が、UEFI BIOSの実装はメーカによってかなりバラツキがあり、インストールできない可能性がありますので、やはりUEFI BIOSファームウェアのアップデートを行う方が確実であると言えそうです。
(sbctlとかで鍵を入れようとしても失敗するのに、Windows Updateで全てのPCに入れられるとは思えない……)
最悪コンピュータベンダからBIOSアップデートも来ないし、Windows Updateで新しい証明書が入らなかったよという場合には、UEFI BIOSメニュー画面から手動で証明書を入れましょう。
(それすらできないコンピュータは窓から投げ捨てるしか無いです。SecureBoot無効化？セキュリティリスクをちゃんと考えてやるならいいと思いますが、むやみに無効化するのはやめましょう。)

登録されている証明書の確認方法

では手元のコンピュータにどんなSecureBoot用の証明書が入っているのか、2023年発行の証明書が入っているのかは大変気になると思いますので、WindowsとLinuxで確認する方法を書いておきます。

Linuxの場合

Linuxでは efitools に含まれている efi-readvar コマンドで確認するのが結果が見やすく、一番簡単です。
efi-readvar -v KEK でKEKが、efi-readvar -v db でdbが確認できます。

以下はVMware WS 25H2上のUbuntu 24.04で実行してみた結果です。

$ sudo efi-readvar -v KEK
Variable KEK, length 3066
KEK: List 0, type X509
    Signature 0, size 1478, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=US, O=Microsoft Corporation, CN=Microsoft Corporation KEK 2K CA 2023
        Issuer:
            C=US, O=Microsoft Corporation, CN=Microsoft RSA Devices Root CA 2021
KEK: List 1, type X509
    Signature 0, size 1532, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
        Issuer:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root

$ sudo efi-readvar -v db
Variable db, length 8151
db: List 0, type X509
    Signature 0, size 991, owner a3d5e95b-0a8f-4753-8735-445afb708f62
        Subject:
            C=US, ST=California, L=Palo Alto, O=VMware, Inc.
        Issuer:
            C=US, ST=California, L=Palo Alto, O=VMware, Inc.
db: List 1, type X509
    Signature 0, size 971, owner a3d5e95b-0a8f-4753-8735-445afb708f62
        Subject:
            C=US, ST=California, L=Palo Alto, O=VMware, Inc., CN=VMware Secure Boot Signing
        Issuer:
            C=US, ST=California, L=Palo Alto, O=VMware, Inc., CN=VMware Secure Boot Signing
db: List 2, type X509
    Signature 0, size 1572, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
        Issuer:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
db: List 3, type X509
    Signature 0, size 1515, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
        Issuer:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
db: List 4, type X509
    Signature 0, size 1470, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023
        Issuer:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
db: List 5, type X509
    Signature 0, size 1464, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023
        Issuer:
            C=US, O=Microsoft Corporation, CN=Microsoft RSA Devices Root CA 2021

VMware Workstation Pro 25H2ではちゃんと2023と記載が入った証明書が入っていますね。
手元のマシンで実行してみて、結果の中に、Windows UEFI CA 2023 や Microsoft UEFI CA 2023 が入っていれば、来年6月や10月に慌てることはないと思われます。

Windowsの場合

PowershellでEFI変数を直接読み出すのが、新たなツールをいれることなく確認できるのでオススメです。

Get-SecureBootUEFI でSecureBootに関するEFI変数を読めるのですが、そのままだとオブジェクトが返されてしまいます。カッコでくくって .bytes をつけることでバイナリデータを取り出せるのですが、バイナリ列を(しかも10進数で)デロっと吐かれても(一部の超人を除いて)困ると思うので、 [System.Text.Encoding]::ASCII.GetString で最低限人間が読めるデータにしてもらいます。でも、そのままASCII変換されても、一部の文字列は読めますがほとんどのデータは読めないので、 -match を使うことで含まれているか否かを判断してもらうことにします。True が返ってくれば、2023年発行の証明書が登録されているし、False が返ったら登録されていないということになります。

PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
True

PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
True

PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft UEFI CA 2023'
True

PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Option ROM UEFI CA 2023'
False

こちらもVMware Workstation Pro 25H2上で実行しました。
KEKや Microsoft (Windows|Microsoft) UEFI CA 2023 は True が返ってきましたが、 Microsoft Option ROM UEFI CA 2023 は False が返ってきているのが分かります。
まぁ仮想マシンでOptionRomが必要な起動の仕方はしないでしょうから、これでも問題ないという判断なのだと思います。(vSphereでRAIDカードごとPCIeパススルーしたときに設定画面見れなくないか？)

結び

LinuxClubのアドベントカレンダーで「久々にいい感じの記事書くかぁ」と思い立ち、ArchLinuxでMOKを使ったSecureBootを実現しようとして嵌ったネタと、嵌ってたときに偶然dbの中身を見て「あれ？これって来年の日付だけど、やばくね？」と思ったネタがあり、どっちがいいかなと天秤をかけてました。とりあえずどちらのネタもネットを漁ってみましたが、MOKを使ったSecureBootはArchWikiという偉大なページもあり、それほど私が書くモチベーションもなかったのですが、SecureBootの方はあまり記事もなくネットメディア系でも数本しか発見できなかったので、「そんじゃあ、こっち書くべぇ」となって、まとめてみました。
(それはそれとしてMOKのSecureBootの方も備忘録をそのうち書くと思います。)

多分、今のまま来年6月を迎えたら、鯖が再起動したら謎のエラーで上がってこなくて阿鼻叫喚だし、10月末は各々のPCが上がってこなくて阿鼻叫喚だと思います。知らないと致命傷ですが、知っていれば回避できる(はず)ですので、この記事を読んだ人は身の回りの人に「来年やばいかも？」と教えてあげてください。

ここまで読んで頂き、ありがとうございました。

TUT (powered by LinuxClub) Advent Calendar 2025の次回担当はゆう(@luy869)さんです!