web-dev-qa-db-ja.com

Shimはセキュアブートでバイナリをどのように検証しますか？

EFIシムローダー

shimは、実行時に別のアプリケーションを開いて実行しようとする簡単なEFIアプリケーションです。最初に、標準のEFI LoadImage()およびStartImage()呼び出しを介してこれを試みます。これらが失敗した場合（たとえば、セキュアブートが有効になっていて、バイナリが適切なキーで署名されていないため）、ビルトイン証明書に対してバイナリを検証します。これが成功し、バイナリまたは署名キーがブラックリストに登録されていない場合、shimはバイナリを再配置して実行します。

セキュアブートオプションが有効になっている場合、検証手順がどのように行われるかを理解するために読んでいます。

vmlinuz * -genericと* -generic.efi.signedの違い

セキュアブートは実際にどのように機能しますか？

Linux用EFIブートローダーの管理：セキュアブートの制御

これで手順は次のようになります。

シムは、最初にマシンのファームウェアによって実行されます。ここで、shimはブートローダーを実行する必要があります。私が理解していないのは、shimがバイナリを検証する方法ですか？たとえば、上記の引用段落では、shimは標準のEFI LoadImage()およびStartImage()呼び出しを介して他のアプリケーションを起動しようとし、これが失敗するとshimは組み込み証明書からバイナリを検証しようとします。この組み込み証明書はシムに属しますか？本質的に、シムがマシンオーナーキーマネージャー（MOK）と呼ばれるのはなぜですか？バイナリを検証するための独自のキーのデータベースがあるためです。

簡単に言うと、マシンのファームウェアには、NVRAMにバイナリを検証するための独自のキーのデータベースがあり、シムにはバイナリを検証するための独自のキーのデータベースがありますか？

ブートローダーが検証および実行された後、ブートローダーは、たとえば、ファームウェアのキーのデータベースから、ブートする必要がある署名付きカーネルのキーを見つけるためにどこを探しますか？

bootgrub2uefibootloadersecure-boot
3
direprobs

正しく推測できたように、SHIMは最初に LoadImage() および StartImage() からロードしようとします。次に、EFIは署名が一致することを検証します（内部SecureBootメカニズムの使用により）。 LoadImage()がEFI_SECURITY_VIOLATIONを返す場合、システムは内部証明書からstage2（この場合はGRUB2）のフォールバックロードを試みます。

この証明書はコンパイル時にシステムに焼き付けられます。これはこの場合Canonicalによって行われました。 この証明書 は、binwalkまたは同様のユーティリティを使用してSHIMから抽出できます。

事実上、これによりSecureBootはshimの検証済み署名をキャッシュに保存し、次にshimがGRUBが前述の証明書で署名されたことを確認できます。そうであった場合、GRUBは正常に起動します。

SHIMは可能な限りシステムキーを使用します。そのため、LoadImage()とStartImage()が最初に使用されます。動作しない場合にのみ、SHIMは独自の内部証明書でstage2をロードしようとします。このコードを見ることができます こちら （verify_bufferの一部）、handle_imageチェーンの一部で呼び出されます。

検証チェーン全体は次のようになります。

  1. システムハッシュとMOKリストを確認する
  2. バイナリが ブラックリストに載っていない であることを確認してください
  3. MOK/BIOSホワイトリスト を使用してバイナリをチェックしようとします
  4. ビルドキーとSHIM独自の内部キーで定義されている内部署名をチェックします。

MOK ManagerがMOKデータベースそのものではないことも重要です。後者は、フラッシュ中にメーカーに追加/削除するものとオペレーティングシステム（またはこの場合はshim）に追加/削除するコマンドを受け取るEFIファームウェアによって維持されます。 shimは、前述のコンパイルされたキーの非常に短いリストのみを保存してブートできるようにします。他のすべてはEFIファームウェアで処理する必要があります。

4
Kaz Wolfe