Ubuntu 26.04 LTSの導入(その4) UEFIセキュアブート用鍵の手動追加

MOK(Machine Owner Kye)による追加

MOK(Machine Owner Key)は、UbuntuのSecure Boot実装(shim)が用意している「利用者自身が追加の署名鍵をファームウェアに登録できる仕組み」です。

shimはファームウェアのdbとは別に、自分専用の信頼リスト(MokList)、失効リスト(MokListX)をNVRAMに保持しています。 ロードしようとしたバイナリがMicrosoft/Canonicalの署名で検証できない場合、shimは次にこのMOKリストを確認し、そこに登録された鍵で署名されていれば実行を許可します。

登録・管理ツール:mokutil

MOKの登録・管理は mokutil コマンドで行います。

  • 鍵の登録

    sudo mokutil --import my_signing_key.der

    実行するとパスワード(一時的なもの)の設定を求められます。

    • 重要な点:この登録はコマンド一発では完了しません。次回再起動時に、青い画面のMokManager(shimが起動時に呼び出す専用ツール)が自動的に立ち上がり、そこで先ほど設定したパスワードを入力して「Enroll MOK」を選ぶことで、初めてNVRAMに鍵が書き込まれます。これはファームウェアへの改ざんを防ぐための、ユーザー本人による物理的な確認ステップです。
  • 登録状況の確認

    mokutil --list-enrolled
  • 典型的な利用例(NVIDIAドライバ):DKMS経由でNVIDIAドライバをインストールすると、Ubuntuは自動的に一時鍵を生成してカーネルモジュールに署名し、mokutil --import に相当する処理を行った上で、再起動時にMokManager画面でのEnrollを促してくることがあります。ここで手続きを飛ばすとSecure Boot有効時にドライバがロードされず、フォールバック(nouveauなど)で起動してしまいます。


BIOS設定画面からファームウェアに追加

前回までの調査で、今回の導入先PCのファームウェアには2011・2023両方のMicrosoft証明書がすでにdb/KEKに登録済みで、追加の鍵追加なしにUbuntu/Windowsとも正常に起動することが確認済みです。この手順が必要となるのは、①ディストリのシステムを使わず自己署名した独自鍵で完全にカスタムなSecure Bootチェーンを組みたい場合、②PKやKEK自体を入れ替えたい場合、などになります。特にPK/KEKやdbからMicrosoftの証明書を削除・置換する操作は、Windows Boot Managerの検証にも影響するため、デュアルブート環境では「Windowsが起動しなくなるリスクがあります。このため、ファームウェアの「Restore Factory Keys」「Install Default Secure Boot Keys」で復元する(一番簡単で推奨)ことができない場合に実施してください。メーカーが出荷時に用意したdb/KEK/PKのセットが書き戻され、通常はここにMicrosoftの2011証明書(場合によっては2023証明書も)が含まれています。証明書ファイルを自分で用意する必要がなく、まずはこれを試すのが安全かつ確実です。

dbに証明書を追加するには、通常OS上からの認証済み書き込み(KEKの秘密鍵での署名が必要)が求められるが、ユーザー側にKEKの秘密鍵はないため、OS上から任意の証明書を追加することは基本的にできません。代わりに、ファームウェア(マザーボード)のUEFI Setup画面のCustomモードを使う方法があります。ASRock製のマザーボードを使用している場合、2011のMicrosoft証明書が導入されておらず導入する場合以下の手順で可能です。

  1. Microsoftの公開リポジトリから2011年版UEFI CA証明書(MicCorUEFCA2011_2011-06-27.crtファイル)を入手し、USBメモリまたはESP(EFIシステムパーティション)に配置する
  2. UEFI Setup → Security → Secure Boot → Secure Boot Mode を Custom に切り替える
  3. Key Management(または類似メニュー) → DB → Insert Signature のような項目から、USB上の証明書ファイルを選んで追加する

この操作はファームウェア自体のUIを通じて行うため、OS側の署名検証を経由せず、物理的にファームウェア設定にアクセスできる人による直接操作として許可されます。


前回までの話との関係

  • shim自体の信頼(Microsoft/Canonical署名) → ファームウェアのdb/KEKが管理する領域(前回話した2023年証明書移行の話はここに関係します)
  • shimより上位で動くサードパーティ製モジュールの信頼 → MOKが管理する領域

この2つは別レイヤーの話で、MOKを正しく登録してもshim自体がファームウェアに信頼されていなければ意味がなく、逆にshimが信頼されていてもMOKが空ならNVIDIAドライバなどは弾かれます。両方が揃って初めて「Secure Boot有効のまま、かつサードパーティドライバも動く」状態になります。