ArchWiki - 利用者の投稿記録 [ja]

ユニファイドカーネルイメージ

2026-03-12T03:01:00Z

ELC: /* mkinitcpio */ スクリプトを簡略化

[[Category:ブートローダー]]
[[en:Unified kernel image]]
[[pt:Unified kernel image]]
[https://uapi-group.org/specifications/specs/unified_kernel_image ユニファイドカーネルイメージ] (UKI) は、単一の実行可能ファイルであり、[[UEFI]] ファームウェアから直接起動するか、ほとんどまたは全く設定を必要とせずにブートローダーによって自動的に取得されます。これは {{man|7|systemd-stub}} のような UEFI ブートスタブプログラム、Linux [[Arch ブートプロセス#カーネル|カーネルイメージ]]、[[Arch ブートプロセス#initramfs|initrd]]、および [https://uapi-group.org/specifications/specs/unified_kernel_image/#uki-components その他のリソース] を単一の UEFI PE ファイルに組み合わせたものです。

このファイルは、したがってこれらのすべての要素を[[Unified Extensible Firmware Interface/セキュアブート# EFI バイナリに署名する|署名]]して [[Secure Boot]] で使用することが容易になります。

{{Note|記事全体で {{ic|''esp''}} は [[EFI システムパーティション]] のマウントポイントを表します。}}

== ユニファイドカーネルイメージの準備 ==

UKI (Unified Kernel Image) イメージを生成し、適切な場所 ("esp/Linux" ディレクトリ) にインストールする方法はいくつかあります。現在、この機能を実行するためのツールがいくつか競合しているので、ニーズと好みに応じて以下のいずれかを選択してください。

{{Note|
* 以下のいずれかのサブセクションを実行するだけで済みます。
* UKI を [[Unified Extensible Firmware Interface#Default boot path for removable drives|フォールバックブートパス]] {{ic|''esp''/EFI/BOOT/BOOTx64.EFI}} (または 32 ビット IA32 UEFI の場合は {{ic|BOOTIA32.EFI}}) に配置することも可能です。フォールバックブートパスを使用すると、NVRAM に UEFI ブートエントリを明示的に作成する必要がなくなります。
}}

=== mkinitcpio ===

[[mkinitcpio]] は、{{Pkg|systemd-ukify}} がインストールされていない限り、UKI (Unified Kernel Image) を自身で組み立てます。{{Pkg|systemd-ukify}} がインストールされている場合は、{{ic|--no-ukify}} オプションで明示的に無効にしない限り、UKI の作成は "ukify" にオフロードされます。

==== カーネルコマンドライン ====

[[mkinitcpio]] は、{{ic|/etc/cmdline.d}} ディレクトリ内のコマンドラインファイルからの[[カーネルパラメータ]]の読み取りをサポートします。Mkinitcpio は、このディレクトリ内の {{ic|.conf}} 拡張子を持つすべてのファイルの内容を連結し、それらを使用してカーネルコマンドラインを生成します。コマンドラインファイル内の ''#'' 文字で始まる行はコメントとして扱われ、mkinitcpio によって無視されます。マイクロコードと initramfs を指す ''エントリを削除'' するように注意してください。

例:

{{hc|/etc/cmdline.d/root.conf|2=
root=UUID=0a3407de-014b-458b-b5c1-848e92a327a3 rw
}}

{{Tip|
* ルートファイルシステムがデフォルト以外の Btrfs サブボリューム上にある場合は、必ず必要なマウントフラグを {{ic|rootflags}} に設定してください。[[Btrfs#サブボリュームをルートとしてマウントする]] を参照してください。
* たとえば、システムのサブボリューム ID が {{ic|256}} の場合 (サブボリューム ID は、{{ic|btrfs subvolume list ''btrfs_mountpoint''}} を使用して確認できます。または、{{ic|/etc/fstab}}) でフラグを見ることができます、カーネルコマンドラインに {{ic|1=rootflags=subvolid=256}} を追加する必要があります。
* {{ic|rootflags}} は起動時にのみ使用されるため、{{ic|/etc/fstab}} 内のすべてのフラグをコピーする必要はありません。Systemd は fstab を読み取り、再マウントし、ブート後にそこにリストされているフラグを自動的に適用します。
}}

{{hc|/etc/cmdline.d/security.conf|2=
# enable apparmor
lsm=landlock,lockdown,yama,integrity,apparmor,bpf audit=1 audit_backlog_limit=256
}}

あるいは、{{ic|/etc/kernel/cmdline}} を使用してカーネルコマンドラインを設定することもできます。

例:

{{hc|/etc/kernel/cmdline|2=
root=UUID=0a3407de-014b-458b-b5c1-848e92a327a3 rw quiet bgrt_disable
}}

{{Tip|
* root パーティションが [[systemd#GPT パーティションの自動マウント|systemd によって自動マウントされる]] 場合、{{ic|1=root=}} パラメータは省略できます。
* {{ic|bgrt_disable}} パラメータは、ACPI テーブルのロード後に OEM ロゴを表示しないように Linux に指示します。
}}

==== .preset ファイル ====

次に、{{ic|/etc/mkinitcpio.d/linux.preset}}、または使用しているプリセットを、[[EFI システムパーティション]] の適切なマウントポイントを指定して、以下のように変更します:

* {{ic|1=PRESETS=}} の各項目について、{{ic|1=''PRESET''_uki=}} パラメータのコメントを解除する (つまり {{ic|#}} を削除する)、
* 冗長な {{ic|initramfs-*.img}} ファイルを保存しないように、{{ic|1=''PRESET''_image=}} をコメントアウトする、
* オプションとして、スプラッシュイメージを追加したい各 {{ic|1=''PRESET''_options=}} 行に {{ic|--splash}} パラメータを追加またはコメント解除します。

以下は {{Pkg|linux}} カーネルと Arch スプラッシュスクリーンの {{ic|linux.preset}} の例です。

{{hc|/etc/mkinitcpio.d/linux.preset|2=
# mkinitcpio preset file for the 'linux' package

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
#default_image="/boot/initramfs-linux.img"
default_uki="''esp''/EFI/Linux/arch-linux.efi"
default_options="--splash=/usr/share/systemd/bootctl/splash-arch.bmp"

#fallback_config="/etc/mkinitcpio.conf"
#fallback_image="/boot/initramfs-linux-fallback.img"
fallback_uki="''esp''/EFI/Linux/arch-linux-fallback.efi"
fallback_options="-S autodetect"
}}

{{Tip|
* 統一されたカーネルイメージからブートしたいだけであれば、[[EFI システムパーティション#典型的なマウントポイント|ESP のマウント]]を {{ic|/efi}} にして、[[ESP]] パーティションに存在する必要があるものだけをマウントすることができます。
* {{ic|--cmdline /etc/kernel/''fallback_cmdline''}} を {{ic|fallback_options}} に追加することで、フォールバックイメージに上記とは異なる [[Unified カーネルイメージ#カーネルコマンドライン|cmdline]] を使用することができます (例えば {{ic|quiet}} を無くす。)
* カーネルコマンドラインの埋め込みを省略するには、{{ic|--no-cmdline}} を {{ic|1=''PRESET''_options=}} に追加してください。カーネルパラメーターはブートローダー経由で渡す必要があります。
}}

{{Note|
* {{ic|''PRESET''_uki}} オプションは以前は {{ic|''PRESET''_efi_image}} として知られていました。[https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/134 2022 年 11 月変更], 古いオプションは非推奨ですが、今のところ動作しています。
* [[Unified Extensible Firmware Interface# UEFI ファームウェアのビット数|IA32 UEFI]] では、{{ic|--uefistub /usr/lib/systemd/boot/efi/linuxia32.efi.stub}} を {{ic|1=''PRESET''_options=}} に追加してください。
}}

==== pacman フック ====

systemd-stub ({{pkg|systemd}} の一部)、microcode ({{pkg|intel-ucode}} と {{pkg|amd-ucode}} の両方)、および {{pkg|linux}} カーネルの更新は、自動的に UKI (Unified Kernel Image) の再構築をトリガーします。ただし、{{ic|/etc/pacman.d/hooks/}} ディレクトリにある他の [[pacman フック]] (例えば、[[NVIDIA#pacman hook|NVIDIA ドライバー]] のものなど) を確認することをお勧めします。

==== UKI の構築 ====

最後に、UKI のディレクトリが存在することを確認し、[[mkinitcpio#イメージ作成とアクティベーション|initramfs を再生成]] します。たとえば、''linux'' プリセットの場合は次のようになります。

# mkdir -p ''esp''/EFI/Linux
# mkinitcpio -p linux

必要に応じて、残っている {{ic|initramfs-*.img}} を {{ic|/boot}} または {{ic|/efi}} から削除します。

=== kernel-install ===

確実に kernel-install が [[Kernel-install#自動で|正しく設定されている]] ことを確認してください。

UKI を生成するには、{{Pkg|systemd-ukify}} をインストールし、{{ic|kernel-install}} の layout を {{ic|uki}} に設定します。

{{hc|/etc/kernel/install.conf|
2=layout=uki}}

{{Note|[[mkinitcpio]] が initrd を作成し、その後 [[#ukify]] が UKI を生成します。}}

[[#ukify]] の設定は、[[kernel-install]] で使用するために、{{ic|/etc/kernel/uki.conf}} で行う必要があります。例:

{{hc|/etc/kernel/uki.conf|
2=[UKI]
Splash=/usr/share/systemd/bootctl/splash-arch.bmp
}}

{{Tip|{{ic|/usr/lib/kernel/uki.conf}} から {{ic|/etc/kernel/uki.conf}} にテンプレートをコピーし、セクションタイトルと役立つ行をコメントアウトすることもできます。このファイルにカーネルコマンドラインを設定しないでください。無視されます。[[Kernel-install#カーネルコマンドライン]] を使用してください。}}

あるいは、mkinitcpio が UKI を生成するように、それをデフォルトの {{ic|uki_generator}} として設定します。

{{hc|/etc/kernel/install.conf|
2=layout=uki
uki_generator=mkinitcpio}}

この場合、{{Pkg|systemd-ukify}} は不要です。別の {{ic|initrd_generator}} を設定することもできます。{{Man|8|kernel-install}} を参照してください。

変更を有効にするには、使用しているカーネルパッケージを再インストールしてください。

=== dracut ===

こちらを参照して下さい [[dracut#ユニファイドカーネルイメージ]] と [[dracut#カーネルのアップグレード時に新しい initramfs を生成]]

=== ukify ===

{{Pkg|systemd-ukify}} パッケージを [[インストール]] します。''ukify'' は単独で initramfs を生成できないため、必要な場合は、[[dracut]]、[[mkinitcpio]]、または [[booster]] を使用して生成する必要があります。

最小限の動作例は次のようになります。

# ukify build --linux=''/boot/vmlinuz-linux'' \
--initrd=''/boot/initramfs-linux.img'' \
--cmdline="''quiet rw''"

{{Note|[[マイクロコード#早期ロード|外部マイクロコード initramfs イメージ]] を使用する場合 ({{ic|/boot/amd-ucode.img}} または {{ic|/boot/intel-ucode.img}}) を使用する必要があります。常にメインの initramfs イメージの前に ''最初に'' 配置します (例: {{ic|/boot/initramfs-linux.img}})}}

{{Tip|
* 出来上がった EFI 実行ファイルを EFI システムパーティションにコピーするのをスキップするには、{{ic|1=--output=''esp''/EFI/Linux/''filename''.efi}} コマンドラインオプションを ''ukify'' に使用します。
* {{ic|--cmdline}} オプションを指定する場合、{{ic|1=--cmdline=@''/path/to/cmdline''}} のように {{ic|/etc/kernel/cmdline}} ファイル名の前に {{ic|@}} シンボルを追加することで、カーネルパラメータを読み込むファイル名を指定できます。
}}

詳細については、{{man|1|ukify}}を参照してください。

intel ucode および /efi マウント ESP を使用した通常のカーネルイメージの systemd サービスを使用した自動 UKI 構築の例:

{{Note|カーネル、マイクロコード、または initramfs が変更されたときに UKI が自動的に更新されるようにするには、例えば [[kernel-install]] や [[mkinitcpio]] と共に ukify を使用するだけです。詳細については、上記のセクション [[#kernel-install]] および [[#mkinitcpio]] を参照してください。}}

=== 手動で ===

使用するカーネルコマンドラインをファイルに記述し、{{man|1|objcopy}} を使用してバンドルファイルを作成します。

[[マイクロコード]] の場合は、まず次のようにマイクロコードファイルと initrd を連結します。

$ cat ''esp''/''cpu_manufacturer''-ucode.img ''esp''/initramfs-linux.img > /tmp/combined_initrd.img

統合カーネルイメージを構築するときは、{{ic|/tmp/combined_initrd.img}} を initrd として渡します。このファイルは後で削除できます。

{{Note|[[Unified Extensible Firmware Interface#UEFI ファームウェアのビット数|IA32 UEFI]] では、以下のコマンドの {{ic|/usr/lib/systemd/boot/efi/linuxx64.efi.stub}} を {{ic|/usr/lib/systemd/boot/efi/linuxia32.efi.stub}} に置き換えてください。}}

{{bc|1=
$ align="$(objdump -p /usr/lib/systemd/boot/efi/linuxx64.efi.stub {{!}} awk '{ if ($1 == "SectionAlignment"){print $2} }')"
$ align=$((16#$align))
$ osrel_offs="$(objdump -h "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" {{!}} awk 'NF==7 {size=strtonum("0x"$3); offset=strtonum("0x"$4)} END {print size + offset}')"
$ osrel_offs=$((osrel_offs + "$align" - osrel_offs % "$align"))
$ cmdline_offs=$((osrel_offs + $(stat -Lc%s "/usr/lib/os-release")))
$ cmdline_offs=$((cmdline_offs + "$align" - cmdline_offs % "$align"))
$ splash_offs=$((cmdline_offs + $(stat -Lc%s "/etc/kernel/cmdline")))
$ splash_offs=$((splash_offs + "$align" - splash_offs % "$align"))
$ initrd_offs=$((splash_offs + $(stat -Lc%s "/usr/share/systemd/bootctl/splash-arch.bmp")))
$ initrd_offs=$((initrd_offs + "$align" - initrd_offs % "$align"))
$ linux_offs=$((initrd_offs + $(stat -Lc%s "''initrd-file''")))
$ linux_offs=$((linux_offs + "$align" - linux_offs % "$align"))

$ objcopy \
--add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=$(printf 0x%x $osrel_offs) \
--add-section .cmdline="/etc/kernel/cmdline" \
--change-section-vma .cmdline=$(printf 0x%x $cmdline_offs) \
--add-section .splash="/usr/share/systemd/bootctl/splash-arch.bmp" \
--change-section-vma .splash=$(printf 0x%x $splash_offs) \
--add-section .initrd="''initrd-file''" \
--change-section-vma .initrd=$(printf 0x%x $initrd_offs) \
--add-section .linux="''vmlinuz-file''" \
--change-section-vma .linux=$(printf 0x%x $linux_offs) \
"/usr/lib/systemd/boot/efi/linuxx64.efi.stub" "''linux''.efi"
}}

注意すべき点がいくつかあります:

* [https://github.com/systemd/systemd/commit/0fa2cac4f0cdefaf1addd7f1fe0fd8113db9360b#commitcomment-76747223] で推奨されているように、オフセットは動的に計算されるので、セクションが重なることはありません。
* セクションは、PE スタブの {{ic|SectionAlignment}} フィールドが示す値 (通常は 0x1000) にアラインメントされます。
* カーネルイメージは、[https://github.com/systemd/systemd/commit/0fa2cac4f0cdefaf1addd7f1fe0fd8113db9360b#commitcomment-84868898] で述べられているように、インプレース解凍で後続のセクションが上書きされるのを防ぐために、最後のセクションにある必要があります。

イメージを作成したら、それを EFI システムパーティションにコピーします。

# cp ''linux''.efi ''esp''/EFI/Linux/

== セキュアブート用の UKI への署名 ==

=== sbctl ===

{{Pkg|sbctl}} は、更新されたバイナリに署名するための [[kernel-install]] スクリプト、[[mkinitcpio]] ポストフック、および pacman フックを提供します。

=== mkinitcpio ===

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使用することで、生成された Unified Kernel Image に [[セキュアブート]] 用の署名を付けることができます。以下のファイルを作成し、[[ヘルプ:読み方#実行可能属性の付与|実行可能]]にしてください。

{{hc|/etc/initcpio/post/uki-sbsign|2=
#!/usr/bin/env bash

uki="$3"
<nowiki>[[ -n "$uki" ]] || exit 0</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$uki" &>/dev/null; then
sbsign "$uki" --key "$key" --cert "$cert" --output "$uki"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} を、イメージの署名に使用するキーペアのパスに置き換えてください。

=== ukify ===

{{Pkg|sbsigntools}} をインストールし、{{ic|/etc/kernel/uki.conf}} で {{ic|--secureboot-private-key}} と {{ic|--secureboot-certificate}} を指定します。

== 起動方法 ==

{{Note|[[セキュアブート]] がアクティブな場合、{{ic|.cmdline}} が埋め込まれた統合カーネルイメージは、(ブートエントリを使用するか対話的に) 渡されたすべてのコマンドラインオプションを無視します。セキュアブートがアクティブでない場合、コマンドライン経由で渡されたオプションは、埋め込まれた {{ic|.cmdline}} をオーバーライドします。}}

=== Limine ===

[[Limine]] は Unified Kernel Image (UKI) を自動的に検出しません。ただし、{{ic|limine.conf}} を手動で構成して UKI をロードできます。

'''例 1: デフォルトの EFI システムパーティションから UKI を起動する'''

UKI ファイルが {{ic|''esp''/EFI/Linux/}} に保存されている場合は、次の設定を {{ic|limine.conf}} に追加します。

{{hc|limine.conf|2=
/Arch Linux
protocol: efi_chainload
image_path: boot():/EFI/Linux/arch-linux.efi
}}

'''例 2: 別の EFI パーティションから UKI を起動する'''

UKI ファイルが別のディスク上の別の EFI パーティションにある場合は、{{ic|uuid(''partition UUID'')}} を使用します。

{{Note|パーティション UUID はファイルシステム UUID '''ではありません'''。{{ic|PARTUUID}} としてパーティション UUID を見つけるには、次を使用します。
$ lsblk -o NAME,FSTYPE,PARTUUID,PARTTYPENAME,MOUNTPOINT,SIZE,LABEL
}}

{{hc|limine.conf|2=
/Arch Linux
protocol: efi_chainload
image_path: uuid(''xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx''):/EFI/Linux/arch-linux.efi
}}

サポートされているパスと設定オプションの詳細については、[https://github.com/limine-bootloader/limine/blob/v8.x/CONFIG.md#Paths Limine Paths ドキュメント] を参照してください。

=== systemd-boot ===

[[systemd-boot#Unified kernel images|systemd-boot]] は {{ic|''esp''/EFI/Linux/}} 内でユニファイドカーネルイメージを検索しますので、それ以上の設定は必要ありません。{{man|7|sd-boot|FILES}} を見て下さい。

=== rEFInd ===

[[rEFInd]] は、EFI システムパーティション上のユニファイドカーネルイメージを自動検出し、それらをロードできます。{{ic|refind.conf}} で手動で指定することもできます。デフォルトでは次の場所にあります。

{{hc|''esp''/EFI/refind/refind.conf|2=
menuentry Linux {
loader ''esp''/EFI/Linux/archlinux-linux.efi
}
}}

イメージが ESP のルートにある場合、rEFInd は次のようにその名前のみを必要とします: {{ic|loader archlinux-linux.efi}} この方法で起動すると、{{ic|''esp''/EFI/refind_linux.conf}} からのカーネルパラメータは渡されません。

=== GRUB ===

rEFInd と同様に、[[GRUB]] は [[GRUB#ユニファイドカーネルイメージをチェインロード]] で説明されているように EFI UKI をチェーンロードできます。

=== UEFI から直接起動 ===

[[efibootmgr]] を使って ''.efi'' ファイルに UEFI ブートエントリを作成することができます。

# efibootmgr --create --disk /dev/sd''X'' --part ''partition_number'' --label "Arch Linux" --loader '\EFI\Linux\arch-linux.efi' --unicode

オプションの説明は {{man|8|efibootmgr}} をご覧ください。

== 参照 ==

* [https://www.youtube.com/watch?v=7UhwK3g99_0 All Systems Go! talk on UKIs]
* [https://uapi-group.org/specifications/specs/unified_kernel_image/ Unified kernel image specification]
* [https://linderud.dev/blog/mkinitcpio-v31-and-uefi-stubs/ mkinitcpio v31 and UEFI stubs]

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

2026-03-12T02:53:22Z

ELC: /* インストールメディアを起動する */ リンク修正

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|セキュリティ}}
{{Related articles end}}

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

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

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

=== OS の起動前 ===

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

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

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

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

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

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

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

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

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

6 0 0 0 1

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

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

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

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

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://archboot.com/ Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

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

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

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

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

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

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

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

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

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

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

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

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- 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
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

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

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

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

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

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

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

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

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

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

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

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

$ sbctl status

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

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

# sbctl create-keys

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

# sbctl enroll-keys -m

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

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

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

$ sbctl status

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

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

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

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

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

$ sbctl status

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

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

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

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

}}

==== 手動による手順 ====

===== efitools をインストールする =====

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

===== 鍵の生成 =====

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

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

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

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

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

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

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

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

====== sbkeysync を使う ======

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

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

例えば、以下のように:

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

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

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

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

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

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

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

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

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

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

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

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

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

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

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

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

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

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

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

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

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

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

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

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

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

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

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

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

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

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

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

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

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

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

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

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

==== PreLoader ====

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

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

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

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

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

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

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

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

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

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

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

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

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

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

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

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

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

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

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

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

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

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

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

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

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

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

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

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

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

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

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

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

==== shim ====

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

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

===== shim をセットアップする =====

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

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

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

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

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

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

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

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

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

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

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

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''MOK.key
cert=''/path/to/''MOK.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

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

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

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

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

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

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

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

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

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

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

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

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

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

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

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

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

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

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

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

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

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

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

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

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2026-03-12|862815}}

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

2026-03-12T02:04:33Z

ELC: TranslationStatus

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|セキュリティ}}
{{Related articles end}}

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

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

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

=== OS の起動前 ===

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

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

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

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

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

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

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

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

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

6 0 0 0 1

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

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

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

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

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

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

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

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

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

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

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

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

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

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

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

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

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- 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
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

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

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

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

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

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

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

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

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

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

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

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

$ sbctl status

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

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

# sbctl create-keys

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

# sbctl enroll-keys -m

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

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

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

$ sbctl status

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

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

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

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

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

$ sbctl status

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

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

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

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

}}

==== 手動による手順 ====

===== efitools をインストールする =====

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

===== 鍵の生成 =====

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

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

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

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

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

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

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

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

====== sbkeysync を使う ======

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

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

例えば、以下のように:

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

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

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

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

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

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

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

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

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

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

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

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

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

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

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

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

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

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

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

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

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

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

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

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

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

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

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

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

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

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

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

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

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

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

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

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

==== PreLoader ====

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

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

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

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

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

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

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

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

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

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

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

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

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

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

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

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

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

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

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

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

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

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

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

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

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

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

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

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

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

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

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

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

==== shim ====

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

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

===== shim をセットアップする =====

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

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

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

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

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

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

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

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

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

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

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

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''MOK.key
cert=''/path/to/''MOK.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

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

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

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

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

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

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

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

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

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

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

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

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

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

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

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

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

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

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

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

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

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

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

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

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2026-03-12|862815}}

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

2026-03-12T02:00:47Z

ELC: 重複リンク削除

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|セキュリティ}}
{{Related articles end}}

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

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

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

=== OS の起動前 ===

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

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

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

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

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

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

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

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

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

6 0 0 0 1

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

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

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

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

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

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

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

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

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

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

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

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

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

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

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

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

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- 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
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

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

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

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

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

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

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

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

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

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

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

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

$ sbctl status

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

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

# sbctl create-keys

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

# sbctl enroll-keys -m

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

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

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

$ sbctl status

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

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

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

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

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

$ sbctl status

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

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

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

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

}}

==== 手動による手順 ====

===== efitools をインストールする =====

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

===== 鍵の生成 =====

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

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

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

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

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

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

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

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

====== sbkeysync を使う ======

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

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

例えば、以下のように:

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

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

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

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

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

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

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

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

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

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

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

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

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

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

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

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

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

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

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

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

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

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

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

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

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

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

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

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

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

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

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

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

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

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

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

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

==== PreLoader ====

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

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

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

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

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

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

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

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

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

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

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

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

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

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

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

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

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

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

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

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

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

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

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

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

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

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

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

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

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

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

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

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

==== shim ====

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

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

===== shim をセットアップする =====

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

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

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

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

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

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

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

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

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

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

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

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''MOK.key
cert=''/path/to/''MOK.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

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

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

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

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

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

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

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

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

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

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

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

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

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

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

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

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

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

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

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

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

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

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

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

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

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

2026-03-12T01:50:03Z

ELC: /* shim で鍵を使う */ kernel-sbsign スクリプトを簡略化

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

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

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

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

=== OS の起動前 ===

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

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

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

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

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

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

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

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

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

6 0 0 0 1

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

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

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

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

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

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

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

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

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

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

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

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

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

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

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

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

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- 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
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

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

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

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

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

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

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

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

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

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

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

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

$ sbctl status

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

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

# sbctl create-keys

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

# sbctl enroll-keys -m

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

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

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

$ sbctl status

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

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

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

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

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

$ sbctl status

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

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

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

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

}}

==== 手動による手順 ====

===== efitools をインストールする =====

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

===== 鍵の生成 =====

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

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

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

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

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

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

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

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

====== sbkeysync を使う ======

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

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

例えば、以下のように:

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

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

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

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

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

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

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

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

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

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

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

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

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

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

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

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

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

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

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

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

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

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

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

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

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

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

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

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

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

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

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

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

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

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

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

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

==== PreLoader ====

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

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

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

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

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

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

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

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

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

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

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

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

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

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

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

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

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

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

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

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

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

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

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

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

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

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

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

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

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

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

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

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

==== shim ====

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

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

===== shim をセットアップする =====

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

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

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

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

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

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

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

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

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

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

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

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''MOK.key
cert=''/path/to/''MOK.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

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

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

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

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

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

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

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

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

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

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

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

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

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

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

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

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

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

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

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

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

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

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

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

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

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

2026-03-12T01:48:01Z

ELC: /* mkinitcpio のポストフックでカーネルに署名する */ kernel-sbsign スクリプトを簡略化

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

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

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

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

=== OS の起動前 ===

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

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

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

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

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

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

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

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

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

6 0 0 0 1

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

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

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

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

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

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

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

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

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

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

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

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

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

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

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

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

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- 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
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

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

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

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

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

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

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

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

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

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

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

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

$ sbctl status

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

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

# sbctl create-keys

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

# sbctl enroll-keys -m

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

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

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

$ sbctl status

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

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

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

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

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

$ sbctl status

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

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

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

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

}}

==== 手動による手順 ====

===== efitools をインストールする =====

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

===== 鍵の生成 =====

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

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

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

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

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

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

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

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

====== sbkeysync を使う ======

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

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

例えば、以下のように:

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

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

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

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

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

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

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

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

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

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

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

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

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

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

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

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

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

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

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

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

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

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

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

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

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

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

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

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

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

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

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

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

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

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

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

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

==== PreLoader ====

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

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

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

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

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

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

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

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

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

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

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

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

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

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

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

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

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

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

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

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

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

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

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

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

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

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

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

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

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

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

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

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

==== shim ====

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

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

===== shim をセットアップする =====

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

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

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

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

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

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

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

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

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

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

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

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

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

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

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

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

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

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

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

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

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

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

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

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

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

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

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

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

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

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

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

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

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

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

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

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

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

2026-03-12T01:13:55Z

ELC: /* 公式の ISO をカスタムの鍵で署名する */ AURからgsaiを追加

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

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

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

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

=== OS の起動前 ===

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

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

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

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

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

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

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

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

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

6 0 0 0 1

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

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

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

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

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

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

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

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

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

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

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

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

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

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

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

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

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- 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
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

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

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

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

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

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

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

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

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

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

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

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

$ sbctl status

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

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

# sbctl create-keys

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

# sbctl enroll-keys -m

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

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

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

$ sbctl status

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

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

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

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

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

$ sbctl status

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

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

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

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

}}

==== 手動による手順 ====

===== efitools をインストールする =====

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

===== 鍵の生成 =====

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

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

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

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

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

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

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

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

====== sbkeysync を使う ======

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

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

例えば、以下のように:

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

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

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

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

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

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

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

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

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

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

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

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

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

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

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

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

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

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

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

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

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

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

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

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

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

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

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

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

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

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

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

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

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

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

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

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

==== PreLoader ====

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

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

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

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

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

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

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

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

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

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

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

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

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

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

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

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

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

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

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

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

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

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

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

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

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

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

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

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

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

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

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

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

==== shim ====

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

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

===== shim をセットアップする =====

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

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

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

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

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

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

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

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

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

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

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

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

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

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

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

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

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

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

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

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

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

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

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

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

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

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

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

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

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

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

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

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

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

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

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

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

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

2026-03-12T01:03:22Z

ELC: /* OpROM 署名を特定する */ 追加

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

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

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

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

=== OS の起動前 ===

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

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

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

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

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

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

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

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

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

6 0 0 0 1

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

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

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

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

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

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

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

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

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

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

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

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

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

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

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

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

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- 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
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

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

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

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

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

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

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

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

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

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

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

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

$ sbctl status

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

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

# sbctl create-keys

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

# sbctl enroll-keys -m

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

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

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

$ sbctl status

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

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

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

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

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

$ sbctl status

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

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

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

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

}}

==== 手動による手順 ====

===== efitools をインストールする =====

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

===== 鍵の生成 =====

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

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

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

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

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

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

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

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

====== sbkeysync を使う ======

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

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

例えば、以下のように:

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

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2026-03-12T00:44:34Z

ELC: /* GRUB で sbctl を使う */ 追加

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-29T12:47:08Z

ELC: ハンガリー語ページへのリンク

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-29T08:51:23Z

ELC: TranslationStatus

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-29T08:43:13Z

ELC: /* ISO の再パック */ Expansion（英語ページより）

Unified Extensible Firmware Interface/セキュアブート

2025-10-29T08:38:55Z

ELC: /* 署名 */ 追加の一括署名コマンド（英語ページより）

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-29T08:35:20Z

ELC: /* インストールメディアを起動する */ リンク変更（英語ページより）

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

FFmpeg

2025-10-29T07:40:52Z

ELC: TranslationStatus

[[Category:オーディオ]]
[[Category:ビデオ]]
[[en:FFmpeg]]
[[zh-hans:FFmpeg]]
{{Related articles start}}
{{Related|Flac を Mp3 に変換#FFmpeg を使う}}
{{Related articles end}}
プロジェクトの[https://www.ffmpeg.org/ ホームページ] より:
:FFmpeg は、音声と動画を記録、変換、そしてストリーミングするための完全でクロスプラットフォームなソリューションです。先進的な音声・動画コーデックライブラリである libavcodec が含まれています。

== インストール ==

{{Note|''libav'' や ''avconv'' など FFmpeg のフォークも存在しています。FFmpeg の現在の状態やプロジェクトの違いについては [https://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html The FFmpeg/Libav situation] を読んでください。}}

{{Pkg|ffmpeg}} パッケージを[[インストール]]してください。

開発版は {{AUR|ffmpeg-git}} パッケージでインストールできます。可能な限り多くのオプション機能を有効化してビルドする {{AUR|ffmpeg-full}} も存在します。

== エンコードの例 ==

{{Note|
* パラメータを正しい順序で指定することが重要です (例: input、video、filters、audio、output)。順序を間違うと、パラメータがスキップされたり、FFmpeg が実行されなかったりする場合があります。
* FFmpeg は、使用できる CPU スレッド数を自動的に選択するはずです。しかし、パラメータ {{ic|-threads ''number''}} を使って、使用できるスレッド数を強制したほうが良い場合もあります。
}}

[https://trac.ffmpeg.org/wiki#Encoding FFmpeg のエンコード wiki] と {{man|1|ffmpeg|EXAMPLES}} を参照してください。

=== スクリーンキャプチャ ===

FFmpeg には [https://www.ffmpeg.org/ffmpeg-devices.html#x11grab x11grab] と [https://www.ffmpeg.org/ffmpeg-devices.html#alsa-1 ALSA] の仮想デバイスが含まれており、ユーザのディスプレイ全体と音声入力をキャプチャすることができます。

スクリーンショットを撮って {{ic|screen.png}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -i $DISPLAY -vframes 1 screen.png

ここで、{{ic|-video_size}} はキャプチャする領域のサイズを指定します。

ロスレスエンコードで音声なしのスクリーンキャストを撮って {{ic|screen.mkv}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -framerate 25 -i $DISPLAY -c:v ffvhuff screen.mkv

ここでは、Huffyuv コーデックが使用されます。このコーデックは高速ですが、ファイルサイズが大きくなります。

ロッシーエンコードで音声ありのスクリーンキャストを撮って {{ic|screen.mp4}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -framerate 25 -i $DISPLAY -f alsa -i default -c:v libx264 -preset ultrafast -c:a aac screen.mp4

ここでは、x264 コーデックが最も高速なオプションで使用されます。他のコーデックを使用することもできます。(ディスクのパフォーマンスが十分でなかったり、エンコードが遅かったりで) 各フレームの書き込みが遅すぎる場合、フレームがドロップされ、動画出力がカクカクになります。

動画ストリームをファイルとして保存する必要はないが、画面共有のために仮想ウェブカメラとして使う場合、[[v4l2loopback#FFmpeg を使って X11 をキャストする]] を参照してください。

[https://trac.ffmpeg.org/wiki/Capture/Desktop#Linux 公式のドキュメント]も参照してください。

=== ウェブカメラの録画 ===

FFmpeg には [https://www.ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 video4linux2] と [https://www.ffmpeg.org/ffmpeg-devices.html#alsa-1 ALSA] の入力デバイスが含まれています。これらにより、ウェブカメラと音声入力をキャプチャすることができます。

以下のコマンドは、ウェブカメラから音声無しで動画を録画し {{ic|webcam.mp4}} に保存します。ウェブカメラが {{ic|/dev/video0}} として正しく認識されていると仮定します:

$ ffmpeg -f v4l2 -video_size 640x480 -i /dev/video0 -c:v libx264 -preset ultrafast webcam.mp4

ここで、{{ic|-video_size}} は、ウェブカメラからの許可されるイメージサイズの最大値を指定します。

上記のコマンドは無音動画を出力します。音声ありでウェブカメラから動画を録画し {{ic|webcam.mp4}} に保存するには:

$ ffmpeg -f v4l2 -video_size 640x480 -i /dev/video0 -f alsa -i default -c:v libx264 -preset ultrafast -c:a aac webcam.mp4

ここでは、x264 コーデックが最も高速なオプションで使用されます。他のコーデックを使用することもできます。(ディスクのパフォーマンスが十分でなかったり、エンコードが遅かったりで) 各フレームの書き込みが遅すぎる場合、フレームがドロップされ、動画出力がカクカクになります。

[https://trac.ffmpeg.org/wiki/Capture/Webcam#Linux 公式のドキュメント]も参照してください。

=== VOB から他のコンテナに ===

[[Wikipedia:VOB|VOB]] ファイルを一つのストリームに連結して MPEG-2 にするには:

$ cat f0.VOB f1.VOB f2.VOB | ffmpeg -i - out.mp2

=== x264 ===

==== ロスレス ====

''ultrafast'' プリセットは最速のエンコードをするので素早い録画をしたいときに有用です (スクリーンキャストなど):

$ ffmpeg -i input -c:v libx264 -preset ultrafast -qp 0 -c:a copy output

''ultrafast'' プリセットの反対は ''veryslow'' で、''ultrafast'' よりもエンコードが遅いかわりに出力するファイルのサイズが小さくなります:

$ ffmpeg -i input -c:v libx264 -preset veryslow -qp 0 -c:a copy output

どちらでも出力のクオリティは同じです。

{{Tip|あなたの使っているコンピュータがリアルタイムで {{ic|-preset superfast}} を処理できる場合、{{ic|-preset ultrafast}} ではなく {{ic|-preset superfast}} を使用してください。Ultrafast は superfast よりも圧縮率が''かなり''落ちます。}}

==== Constant rate factor ====

出力する品質を指定したいときに使います。一般的に使われているのは最高の {{ic|-crf}} 値で、これでも許容範囲内の画質になります。値が低いほど画質は高くなります。0はロスレス、18は見た目がロスレス、そして23がデフォルトの値です。賢明な値は18から28の範囲になります。一番遅い {{ic|-preset}} を使うなら辛抱する必要があります。詳しくは [https://ffmpeg.org/trac/ffmpeg/wiki/x264EncodingGuide x264 Encoding Guide] を見て下さい。

$ ffmpeg -i ''video'' -c:v libx264 -tune film -preset slow -crf 22 -x264opts fast_pskip=0 -c:a libmp3lame -aq 4 ''output''.mkv

{{ic|-tune}} オプションを使うことで[https://forum.doom9.org/showthread.php?t=149394 エンコードされるメディアの中身とタイプにあった設定にすることができます]。

==== ツーパス (超高品質) ====

マルチパスの始めは動画の統計が記録されるため、音声が無効化されます:

$ ffmpeg -i ''video''.VOB -an -vcodec libx264 -pass 1 -preset veryslow \
-threads 0 -b:v 3000k -x264opts frameref=15:fast_pskip=0 -f rawvideo -y /dev/null

コンテナの形式は出力ファイルの拡張子 ({{ic|.mkv}}) から自動的に検出して変換されます:

$ ffmpeg -i ''video''.VOB -acodec aac -b:a 256k -ar 96000 -vcodec libx264 \
-pass 2 -preset veryslow -threads 0 -b:v 3000k -x264opts frameref=15:fast_pskip=0 ''video''.mkv

==== 動画の手ブレ補正 ====

vbid.stab プラグインを使ってツーパスで手ブレ補正 (ビデオ安定化) を行います。

===== ファーストパス =====

ファーストパスでは補正パラメータを記録してファイルに書き出します、または視覚分析のテスト動画を作成します。

* 補正パラメータを記録してファイルだけに書き出す: {{bc|1=$ ffmpeg -i input -vf vidstabdetect=stepsize=4:mincontrast=0:result=transforms.trf -f null -}}
* 補正パラメータをファイルに書きだして、視覚分析用のテストビデオ "output-stab" を作成: {{bc|1=$ ffmpeg -i input -vf vidstabdetect=stepsize=4:mincontrast=0:result=transforms.trf output-stab}}

===== セカンドパス =====

セカンドパスではファーストパスで作成した補正パラメータを解析して、それを使って "output-stab_final" を生成します。セカンドパスで他のフィルターを適用することもでき、変換を繰り返す必要をなくして画質を最大限保つことができます。下のコマンドでは以下のオプションを使っています:

* {{ic|unsharp}}: vid.stab の作者によって推奨されています。下の例ではデフォルトの 5:5:1.0:5:5:1.0 を使っています。
* {{ic|1=fade=t=in:st=0:d=4}}: 4秒間のフェードインをファイルの冒頭に挟みます。
* {{ic|1=fade=t=out:st=60:d=4}}: 動画の60秒目から4秒間のフェードアウトを挟みます。
* {{ic|-c:a pcm_s16le}}: XAVC-S コーデックは pcm_s16be で記録されロスレスの pcm_s16le に変換されます。

$ ffmpeg -i input -vf vidstabtransform=smoothing=30:interpol=bicubic:input=transforms.trf,unsharp,fade=t=in:st=0:d=4,fade=t=out:st=60:d=4 -c:v libx264 -tune film -preset veryslow -crf 8 -x264opts fast_pskip=0 -c:a pcm_s16le output-stab_final

=== x265 ===

以下の例は、パラメータを指定せずに libx265 を呼び出した場合のデフォルトを示します (Constant Rate Factor エンコード):

ffmpeg -i input -c:v libx265 -crf 28 -preset medium -c:a libvorbis output.mp4

詳細は FFmpeg の [https://trac.ffmpeg.org/wiki/Encode/H.265 H.265/HEVC Video Encoding Guide] を参照してください。

=== シングルパス MPEG-2 (ニアロスレス) ===

DVD 標準のパラメータに FFmpeg を自動的に設定することができます。約 30 FPS の DVD [[Wikipedia:ja:MPEG-2|MPEG-2]] にエンコードするには:

$ ffmpeg -i ''video''.VOB -target ntsc-dvd ''output''.mpg

約 24 FPS の DVD MPEG-2 にエンコードするには:

$ ffmpeg -i ''video''.VOB -target film-dvd ''output''.mpg

=== 字幕 ===

==== 抽出 ====

MPEG-2 や Matroska などのコンテナファイルに埋め込まれた字幕を抽出して、SRT や SSA、WebVTT などの字幕形式に変換することができます。[https://trac.ffmpeg.org/wiki/ExtractSubtitles]

* ファイルに字幕ストリームが含まれているか確認してください:

{{hc|$ ffprobe -hide_banner foo.mkv|
...
Stream #0:0(und): Video: h264 (High), yuv420p, 1920x800 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Metadata:
CREATION_TIME : 2012-06-05 05:04:15
LANGUAGE : und
Stream #0:1(und): Audio: aac, 44100 Hz, stereo, fltp (default)
Metadata:
CREATION_TIME : 2012-06-05 05:10:34
LANGUAGE : und
HANDLER_NAME : GPAC ISO Audio Handler
'''Stream #0:2: Subtitle: ssa (default)'''
}}

* {{ic|foo.mkv}} には SSA の字幕が埋め込まれており、別のファイルに抽出することが可能です:

$ ffmpeg -i foo.mkv foo.ssa

字幕を望ましい形式 (例として [[Wikipedia:ja:SubRip|SubRip]]) に保存するには {{ic|-c:s srt}} を追加してください:

$ ffmpeg -i foo.mkv -c:s srt foo.srt

複数の字幕が存在する場合、{{ic|-map ''key'':''stream''}} パラメータを使用して抽出するストリームを指定する必要があります:

$ ffmpeg -i foo.mkv -map 0:2 foo.ssa

==== ハードサブ ====

(FFmpeg wiki の記事の [https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo HowToBurnSubtitlesIntoVideo] に基づく説明)

[[Wikipedia:Hardsub|ハードサブ]]は動画に字幕を焼きこむことになります。ハードサブは無効化できず、言語の切り替えやフォントサイズのカスタマイズもできないため、推奨されない場合もあります。不明な場合は、ハードサブではなくソフトサブを使用してください。

* {{ic|foo.mpg}} に {{ic|foo.ssa}} の字幕を重ねるには:

$ ffmpeg -i foo.mpg -vf subtitles=foo.ssa out.mpg

=== ボリュームゲイン ===

ボリュームゲインは ''ffmpeg'' のフィルタ機能で変更できます。まず、{{ic|-af}} または {{ic|-filter:a}} を使って音声ストリームを選択し、次に、''volume'' フィルタの後にそのストリームに対するゲインを指定してください。例えば:

$ ffmpeg -i input.flac -af '''volume=1.5''' ouput.flac

ここで、{{ic|1=volume=1.5}} によって 150% のボリュームゲインとなります。1.5 から 0.5 にすると、ボリュームが半分になります。ボリュームフィルタにはデシベル単位を渡すこともできます。{{ic|1=volume=3dB}} とすると、ボリュームが 3dB 増え、{{ic|1=volume=-3dB}} とすると 3dB 減ります。

{{Note|ファイルのボリュームゲインを倍にすることは、ボリュームを倍にすることと同じではありません。実験して正しいボリュームを見つける必要があります。}}

{{Tip|''volumedetect'' フィルタを使用することで、ファイルの現在の平均ボリュームとピークボリュームを調べることができます: {{ic|ffmpeg -i input.flac -af volumedetect -f null -}}。そして、目標のレベルと現在のレベルとの差を ''volume'' フィルタに渡すことで、望みのレベルにすることができます。}}

=== ボリュームノーマライゼーション ===

''loudnorm'' フィルタによるノーマライゼーションにより、平均ボリュームとピークボリュームを特定の値にすることができます。''fmpeg'' のデフォルトの平均ラウドネス、ピークラウドネス、そしてレンジラウドネスの目標値 (それぞれ、-24 LUFS、-2 dBTP、7 LU) を使って、ファイルの知覚ラウドネスを正規化するには、以下のコマンドを使用してください:

$ ffmpeg -i input.flac -af '''loudnorm''' output.flac

別のラウドネスプロファイルを得るには、''loudnorm'' フィルタのパラメータ {{ic|i}}、{{ic|tp}}、そして {{ic|lra}} を使って、それぞれ ''i''ntegrated、''t''rue ''p''eak、''l''oudness ''ra''nge を指定してください。例えば、デフォルトよりも高い知覚ラウドネスにするには:

$ ffmpeg -i input.flac -af loudnorm=i=-16:tp=-1.5:lra=11:print_format=summary output.flac

この例では、オーディオファイルの入力ラウドネスと出力ラウドネスを表示するために {{ic|1=print_format=summary}} も追加しています。

{{Note|このフィルタはツーパスモードもサポートしています。最初の実行から測定されたラウドネス値を抽出し、その値を使って2回めの実行で線形ノーマライゼーションを行います。詳細は [https://ffmpeg.org/ffmpeg-filters.html#loudnorm ffmpeg loudnorm ドキュメント]を参照してください。}}

{{Tip|ファイルの現在のラウドネスを調べるには、{{ic|1=ffmpeg -i input.flac -af loudnorm=print_format=summary -f null -}} を使ってください。}}

=== 音声を抽出する ===

{{hc|$ ffmpeg -i ''video''.mpg output.ext|
...
Input #0, avi, from '''video''.mpg':
Duration: 01:58:28.96, start: 0.000000, bitrate: 3000 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720x480 [PAR 1:1 DAR 16:9], 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0.1: Audio: ac3, 48000 Hz, stereo, s16, 384 kb/s
Stream #0.2: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s
Stream #0.3: Audio: dts, 48000 Hz, 5.1 768 kb/s
...
}}

多重化されている一番目の ({{ic|-map 0:1}}) [[Wikipedia:ja:ドルビーデジタル|AC-3]] でエンコードされた音声ストリームをファイルに抽出する:

$ ffmpeg -i ''video''.mpg -map 0:1 -acodec copy -vn ''video''.ac3

三番目の ({{ic|-map 0:3}}) [[Wikipedia:ja:デジタル・シアター・システムズ|DTS]] 音声ストリームをビットレートが 192 kb/s で[[Wikipedia:ja:サンプリングレート|サンプリングレート]]が 96000 Hz の [[Wikipedia:ja:AAC|AAC]] ファイルに変換する:

$ ffmpeg -i ''video''.mpg -map 0:3 -acodec aac -b:a 192k -ar 96000 -vn ''output''.aac

{{ic|-vn}} は動画ストリームの処理を無効にします。

時間を指定して音声ストリームを抽出する:

$ ffmpeg -ss 00:01:25 -t 00:00:05 -i ''video''.mpg -map 0:1 -acodec copy -vn ''output''.ac3

{{ic|-ss}} で開始時間を、{{ic|-t}} で長さを指定します。

=== 音声を除去する ===

# 一番目の動画ストリーム ({{ic|-map 0:0}}) と二番目の AC-3 音声ストリーム ({{ic|-map 0:2}}) をコピーします。
# AC-3 音声ストリームをビットレートが 128 kb/s でサンプリングレートが 48000 Hz の2チャンネルの MP3 に変換します。

$ ffmpeg -i ''video''.mpg -map 0:0 -map 0:2 -vcodec copy -acodec libmp3lame \
-b:a 128k -ar 48000 -ac 2 ''video''.mkv

{{hc|$ ffmpeg -i ''video''.mkv|
...
Input #0, avi, from '''video''.mpg':
Duration: 01:58:28.96, start: 0.000000, bitrate: 3000 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720x480 [PAR 1:1 DAR 16:9], 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0.1: Audio: mp3, 48000 Hz, stereo, s16, 128 kb/s
}}

{{Note|無駄な音声ストリームを削除することで余ったビットを画質の向上に割り当てることができます。}}

=== ファイルを分割する ===

{{ic|copy}} コーデックを使うことでエンコーディングを変更せずにファイルの操作を行うことができます。例えば、次のコマンドであらゆるメディアファイルを簡単に2つに分けることが可能です:

$ ffmpeg -i file.ext -t 00:05:30 -c copy part1.ext -ss 00:05:30 -c copy part2.ext

=== ハードウェアビデオアクセラレーション ===

[https://trac.ffmpeg.org/wiki/HWAccelIntro ハードウェアアクセラレーション API] を使用することで、エンコード/デコードのパフォーマンスを向上させることができます。しかし、特定の種類のコーデックしか使えませんし、場合によっては、ソフトウェアエンコードを使ったときと同じ結果が得られるとは限りません。

==== VA-API ====

Intel CPU ({{Pkg|intel-media-driver}} か {{Pkg|libva-intel-driver}} が必要) を使っている場合や、特定の AMD GPU でオープンソースの [[AMDGPU]] ドライバー ({{Pkg|mesa}} が必要) を使っている場合、[[VA-API]] を使用してエンコードとデコードができます。

利用可能なパラメータとサポートされているプラットフォームに関する情報は、[https://trac.ffmpeg.org/wiki/Hardware/VAAPI FFmpeg のドキュメント] を参照してください。

サポートされている H.264 コーデックを使用してエンコードする例:

$ ffmpeg -threads 1 -i file.ext -vaapi_device /dev/dri/renderD128 -vcodec h264_vaapi -vf format='nv12|vaapi,hwupload' output.mp4

{{Note|通常、VA-API は、(FFmpeg パッケージの依存関係である) {{Pkg|libva}} に含まれるヘッダとライブラリが検出されれば、ビルド時に {{Pkg|ffmpeg}} の自動検出機能によって有効化されます。}}

クイックリファレンスとして、constant quality エンコードを行う例を以下に挙げます:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -i input.mp4 -vf 'format=nv12,hwupload' -c:v hevc_vaapi -f mp4 -rc_mode 1 -qp 25 output.mp4

hevc_vaapi を使用する場合、-qp を 25 (視覚的に等価) からそれ以上 (28 から非常に小さな視覚的な損失が発生し始めます) の間で調整してください。h264_vaapi を使用する場合、18 (視覚的に等価) からそれ以上 (20 から非常に小さな視覚的な損失が発生し始めます) の間で調整してください。また、hevc_vaapi は h264_vaapi よりも 50% 高速にエンコードできるようです。

==== NVIDIA NVENC/NVDEC ====

プロプライエタリな [[NVIDIA]] ドライバを使用していて、{{Pkg|nvidia-utils}} パッケージがインストールされている場合、[[Wikipedia:Nvidia NVENC|NVENC]] と [[Wikipedia:Nvidia NVDEC|NVDEC]] をエンコード/デコードに使用できます。サポートされている GPU は [[Wikipedia:GeForce 600 series|600 シリーズ]]からです。詳細は [[ハードウェアビデオアクセラレーション#NVIDIA]] を参照してください。

テクニックが[https://web.archive.org/web/20190808223352/https://gist.github.com/Brainiarc7/8b471ff91319483cdb725f615908286e こちらの古い gist] に載っています。NVENC は [[CUDA]] と似ているため、ターミナルセッションからでも動作します。ハードウェア NVENC は Intel の VA-API エンコーダよりも数倍高速です。

利用可能なオプションを表示するには以下のコマンドを実行してください ({{ic|hevc_nvenc}} も使えます):

$ ffmpeg -help encoder=h264_nvenc

使用例:

$ ffmpeg -i source.ext -c:v h264_nvenc -rc constqp -qp 28 output.mkv

==== Intel QuickSync (QSV) ====

{{Merge|ハードウェアビデオアクセラレーション#Intel Video Processing Library (Intel VPL)|This is not specific to ffmpeg}}

[https://www.intel.com/content/www/us/en/architecture-and-technology/quick-sync-video/quick-sync-video-general.html Intel® Quick Sync Video] は、[[Intel]] GPU のメディア処理機能を使用して高速なデコードとエンコードを行い、プロセッサが他のタスクを処理できるようにしてシステムの応答性を向上させます。

これを使用するには、'''libmfx''' ランタイム実装がインストールされている必要があります。'''libmfx''' は、ハードウェアプラットフォームに基づいて実行時に実装をロードするディスパッチャライブラリです。
[[Wikipedia:ja:Broadwellマイクロアーキテクチャ|Broadwell]] から [[Wikipedia:ja:Rocket Lakeマイクロプロセッサ|Rocket Lake]] までの GPU で実行する場合、このライブラリは {{Pkg|intel-media-sdk}} をランタイム実装としてロードします。
[[Wikipedia:ja:Tiger Lakeマイクロアーキテクチャ|Tiger Lake]] 及びそれ以降の GPU においては、'''libmfx''' は {{Pkg|vpl-gpu-rt}} をロードします。[https://github.com/intel/vpl-gpu-rt#system-requirements vpl-gpu-rt system-requirements]も参照してください。
単一の Intel GPU を搭載しているシステムでは、ランタイム実装を変更したり選択したりできません。対応する実装は、ハードウェアに応じてインストールする必要があります。

上記のランタイムをインストールしないと、以下のようなエラーが発生します:

[AVHWDeviceContext @ 0x558283838c80] Error initializing an MFX session: -3.
Device creation failed: -1313558101.

QuickSync の使用方法は [https://trac.ffmpeg.org/wiki/Hardware/QuickSync FFmpeg Wiki] で説明されています。''libmfx'' を直接使わずに ''iHD'' ドライバか ''i965'' ドライバで [[VA-API]] [https://trac.ffmpeg.org/wiki/Hardware/VAAPI] を使用することが推奨されます。エンコード例は FFmpeg Wiki の ''Hybrid transcode'' セクションを、ドライバに関する指示は [[ハードウェアビデオアクセラレーション#VA-API の設定]] を参照してください。

==== AMD AMF ====

AMD は、[[AMDGPU PRO]] プロプライエタリパッケージを使用して AMD Video Coding Engine (GPU エンコード) によって Linux で H264 のみのビデオエンコードを行うためのサポートを追加し、ffmpeg は AMF ビデオエンコードのサポートを追加しました。なので、h264_amf ビデオエンコーダを使ってエンコードするには、{{AUR|amf-amdgpu-pro}} が必要です。[[AMDGPU PRO]] パッケージによって提供されている ICD ファイルを環境変数でリンクする必要がある場合があります。そうしないと、ffmpeg はオープンな AMDGPU の ICD ファイルを使用してしまい、このビデオエンコーダを使用できません。エンコードを行うコマンドの例は以下のようになります:

$ VK_DRIVER_FILES=/usr/share/vulkan/icd.d/amd_pro_icd64.json ffmpeg -hwaccel auto -vaapi_device /dev/dri/renderD128 -i input.mkv -c:v h264_amf -rc 1 -b:v 8M h264_amf_8M.mp4

クイックリファレンスとして、constant quality エンコードを行う例を挙げましょう:

$ VK_DRIVER_FILES=/usr/share/vulkan/icd.d/amd_pro_icd64.json ffmpeg -hwaccel auto -vaapi_device /dev/dri/renderD128 -i input.mp4 -c:v h264_amf -f mp4 -rc 0 -qp_b 22 -qp_i 22 -qp_p 22 -quality 2 output.mp4

3つの -qp_(b|i|p) を調整してください。18 にすると視覚的に等価で、22 から非常に小さな視覚的な損失が発生し始めます。

=== アニメーション GIF ===

一般に、アニメーション GIF は、画像品質が悪く、ファイルサイズが比較的大きく、音声サポートもないので、動画フォーマットとして素晴らしい選択肢とは言えません。しかし、ウェブでは依然として頻繁に使用されています。以下のコマンドを使うことで、動画をアニメーション GIF に変換することができます:

$ ffmpeg -i input.mp4 -vf "fps=10,split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" -loop -1 output.gif

パレットフィルタを使って高品質な GIF を生成する方法については、https://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html を見てください。

== プリセットファイル ==

デフォルトの[https://ffmpeg.org/ffmpeg.html#Preset-files プリセットファイル]で {{ic|~/.ffmpeg}} を作成する:

$ cp -iR /usr/share/ffmpeg ~/.ffmpeg

新しいファイルを作成したりデフォルトのプリセットファイルを編集する:

{{hc|~/.ffmpeg/libavcodec-vhq.ffpreset|2=
vtag=DX50
mbd=2
trellis=2
flags=+cbp+mv0
pre_dia_size=4
dia_size=4
precmp=4
cmp=4
subcmp=4
preme=2
qns=2
}}

=== プリセットファイルを使う ===

{{ic|-vcodec}} の宣言の後に {{ic|-vpre}} オプションを加えて下さい。

==== libavcodec-vhq.ffpreset ====

* {{ic|libavcodec}} '''=''' vcodec/acodec の名前
* {{ic|vhq}} '''=''' 使用するプリセットの名前
* {{ic|ffpreset}} '''=''' FFmpeg プリセットの拡張子

== ヒントとテクニック ==

=== 出力を簡略化 ===

以下のオプションを組み合わせて使うことで、出力の詳細さを好きなレベルまで減らすことができます:

* {{ic|-hide_banner}}: 著作権表示、ビルドオプション、そしてライブラリのバージョンが表示されなくなります
* {{ic|-loglevel}}: ログレベルを調整します (微調整オプションが利用できます)。例: {{ic|-loglevel warning}}
* {{ic|-nostats}}: エンコードの進捗/統計が表示されなくなります

=== 動画の再生時間を出力 ===

$ ffprobe -select_streams v:0 -show_entries stream=duration -of default=noprint_wrappers=1:nokey=1 file.ext

=== ストリーム情報を JSON で出力 ===

$ ffprobe -v quiet -print_format json -show_format -show_streams file.ext

=== X フレームごとに動画のスクリーンショットを作成する ===

$ ffmpeg -i file.ext -an -s 319x180 -vf fps=1/'''100''' -qscale:v 75 %03d.jpg

=== メタデータの変更 ===

メタデータは直接変更することはできません。メタデータをエクスポートして変更し、新しいファイルにマージする必要があります。

既存の（グローバル）メタデータをテキストファイルに抽出する:

$ ffmpeg -i 'song.mp3' -f ffmetadata song_metadata.txt

テキストファイルからメタデータを含む新しいファイルを作成する:

$ ffmpeg -i 'song.mp3' -f ffmetadata -i new_metadata.txt -map_metadata 1 -id3v2_version 4 song_new.mp3

{{ic|-map_metadata 1}} は、ffmpeg に 2 番目のファイル (インデックスは 0 から始まる) のメタデータを使用するように指示します。

グローバルメタデータの他に、各ストリームは独自のメタデータを持つこともできます。たとえば、{{ic|-map_metadata:s:v 0:s:v}} および {{ic|-map_metadata:s:a 0:s:a}} を使用してエクスポートします。

{{ic|ffprobe}} は({{Pkg|ffmpeg}} パッケージからも同様に) 、default、compact/csv、flat、ini、json、xml など、さらに多くのエクスポート形式を提供します。

== 参照 ==

* [https://ffmpeg.org/ffmpeg.html FFmpeg documentation] - 公式ドキュメント
* [https://trac.ffmpeg.org/wiki FFmpeg Wiki] - 公式 wiki
* [http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html Encoding with the x264 codec] - MEncoder ドキュメント
* [https://avidemux.org/admWiki/doku.php?id=tutorial:h.264 H.264 encoding guide] - Avidemux wiki
* [http://howto-pages.org/ffmpeg/ Using FFmpeg] - Linux how to pages
* サポートしている音声・動画ストリームの[https://ffmpeg.org/general.html#Supported-File-Formats_002c-Codecs-or-Features リスト]

{{TranslationStatus|FFmpeg|2025-10-29|848305}}

FFmpeg

2025-10-29T07:38:09Z

ELC: /* Intel QuickSync (QSV) */ 英語ページのアナウンス

FFmpeg

2025-10-29T07:33:15Z

ELC: /* ハードウェアビデオアクセラレーション */ リンク切れ削除

[[Category:オーディオ]]
[[Category:ビデオ]]
[[en:FFmpeg]]
[[zh-hans:FFmpeg]]
{{Related articles start}}
{{Related|Flac を Mp3 に変換#FFmpeg を使う}}
{{Related articles end}}
プロジェクトの[https://www.ffmpeg.org/ ホームページ] より:
:FFmpeg は、音声と動画を記録、変換、そしてストリーミングするための完全でクロスプラットフォームなソリューションです。先進的な音声・動画コーデックライブラリである libavcodec が含まれています。

== インストール ==

{{Note|''libav'' や ''avconv'' など FFmpeg のフォークも存在しています。FFmpeg の現在の状態やプロジェクトの違いについては [https://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html The FFmpeg/Libav situation] を読んでください。}}

{{Pkg|ffmpeg}} パッケージを[[インストール]]してください。

開発版は {{AUR|ffmpeg-git}} パッケージでインストールできます。可能な限り多くのオプション機能を有効化してビルドする {{AUR|ffmpeg-full}} も存在します。

== エンコードの例 ==

{{Note|
* パラメータを正しい順序で指定することが重要です (例: input、video、filters、audio、output)。順序を間違うと、パラメータがスキップされたり、FFmpeg が実行されなかったりする場合があります。
* FFmpeg は、使用できる CPU スレッド数を自動的に選択するはずです。しかし、パラメータ {{ic|-threads ''number''}} を使って、使用できるスレッド数を強制したほうが良い場合もあります。
}}

[https://trac.ffmpeg.org/wiki#Encoding FFmpeg のエンコード wiki] と {{man|1|ffmpeg|EXAMPLES}} を参照してください。

=== スクリーンキャプチャ ===

FFmpeg には [https://www.ffmpeg.org/ffmpeg-devices.html#x11grab x11grab] と [https://www.ffmpeg.org/ffmpeg-devices.html#alsa-1 ALSA] の仮想デバイスが含まれており、ユーザのディスプレイ全体と音声入力をキャプチャすることができます。

スクリーンショットを撮って {{ic|screen.png}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -i $DISPLAY -vframes 1 screen.png

ここで、{{ic|-video_size}} はキャプチャする領域のサイズを指定します。

ロスレスエンコードで音声なしのスクリーンキャストを撮って {{ic|screen.mkv}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -framerate 25 -i $DISPLAY -c:v ffvhuff screen.mkv

ここでは、Huffyuv コーデックが使用されます。このコーデックは高速ですが、ファイルサイズが大きくなります。

ロッシーエンコードで音声ありのスクリーンキャストを撮って {{ic|screen.mp4}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -framerate 25 -i $DISPLAY -f alsa -i default -c:v libx264 -preset ultrafast -c:a aac screen.mp4

ここでは、x264 コーデックが最も高速なオプションで使用されます。他のコーデックを使用することもできます。(ディスクのパフォーマンスが十分でなかったり、エンコードが遅かったりで) 各フレームの書き込みが遅すぎる場合、フレームがドロップされ、動画出力がカクカクになります。

動画ストリームをファイルとして保存する必要はないが、画面共有のために仮想ウェブカメラとして使う場合、[[v4l2loopback#FFmpeg を使って X11 をキャストする]] を参照してください。

[https://trac.ffmpeg.org/wiki/Capture/Desktop#Linux 公式のドキュメント]も参照してください。

=== ウェブカメラの録画 ===

FFmpeg には [https://www.ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 video4linux2] と [https://www.ffmpeg.org/ffmpeg-devices.html#alsa-1 ALSA] の入力デバイスが含まれています。これらにより、ウェブカメラと音声入力をキャプチャすることができます。

以下のコマンドは、ウェブカメラから音声無しで動画を録画し {{ic|webcam.mp4}} に保存します。ウェブカメラが {{ic|/dev/video0}} として正しく認識されていると仮定します:

$ ffmpeg -f v4l2 -video_size 640x480 -i /dev/video0 -c:v libx264 -preset ultrafast webcam.mp4

ここで、{{ic|-video_size}} は、ウェブカメラからの許可されるイメージサイズの最大値を指定します。

上記のコマンドは無音動画を出力します。音声ありでウェブカメラから動画を録画し {{ic|webcam.mp4}} に保存するには:

$ ffmpeg -f v4l2 -video_size 640x480 -i /dev/video0 -f alsa -i default -c:v libx264 -preset ultrafast -c:a aac webcam.mp4

ここでは、x264 コーデックが最も高速なオプションで使用されます。他のコーデックを使用することもできます。(ディスクのパフォーマンスが十分でなかったり、エンコードが遅かったりで) 各フレームの書き込みが遅すぎる場合、フレームがドロップされ、動画出力がカクカクになります。

[https://trac.ffmpeg.org/wiki/Capture/Webcam#Linux 公式のドキュメント]も参照してください。

=== VOB から他のコンテナに ===

[[Wikipedia:VOB|VOB]] ファイルを一つのストリームに連結して MPEG-2 にするには:

$ cat f0.VOB f1.VOB f2.VOB | ffmpeg -i - out.mp2

=== x264 ===

==== ロスレス ====

''ultrafast'' プリセットは最速のエンコードをするので素早い録画をしたいときに有用です (スクリーンキャストなど):

$ ffmpeg -i input -c:v libx264 -preset ultrafast -qp 0 -c:a copy output

''ultrafast'' プリセットの反対は ''veryslow'' で、''ultrafast'' よりもエンコードが遅いかわりに出力するファイルのサイズが小さくなります:

$ ffmpeg -i input -c:v libx264 -preset veryslow -qp 0 -c:a copy output

どちらでも出力のクオリティは同じです。

{{Tip|あなたの使っているコンピュータがリアルタイムで {{ic|-preset superfast}} を処理できる場合、{{ic|-preset ultrafast}} ではなく {{ic|-preset superfast}} を使用してください。Ultrafast は superfast よりも圧縮率が''かなり''落ちます。}}

==== Constant rate factor ====

出力する品質を指定したいときに使います。一般的に使われているのは最高の {{ic|-crf}} 値で、これでも許容範囲内の画質になります。値が低いほど画質は高くなります。0はロスレス、18は見た目がロスレス、そして23がデフォルトの値です。賢明な値は18から28の範囲になります。一番遅い {{ic|-preset}} を使うなら辛抱する必要があります。詳しくは [https://ffmpeg.org/trac/ffmpeg/wiki/x264EncodingGuide x264 Encoding Guide] を見て下さい。

$ ffmpeg -i ''video'' -c:v libx264 -tune film -preset slow -crf 22 -x264opts fast_pskip=0 -c:a libmp3lame -aq 4 ''output''.mkv

{{ic|-tune}} オプションを使うことで[https://forum.doom9.org/showthread.php?t=149394 エンコードされるメディアの中身とタイプにあった設定にすることができます]。

==== ツーパス (超高品質) ====

マルチパスの始めは動画の統計が記録されるため、音声が無効化されます:

$ ffmpeg -i ''video''.VOB -an -vcodec libx264 -pass 1 -preset veryslow \
-threads 0 -b:v 3000k -x264opts frameref=15:fast_pskip=0 -f rawvideo -y /dev/null

コンテナの形式は出力ファイルの拡張子 ({{ic|.mkv}}) から自動的に検出して変換されます:

$ ffmpeg -i ''video''.VOB -acodec aac -b:a 256k -ar 96000 -vcodec libx264 \
-pass 2 -preset veryslow -threads 0 -b:v 3000k -x264opts frameref=15:fast_pskip=0 ''video''.mkv

==== 動画の手ブレ補正 ====

vbid.stab プラグインを使ってツーパスで手ブレ補正 (ビデオ安定化) を行います。

===== ファーストパス =====

ファーストパスでは補正パラメータを記録してファイルに書き出します、または視覚分析のテスト動画を作成します。

* 補正パラメータを記録してファイルだけに書き出す: {{bc|1=$ ffmpeg -i input -vf vidstabdetect=stepsize=4:mincontrast=0:result=transforms.trf -f null -}}
* 補正パラメータをファイルに書きだして、視覚分析用のテストビデオ "output-stab" を作成: {{bc|1=$ ffmpeg -i input -vf vidstabdetect=stepsize=4:mincontrast=0:result=transforms.trf output-stab}}

===== セカンドパス =====

セカンドパスではファーストパスで作成した補正パラメータを解析して、それを使って "output-stab_final" を生成します。セカンドパスで他のフィルターを適用することもでき、変換を繰り返す必要をなくして画質を最大限保つことができます。下のコマンドでは以下のオプションを使っています:

* {{ic|unsharp}}: vid.stab の作者によって推奨されています。下の例ではデフォルトの 5:5:1.0:5:5:1.0 を使っています。
* {{ic|1=fade=t=in:st=0:d=4}}: 4秒間のフェードインをファイルの冒頭に挟みます。
* {{ic|1=fade=t=out:st=60:d=4}}: 動画の60秒目から4秒間のフェードアウトを挟みます。
* {{ic|-c:a pcm_s16le}}: XAVC-S コーデックは pcm_s16be で記録されロスレスの pcm_s16le に変換されます。

$ ffmpeg -i input -vf vidstabtransform=smoothing=30:interpol=bicubic:input=transforms.trf,unsharp,fade=t=in:st=0:d=4,fade=t=out:st=60:d=4 -c:v libx264 -tune film -preset veryslow -crf 8 -x264opts fast_pskip=0 -c:a pcm_s16le output-stab_final

=== x265 ===

以下の例は、パラメータを指定せずに libx265 を呼び出した場合のデフォルトを示します (Constant Rate Factor エンコード):

ffmpeg -i input -c:v libx265 -crf 28 -preset medium -c:a libvorbis output.mp4

詳細は FFmpeg の [https://trac.ffmpeg.org/wiki/Encode/H.265 H.265/HEVC Video Encoding Guide] を参照してください。

=== シングルパス MPEG-2 (ニアロスレス) ===

DVD 標準のパラメータに FFmpeg を自動的に設定することができます。約 30 FPS の DVD [[Wikipedia:ja:MPEG-2|MPEG-2]] にエンコードするには:

$ ffmpeg -i ''video''.VOB -target ntsc-dvd ''output''.mpg

約 24 FPS の DVD MPEG-2 にエンコードするには:

$ ffmpeg -i ''video''.VOB -target film-dvd ''output''.mpg

=== 字幕 ===

==== 抽出 ====

MPEG-2 や Matroska などのコンテナファイルに埋め込まれた字幕を抽出して、SRT や SSA、WebVTT などの字幕形式に変換することができます。[https://trac.ffmpeg.org/wiki/ExtractSubtitles]

* ファイルに字幕ストリームが含まれているか確認してください:

{{hc|$ ffprobe -hide_banner foo.mkv|
...
Stream #0:0(und): Video: h264 (High), yuv420p, 1920x800 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Metadata:
CREATION_TIME : 2012-06-05 05:04:15
LANGUAGE : und
Stream #0:1(und): Audio: aac, 44100 Hz, stereo, fltp (default)
Metadata:
CREATION_TIME : 2012-06-05 05:10:34
LANGUAGE : und
HANDLER_NAME : GPAC ISO Audio Handler
'''Stream #0:2: Subtitle: ssa (default)'''
}}

* {{ic|foo.mkv}} には SSA の字幕が埋め込まれており、別のファイルに抽出することが可能です:

$ ffmpeg -i foo.mkv foo.ssa

字幕を望ましい形式 (例として [[Wikipedia:ja:SubRip|SubRip]]) に保存するには {{ic|-c:s srt}} を追加してください:

$ ffmpeg -i foo.mkv -c:s srt foo.srt

複数の字幕が存在する場合、{{ic|-map ''key'':''stream''}} パラメータを使用して抽出するストリームを指定する必要があります:

$ ffmpeg -i foo.mkv -map 0:2 foo.ssa

==== ハードサブ ====

(FFmpeg wiki の記事の [https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo HowToBurnSubtitlesIntoVideo] に基づく説明)

[[Wikipedia:Hardsub|ハードサブ]]は動画に字幕を焼きこむことになります。ハードサブは無効化できず、言語の切り替えやフォントサイズのカスタマイズもできないため、推奨されない場合もあります。不明な場合は、ハードサブではなくソフトサブを使用してください。

* {{ic|foo.mpg}} に {{ic|foo.ssa}} の字幕を重ねるには:

$ ffmpeg -i foo.mpg -vf subtitles=foo.ssa out.mpg

=== ボリュームゲイン ===

ボリュームゲインは ''ffmpeg'' のフィルタ機能で変更できます。まず、{{ic|-af}} または {{ic|-filter:a}} を使って音声ストリームを選択し、次に、''volume'' フィルタの後にそのストリームに対するゲインを指定してください。例えば:

$ ffmpeg -i input.flac -af '''volume=1.5''' ouput.flac

ここで、{{ic|1=volume=1.5}} によって 150% のボリュームゲインとなります。1.5 から 0.5 にすると、ボリュームが半分になります。ボリュームフィルタにはデシベル単位を渡すこともできます。{{ic|1=volume=3dB}} とすると、ボリュームが 3dB 増え、{{ic|1=volume=-3dB}} とすると 3dB 減ります。

{{Note|ファイルのボリュームゲインを倍にすることは、ボリュームを倍にすることと同じではありません。実験して正しいボリュームを見つける必要があります。}}

{{Tip|''volumedetect'' フィルタを使用することで、ファイルの現在の平均ボリュームとピークボリュームを調べることができます: {{ic|ffmpeg -i input.flac -af volumedetect -f null -}}。そして、目標のレベルと現在のレベルとの差を ''volume'' フィルタに渡すことで、望みのレベルにすることができます。}}

=== ボリュームノーマライゼーション ===

''loudnorm'' フィルタによるノーマライゼーションにより、平均ボリュームとピークボリュームを特定の値にすることができます。''fmpeg'' のデフォルトの平均ラウドネス、ピークラウドネス、そしてレンジラウドネスの目標値 (それぞれ、-24 LUFS、-2 dBTP、7 LU) を使って、ファイルの知覚ラウドネスを正規化するには、以下のコマンドを使用してください:

$ ffmpeg -i input.flac -af '''loudnorm''' output.flac

別のラウドネスプロファイルを得るには、''loudnorm'' フィルタのパラメータ {{ic|i}}、{{ic|tp}}、そして {{ic|lra}} を使って、それぞれ ''i''ntegrated、''t''rue ''p''eak、''l''oudness ''ra''nge を指定してください。例えば、デフォルトよりも高い知覚ラウドネスにするには:

$ ffmpeg -i input.flac -af loudnorm=i=-16:tp=-1.5:lra=11:print_format=summary output.flac

この例では、オーディオファイルの入力ラウドネスと出力ラウドネスを表示するために {{ic|1=print_format=summary}} も追加しています。

{{Note|このフィルタはツーパスモードもサポートしています。最初の実行から測定されたラウドネス値を抽出し、その値を使って2回めの実行で線形ノーマライゼーションを行います。詳細は [https://ffmpeg.org/ffmpeg-filters.html#loudnorm ffmpeg loudnorm ドキュメント]を参照してください。}}

{{Tip|ファイルの現在のラウドネスを調べるには、{{ic|1=ffmpeg -i input.flac -af loudnorm=print_format=summary -f null -}} を使ってください。}}

=== 音声を抽出する ===

{{hc|$ ffmpeg -i ''video''.mpg output.ext|
...
Input #0, avi, from '''video''.mpg':
Duration: 01:58:28.96, start: 0.000000, bitrate: 3000 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720x480 [PAR 1:1 DAR 16:9], 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0.1: Audio: ac3, 48000 Hz, stereo, s16, 384 kb/s
Stream #0.2: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s
Stream #0.3: Audio: dts, 48000 Hz, 5.1 768 kb/s
...
}}

多重化されている一番目の ({{ic|-map 0:1}}) [[Wikipedia:ja:ドルビーデジタル|AC-3]] でエンコードされた音声ストリームをファイルに抽出する:

$ ffmpeg -i ''video''.mpg -map 0:1 -acodec copy -vn ''video''.ac3

三番目の ({{ic|-map 0:3}}) [[Wikipedia:ja:デジタル・シアター・システムズ|DTS]] 音声ストリームをビットレートが 192 kb/s で[[Wikipedia:ja:サンプリングレート|サンプリングレート]]が 96000 Hz の [[Wikipedia:ja:AAC|AAC]] ファイルに変換する:

$ ffmpeg -i ''video''.mpg -map 0:3 -acodec aac -b:a 192k -ar 96000 -vn ''output''.aac

{{ic|-vn}} は動画ストリームの処理を無効にします。

時間を指定して音声ストリームを抽出する:

$ ffmpeg -ss 00:01:25 -t 00:00:05 -i ''video''.mpg -map 0:1 -acodec copy -vn ''output''.ac3

{{ic|-ss}} で開始時間を、{{ic|-t}} で長さを指定します。

=== 音声を除去する ===

# 一番目の動画ストリーム ({{ic|-map 0:0}}) と二番目の AC-3 音声ストリーム ({{ic|-map 0:2}}) をコピーします。
# AC-3 音声ストリームをビットレートが 128 kb/s でサンプリングレートが 48000 Hz の2チャンネルの MP3 に変換します。

$ ffmpeg -i ''video''.mpg -map 0:0 -map 0:2 -vcodec copy -acodec libmp3lame \
-b:a 128k -ar 48000 -ac 2 ''video''.mkv

{{hc|$ ffmpeg -i ''video''.mkv|
...
Input #0, avi, from '''video''.mpg':
Duration: 01:58:28.96, start: 0.000000, bitrate: 3000 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720x480 [PAR 1:1 DAR 16:9], 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0.1: Audio: mp3, 48000 Hz, stereo, s16, 128 kb/s
}}

{{Note|無駄な音声ストリームを削除することで余ったビットを画質の向上に割り当てることができます。}}

=== ファイルを分割する ===

{{ic|copy}} コーデックを使うことでエンコーディングを変更せずにファイルの操作を行うことができます。例えば、次のコマンドであらゆるメディアファイルを簡単に2つに分けることが可能です:

$ ffmpeg -i file.ext -t 00:05:30 -c copy part1.ext -ss 00:05:30 -c copy part2.ext

=== ハードウェアビデオアクセラレーション ===

[https://trac.ffmpeg.org/wiki/HWAccelIntro ハードウェアアクセラレーション API] を使用することで、エンコード/デコードのパフォーマンスを向上させることができます。しかし、特定の種類のコーデックしか使えませんし、場合によっては、ソフトウェアエンコードを使ったときと同じ結果が得られるとは限りません。

==== VA-API ====

Intel CPU ({{Pkg|intel-media-driver}} か {{Pkg|libva-intel-driver}} が必要) を使っている場合や、特定の AMD GPU でオープンソースの [[AMDGPU]] ドライバー ({{Pkg|mesa}} が必要) を使っている場合、[[VA-API]] を使用してエンコードとデコードができます。

利用可能なパラメータとサポートされているプラットフォームに関する情報は、[https://trac.ffmpeg.org/wiki/Hardware/VAAPI FFmpeg のドキュメント] を参照してください。

サポートされている H.264 コーデックを使用してエンコードする例:

$ ffmpeg -threads 1 -i file.ext -vaapi_device /dev/dri/renderD128 -vcodec h264_vaapi -vf format='nv12|vaapi,hwupload' output.mp4

{{Note|通常、VA-API は、(FFmpeg パッケージの依存関係である) {{Pkg|libva}} に含まれるヘッダとライブラリが検出されれば、ビルド時に {{Pkg|ffmpeg}} の自動検出機能によって有効化されます。}}

クイックリファレンスとして、constant quality エンコードを行う例を以下に挙げます:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -i input.mp4 -vf 'format=nv12,hwupload' -c:v hevc_vaapi -f mp4 -rc_mode 1 -qp 25 output.mp4

hevc_vaapi を使用する場合、-qp を 25 (視覚的に等価) からそれ以上 (28 から非常に小さな視覚的な損失が発生し始めます) の間で調整してください。h264_vaapi を使用する場合、18 (視覚的に等価) からそれ以上 (20 から非常に小さな視覚的な損失が発生し始めます) の間で調整してください。また、hevc_vaapi は h264_vaapi よりも 50% 高速にエンコードできるようです。

==== NVIDIA NVENC/NVDEC ====

プロプライエタリな [[NVIDIA]] ドライバを使用していて、{{Pkg|nvidia-utils}} パッケージがインストールされている場合、[[Wikipedia:Nvidia NVENC|NVENC]] と [[Wikipedia:Nvidia NVDEC|NVDEC]] をエンコード/デコードに使用できます。サポートされている GPU は [[Wikipedia:GeForce 600 series|600 シリーズ]]からです。詳細は [[ハードウェアビデオアクセラレーション#NVIDIA]] を参照してください。

テクニックが[https://web.archive.org/web/20190808223352/https://gist.github.com/Brainiarc7/8b471ff91319483cdb725f615908286e こちらの古い gist] に載っています。NVENC は [[CUDA]] と似ているため、ターミナルセッションからでも動作します。ハードウェア NVENC は Intel の VA-API エンコーダよりも数倍高速です。

利用可能なオプションを表示するには以下のコマンドを実行してください ({{ic|hevc_nvenc}} も使えます):

$ ffmpeg -help encoder=h264_nvenc

使用例:

$ ffmpeg -i source.ext -c:v h264_nvenc -rc constqp -qp 28 output.mkv

==== Intel QuickSync (QSV) ====

[https://www.intel.com/content/www/us/en/architecture-and-technology/quick-sync-video/quick-sync-video-general.html Intel® Quick Sync Video] は、[[Intel]] GPU のメディア処理機能を使用して高速なデコードとエンコードを行い、プロセッサが他のタスクを処理できるようにしてシステムの応答性を向上させます。

これを使用するには、'''libmfx''' ランタイム実装がインストールされている必要があります。'''libmfx''' は、ハードウェアプラットフォームに基づいて実行時に実装をロードするディスパッチャライブラリです。
[[Wikipedia:ja:Broadwellマイクロアーキテクチャ|Broadwell]] から [[Wikipedia:ja:Rocket Lakeマイクロプロセッサ|Rocket Lake]] までの GPU で実行する場合、このライブラリは {{Pkg|intel-media-sdk}} をランタイム実装としてロードします。
[[Wikipedia:ja:Tiger Lakeマイクロアーキテクチャ|Tiger Lake]] 及びそれ以降の GPU においては、'''libmfx''' は {{Pkg|vpl-gpu-rt}} をロードします。[https://github.com/intel/vpl-gpu-rt#system-requirements vpl-gpu-rt system-requirements]も参照してください。
単一の Intel GPU を搭載しているシステムでは、ランタイム実装を変更したり選択したりできません。対応する実装は、ハードウェアに応じてインストールする必要があります。

上記のランタイムをインストールしないと、以下のようなエラーが発生します:

[AVHWDeviceContext @ 0x558283838c80] Error initializing an MFX session: -3.
Device creation failed: -1313558101.

QuickSync の使用方法は [https://trac.ffmpeg.org/wiki/Hardware/QuickSync FFmpeg Wiki] で説明されています。''libmfx'' を直接使わずに ''iHD'' ドライバか ''i965'' ドライバで [[VA-API]] [https://trac.ffmpeg.org/wiki/Hardware/VAAPI] を使用することが推奨されます。エンコード例は FFmpeg Wiki の ''Hybrid transcode'' セクションを、ドライバに関する指示は [[ハードウェアビデオアクセラレーション#VA-API の設定]] を参照してください。

==== AMD AMF ====

AMD は、[[AMDGPU PRO]] プロプライエタリパッケージを使用して AMD Video Coding Engine (GPU エンコード) によって Linux で H264 のみのビデオエンコードを行うためのサポートを追加し、ffmpeg は AMF ビデオエンコードのサポートを追加しました。なので、h264_amf ビデオエンコーダを使ってエンコードするには、{{AUR|amf-amdgpu-pro}} が必要です。[[AMDGPU PRO]] パッケージによって提供されている ICD ファイルを環境変数でリンクする必要がある場合があります。そうしないと、ffmpeg はオープンな AMDGPU の ICD ファイルを使用してしまい、このビデオエンコーダを使用できません。エンコードを行うコマンドの例は以下のようになります:

$ VK_DRIVER_FILES=/usr/share/vulkan/icd.d/amd_pro_icd64.json ffmpeg -hwaccel auto -vaapi_device /dev/dri/renderD128 -i input.mkv -c:v h264_amf -rc 1 -b:v 8M h264_amf_8M.mp4

クイックリファレンスとして、constant quality エンコードを行う例を挙げましょう:

$ VK_DRIVER_FILES=/usr/share/vulkan/icd.d/amd_pro_icd64.json ffmpeg -hwaccel auto -vaapi_device /dev/dri/renderD128 -i input.mp4 -c:v h264_amf -f mp4 -rc 0 -qp_b 22 -qp_i 22 -qp_p 22 -quality 2 output.mp4

3つの -qp_(b|i|p) を調整してください。18 にすると視覚的に等価で、22 から非常に小さな視覚的な損失が発生し始めます。

=== アニメーション GIF ===

一般に、アニメーション GIF は、画像品質が悪く、ファイルサイズが比較的大きく、音声サポートもないので、動画フォーマットとして素晴らしい選択肢とは言えません。しかし、ウェブでは依然として頻繁に使用されています。以下のコマンドを使うことで、動画をアニメーション GIF に変換することができます:

$ ffmpeg -i input.mp4 -vf "fps=10,split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" -loop -1 output.gif

パレットフィルタを使って高品質な GIF を生成する方法については、https://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html を見てください。

== プリセットファイル ==

デフォルトの[https://ffmpeg.org/ffmpeg.html#Preset-files プリセットファイル]で {{ic|~/.ffmpeg}} を作成する:

$ cp -iR /usr/share/ffmpeg ~/.ffmpeg

新しいファイルを作成したりデフォルトのプリセットファイルを編集する:

{{hc|~/.ffmpeg/libavcodec-vhq.ffpreset|2=
vtag=DX50
mbd=2
trellis=2
flags=+cbp+mv0
pre_dia_size=4
dia_size=4
precmp=4
cmp=4
subcmp=4
preme=2
qns=2
}}

=== プリセットファイルを使う ===

{{ic|-vcodec}} の宣言の後に {{ic|-vpre}} オプションを加えて下さい。

==== libavcodec-vhq.ffpreset ====

* {{ic|libavcodec}} '''=''' vcodec/acodec の名前
* {{ic|vhq}} '''=''' 使用するプリセットの名前
* {{ic|ffpreset}} '''=''' FFmpeg プリセットの拡張子

== ヒントとテクニック ==

=== 出力を簡略化 ===

以下のオプションを組み合わせて使うことで、出力の詳細さを好きなレベルまで減らすことができます:

* {{ic|-hide_banner}}: 著作権表示、ビルドオプション、そしてライブラリのバージョンが表示されなくなります
* {{ic|-loglevel}}: ログレベルを調整します (微調整オプションが利用できます)。例: {{ic|-loglevel warning}}
* {{ic|-nostats}}: エンコードの進捗/統計が表示されなくなります

=== 動画の再生時間を出力 ===

$ ffprobe -select_streams v:0 -show_entries stream=duration -of default=noprint_wrappers=1:nokey=1 file.ext

=== ストリーム情報を JSON で出力 ===

$ ffprobe -v quiet -print_format json -show_format -show_streams file.ext

=== X フレームごとに動画のスクリーンショットを作成する ===

$ ffmpeg -i file.ext -an -s 319x180 -vf fps=1/'''100''' -qscale:v 75 %03d.jpg

=== メタデータの変更 ===

メタデータは直接変更することはできません。メタデータをエクスポートして変更し、新しいファイルにマージする必要があります。

既存の（グローバル）メタデータをテキストファイルに抽出する:

$ ffmpeg -i 'song.mp3' -f ffmetadata song_metadata.txt

テキストファイルからメタデータを含む新しいファイルを作成する:

$ ffmpeg -i 'song.mp3' -f ffmetadata -i new_metadata.txt -map_metadata 1 -id3v2_version 4 song_new.mp3

{{ic|-map_metadata 1}} は、ffmpeg に 2 番目のファイル (インデックスは 0 から始まる) のメタデータを使用するように指示します。

グローバルメタデータの他に、各ストリームは独自のメタデータを持つこともできます。たとえば、{{ic|-map_metadata:s:v 0:s:v}} および {{ic|-map_metadata:s:a 0:s:a}} を使用してエクスポートします。

{{ic|ffprobe}} は({{Pkg|ffmpeg}} パッケージからも同様に) 、default、compact/csv、flat、ini、json、xml など、さらに多くのエクスポート形式を提供します。

== 参照 ==

* [https://ffmpeg.org/ffmpeg.html FFmpeg documentation] - 公式ドキュメント
* [https://trac.ffmpeg.org/wiki FFmpeg Wiki] - 公式 wiki
* [http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html Encoding with the x264 codec] - MEncoder ドキュメント
* [https://avidemux.org/admWiki/doku.php?id=tutorial:h.264 H.264 encoding guide] - Avidemux wiki
* [http://howto-pages.org/ffmpeg/ Using FFmpeg] - Linux how to pages
* サポートしている音声・動画ストリームの[https://ffmpeg.org/general.html#Supported-File-Formats_002c-Codecs-or-Features リスト]

{{TranslationStatus|FFmpeg|2023-07-23|776189}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:26:55Z

ELC: /* 参照 */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:25:43Z

ELC: /* オプション ROM のダイジェスト値を登録する */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:22:32Z

ELC: /* 公式の ISO で MOK と shim を使用する */ 英語ページより追加

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、''digest-to-efi-sig-list'' を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:12:06Z

ELC: /* ブートローダを PreLoader に置き換える */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、''digest-to-efi-sig-list'' を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:09:30Z

ELC: /* 公式の ISO をカスタムの鍵で署名する */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ 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 を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

{{Note|ISO の GRUB EFI バイナリ ({{ic|EFI/BOOT/BOOTx64.EFI}}) は {{ic|--disable-shim-lock}} でビルドされているため、shim で使用することはできません。これは GRUB の制限であり、GRUB に shim かカスタムの署名のどちらか一方との互換性を持たせることはできますが、同時に両方との互換性を持たせることはできません。}}

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-cpx /EFI/BOOT/BOOTx64.EFI ./
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ mv BOOTx64.EFI loader.efi
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、''digest-to-efi-sig-list'' を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:05:26Z

ELC: /* 登録されたハッシュ/鍵を削除する */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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 シェルを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|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 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

{{Note|ISO の GRUB EFI バイナリ ({{ic|EFI/BOOT/BOOTx64.EFI}}) は {{ic|--disable-shim-lock}} でビルドされているため、shim で使用することはできません。これは GRUB の制限であり、GRUB に shim かカスタムの署名のどちらか一方との互換性を持たせることはできますが、同時に両方との互換性を持たせることはできません。}}

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-cpx /EFI/BOOT/BOOTx64.EFI ./
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ mv BOOTx64.EFI loader.efi
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、''digest-to-efi-sig-list'' を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:04:41Z

ELC: /* shim で鍵を使う */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

# mokutil --delete-hash <削除するハッシュ>
Input password:

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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 シェルを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|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 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

{{Note|ISO の GRUB EFI バイナリ ({{ic|EFI/BOOT/BOOTx64.EFI}}) は {{ic|--disable-shim-lock}} でビルドされているため、shim で使用することはできません。これは GRUB の制限であり、GRUB に shim かカスタムの署名のどちらか一方との互換性を持たせることはできますが、同時に両方との互換性を持たせることはできません。}}

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-cpx /EFI/BOOT/BOOTx64.EFI ./
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ mv BOOTx64.EFI loader.efi
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、''digest-to-efi-sig-list'' を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:02:53Z

ELC: /* shim をセットアップする */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio]] のポストフックで自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

# mokutil --delete-hash <削除するハッシュ>
Input password:

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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 シェルを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|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 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

{{Note|ISO の GRUB EFI バイナリ ({{ic|EFI/BOOT/BOOTx64.EFI}}) は {{ic|--disable-shim-lock}} でビルドされているため、shim で使用することはできません。これは GRUB の制限であり、GRUB に shim かカスタムの署名のどちらか一方との互換性を持たせることはできますが、同時に両方との互換性を持たせることはできません。}}

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-cpx /EFI/BOOT/BOOTx64.EFI ./
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ mv BOOTx64.EFI loader.efi
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、''digest-to-efi-sig-list'' を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:01:37Z

ELC: /* PreLoader */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ 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 は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -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 noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -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 -noenc -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

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/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")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''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

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ 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 に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|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

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --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 に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -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

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|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

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio]] のポストフックで自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

# mokutil --delete-hash <削除するハッシュ>
Input password:

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ 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'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ 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 シェルを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|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 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

{{Note|ISO の GRUB EFI バイナリ ({{ic|EFI/BOOT/BOOTx64.EFI}}) は {{ic|--disable-shim-lock}} でビルドされているため、shim で使用することはできません。これは GRUB の制限であり、GRUB に shim かカスタムの署名のどちらか一方との互換性を持たせることはできますが、同時に両方との互換性を持たせることはできません。}}

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-cpx /EFI/BOOT/BOOTx64.EFI ./
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ mv BOOTx64.EFI loader.efi
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、''digest-to-efi-sig-list'' を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}