機械翻訳について

1 UEFI Secure Bootについて

OSをセキュアにするには、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種類のセキュア・ブート・キーが組み込まれています。 ただし、セキュア・ブート・シムでは5番目のキーを使用できますが、6番目のキーはOracle Linuxカーネル・イメージに構築できます:

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

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

Key Exchange Key (KEK)

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

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

ブート・ローダー、ブート・マネージャ、シェル、ドライバなど、実行するバイナリの署名または検証にこのキーが使用されるため、セキュア・ブートでは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キーは、DBXキーとともに使用され、Shimバイナリの署名に使用されるキーを検証します。 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

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

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

Oracle Linux内でのセキュア・ブートの適用には、特定の制限が含まれています。その大部分は、Oracle Linuxがkexecツールを介してブート・ローダーとして使用されないように実装されており、これにより、セキュア・ブートの信頼チェーンが損なわれます。 この制限はlockdownと呼ばれ、セキュア・ブートが有効な場合、rootユーザーでもRing-0にアクセスできません。

次に、Oracle Linux 8カーネル・リリースでのセキュア・ブートの適用方法の詳細を示します。
Unbreakable Enterprise Kernel (UEK)

UEKでは、カーネル・ロックダウン機能が使用されます。 この機能により、実行中のカーネル・イメージへの直接アクセスと間接アクセスの両方が防止され、許可されていない変更からカーネル・イメージが保護されます。 また、カーネルのメモリー内のセキュリティおよび暗号化データへのアクセスも防止します。

ロックダウン制限は、次の3つのモードを使用して適用されます:

  • なし: 制限は適用されません。

  • 整合性: ユーザー領域で実行中のカーネルを編集できるカーネル機能を無効にします。 このモードは、UEKでセキュア・ブートが有効になっている場合に自動的に有効になります。

  • 機密保持: また、ユーザー空間がカーネルから機密情報を抽出できるようにするカーネル機能を無効にします。

ノート:

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

Red Hat互換カーネル(RHCK)

Oracle Linux 8でRHCKを使用してセキュア・ブートが有効になっている場合、カーネルは自動的にロックダウン・モードになります。 これにより、カーネルの未承認の変更を実行するために使用できる特定のカーネル機能が制限されます。

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

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

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

MOKデータベースについて

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

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

DBXに似たMOK禁止シグネチャ・データベース(MOKx)を使用することもできます。 MOKx機能を使用すると、特定のカーネルまたはカーネル・モジュールが、そのコンポーネントの公開キーまたはシグネチャによって識別されるとおりにロードされないようにできます。 また、MOKxは、GRUB2が提供するファイル・パスgrub2, fwupd, mmx64, mmaa64,およびetcと同様に、第2ステージのブート・ローダーまたはバイナリがShimによって起動されることを禁止します。

MOKデータベースを使用して、UEFI Shimの信頼できるキーにユーザー・スペースから直接キーを挿入できます。 これは、別のオプションであるUEFI Secure Boot Key Databaseにキーを手動で追加するよりも簡単です。 ただし、MOKデータベース・アプローチでは、指示は特定のハードウェアに関連付けられず、UEFIからアクセス可能な場所にキーをコピーする必要はありません。

MOKデータベースを管理するためのツールは、MOKマネージャにアクセスするmokutilユーティリティです。 mokutilユーティリティについてを参照してください。

マシン・キーリングについて

マシン・キーリングは、UEK R7で導入された特別なカーネル・キーリングです。 セキュアなブート・プロセスに関連する証明書と公開キーが格納され、カーネル・モジュールとバイナリをセキュアに検証するために、カーネルおよびシステムレベルのサービスからアクセスできます。 マシン・キーリングにロードされた証明書は、セキュアなブート・シーケンス中にシグネチャを検証できるようにし、ファームウェア・レベルのUEFIデータベースによって実行されるキー管理を補完します。 マシン・キーリングを使用すると、セキュアなブート・フレームワーク内でシステムの整合性とコンプライアンスが維持されます。

shimブート・ローダーに埋め込まれたデフォルトのマシン所有者キー(MOK)証明書は、ブート時に自動的にマシン・キーリングに追加されます。 このメカニズムにより、カーネルはセキュアなブートの一部として、信頼できるソースからのシグネチャを検証できます。