Unified Extensible Firmware Interface/セキュアブート

関連記事

• Arch ブートプロセス
• Unified Extensible Firmware Interface
• セキュリティ

セキュアブートとは、UEFI 規格に含まれているセキュリティ機能であり、プリブートプロセスに保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境をセキュアに保つ試みの一環、あるいはそれを補完するものであるとみなせます。システムの暗号化のような他のソフトウェアのセキュリティ対策では簡単にカバーできない攻撃面を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と短所を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

ノート: Linux におけるセキュアブートについてのより詳細な概要は、Rodsbooks' Secure Boot の記事と他のオンライン上のリソース を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。

セキュアブートの状態を確認する

OS の起動前

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 Esc、F2、Del のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

OS の起動後

systemd を使用するシステム上では、systemd-boot でセキュアブートの状態を簡単に確認できます:

ノート: 以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。

$ bootctl status
System:
     Firmware: UEFI 2.70 (American Megatrends 5.15)
  Secure Boot: enabled
   Setup Mode: user
 Boot into FW: supported
...

ここでは、セキュアブートが有効化され強制されていることがわかります。他に取りうる値は、"Secure Boot" は disabled、"Setup Mode" は setup です[1]。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が 1 となります。例えば:

6  0  0  0  1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

# dmesg | grep -i secure

[    0.013442] Secure boot disabled
[    0.013442] Secure boot could not be determined

セキュアブートが検出された場合、カーネルメッセージは Secure boot enabled となります。

インストールメディアを起動する

ノート: 公式の Arch インストールイメージはセキュアブートをサポートしていません (FS#53864)。Arch インストールメディアを起動するには、セキュアブートを無効化する必要があります。

Arch インストールメディアのセキュアブートサポートは archlinux-2013.07.01-dual.iso で初めて追加されました。しかし、その後 archlinux-2016.06.01-dual.iso で削除されました。その時、prebootloader は、未署名の EFI バイナリを使用する efitools に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

Archboot イメージはインストールメディアでセキュアブートを使用する手段を提供します。

セキュアブートを無効化する

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は #OS の起動前 で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。Rod Smith の Secure Boot 無効化に関する記事 も参照。

インストールイメージをリマスタリングする

インストール ISO をリマスタリングする必要があるかもしれません。例えば、#PreLoader の署名済み EFI アプリケーション PreLoader.efi と HashTool.efi が使えます。他の手段としては、セキュアブートをサポートする他の GNU+Linux ディストリビューションのインストールメディアから BOOTx64.EFI (shim) と grubx64.efi を拝借し、GRUB の設定を必要に応じて変更するというものがあります。この場合、セキュアブートの認証チェーンは grubx64.efi で途絶える必要があります Ubuntu の例)。そうすることで、GRUB は archiso の未署名のカーネルと initramfs を起動できます。気をつけるべきなのは、この時点でユーザがマシンの ESP にアクセス可能であると仮定していることです。しかし、OS の存在しないマシン上にインストールする際は、ESP が存在しません。この状況にどう対処すべきかは他の記事を参照してください (例えば Unified Extensible Firmware Interface#ISO から UEFI ブータブル USB を作成する)。

セキュアブートを実現する

セキュアブートの理想的なセットアップを実現するにはいくつか条件があります:

1. UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた批判と脆弱性[2]がある)、必ず強力なパスワードで保護されていること。
2. メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[3]
3. セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 EFISTUB カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
4. マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、ドライブの完全暗号化を使用すること。
5. TPM を使うことでさらに改善することができるかもしれませんが、ツールやサポートの問題がこれを難しくしています。

シンプルかつ完全に自立したセットアップは #自分の鍵を使う で説明されています。一方、#署名済みのブートローダを使う では、サードパーティにより署名された中間ツールを使用します。

自分の鍵を使う

警告: プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するために UEFI/BIOS の設定画面に入ることが不可能になります。これは、一部のデバイス(GPU など)の、起動中に実行されるファームウェア(OpROMs)が、Microsoft の鍵を使って署名されているためです。

セキュアブートでは以下の鍵が使われます:

Platform Key (PK)

トップレベル鍵

Key Exchange Key (KEK)

Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵

Signature Database (db)

EFI バイナリに署名するのに使われる鍵やハッシュが含まれます

Forbidden Signatures Database (dbx)

EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は The Meaning of all the UEFI Keys を見てください。

セキュアブートをを使用するには最低でも PK, KEK, db 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (sign-efi-sig-list を使用)。Platform key は自分自身で署名することができます。

efitools をインストールする

以下のほぼ全てのセクションで、efitools パッケージがインストールされている必要があります。

現在の変数をバックアップする

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、以下のコマンドを実行してください:

$ efi-readvar -v PK -o old_PK.esl
$ efi-readvar -v KEK -o old_KEK.esl
$ efi-readvar -v db -o old_db.esl
$ efi-readvar -v dbx -o old_dbx.esl

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

鍵を作成する

手動による手順

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

.key

EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の秘密鍵。

.crt

sbsign(1)、sbvarsign(1)、sign-efi-sig-list(1) で必要な PEM 形式の証明書。

.cer

ファームウェアが使用する DER 形式の証明書。

.esl

sbvarsign(1) や efi-updatevar(1)、KeyTool、ファームウェアのための EFI 署名リストの証明書。

.auth

efi-updatevar(1) や sbkeysync、KeyTool、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する GUID を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Platform Key/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null rm_PK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Key Exchange Key/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "/CN=my Signature Database key/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

ヘルパースクリプト

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[4](python が必要です)。簡単に編集されたバージョンも sbkeys^AUR としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で sbupdate-git^AUR を使って unified カーネルイメージを作成し署名する予定なのであれば /etc/efi-keys/)、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
<鍵に埋め込む Common Name を入力(例: "Secure Boot")>

これは様々な形式で必要なファイルを生成します。

鍵をアップデートする

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

1. 新しい鍵を作成
2. EFI 署名リストに変換
3. EFI 署名リストに署名
4. 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" new_db.crt new_db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db new_db.esl new_db.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を追加したい場合、-a オプションを使う必要があります (sign-efi-sig-list(1) を参照):

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db new_db.esl new_db.auth

new_db.auth が作成されたら登録してください。

EFI バイナリに署名する

セキュアブートを有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、ドライバ、Unified カーネルイメージ)しか起動できなくなります。

sbsigntools を使って手動で行う

sbsigntools をインストールして、sbsign(1) で EFI バイナリに署名してください。

ヒント:

• バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: $ sbverify --list /path/to/binary。
• rEFInd ブートマネージャの refind-install スクリプトで rEFInd EFI バイナリを署名し、ESP へ db 証明書と一緒にコピーできます。手順は rEFInd#自分の鍵を使う を見てください。

ノート: sbsign を --output 無しで実行すると、出力されるファイルは filename.signed となります。詳細は sbsign(1) を見てください。

カーネルとブートマネージャに署名するには、sbsign を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output esp/EFI/BOOT/BOOTx64.EFI esp/EFI/BOOT/BOOTx64.EFI

警告: カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。sbsign で手動で署名できる結合イメージを生成する方法は Unified カーネルイメージ を見てください。

pacman フックでカーネルに署名する

mkinitcpio の pacman フックを使って、インストール時とアップデート時にカーネルに署名することもできます。

/usr/share/libalpm/hooks/90-mkinitcpio-install.hook を /etc/pacman.d/hooks/90-mkinitcpio-install.hook に、/usr/share/libalpm/scripts/mkinitcpio-install を /usr/local/share/libalpm/scripts/mkinitcpio-install にコピーしてください。

/etc/pacman.d/hooks/90-mkinitcpio-install.hook 内の

Exec = /usr/share/libalpm/scripts/mkinitcpio-install

を

Exec = /usr/local/share/libalpm/scripts/mkinitcpio-install

に置き換えてください。

/usr/local/share/libalpm/scripts/mkinitcpio-install 内の

install -Dm644 "${line}" "/boot/vmlinuz-${pkgbase}"

を

sbsign --key /path/to/db.key --cert /path/to/db.crt --output "/boot/vmlinuz-${pkgbase}" "${line}"

に置き換えてください。

systemd-boot を使用している場合、この作業を半自動的に行う専用の pacman フックが存在します。

sbupdate による完全に自動化された unified カーネルの生成と署名

sbupdate は、Arch Linux で unified カーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、pacman フックを通してカーネルのインストール・削除・アップデートを処理します。

sbupdate-git^AUR をインストールして、プロジェクトのホームページにある手順に従って設定してください。[5]

ヒント: systemd-boot を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために OUT_DIR="EFI/Linux" を設定してください。systemd-boot(7) § FILES と Systemd-boot#ローダーの追加 を参照してください。

設定したら、イメージを生成するために sbupdate を root として実行してください。

ノート: sbupdate の出力にはしばしばエラーを含んでいます(例えば warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?)。これらは無害で、安全に無視できます。[6]

ファームウェアを "Setup Mode" にする

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は #OS の起動前 で説明されています。

ファームウェアに鍵を登録する

db、KEK、PK 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

ヒント: dbx (forbidden signatures db) は空なので、以下の手順では省いても安全です。

警告: Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。

sbkeysync を使う

sbsigntools をインストールしてください。そして、以下のディレクトリ構造を持つ /etc/secureboot/keys ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した .auth ファイルをそれぞれの場所にコピーしてください(例えば、PK.auth は /etc/secureboot/keys/PK へといった感じです)。

sbkeysync がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --pk --dry-run --verbose

最後に、sbkeysync を使って鍵を登録してください。

# sbkeysync --verbose
# sbkeysync --verbose --pk

ヒント:

• sbkeysync で書き込みエラーが発生した場合、sbkeysync のコマンドの前にまず chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}* を実行して、ファイルの属性を一時的に変更してください。これで、efivars ディレクトリ内の EFI 鍵を書き込むことができます。chattr(1) を参照してください。
• PK.auth で permission denied エラーが発生する場合、次のコマンドでその鍵を登録できます: efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

ファームウェアのセットアップユーティリティを使う

FAT でフォーマットされたファイルシステム(EFI システムパーティション が使えます)に noPK.auth を除いて *.cer、*.esl、*.auth をすべてコピーしてください。

警告: noPK.auth を EFI システムパーティション (ESP) にコピーしないでください! そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が noPK.auth ファイルにアクセスできないようにするべきなのです。以上の理由から、noPK.auth ファイルは、あなただけがアクセスできる安全な場所に保管してください。noPK.auth ファイルの保管場所として安全なのは:

• KeyTool を使用している場合は、EFI システムパーティションのある外部 USB スティック。残念ながら、KeyTool は、暗号化されていないストレージからしかファイルを読み出すことができません。
• sbkeysync を使っている場合は、PC 上の暗号化されているストレージ。

UEFI 仕様に従って PC 上の EFI システムパーティションは暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、noPK.auth ファイルをあなたの PC の ESP にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の EFI システムパーティション上で削除されたファイルは、PhotoRec のようなツールで復元できてしまうからです。

ファームウェアのセットアップユーティリティを起動し、db、KEK、PK 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は Replacing Keys Using Your Firmware's Setup Utility を見てください。

使用するツールがサポートしていれば、.cer よりも .auth と .esl を使用することを推奨します。

KeyTool を使う

KeyTool.efi は efitools パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、sbsign で署名してください。

# sbsign --key db.key --cert db.crt --output esp/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか UEFI シェルを使って KeyTool-signed.efi を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は Replacing Keys Using KeyTool を見てください。

他のオペレーティングシステムとデュアルブートする

Microsoft Windows

Windows のデュアルブートをするには、Microsoft の証明書を Signature Database に追加する必要があります。Microsoft は2つの db 証明書を用意しています:

• Microsoft Windows Production PCA 2011 (Windows 用)
• Microsoft Corporation UEFI CA 2011 (UEFI ドライバーやオプション ROM などサードパーティ製のバイナリ用)

Microsoft の GUID (77fa9abd-0359-4d32-bd60-28f4e78f784b) を使って EFI 署名リストを作成してひとつのファイルにまとめます:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db.esl MicCorUEFCA2011_2011-06-27.crt
$ cat MS_Win_db.esl MS_UEFI_db.esl > MS_db.esl

KEK を使って db アップデートに署名してください。sign-efi-sig-list に -a オプションを付けて db 証明書を追加します(置き換えるのではありません):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

#ファームウェアに鍵を登録するに従って add_MS_db.auth を Signature Database に追加してください。

署名済みのブートローダを使う

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常のブートローダー) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

警告: Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011) が登録されていません。[7]。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。

PreLoader

起動時に PreLoader は loader.efi を実行しようとします。MokList に loader.efi のハッシュが存在しない場合、PreLoader は HashTool.efi を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまりブートローダー (loader.efi) とカーネルを登録する必要があります。

ノート: バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。

ヒント: rEFInd ブートマネージャの refind-install スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は rEFInd#PreLoader を使う を見てください。

PreLoader をセットアップする

ノート: efitools パッケージに含まれている PreLoader.efi と HashTool.efi は署名されていないため、使い道は限られています。署名済みの PreLoader.efi と HashTool.efi を入手するには preloader-signed^AUR をインストールするか 手動でダウンロード します。

preloader-signed^AUR パッケージをインストールして PreLoader.efi と HashTool.efi をブートローダーのディレクトリにコピーしてください。systemd-boot の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi esp/EFI/systemd

そしてブートローダーのバイナリをコピーして loader.efi に名前を変更します。systemd-boot の場合、以下を実行:

# cp esp/EFI/systemd/systemd-bootx64.efi esp/EFI/systemd/loader.efi

最後に、PreLoader.efi を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sdX --part Y --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

X は EFI システムパーティションのドライブ文字に、Y は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。efibootmgr コマンドで確認して、必要であればブートローダーの設定を変更してください。

フォールバック

カスタム NVRAM エントリの起動に問題が発生する場合、HashTool.efi と loader.efi を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi esp/EFI/BOOT/
# cp esp/EFI/systemd/systemd-bootx64.efi esp/EFI/BOOT/loader.efi

PreLoader.efi をコピーして名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi esp/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、PreLoader.efi を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p esp/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi esp/EFI/Microsoft/Boot/bootmgfw.efi

ノート: Windows とデュアルブートする場合、元の bootmgfw.efi はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。

上と同じように、HashTool.efi と loader.efi を esp/EFI/Microsoft/Boot にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って loader.efi と /vmlinuz-linux (あるいは使用している他のカーネルイメージ) を登録します。

起動途中で使用するには?

Failed to Start loader... I will now execute HashTool. というメッセージが表示されるでしょう。loader.efi と vmlinuz.efi のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

• OK を選択してください
• HashTool のメインメニューで、Enroll Hash を選択し、\loader.efi を選んで Yes で確定してください。再び Enroll Hash と archiso を選択し archiso のディレクトリに入って、vmlinuz.efi を選択し、Yes で確定してください。そして、Exit を選択してブートデバイスの選択メニューに戻ってください。
• ブートデバイスの選択メニューで、Arch Linux archiso x86_64 UEFI CD を選んでください。

PreLoader を除去する

ノート: 以下を実行する前にバックアップを作成すると良いでしょう。

preloader-signed^AUR をアンインストールし、コピーしたファイルを削除して、設定を元に戻します。systemd-boot の場合、以下を実行:

# rm esp/EFI/systemd/{PreLoader,HashTool}.efi
# rm esp/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum N --delete-bootnum
# bootctl update

N は PreLoader.efi を起動するために作成した NVRAM のブートエントリに置き換えてください。efibootmgr コマンドで確認を行なって、必要に応じてブート順序を修正してください。

ノート: 上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに#セキュアブートを無効化する必要もあります。

登録したハッシュを削除する

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

efitools をインストールし、KeyTool.efi をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi esp/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

shim

起動時に shim は grubx64.efi を実行しようとします。MokList に grubx64.efi のハッシュあるいは署名鍵が存在しない場合、shim は mmx64.efi を起動します。MokManager で起動したい EFI バイナリ (ブートローダー (grubx64.efi) とカーネル) のハッシュか署名鍵を登録する必要があります。

ノート:

• #shim でハッシュを使う を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
• バージョン 15.3 以降、shim は、有効な .sbat セクションが無いと EFI バイナリを起動しません。EFI バイナリが .sbat セクションを持っているか確認するには、objdump -j .sbat -s /path/to/binary.efi を実行してください。詳細は SBAT ドキュメント を見てください。
• セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、mokutil --disable-validation で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の chainloader で Windows を起動することができます。

shim をセットアップする

ヒント: rEFInd ブートマネージャの refind-install スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は rEFInd#shim を使う を見てください。

shim-signed^AUR をインストールしてください。

現在のブートローダーの名前を grubx64.efi に変更してください:

# mv esp/EFI/BOOT/BOOTx64.EFI esp/EFI/BOOT/grubx64.efi

shim と MokManager を ESP 上のブートローダーのディレクトリにコピーしてください; shimx64.efi はブートローダの以前のファイル名を使ってください:

ノート:

• 有効な bootx64.csv が存在しない限り、fbx64.efi (同じディレクトリ内にあります)はコピーしないでください。さもないと、shim は grubx64.efi を実行せず、動作に失敗してマシンをリセットします。

# cp /usr/share/shim-signed/shimx64.efi esp/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi esp/EFI/BOOT/

最後に、BOOTx64.EFI を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sdX --part Y --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

shim は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

Machine Owner Key (MOK)

EFI バイナリに署名するためにユーザが生成し利用する鍵

hash

EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

shim でハッシュを使う

shim は、MokList に grubx64.efi の SHA256 ハッシュが存在しない場合、mmx64.efi を起動します。

MokManager で Enroll hash from disk を選択してから grubx64.efi を探して MokList に追加してください。同じようにカーネルの vmlinuz-linux も追加してください。完了したら Continue boot を選択してください。ブートローダーが起動してカーネルが起動します。

shim で鍵を使う

sbsigntools をインストールしてください。

以下のファイルが必要です:

.key

EFI バイナリに署名するための PEM 形式の秘密鍵。

.crt

sbsign で使うための PEM 形式の証明書。

.cer

MokManager で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:4096 -nodes -keyout MOK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Machine Owner Key/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

(grubx64.efi という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output esp/EFI/BOOT/grubx64.efi esp/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は pacman フック で自動化できます。例えば:

/etc/pacman.d/hooks/999-sign_kernel_for_secureboot.hook

[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = linux
Target = linux-lts
Target = linux-hardened
Target = linux-zen

[Action]
Description = Signing kernel with Machine Owner Key for Secure Boot
When = PostTransaction
Exec = /usr/bin/find /boot/ -maxdepth 1 -name 'vmlinuz-*' -exec /usr/bin/sh -c 'if ! /usr/bin/sbverify --list {} 2>/dev/null | /usr/bin/grep -q "signature certificates"; then /usr/bin/sbsign --key MOK.key --cert MOK.crt --output {} {}; fi' ;
Depends = sbsigntools
Depends = findutils
Depends = grep

MOK.cer を FAT でフォーマットされたファイルシステムにコピーしてください (EFI システムパーティション を使うことができます)。

再起動してセキュアブートを有効にしてください。shim は MokList に grubx64.efi を署名するときに使った証明書がない場合、mmx64.efi を起動します。

MokManager で Enroll key from disk を選択してから MOK.cer を探して MokList に追加してください。完了したら Continue boot を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

shim で鍵と GRUB を使う

GRUB は、必要なモジュールがすべて GRUB の EFI バイナリに含められている 場合に 限り、セキュアブートモードで起動することができます。

GRUB バージョン 2.06.r261.g2f4430cc0 以降、insmod を用いたセキュアブートモードのサイドロードは もはや許可されません。GRUB のモジュールが GRUB の EFI バイナリに組み込まれていない場合、GRUB はそれらのモージュルをサイドロード (すなわち insmod) しようと試みます。しかし、GRUB は次のメッセージで起動に失敗するでしょう:

error: prohibited by secure boot policy

GRUB の EFI バイナリは、必須のモジュールと共にリビルドし、署名する必要があります。 GRUB は、Linux カーネルと initramfs のあるディスクまたはパーティションを読み込み/復号/アクセスするのに必要なモジュールすべてが GRUB の EFI バイナリに含まれている場合に限り、Linux カーネルと initramfs をブートすることができます。

Ubuntuは、公式のビルドスクリプトによると、以下の GRUB モジュールを GRUB EFI バイナリ grubx64.efi に組み込んでいます:

• (CD やシンプルにパーティショニングされたディスクから起動するために必要な) 「基本的な」モジュールについては、ビルドスクリプトの 87 行目を見てください:

CD_MODULES="
	all_video
	boot
	btrfs
	cat
	chain
	configfile
	echo
	efifwsetup
	efinet
	ext2
	fat
	font
	gettext
	gfxmenu
	gfxterm
	gfxterm_background
	gzio
	halt
	help
	hfsplus
	iso9660
	jpeg
	keystatus
	loadenv
	loopback
	linux
	ls
	lsefi
	lsefimmap
	lsefisystab
	lssal
	memdisk
	minicmd
	normal
	ntfs
	part_apple
	part_msdos
	part_gpt
	password_pbkdf2
	png
	probe
	reboot
	regexp
	search
	search_fs_uuid
	search_fs_file
	search_label
	sleep
	smbios
	squash4
	test
	true
	video
	xfs
	zfs
	zfscrypt
	zfsinfo
	"

• x86_64-efi アーキテクチャ向けの「プラットフォーム固有」のモジュールは、ビルドスクリプトの 147 行目を見てください。そのようなモジュールは、例えば、以下のような用途に必要です:
  • 起動中に音を鳴らす: play
  • 起動中に CPU を特定する: cpuid
  • UEFI ブート: linuxefi
  • Measured Boot / Trusted Platform Module: tpm

CD_MODULES="$CD_MODULES
	cpuid
	linuxefi
	play
	tpm
	"

• 「高度」なモジュールについては、ビルドスクリプトの 159 行目 を見てください。以下のモジュールから成ります:
  • plain モードで暗号化されたディスクから起動する: cryptodisk
  • すべてのハッシュ、暗号化アルゴリズム: gcry_...
  • LUKS で暗号化されたディスクから起動する: luks
  • LVM 論理ボリュームディスクから起動する: lvm
  • RAID 仮想ディスクから起動する: mdraid09, mdraid1x, raid5rec, raid6rec

GRUB_MODULES="$CD_MODULES
	cryptodisk
	gcry_arcfour
	gcry_blowfish
	gcry_camellia
	gcry_cast5
	gcry_crc
	gcry_des
	gcry_dsa
	gcry_idea
	gcry_md4
	gcry_md5
	gcry_rfc2268
	gcry_rijndael
	gcry_rmd160
	gcry_rsa
	gcry_seed
	gcry_serpent
	gcry_sha1
	gcry_sha256
	gcry_sha512
	gcry_tiger
	gcry_twofish
	gcry_whirlpool
	luks
	lvm
	mdraid09
	mdraid1x
	raid5rec
	raid6rec
	"

あなたの Arch Linux セットアップで必要な GRUB モジュールをすべて見つけてください。 安全のために、上記のモジュールをすべて含めることもできます。 GRUB のブートプロセスを高速化したい場合や、ESP パーティションのスペースを節約したい場合は、必要ないモジュールを排除してください。 GRUB_MODULES のリストを変数として指定しコンパイルしたら、以下を続けてください:

Secure Boot Advanced Targeting (SBAT) ファイル/セクションも GRUB の EFI バイナリに含める必要があります。これは、GRUB が UEFI shim ローダーから起動される場合にセキュリティを向上するのに役立ちます。

この SBAT ファイル/セクションには、GRUB バイナリに関するメタデータ (バージョン、メンテナ、開発者、上流の URL) が含まれており、脆弱性のある特定の GRUB バージョンのロードを shim がブロックするのを容易にします [8][9]。これは、shim の UEFI shim bootloader secure boot life-cycle improvements ドキュメントで説明されています。

第一段階の UEFI ブートローダーである shim は、SBAT セクションが grubx64.efi に存在しない場合、grubx64.efi の起動に失敗します。

GRUB がインストールされている場合、シンプルな SBAT .csv ファイルが /usr/share/grub/sbat.csv に提供されています。

提供されている /usr/share/grub/sbat.csv ファイルと 必要な GRUB_MODULES を用いて GRUB を再インストールし、それを署名してください:

# grub-install --target=x86_64-efi --efi-directory=esp --modules=${GRUB_MODULES} --sbat /usr/share/grub/sbat.csv
# sbsign --key MOK.key --cert MOK.crt --output esp/EFI/GRUB/grubx64.efi esp/EFI/GRUB/grubx64.efi
# cp esp/GRUB/grubx64.efi esp/boot/grubx64.efi

再起動し、MokManager で鍵を選択してください。セキュアブートが機能するようになるはずです。

shim を除去する

shim-signed^AUR をアンインストールして、コピーした shim と MokManager のファイルを削除してブートローダーを元の名前に戻してください。

セキュアブートを保護する

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

ヒントとテクニック

sbctl

sbctl は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

ノート: sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。

キーを作成・登録する

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを Setup mode にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

警告: 一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、# sbctl enroll-keys を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートをは動作しません。

署名する

セキュアブートのためにどのファイルを署名する必要があるか確認してください:

# sbctl verify

次に、それらの署名されていないファイルをすべて署名してください。通常、カーネルとブートローダーを署名する必要があります。例えば:

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名すべきファイルは、あなたのシステムの構成、カーネル、ブートローダに依存します。

これで終わりです。システムを再起動し、ファームウェアの設定画面でセキュアブートをオンに戻してください。ブートローダーと OS がロードされれば、セキュアブートが機能しているはずです。確認するには:

$ sbctl status

pacman フックを使って自動的に署名する

sbctl には、Linux カーネル、systemd、ブートローダーがアップデートされたときに自動的にすべての新規ファイルを署名する pacman フックが同梱されています。

ヒント: Systemd-boot と systemd-boot-update.service を使用している場合、ブートローダーは再起動後にしかアップデートされないので、sbctl の pacman フックはその新しいファイルを署名しません。回避策としては、/usr/lib/ 内のブートローダーを直接署名すると良いかもしれません。bootctl install と update は自動的に、通常の .efi ではなく .efi.signed ファイルを認識し、ESP にコピーします。bootctl(1) を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

公式の ISO をカスタムの鍵で署名する

ブートローダー (BOOTx64.EFI と BOOTIA32.EFI)、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

libisoburn、mtools、sbsigntools をインストールしてください。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

$ osirrox -indev archlinux-YYYY.MM.DD-x86_64.iso \
	-extract_boot_images ./ \
	-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
	-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
	-extract /shellx64.efi shellx64.efi \
	-extract /shellia32.efi shellia32.efi \
	-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux

mkarchiso によって使用されている xorrisofs(1) のオプション -rational-rock は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

登録されている db 鍵と証明書を使ってファイルを署名してください:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

ブートローダーと UEFI シェルを eltorito_img2_uefi.img にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。eltorito_img2_uefi.img のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために mkarchiso によって 1 MiB の空き領域が追加されています。なので、シグネチャによるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名されたブートローダーのファイル、UEFI シェル、カーネルを ISO 9660 に追加してください:

$ xorriso -indev archlinux-YYYY.MM.DD-x86_64.iso \
	-outdev archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso \
	-boot_image any replay \
	-append_partition 2 0xef eltorito_img2_uefi.img \
	-map BOOTx64.EFI /EFI/BOOT/BOOTx64.EFI \
	-map BOOTIA32.EFI /EFI/BOOT/BOOTIA32.EFI \
	-map shellx64.efi /shellx64.efi \
	-map shellia32.efi /shellia32.efi \
	-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux

完成した archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso を起動してみてください。

参照

• Understanding the UEFI Secure Boot Chain by tianocore
• Wikipedia:Unified Extensible Firmware Interface#Secure boot
• Dealing with Secure Boot by Rod Smith
• Controlling Secure Boot by Rod Smith
• UEFI secure booting (part 2) by Matthew Garrett
• UEFI Secure Boot by James Bottomley
• efitools README
• Will your computer's "Secure Boot" turn out to be "Restricted Boot"? — Free Software Foundation
• Free Software Foundation recommendations for free operating system distributions considering Secure Boot
• Intel's UEFI Secure Boot Tutorial
• Secure Boot, Signed Modules and Signed ELF Binaries
• 国家安全保障局のドキュメント: UEFI Defensive Practices Guidance と機密を解かれたUEFI Secure Boot customization
• sbkeysync & maintaining uefi key databases by Jeremy Kerr
• Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux (2020-07)
• How is hibernation supported, on machines with UEFI Secure Boot? (Security StackExchange)
• Authenticated Boot and Disk Encryption on Linux by Lennart Poettering (2021-09-23)