「Unified Extensible Firmware Interface/セキュアブート」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(恐らくファイルのパスが変わっているため修正。英語版wikiと自分の環境がソースです。)
(ユニファイドカーネルイメージに変更)
 
(2人の利用者による、間の69版が非表示)
1行目: 1行目:
 
[[Category:ブートプロセス]]
  
[[Category:ブートプロセス]]
−
[[en:Secure Boot]]
 +
[[en:Unified Extensible Firmware Interface/Secure Boot]]
−
[[zh-hans:Secure Boot]]
 +
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
 
{{Related articles start}}
  
{{Related articles start}}
  +
{{Related|Arch ブートプロセス}}
 
{{Related|Unified Extensible Firmware Interface}}
  
{{Related|Unified Extensible Firmware Interface}}
  +
{{Related|セキュリティ}}
 
{{Related articles end}}
  
{{Related articles end}}
−
Linux における Secure Boot の概要については [http://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks の Secure Boot に関する記事] を見て下さい。この記事では Arch Linux で Secure Boot を設定する方法に焦点を置いています。
  
   
  +
[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。
−
== 署名済みのブートローダーを使う ==
  
   
  +
なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。
−
署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。
  
   
  +
{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}
−
=== archiso の起動 ===
  
−
EFI アプリケーション {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} が archiso に追加されたことで Secure Boot を有効にして archiso を起動することが可能になりました。{{ic|Failed to Start loader... I will now execute HashTool}} というメッセージが表示されます。HashTool を使って {{ic|loader.efi}} と {{ic|vmlinzu.efi}} のハッシュを登録するには、以下の手順に従って下さい:
  
−
* {{ic|OK}} を選択してください
  
−
* HashTool のメインメニューから {{ic|Enroll Hash}} を選択し、{{ic|\loader.efi}} を選んで {{ic|Yes}} で確定します。また、{{ic|Enroll Hash}} と {{ic|archiso}} を選択して archiso のディレクトリに入り、{{ic|vmlinuz-efi}} を選んで {{ic|Yes}} で確定してください。それから {{ic|Exit}} を選択してブートデバイスの選択メニューに戻って下さい。
  
−
* ブートデバイスの選択メニューから {{ic|Arch Linux archiso x86_64 UEFI CD}} を選択して下さい
  
−
archiso が起動し、シェルプロンプトが表示され、自動的に root でログインがされます。archiso が Secure Boot で起動しているかどうか確認するには、次のコマンドを使って下さい (1234 という所はマシンによって異なります。タブ補完を使ったり efi 変数を表示することで調べることができます):
  
   
  +
== セキュアブートの状態を確認する ==
−
$ od -An -t u1 /sys/firmware/efi/efivars/SecureBoot-1234abcde-5678-
  
   
  +
=== OS の起動前 ===
−
このコマンドで返ってくるリストの最後が {{ic|1}} ならば Secure Boot で起動しています。例:
  
  +
  +
OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。
  +
  +
起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。
  +
  +
ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。
  +
  +
=== OS の起動後 ===
  +
  +
[[systemd]] を使用するシステム上では、[[systemd-boot]] でセキュアブートの状態を簡単に確認できます:
  +
  +
{{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
  +
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*
  +
  +
セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:
   
 
6 0 0 0 1
  
6 0 0 0 1
   
  +
しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:
−
次のコマンドを実行すると、詳しい状態を表示できます:
  
−
# bootctl status
  
   
  +
{{hc|# dmesg {{!}} grep -i secure|
−
=== PreLoader ===
  
  +
[ 0.013442] Secure boot disabled
  +
[ 0.013442] 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 を含む、ユーザ署名済み結合 [[EFISTUB]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
  +
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
  +
# [[TPM]] を使うことでさらに改善することができるかもしれませんが、ツールやサポートの問題がこれを難しくしています。
  +
  +
シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。
  +
  +
[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。
  +
  +
=== 自分の鍵を使う ===
  +
  +
{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書を使って署名されている]]ためです。}}
  +
  +
セキュアブートでは以下の鍵が使われます:
  +
  +
; 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 の起動前]] で説明されています。
  +
  +
==== 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}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}
  +
  +
セキュアブートの状態を再び確認してください:
  +
  +
$ 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 -nodes -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
  +
$ openssl x509 -outform DER -in PK.crt -out PK.cer
  +
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
  +
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth
  +
  +
"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:
  +
  +
$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth
  +
  +
Key Exchange Key:
  +
  +
$ openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
  +
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
  +
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
  +
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth
  +
  +
Signature Database key:
  +
  +
$ openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
  +
$ openssl x509 -outform DER -in db.crt -out db.cer
  +
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
  +
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth
  +
  +
====== ヘルパースクリプト ======
  +
  +
便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[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}}
  +
}}
  +
  +
次の起動時に、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 を使う ======
  +
  +
{{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]] のポストフックを使って、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 による完全に自動化されたユニファイドカーネルの生成と署名 =====
  +
  +
{{Note|''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}}) とカーネルを登録する必要があります。
  
起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。
33行目: 481行目:
 
{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}
  
{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}
   
  +
{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}
−
==== PreLoader の設定 ====
  
  +
  +
===== PreLoader をセットアップする =====
   
−
{{Warning|{{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/ 手動でダウンロード] します。}}
 +
{{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]] の場合、以下を実行:
  
{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:
47行目: 497行目:
 
最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:
  
最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:
   
−
# efibootmgr --disk /dev/sd'''X''' --part '''Y''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi
 +
# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi
   
 
{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。
  
{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。
53行目: 503行目:
 
上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。
  
上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。
   
−
===== フォールバック =====
 +
====== フォールバック ======
   
 
カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:
  
カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:
   
−
# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/Boot
 +
# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
−
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/Boot/loader.efi
 +
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi
   
−
{{ic|PreLoader.efi}} をコピーして名前を変更します:
 +
{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:
   
−
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Boot/bootx64.efi
 +
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI
   
 
Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:
  
Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:
73行目: 523行目:
 
上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。
  
上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。
   
−
Secure Boot を有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。
 +
セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。
   
−
==== PreLoader の削除 ====
 +
===== 起動途中で使用するには? =====
  +
  +
{{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'' を選んでください。
  +
  +
===== PreLoader を除去する =====
   
 
{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}
  
{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}
   
−
インストールした {{AUR|preloader-signed}} パッケージやコピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:
 +
{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:
   
 
# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
  
# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
 
# rm ''esp''/EFI/systemd/loader.efi
  
# rm ''esp''/EFI/systemd/loader.efi
−
# efibootmgr -b ''N'' -B
 +
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
 
# bootctl update
  
# bootctl update
   
 
{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。
  
{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。
   
−
{{Note|上記のコマンドは一番簡単な場合です。他のファイルを作成した場合はそれらも削除する必要があります。}}
 +
{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
  +
}}
   
  +
===== 登録したハッシュを削除する =====
−
=== shim ===
  
  +
  +
MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。
  +
  +
{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:
  +
  +
# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi
  +
  +
PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。
  +
  +
==== shim ====
   
 
起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。
  
起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。
   
  +
{{Note|
−
{{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 の設定 ====
 +
===== shim をセットアップする =====
  +
  +
{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}
   
 
{{AUR|shim-signed}} を[[インストール]]してください。
  
{{AUR|shim-signed}} を[[インストール]]してください。
   
−
使用している [[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください:
 +
現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください:
  +
  +
# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi
   
  +
''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:
−
# mv ''esp''/EFI/BOOT/BOOTX64.efi ''esp''/EFI/BOOT/grubx64.efi
  
   
  +
{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}
−
''shim'' と ''MokManager'' を ESP のブートローダーディレクトリにコピーします。ブートローダーの元の名前を {{ic|shimx64.efi}} の名前として使います:
  
   
−
# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTX64.efi
 +
# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
 
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/
  
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/
   
  +
最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:
−
''shim'' は Machine Owner Key と MokList に保存されたハッシュでバイナリを認証できます:
  
   
  +
# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI
−
; Machine Owner Key (MOK): ユーザーが生成して EFI バイナリの署名に使用する鍵。
  
−
; ハッシュ: EFI バイナリの SHA256 ハッシュ。
  
   
  +
''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。
−
ハッシュを使うほうが簡単ですが、ブートローダーやカーネルのアップデートのたびに MokManager でハッシュを追加する必要があります。MOK を使用する場合、鍵の追加は一度だけですが、ブートローダーやカーネルをアップデートするたびに署名が必要です。
  
   
  +
; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
−
===== shim でハッシュを使う =====
  
  +
; hash: EFI バイナリの SHA256 ハッシュ
   
  +
ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。
−
''shim'' は MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。
  
  +
  +
====== shim でハッシュを使う ======
  +
  +
''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。
   
 
''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。
  
''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。
   
−
===== shim で鍵を使う =====
 +
====== shim で鍵を使う ======
   
 
{{Pkg|sbsigntools}} をインストールしてください。
  
{{Pkg|sbsigntools}} をインストールしてください。
136行目: 617行目:
 
$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
  
$ 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
  
$ 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}} という名前の) ブートローダーとカーネルに署名:
  
({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:
142行目: 625行目:
 
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi
  
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi
   
−
ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。
 +
ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitpcio]] のポストフックで自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:
  +
  +
{{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 System Partition]] を使うことができます)。
 +
{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。
   
 
再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。
  
再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。
150行目: 652行目:
 
''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。
  
''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。
   
−
==== shim の削除 ====
 +
====== shim で鍵と GRUB を使う ======
   
  +
手順は [[GRUB#Shim-lock]] を見てください。
−
{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。
  
   
−
== 自分で署名した鍵を使う ==
 +
===== 登録されたハッシュ/鍵を削除する =====
−
{{Tip|
  
−
* [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot] を読むことを推奨します。
  
−
* {{AUR|cryptboot}} パッケージに含まれている {{ic|cryptboot-efikeys}} スクリプトを使うことで鍵の作成・登録・ブートローダーの署名・署名の検証が簡単に行なえます。}}
  
   
  +
MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。
−
Secure Boot では以下の鍵が使われます:
  
−
;Platform Key (PK): トップレベル鍵
  
−
;Key Exchange Key (KEK): 署名データベースや EFI バイナリに署名するのに使われる鍵
  
−
;Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
  
−
;Forbidden Signatures Database (dbx): EFI バイナリをブラックリスト化するのに使われる鍵やハッシュが含まれます
  
   
  +
MOK データベースは {{Pkg|mokutil}} で管理できます。
−
詳しい説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。
  
   
  +
登録された鍵とハッシュを一覧表示する:
−
=== カスタム鍵 ===
  
   
  +
# mokutil --list-enrolled
−
Secure Boot を使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。
  
   
  +
データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。
−
Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。
  
   
  +
# mokutil --delete-hash <削除するハッシュ>
−
=== 鍵の作成 ===
  
  +
Input password:
   
  +
データベースから鍵を削除する:
−
鍵を生成するには、{{Pkg|efitools}} の[[インストール]]が必要です。
  
   
  +
# mokutil --delete MOK.cer
−
鍵と複数の形式の証明書を作成する必要があります:
  
−
# 鍵を作成して {{ic|sbsign}} のための '''PEM''' 形式の証明書を作成
  
−
# ファームウェア用に証明書を '''DER''' 形式に変換
  
−
# {{ic|KeyTool}} のために証明書を '''EFI Signature List''' に変換
  
   
  +
次回のブート時に削除されるハッシュ/鍵を一覧表示する:
−
; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
  
−
; {{ic|.crt}}: ''sbsign'' で必要な PEM 形式の証明書。
  
−
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
  
−
; {{ic|.esl}}: ''KeyTool'' やファームウェアのための EFI 署名リストの証明書。
  
−
; {{ic|.auth}}: ''KeyTool'' やファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (署名済みの証明書アップデートファイル)。
  
   
  +
# mokutil --list-delete
−
所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成:
  
−
$ uuidgen --random > GUID.txt
  
   
  +
次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。
−
Platform Key:
  
−
$ openssl req -newkey rsa:2048 -nodes -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
  
−
$ openssl x509 -outform DER -in PK.crt -out PK.cer
  
−
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
  
−
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth
  
   
  +
===== shim を除去する =====
−
空のファイルを使って "User Mode" で Platform Key を削除できるように署名:
  
−
$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null rm_PK.auth
  
   
  +
{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。
−
Key Exchange Key:
  
−
$ openssl req -newkey rsa:2048 -nodes -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
  
−
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
  
−
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
  
−
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth
  
   
  +
== セキュアブートを保護する ==
−
Signature Database:
  
−
$ openssl req -newkey rsa:2048 -nodes -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
  
−
$ openssl x509 -outform DER -in db.crt -out db.cer
  
−
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
  
−
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth
  
   
  +
マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。
−
==== 鍵のアップデート ====
  
   
  +
ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。
−
一度 Secure Boot を "User Mode" にしたら KEK, db, dbx を変更するには上位の鍵による署名が必要です。
  
   
  +
== ヒントとテクニック ==
−
例えば、db 鍵を新しく置き換えたい場合:
  
   
  +
=== ISO の再パック ===
−
# [[#鍵の作成|新しい鍵を作成]]
  
−
# EFI 署名リストに変換
  
−
# EFI 署名リストに署名
  
−
# 署名された証明書アップデートファイルを登録
  
   
  +
{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。
−
$ 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
  
   
  +
==== 公式の ISO をカスタムの鍵で署名する ====
−
db 鍵を置き換えるかわりに Signature Database に別の鍵を追加したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):
  
   
  +
ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。
−
$ 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}} が作成されたら[[#ファームウェアに鍵を登録|登録]]してください。
 +
まず、関連するファイルと 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 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:
−
Secure Boot を有効にすると ("User Mode")、署名したバイナリしか起動できなくなるため、カーネルと[[ブートローダー]]に署名が必要です。
  
   
  +
$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux
−
{{Pkg|sbsigntools}} をインストールしてください。
  
   
  +
ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:
−
{{Note|{{ic|--output}} を付けずに ''sbsign'' を実行すると作成されるファイルは {{ic|''filename''.signed}} となります。詳しくは {{man|1|sbsign}} を参照。}}
  
−
# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
  
−
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTX64.EFI ''esp''/EFI/BOOT/BOOTX64.EFI
  
   
  +
$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
−
{{Tip|
  
  +
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
−
* バイナリが署名されたかどうか確認するには: {{ic|$ sbverify --list ''/path/to/binary''}}。
  
  +
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
−
* {{AUR|sbupdate-git}} を使うことでアップデート時にカーネルを自動的に署名できます。保護されていない initramfs とカーネルコマンドラインが署名済みの UEFI イメージに組み込まれてしまう可能性があるため注意してください。
  
  +
$ 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 の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。
−
==== pacman フックを使ってカーネルに署名 ====
  
   
  +
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
−
pacman フックを使ってカーネルのインストール・アップデート時に署名することも可能です。
  
  +
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/
   
  +
変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名されたブートローダーのファイル、UEFI シェル、カーネルを ISO 9660 に追加してください:
−
{{hc|/etc/pacman.d/hooks/99-secureboot.hook|2=
  
−
[Trigger]
  
−
Operation = Install
  
−
Operation = Upgrade
  
−
Type = Package
  
−
Target = linux
  
   
  +
{{bc|
−
[Action]
  
  +
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
−
Description = Signing Kernel for SecureBoot
  
  +
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
−
When = PostTransaction
  
−
Exec = /usr/bin/sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
 +
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
  +
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
−
Depends = sbsigntools
  
  +
-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}} を起動してみてください。
−
=== ファームウェアを "Setup Mode" にする ===
  
   
  +
==== ブートローダを PreLoader に置き換える ====
−
Platform Key を削除するとき Secure Boot は Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェアのセットアップユーティリティを起動して証明書を削除・消去するオプションを探して下さい。
  
   
  +
公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。
−
=== ファームウェアに鍵を登録 ===
  
   
  +
{{Note|ISO の GRUB EFI バイナリ ({{ic|EFI/BOOT/BOOTx64.EFI}}) は {{ic|--disable-shim-lock}} でビルドされているため、shim で使用することはできません。これは GRUB の制限であり、GRUB に shim かカスタムの署名のどちらか一方との互換性を持たせることはできますが、同時に両方との互換性を持たせることはできません。}}
−
{{ic|*.cer}}, {{ic|*.esl}}, {{ic|*.auth}} を全て FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]]を使うことができます)。
  
   
−
ファームウェアのセットアップユーティリティあるいは KeyTool を起動して '''db''', '''KEK''', '''PK''' 証明書を登録してください。
 +
まず、ブートローダと El Torito ブートイメージを抽出してください。
   
  +
{{bc|
−
使用しているツールが {{ic|.auth}} や {{ic|.esl}} をサポートしている場合 {{ic|.cer}} よりも優先して使って下さい。
  
  +
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
  +
-extract_boot_images ./ \
  +
-cpx /EFI/BOOT/BOOTx64.EFI ./
  +
}}
   
  +
{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:
−
{{Warning|Platform Key を登録すると Secure Boot が "User Mode" になるため、Platform Key は最後に登録してください。}}
  
   
  +
{{bc|
−
==== ファームウェアのセットアップユーティリティを使う ====
  
  +
$ mv BOOTx64.EFI loader.efi
  +
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
  +
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
  +
}}
   
  +
新しいファイルをブートイメージに追加してください:
−
ファームウェアには様々なインターフェイスがあります。鍵を登録する例が [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] に載っています。
  
   
  +
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/
−
==== KeyTool を使う ====
  
   
  +
最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。
−
{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれているので、ESP にコピーしてください。鍵を登録した後に使用するには、{{ic|sbsign}} で署名する必要があります:
  
   
  +
{{bc|
−
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi
  
  +
$ 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 のダイジェスト値を登録する ===
−
ファームウェアのセットアップユーティリティやブートローダー、あるいは [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]で {{ic|KeyTool-signed.efi}} を起動して鍵を登録してください。
  
   
  +
[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。
−
KeyTool のメニューオプションの解説は [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を参照。
  
   
  +
{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}
−
=== 他のオペレーティングシステムとのデュアルブート ===
  
   
  +
[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。
−
==== Microsoft Windows ====
  
   
  +
{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。
−
[[Windows と Arch のデュアルブート|Windows のデュアルブート]]をするには、Microsoft の証明書を Signature Database に追加する必要があります。Microsoft は2つの db 証明書を用意しています:
  
   
  +
{{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]
−
* [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011] (Windows 用)
  
−
* [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011] (UEFI ドライバーやオプション ROM などサードパーティ製のバイナリ用)
  
   
  +
例えば:
−
Microsoft の証明書は DER 形式なので、''openssl'' で PEM 形式に変換してください:
  
   
  +
{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
−
$ openssl x509 -inform DER -outform PEM -in MicWinProPCA2011_2011-10-19.crt -out MicWinProPCA2011_2011-10-19.crt.pem
  
  +
...
−
$ openssl x509 -inform DER -outform PEM -in MicCorUEFCA2011_2011-06-27.crt -out MicCorUEFCA2011_2011-06-27.crt.pem
  
  +
- 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'' を使用してください:
−
Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って EFI 署名リストを作成してひとつのファイルにまとめます:
  
   
−
$ cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b MicWinProPCA2011_2011-10-19.crt.pem MS_Win_db.esl
 +
$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
−
$ cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b MicCorUEFCA2011_2011-06-27.crt.pem MS_UEFI_db.esl
 +
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl
−
$ cat MS_Win_db.esl MS_UEFI_db.esl > MS_db.esl
  
   
  +
複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:
−
KEK を使って db アップデートに署名してください。{{ic|sign-efi-sig-list}} に {{ic|-a}} オプションを付けて db 証明書を追加します:
  
   
  +
$ cat OpROM1.esl OpROM2.esl > OpROM.esl
−
$ 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
  
   
−
[[#ファームウェアに鍵を登録]]に従って {{ic|add_MS_db.auth}} を Signature Database に追加してください。
 +
EFI 署名リストに署名して、Signature Database に追加してください:
   
  +
$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth
−
== Secure Boot の無効化 ==
  
−
Secure Boot 機能は UEFI ファームウェアのインターフェイスから無効化することができます。ファームウェアの設定を開くには起動時に特定のキーを押下します。ファームウェアによって押すキーは違います。大抵は {{ic|Esc}}, {{ic|F2}}, {{ic|Del}}, {{ic|F''n''}} キーのどれかです。
  
   
  +
そして、[[#ファームウェアに鍵を登録する|登録してください]]。
−
ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。
  
   
  +
最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。
−
一部のマザーボード (例: Packard Bell 製ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[http://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。
  
   
 
== 参照 ==
  
== 参照 ==
   
  +
* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
 
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
  
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
−
* [http://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] by Rod Smith
 +
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
−
* [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] by 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)] by Matthew Garrett
 +
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
−
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] by James Bottomley
 +
* [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://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 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 recommendations for free operating system distributions considering Secure Boot]
 +
* [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}}

2024年4月24日 (水) 20:24時点における最新版

関連記事

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

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

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

目次

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

OS の起動前

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

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

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

OS の起動後

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

ノート: 以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。
$ bootctl
System:
      Firmware: UEFI 2.80 (American Megatrends 5.26)
 Firmware Arch: x64
   Secure Boot: enabled (user)
  TPM2 Support: yes
  Boot into FW: supported
...

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

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

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

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

6  0  0  0  1

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

# dmesg | grep -i secure
[    0.013442] Secure boot disabled
[    0.013442] Secure boot could not be determined

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 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

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

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

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

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

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

自分の鍵を使う

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

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

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

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

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

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

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

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

主要なセキュアブートの変数4つを全てバックアップするには、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 の起動前 で説明されています。

sbctl でより簡単に行う

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

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

使用するには sbctl をインストールしてください。upstream README と sbctl(8) も参照してください。

キーを作成・登録する

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

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

$ sbctl status

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

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

# sbctl create-keys

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

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

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

$ sbctl status

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

署名

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

# sbctl verify

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

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

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

ヒント: 特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。sed を使えば、sbctl によるファイルの署名を全て済ませることができます: 
# sbctl verify | sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが /boot からの相対パスであると仮定しています。

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

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

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

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

手動による手順

efitools をインストールする

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

鍵の生成

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

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

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

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

$ uuidgen --random > GUID.txt

Platform key: 

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

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

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

Key Exchange Key: 

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

Signature Database key: 

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

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

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

ヒント: dbx (forbidden signatures db) は空なので、以下の手順では省いても安全です。
警告: Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。
sbkeysync を使う

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

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

例えば、以下のように: 

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

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

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

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

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

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

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

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

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

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

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

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

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

KeyTool を使う

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

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

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

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

EFI バイナリに署名する

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

sbsigntools を使う

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

ヒント:
  • バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: $ sbverify --list /path/to/binary。
  • rEFInd ブートマネージャの refind-install スクリプトで rEFInd EFI バイナリを署名し、ESP へ db 証明書と一緒にコピーできます。手順は rEFInd#自分の鍵を使う を見てください。
ノート: sbsign を --output 無しで実行すると、出力されるファイルは filename.signed となります。詳細は sbsign(1) を見てください。

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

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output esp/EFI/BOOT/BOOTx64.EFI esp/EFI/BOOT/BOOTx64.EFI
警告: カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。sbsign で手動で署名できる結合イメージを生成する方法はユニファイドカーネルイメージ を見てください。
mkinitcpio のポストフックでカーネルに署名する

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

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

/etc/initcpio/post/kernel-sbsign
#!/usr/bin/env bash

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

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

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

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

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

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

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

sbupdate による完全に自動化されたユニファイドカーネルの生成と署名
ノート: sbupdate が作成されたのは、mkinitcpio やその他の initramfs ジェネレータにユニファイドカーネルイメージの生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、#sbctl でより簡単に行う にあるように sbctl を使用することを検討してください。

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

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

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

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

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

鍵をアップデートする

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

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

  1. 新しい鍵を作成
  2. EFI 署名リストに変換
  3. EFI 署名リストに署名
  4. 署名された証明書アップデートファイルを登録
$ cert-to-efi-sig-list -g "$(< GUID.txt)" new_db.crt new_db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db new_db.esl new_db.auth

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

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

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

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

Microsoft Windows

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

  • 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 ファームウェア実装は、bootmgfw.efi を起動せず、セキュリティ違反エラー (Selected boot image did not authenticate. Press ENTER to continue.) を発生させます: このような UEFI ファームウェア実装は、おそらく1番目の署名だけは読み込むことができるでしょうが、2番目の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
  • bootmgfw.efi ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう (bootmgfw.efi ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

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

  • 選択肢1: bootmgfw.efi のハッシュを db 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが bootmgfw.efi を変更するたびに毎回 db 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
  • 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。Microsoft は4つの db 証明書と2つの KEK 証明書を持っています (日本語訳ページ):

Microsoft の GUID (77fa9abd-0359-4d32-bd60-28f4e78f784b) を使用して Microsoft の DER 形式 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 (77fa9abd-0359-4d32-bd60-28f4e78f784b) を使って Microsoft の DER 形式 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

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

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

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): KEK 変数のアップデートを PK で署名してください。sign-efi-sig-list を -a オプションで使用してください (-a オプションは 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 セキュアブートデータベース変数に add_MS_db.auth を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、add_MS_Win_KEK.auth も登録してください。

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

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

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

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

PreLoader

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

ノート: バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。
ヒント: rEFInd ブートマネージャの refind-install スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は rEFInd#PreLoader を使う を見てください。
PreLoader をセットアップする
ノート: efitools パッケージに含まれている PreLoader.efi と HashTool.efi は署名されていないため、使い道は限られています。署名済みの PreLoader.efi と HashTool.efi を入手するには preloader-signedAUR をインストールするか 手動でダウンロード します。

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

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

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

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

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

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

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

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

フォールバック

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

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

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

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

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

# mkdir -p esp/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi esp/EFI/Microsoft/Boot/bootmgfw.efi
ノート: Windows とデュアルブートする場合、元の bootmgfw.efi はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。

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

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

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

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

  • OK を選択してください
  • HashTool のメインメニューで、Enroll Hash を選択し、\loader.efi を選んで Yes で確定してください。再び Enroll Hash と archiso を選択し archiso のディレクトリに入って、vmlinuz.efi を選択し、Yes で確定してください。そして、Exit を選択してブートデバイスの選択メニューに戻ってください。
  • ブートデバイスの選択メニューで、Arch Linux archiso x86_64 UEFI CD を選んでください。
PreLoader を除去する
ノート: 以下を実行する前にバックアップを作成すると良いでしょう。

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

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

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

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

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

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

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

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

shim

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

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

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

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

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

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

ノート: 有効な bootx64.csv が存在しない限り、fbx64.efi (同じディレクトリ内にあります) はコピーしないでください。さもないと、shim は grubx64.efi を実行せず、動作に失敗してマシンをリセットします。
# cp /usr/share/shim-signed/shimx64.efi esp/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi esp/EFI/BOOT/

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

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

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

Machine Owner Key (MOK)
EFI バイナリに署名するためにユーザが生成し利用する鍵
hash
EFI バイナリの SHA256 ハッシュ

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

shim でハッシュを使う

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

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

shim で鍵を使う

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

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

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

Machine Owner Key を作成: 

$ openssl req -newkey rsa: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
ノート: shim は 4096 RSA キーを MokList に追加できないようです (grubx64.efi バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。Debian:SecureBoot#Generating a new key を参照してください。

(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

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

/etc/initcpio/post/kernel-sbsign
#!/usr/bin/env bash

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

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

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

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

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

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

shim で鍵と GRUB を使う

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

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

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

MOK データベースは mokutil で管理できます。

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

# mokutil --list-enrolled

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

# mokutil --delete-hash <削除するハッシュ>
Input password:

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

# mokutil --delete MOK.cer

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

# mokutil --list-delete

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

shim を除去する

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

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

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

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

ヒントとテクニック

ISO の再パック

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

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

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

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

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

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

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

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

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

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

$ xorriso -indev archlinux-YYYY.MM.DD-x86_64.iso \
	-outdev archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso \
	-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

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

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

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

ノート: ISO の GRUB EFI バイナリ (EFI/BOOT/BOOTx64.EFI) は --disable-shim-lock でビルドされているため、shim で使用することはできません。これは GRUB の制限であり、GRUB に shim かカスタムの署名のどちらか一方との互換性を持たせることはできますが、同時に両方との互換性を持たせることはできません。

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

$ osirrox -indev archlinux-YYYY.MM.DD-x86_64.iso \
	-extract_boot_images ./ \
	-cpx /EFI/BOOT/BOOTx64.EFI ./

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

$ 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 を再パックしてください。 

$ 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 のダイジェスト値を登録する

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

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

TPM のあるシステムでは、TPM イベントログからオプション ROM の SHA256 ダイジェスト値を得ることができます。

tpm2-tools と digest-to-efi-sig-listAUR をインストールしてください。

tpm2_eventlog(1) を使い、/sys/kernel/security/tpm0/binary_bios_measurements から BOOT_SERVICES_DRIVER のダイジェスト値を探してください。[7]

例えば: 

# 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 から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

参照

翻訳ステータス: このページは en:Unified Extensible Firmware Interface/Secure Boot の翻訳バージョンです。最後の翻訳日は 2024-03-28 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。
「https://wiki.archlinux.jp/index.php?title=Unified_Extensible_Firmware_Interface/セキュアブート&oldid=37204」から取得