1. UEFI Secure Bootの操作
  2. UEFI Secure Bootについて

1 UEFI Secure Bootについて

オペレーティング・システムをセキュリティ保護するには、OSレイヤーの下にあるすべてのレイヤーもセキュアである必要があります。ソフトウェアを信頼してコードを正常に実行できない場合、CPU上でソフトウェアを実行することは安全ではありません。同様に、ブート・ローダーが改ざんされているか、ファームウェア自体の安全性が損なわれている場合、ブートされるカーネルを信頼することはできません。

UEFI Secure Bootは、UEFI仕様内のプラットフォーム機能であり、ハードウェア製造業者に信頼されているソフトウェアのみを使用することでシステムがブートされるようにします。セキュア・ブートでは、ファームウェアでブート・ローダーをその実行前に検証する、検証メカニズムが用意されています。このメカニズムにより、システムのファームウェアによって実行されるコードを信頼できるかどうかがチェックされます。システムの起動時、ファームウェアにより、ファームウェア・ドライバやOS自体を含むブート・ソフトウェアの各部分について署名がチェックされます。署名が有効だった場合、システムはブートされ、ファームウェアによるOSへの制御は解除されます。

セキュア・ブートでは、ブート・プロセスの早期段階で、OSがロードされる前に、暗号チェックサムおよび署名を使用して、悪意のあるコードがロードされて実行されることを防ぎます。ファームウェアによってロードされるすべてのプログラムには、署名とチェックサムが含まれ、ファームウェアによって同じ検証が行われます。セキュア・ブートでは、予期しないコードや承認されていないコードがUEFIベースの環境で動作することを防ぐために、信頼できないすべてのプログラムの実行を停止します。

ほとんどのUEFI準拠システムは、セキュア・ブートが有効になっている状態で出荷されます。これらのシステムには、Microsoftキーもロードされます。したがって、Microsoftによって署名されたバイナリもファームウェアによって信頼されます。デフォルトでは、これらのシステムでは署名のないコードは実行されません。ただし、ファームウェア構成を変更して、他の署名キーを登録するかセキュア・ブートを無効にすることができます。

セキュア・ブートでは、ユーザーが自分のシステムを制御できなくなることはありません。ユーザーは、システムに追加のキーを登録して、他のプログラムの署名を有効にできます。さらに、デフォルトでセキュア・ブートが有効になっているシステムによっては、ユーザーがプラットフォーム提供のキーを削除して、ユーザー署名されたバイナリのみをファームウェアに強制的に信頼させることもできます。

セキュア・ブート・プロセスの動作

セキュア・ブート・プロセスの各ステップでは、次のステップの実行可能ファイルに対する暗号化署名がチェックされます。BIOSでブート・ローダーの署名がチェックされた後、ブート・ローダーにより、ロードするすべてのカーネル・オブジェクトの署名がチェックされます。

通常、チェーン内のオブジェクトは、BIOS内にすでに存在する公開キーと一致する秘密キーを使用して、ソフトウェア製造業者によって署名されます。ブート・チェーン内の変更されたモジュールまたはオブジェクトの署名は一致しないため、デバイスでそのイメージをブートできなくなります。それ以外の場合、プラットフォームは正常にブートされます。

セキュア・ブートの目標を達成するには、次のものが必要です。

  • Linuxブート・ローダーは、Linuxカーネルの認証を提供する必要があります。

  • Linuxディストリビューションは、それがディストリビュートするカーネルにさらなるセキュリティの適用を提供する必要があります。

Shimの第1段階のブート・ローダー・プログラムでは、これら両方の目標を達成する方法を提供します。詳細は、Shimの第1段階のブート・ローダーの説明を参照してください。

次の図は、セキュア・ブート・プロセスを示しています。

図1-1 セキュア・ブート・プロセス


この図は、セキュア・ブート・プロセスを示しています。ブート・プロセスには、フェーズ0 (UEFI)、フェーズ1 (SHIM)、フェーズ2 (GRUB2)、フェーズ3 (LINUX)、フェーズ4 (LINUXモジュール)の5つのチェーン・フェーズが含まれます。各フェーズには検証ステップが必要です。フェーズ1では、ブート・プロセスの後続のフェーズでの検証ステップで、キーの検証の大部分がShimに渡されます。

フェーズ0: UEFIにより、セキュア・ブートが有効になっているかどうかがチェックされ、この目的のために格納されているキーが、UEFI Secure Bootキー・データベースからロードされます。

フェーズ1: Shimソフトウェアがロードされます。UEFIは、Shimの署名に使用された署名を最初に検証します。署名が有効な場合は、Shimのロードを続行できます。それ以外の場合、Shimをロードできません。その後、ロードされたShimによってすべてのコードが検証されます。Shimによって独自のMOKデータベースが維持され、そこには検証のための他のキーが格納されます。

フェーズ2: Shimソフトウェアにより、GRUB2セカンダリ・ブート・ローダーの署名に使用されるキーが検証されます。検証が成功すると、GRUB2がロードされ、Shimにより、GRUB2で使用可能なカーネル・イメージの署名に使用されるキーを検証できます。

フェーズ3: 有効なカーネルがロードされます。カーネルには、UEFI Secure Bootキー・データベースおよびMOKデータベース内のキーへの読取りアクセス権があります。カーネルには、カーネル・イメージ自体に組み込まれた独自の信頼できるキー・セットもあります。

フェーズ4: カーネルにより、kexec操作での署名付きカーネル・イメージを含む、ロードする必要がある他のすべてのモジュールの署名に使用されるキーが検証されます。カーネルの実装に応じて、カーネルによってUEFI Secure BootデータベースまたはMOKデータベース内のキーが信頼されます。または、カーネル・イメージ自体に組み込まれているキーのみが信頼されます。なお、kexec署名付きカーネル・イメージの署名検証には、UEFI、DB/MOK、DBキーおよびカーネル組込みキーを使用できます。

セキュア・ブートの制限

セキュア・ブートでは、システムとその操作に制限を実装できます。この機能は、OSのブート前に実行できるアプリケーションを制限することを目的として設計されています。これは、システムのブート後、OSには、以前にブートされたプログラムを識別したり、システムが安全にブートされたかどうかを識別する方法がないためです。たとえば、ブート前にブート・キットがシステムに注入された場合、セキュア・ブートは使用できなくなる可能性があります。または、攻撃者がセキュア・ブートを無効にし、OSによってプラットフォームのセキュリティとして解釈される可能性のあるマルウェアをインストールすると、システムが危険にさらされます。

セキュア・ブートを有効にすると、カーネル・ロックダウン機能のアクティブ化など、一部の機能やユーザー・アクションの使用が影響を受けることもあります。この機能により、実行中のカーネル・イメージへの直接アクセスおよび間接アクセスが防止され、認可されていない変更からカーネル・イメージが保護され、カーネル・メモリー内のセキュリティおよび暗号化データへのアクセスが防止されます。

ロックダウン・モードがアクティブ化されると、カーネルを変更するために通常使用する、次のような一部の機能が影響を受ける可能性があります。

  • 信頼できるキーによって署名されていないカーネル・モジュールのロード。

  • kexecツールを使用した、署名されていないカーネル・イメージの起動。

  • ハイバネーションおよびハイバネーション・モードからの再開。

  • 物理メモリーおよびI/Oポートへのユーザー・スペース・アクセス。

  • メモリーおよびI/Oポート・アドレスを設定できるモジュール・パラメータ。

  • x86_64システムでのみの、/dev/cpu/*/msrを介したMSRへの書込み。Armプラットフォームでは、/dev/cpu/*は実装されていません。

  • カスタムACPIメソッドおよびテーブルの使用。

  • Advanced Configuration and Power Interface (ACPI)およびACPI Platform Error Interface (APEI)のエラー注入。

これらの機能のいずれかを使用する必要がある場合は、システムのExtensible Firmware Interface (EFI)設定プログラムを使用して、セキュア・ブートを無効にできます。詳細は、セキュア・ブートの有効化と無効化を参照してください。

セキュア・ブート・キーについて

すべてのセキュア・ブート・キー・タイプが、公開キー・インフラストラクチャ(PKI)の例です。各キーには、暗号化に使用される2つの長い数字が含まれており、セキュア・ブートの場合はデータの認証に使用されます。

セキュア・ブートでは、秘密キーおよび公開キーを使用します。

  • 秘密キーは、ファイルの署名(EFIプログラム)に使用されます。その署名がプログラムに追加されます。

  • 公開キーは、パブリックに使用可能にする必要があります。セキュア・ブートの場合、このキーはファームウェア自体に埋め込まれるか、NVRAMに格納されます。公開キーを署名と組み合せて使用し、ファイルが変更されていないことを確認して、現在使用されている公開キーと一致するキーでファイルが署名されていることを確認することもできます。

PKIの詳細は、『Oracle Linux: 証明書と公開キー・インフラストラクチャの管理』を参照してください。

次の図は、セキュア・ブートのキーの署名および検証プロセスをより詳しく示しています。

図1-2 セキュア・ブート・キーの署名および検証プロセス


この図は、セキュア・ブートの署名および検証が実行されるプロセスを示しています。

データは秘密キーで署名されます。このプロセスでは、データのハッシュが生成され、署名者の秘密キーを使用してハッシュが暗号化されます。データを検証する必要がある場合は、署名者の公開キーを使用して署名を復号化し、署名されたデータのハッシュを取得します。データのハッシュが生成され、署名から暗号化されたハッシュと比較されます。ハッシュ間の一致は、データが署名後に変更されていないことを示します。

UEFI仕様では複数のキー・タイプが扱われていますが、X.509キーが一般的に使用されます。X.509は、暗号化キー・ペアをアイデンティティ、個人および組織と安全に関連付ける、公開キー証明書およびデジタル・ドキュメントの標準形式です。プラットフォーム・キー(PK)はX.509キーである必要があります。X.509キーは、Distinguished Encoding Rules (DER)形式で格納されます。DERキーは、base64でエンコードして、PEMファイルにテキストとして格納できます。

X.509証明書には、公開キー、デジタル署名、および証明書とその発行元である認証局(CA)に関連付けられたアイデンティティに関する情報が含まれます。公開キーと秘密キーによってキー・ペアが形成されます。秘密キーはセキュアに保持され、公開キーは証明書に含まれます。キー・ペアを使用することで、秘密キーの所有者がドキュメントにデジタル署名し、対応する公開キーを持つ他のユーザーがそれを検証できます。キー・ペアを使用すると、サードパーティは、秘密キーの所有者によってのみ復号化される公開キーで暗号化されたメッセージを送信できます。

ノート:

UEFI仕様では、キーと公開キーという用語は、キー・ペアの公開部分またはX.509証明書を意味するために使用されます。ただし、OpenSSLでは、キーという用語は、署名に使用される秘密キーです。そのため、すべてのセキュア・ブート・キーはX.509キーである必要があり、OpenSSLキーはそうではありません。

最近のカーネル・イメージでは、PKCS#7キー・タイプが使用されます。PKCS (公開キーの暗号化標準)は、デジタル署名と証明書の生成および検証のための一連の標準セットです。PKCS#7は、X.509証明書を含む署名済または暗号化されたデータを格納する方法です。PKCS#7構造化DERまたはPEM形式ファイル内に格納されているキーは引き続きX.509キーであるため、この点がわかりにくい可能性があります。ただし、ファイルの処理時のタイプおよび必要な形式は異なります。カーネル・モジュールに署名するときは、この違いに注意する必要があります。なぜなら、署名操作を実行するときに正しいツールを使用する必要があるからです。

ファームウェアには、4種類のセキュア・ブート・キーが組み込まれています。ただし、セキュア・ブートShimで使用できる5番目のキー、およびOracle Linuxカーネル・イメージに組み込むことができる6番目のキーがあります。

プラットフォーム・キー(PK)

セキュア・ブートで使用されるトップ・レベルのキー・タイプです。PKを使用すると、セキュア・ブート・キー階層を完全に制御できます。PKの所有者は、新しいPKをインストールし、キー暗号化キー(KEK)を更新できます。UEFI Secure Bootでは、通常はマザーボードの製造業者から提供される単一のPKが扱われています。このため、マザーボードの製造業者のみがシステムを完全に制御できます。PKを自分で生成したバージョンに置き換えることで、セキュア・ブート・プロセスを制御できます。

Key Exchange Key (KEK)

データベースへの入力時にファームウェアでキーが有効として受け入れられるように、キーに署名します。KEKがないと、ファームウェアでは、新しいキーが有効であるか、マルウェアによって導入されたかを検出できません。KEKがない場合、セキュア・ブートでは、データベースが静的であることが必要になります。ただし、DBXはセキュア・ブートの重要なポイントであるため、静的データベースは機能しなくなります。ハードウェアには、通常、MicrosoftのKEKとマザーボードの製造元のKEKの2つのKEKが付属しています。したがって、どちらもKEK更新を発行できます。

UEFI Secure Bootデータベース・キー(DB)

多くの場合、このキーは、ブート・ローダー、ブート・マネージャ、シェル、ドライバなど、実行するバイナリの署名または検証に使用されるため、セキュア・ブートに関連付けられています。ほとんどのハードウェアには2つのMicrosoftキーがインストールされています。1つはMicrosoftが使用するためのキーで、もう1つはShimなどのサードパーティ製のソフトウェアに署名するためのキーです。一部のハードウェアには、コンピュータの製造業者または他のパーティが作成したキーも付属しています。データベースには様々な目的に応じて複数のキーを保持できることに注意してください。また、データベースには、秘密キー(複数のバイナリの署名に使用できる)と照合される公開キーとハッシュ(個々のバイナリを記述する)の両方を含めることができます。

禁止された署名データベース・キー(DBX)

既知のマルウェアや他の不要なソフトウェアに対応するキーとハッシュが含まれています。バイナリが、UEFI Secure Bootキー・データベースとDBXの両方に含まれるキーまたはハッシュに一致する場合、DBXが優先されます。この機能により、複数の正当なバイナリの署名に使用されているため失効させたくないキーによってバイナリが署名されている場合でも、単一のバイナリを使用できないようにします。

Machine Owner Key (MOK)

DBXと同等で、このキー・タイプはブート・ローダーや他のEFI実行可能ファイルを署名し、個々のプログラムに対応するハッシュを格納するためにも使用できます。MOKはセキュア・ブートの標準部分ではありません。ただし、ShimおよびPreLoaderプログラムでは、キーとハッシュを格納するために使用されます。MOK機能は、新しく生成されたキー・ペアと、それらで署名されているカーネル・モジュールをテストするための理想的な方法です。MOKキーはMOKデータベースに格納されます。MOKデータベースについてを参照してください。

カーネル内の公開キー

カーネル・モジュールのロード時に署名をチェックするためにOSに組み込むことができるキーです。通常、CONFIG_MODULE_SIG_KEYパラメータがデフォルトから変更されていない場合、カーネル・ビルドでは、OpenSSLを使用して新しいキー・ペアが自動的に生成されます(存在しない場合)。その後、vmlinuxが構築されると、公開キーがカーネルに組み込まれます。UEK R6U2までのUEK R6のセキュア・ブート実装では、カーネルに組み込まれているキーを使用して、すべてのモジュールが署名されている必要があります。これら以前のUEK R6カーネルでは、MOKデータベースにのみ存在するキーを使用して署名されたカーネル・モジュールに、同じレベルの信頼は適用されません。

セキュア・ブート・キーの実装の説明

次の図は、Oracle Linuxでセキュア・ブート・キーの実装がどのように機能するかを示しています。

セキュア・ブート・キーの実装


この図は、セキュア・ブートでOracle Linuxのキーの実装に使用される順序を示しています。

UEFIファームウェア・レベルでは、プラットフォーム・キー(PK)はKey Exchange Key (KEK)の検証に使用され、KEKはすべてのデータベース・キー(DB)とすべてのDBXキー(DBX)の検証に使用されます。DBキーは、Shimバイナリの署名に使用されるキーを検証するためにDBXキーとともに使用されます。Shimの検証後、MOKリスト内に格納され、Shimによってロードされるキーは、後続のロード操作の検証を実行する際に信頼できます。GRUB2セカンダリ・ブート・ローダーは、MOKリスト内のキーおよび禁止されたMOKキーを含むMokListXによって検証されます。同様に、カーネルがロードされる前に、まずカーネル・イメージ・バイナリの検証がMOKリスト内のキーに対して実行されます。最後に、カーネルのロード後、kexec操作に使用されるLinuxカーネル・モジュールまたはLinuxカーネル・イメージを、MOKリストに対して、またはLinuxカーネルに直接コンパイルされた公開キーに対して検証できます。

UEK R6U3より前のUEK R6リリースでは、実装は若干異なります。カーネル・モジュールがロードされる最後の段階では、MOKリストまたはUEFI Secure Bootキー・データベースに格納されているキーでのみ署名されたカーネル・モジュールは、セキュア・ブート実装で信頼されません。かわりに、カーネルでモジュールをロードする前に、カーネルにコンパイルされたキーを使用してすべてのカーネル・モジュールに署名する必要があります。このプロセスの詳細は、unresolvable-reference.html#sb-mod-sign-kernelを参照してください。UEK R6U3以降では、MOKリストに格納されたキーで署名されたカーネル・モジュールは信頼されます。

Shimの第1段階のブート・ローダーの説明

Shimは、UEFIベースのシステムで第1段階のブート・ローダーとして機能するように設計された基本ソフトウェア・パッケージです。

UEFI Secure Bootを使用できるシステムには、通常、次の2つのキーが付属しています。

  • Microsoft Windows Production PCA 2011

  • Microsoft Corporation UEFI CA 2011

システムでセキュア・ブートが有効になっている場合、前述の2つのキーのいずれかで署名されたプログラムのみがブートされます。Shimの第1段階のブート・ローダーの場合、Oracleでは、Microsoft社に同意されたプロセスを使用して、Microsoft Corporation UEFI CA 2011のCAキーでOracleのバージョンのShimに署名します。Oracle Shim内に埋め込まれた証明書により、署名された第2段階のブート・ローダーおよびカーネルが検証されます。セキュア・ブート・キーの実装の説明を参照してください。

Oracle Linux内でのセキュア・ブートの適用方法

Oracle Linux内でのセキュア・ブートの適用には特定の制限事項があります。その大半は、セキュア・ブート・チェーンの信頼性を損なう可能性があるkexecツールを介してOracle Linuxがブート・ローダーとして使用されないようにするために実装されています。当初はsecurelevelと呼ばれ、最近はlockdownと呼ばれているこの制限により、セキュア・ブートが有効になっている場合は、rootユーザーであってもRing-0にアクセスすることはできません。

次に、Unbreakable Enterprise Kernel (UEK)およびOracle Linuxリリースでセキュア・ブートを適用する方法について詳しく説明します。

  • Unbreakable Enterprise Kernel (UEK)

    次の情報は、UEKリリースでセキュア・ブートを適用する場合に該当します。

    • UEK R4 (セキュア・レベル)

      UEK R4には、BSDスタイルのセキュア・レベルで実行中のカーネルを編集するユーザー・スペースの機能を制限するための、大まかなランタイム構成オプションの追加に基づいたツリー外パッチが含まれています。/sys/kernel/security/securelevelでランタイム構成変数を提供します。これはrootによって記述できます。

    • UEK R5 (ロックダウン)

      カーネル・ロックダウン機能は、実行中のカーネル・イメージに対する直接アクセスと間接アクセスの両方を防止するよう設計されています。この機能により、カーネル・イメージの認可されていない変更から保護します。また、カーネル・メモリーに格納されているセキュリティと暗号化データへのアクセスも防止されますが、ドライバ・モジュールのロードは引き続き許可されます。UEK R5でセキュア・ブートが有効になっている場合、ロックダウンは自動的に有効になります。

    • UEK R6およびR7 (ロックダウン)

      UEK R6では、メインラインLinux 5.4カーネル内に含まれているロックダウン機能を使用します。5.4ロックダウンには、なし、整合性および機密性の3つの異なるモードがあります。整合性に設定すると、ユーザー・スペースで実行中のカーネルを編集できるようにするカーネル機能は無効になります。機密性に設定すると、ユーザー・スペースでカーネルから機密情報を抽出できるようにするカーネル機能も無効になります。UEK R6でセキュア・ブートが有効になっている場合、ロックダウン整合性モードは自動的に有効になります。

      ノート:

      aarch64プラットフォームでは、セキュア・ブートが実装され、カーネル・イメージはUEK R7 U1から署名されています。

  • Red Hat Compatible Kernel (RHCK)

    次の情報は、Oracle Linux用のRHCKでセキュア・ブートを実装する場合に該当します。

    • Oracle Linux 7 (ロックダウン)

      Oracle Linux 7用のRHCKでは、BSDスタイルのセキュア・レベルで実行中のカーネルを変更するユーザー・スペースの機能を制限するための、UEK R4と同じ大まかなランタイム構成オプションを使用します。

    • Oracle Linux 8 (ロックダウン)

      Oracle Linux 8用のRHCKでは、UEK R5で有効になっているものよりも古いロックダウン実装を使用しますが、これは、UEK R4のBSDスタイルのセキュア・レベル実装よりも新しいものです。

セキュア・ブートの有効化と無効化

システムのEFI設定プログラムにアクセスして、セキュア・ブートを有効または無効にできます。特定のハードウェアのEFI設定プログラムを使用してセキュア・ブートを有効および無効にする手順については、製造業者による説明を参照してください。

システムUEFIの操作中に問題が発生した場合は、Shimレベルでセキュア・ブートに対する追加の検証を無効にできます。ユーザー・スペースからのセキュア・ブートに対する追加検証は無効にできますが、Shimのロード時にMokManagerユーティリティにアクセスできるよう、引き続きブート時にシステムに物理的にアクセスできる必要があります。詳細は、セキュア・ブートの無効化を参照してください。

MOKデータベースについて

MOKキーはMOKリストまたはデータベースに格納されます。データベースを使用して、カスタム・ビルド・カーネルまたはカーネル・モジュールの証明書を追加します。この場合、これらのコンポーネントの署名に使用されるキーまたはこれらのキーのCA証明書は、UEFI Secure Bootキー・データベース内に存在しません。これらのキーは、キー・チェーンをKEKデータベース内にすでに存在する別のキーに戻さなくても追加できます。キーがMOKリストに存在する場合、UEFI Secure Bootが有効になっていると、このキーは、ブートごとにシステム・キー・リングに自動的に伝播されます。

MOKキーを登録するには、UEFIシステム・コンソールのMokManagerユーティリティを使用して、各ターゲット・システムで手動で登録する必要があります。

DBXに似たMOK禁止された署名データベース(MOKx)も存在します。MOKx機能を使用すると、ユーザーは、公開キーまたは署名で識別される特定のカーネルまたはカーネル・モジュールのロードを禁止できます。また、MOKxでは、grub2/fwupd/mmx64/mmaa64/etcと同様に、Shimによってブートされる第2段階のブート・ローダーまたはバイナリも禁止されます。

MOKデータベースを使用すると、UEFI Shim内の信頼できるキーに、ユーザー・スペースからキーを直接挿入できます。MOKデータベースを使用してキーを挿入するほうが、UEFI Secure Bootキー・データベースにキーを手動で追加するよりも簡単です。オプションとして、UEFI Secure Bootキー・データベースにキーを手動で追加できます。ただし、MOKデータベースのアプローチでは、手順は特定のハードウェアに関連付けられていないため、UEFIがアクセスできるストレージにキーをコピーする必要はありません。

MOKデータベースを管理するツールはmokutilユーティリティで、このユーティリティからMokManagerにアクセスします。mokutilユーティリティについてを参照してください。