UEFI SecureBootを使いこなす

これらの約束は、特にUEFIセキュリティに関する作品の最後の部分で最初に行われ、その後ZeroNights 2015シーンから繰り返される場合に満たす必要があります。今日は、Microsoftの利益のためにUEFI SecureBootを機能させない方法について説明します。デフォルトですが、私たちのために。

SecureBootの独自のキーを生成する方法、標準のキーの代わりに(またはそれらを使用して)キーをインストールする方法、お気に入りのEFIブートローダーに署名する方法、未署名または他の人のキーコードによって署名されたダウンロードを禁止する方法、SecureBoot for AMIを設定するためのインターフェイスに興味がある場合、InsydeとPhoenix、そしてなぜこれが全体的に重要ではないのか-カットへようこそが、多数の写真と長いコンソールコマンドに注意してください。



はじめに



前述のopusの第5部の冒頭でSecureBootがどのように機能し、どのように機能するかについては既に説明しましたが、繰り返す必要はありません。 このUEFI SecureBootのすべて、 PKKEKdbdbxが何であるかがわからない場合、およびSecureBootの観点から見ると、UEFIメーカーがデフォルトでシステムの所有者であり、Microsoftが唯一の許可ユーザーです。ここでお待ちします。



これで教育プログラムは終了しました。 キーの作成とSecureBootの設定については、過去3年間に多数の優れた記事(文献セクションで提供されているものへのリンク)で書かれてきましたが、まだそこにあります。 英語圏のネットワークセグメント(Runetは言うまでもありません)でもSecureBootをセットアップすることに関する情報の主な問題は、ほとんどの記事、テキスト、投稿が「ここでEFI署名リスト形式のキーがあり、ファームウェアベンダーに依存する方法で追加する」ことです準備ができています。」 同時に、ベンダー自身も、OEMプラットフォームのドキュメントでもエンドシステムのマニュアルでもSecureBootセットアップメニューを説明することを急いでいません。その結果、ユーザーはなじみのない領域で失われ、SecureBootを無効にします。または、デフォルト設定のままにします(そして、Windowsが同じものを読み込んでいます)。 この最後のステップで詳細に説明しようとしますが、残りの必要なステップを犠牲にすることはありません。



テスト構成



この記事のために、Phoenix SCTおよびInsyde H2Oプラットフォームのファームウェアを搭載したいくつかのそれほど新しくないラップトップをビンから取り出し、AMI AptioVプラットフォームのまったく新しいcongatecボード(現在ファームウェアを開発中)を取り出しました。 テストベンチをご覧ください:



1 AMI 、「 三角形 」: congatec conga-TR3 @ conga-TEVAL 、AMD RX-216GD(Merlin Falcon)、AMI AptioV(UEFI 2.4)



2Insyde 、「 正方形 」: Acer Aspire R14 R3-471T (Quanta ZQX) 、Intel Core i3-4030U(Ivy Bridge)、Insyde H2O(UEFI 2.3.1C)



フェニックス 、「 半円形 」: Dell Vostro 3360 (Quanta V07) 、Intel Core i7-3537U(Ivy Bridge)、Phoenix SCT(UEFI 2.3.1C)



SecureBootをセットアップするためのインターフェイスについて



上記のすべてのシステムで、製造業者はUEFI SecureBootテクノロジーのサポートを主張していますが、それをセットアップするためのインターフェースはシステムによって大きく異なります。 幸いなことに、これはそれほど大きな問題ではありません。なぜなら、UEFI 2.3.1C準拠(およびより新しい)ファームウェア SecureBootを構成するためには、現在のPKを削除する機能以外のセットアップにはインターフェイスがありません (つまり、SecureBootをいわゆるセットアップモードに移行するからです) 必須はありません 。その後、ユーザーが提供するデータでgRS-> SetVariable UEFIサービスを呼び出すことができるEFIアプリケーションを使用できます。これには、キー管理用に特別に設計されたefitoolsパッケージのKeyTool.efiユーティリティが含まれます使用する。

それにもかかわらず、チューニングに便利なインターフェースがある場合(私の意見では、AMIにはKeyToolよりもさらに便利です )、それを使用することができます。

UEFIスクリーンショットについての一言
GOP 、ConIn / ConOut、DevicePathの汎用性のおかげで、座って30分で簡単なDXEドライバーを作成できます。これにより、ホットキーを押して(ドライバー)が読み込まれた後、グラフィカルコンソールで発生するすべてのものからBMP形式の素晴らしいスクリーンショットを取得し、 FAT32 FSを使用して最初のUSBスティックに保存します...しかし、最初に書き込み、デバッグしてから、ファームウェアに統合して、バラバラにならないようにします(ラップトップでは、ファームウェアでマイクロサーキットをはんだ付けし、プログラマーの下に置く必要があります)なに さらに、私が制御するAptioVからは、ターミナルとコンソールのシリアルリダイレクトを使用してスクリーンショットを撮ることができ、残りの部分には文字通り2つまたは3つの画面があり、モニターから写真を撮ることができます。これらの曲がった写真と彼が怠け者のお尻であるという事実のためのあなたの謙虚な使用人。


橋頭aを準備しています



さまざまなオペレーティングシステムに必要なソフトウェアの可用性に関する余談から始めましょう。 Microsoftはこの技術の開発者の1人であるという事実にもかかわらず、Windowsから操作するための通常の手段はまだありません(キーはWindows SDKのMakeCertユーティリティで生成できます。 。 最初はQtで必要なユーティリティを使用して作成することを考えましたが、毎日キーと署名を生成する必要はなく、既存のソリューションで数回は十分だと判断したためです。 必要に応じて、コメントで私を納得させることができます。

一般的に、以下のすべてについて、Linuxが必要です(Linuxがインストールされていない場合は、LiveUSBで実行できます)。 彼のためにSecureBootを操作するための2つのユーティリティセットがあります: efitools / sbsigntoolEFIKeyGen / pesignです。 私は最初のセットで前向きな経験を持っているので、それについてです。

その結果、Linuxのほかに、いくつかのものが必要です。

1.キーペアを生成し、証明書をDERからPEMに変換するためのopensslパッケージと同じ名前のユーティリティ。

2. efitoolsパッケージ、またはユーティリティcert-to-efi-sig-list 、証明書をESL形式に変換してこの形式のファイルに署名するためのsign-efi-sig-list 、およびSetupModeにあるシステムキーを管理するためのKeyTool.efi 。

3. sbsigntoolパッケージ、またはUEFI実行可能ファイル(つまり、ブートローダー、DXEドライバー、OptionROM、およびUEFI Shell用のアプリケーション)にキーで署名するためのsbsignユーティリティ。

Linuxをダウンロードし、上記のパッケージをインストールし、ホームディレクトリでターミナルを開き、次の手順に進みます。



SecureBoot用の独自のキーを生成します



いつものように、何かを行うにはいくつかの方法があり、ツールがより強力になればなるほど、そのような方法が増えます。 ツールとしてのOpenSSLは非常に開発されているため、すべてを実行できるように思えます。 したがって、この記事では、キーファイルを直接生成することに限定し、独自のCAを作成することを中心に独自の研究を行うようにます。



キーペアを生成する
キーは、PK、KEK、およびISKの 3つのピースを生成する必要があります。

PKから始めましょう。PKを生成するには、次のことを行う必要があります。

openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Platform Key" -keyout PK.key -out PK.pem
      
      



次に、パスワードを入力して確認します。パスワードは、作成された秘密キーで何かに署名しようとするときに尋ねられます。

上記のコマンドを使用して、PK.keyファイルへの秘密鍵出力とPK.pemファイルへの公開鍵を使用して、プラットフォームキーと呼ばれる1年間の有効期間を持つRSA2048 / SHA256キーペアを生成するようOpenSSLに要求します。 -nodesを追加する場合、このキーペアで署名するためのパスワードは必要ありませんが、ここではこれを行いません-少なくともあまり多くはありませんが、より安全です。

同様に、KEKとISKのキーペアを生成しますが、異なるパスワードを入力することをお勧めします。

 openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Key Exchange Key" -keyout KEK.key -out KEK.pem
      
      



 openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Image Signing Key" -keyout ISK.key -out ISK.pem
      
      





公開鍵をESL形式に変換する
次に、公開キーをPEM形式からわかりやすいUEFI SecureBoot ESL形式に変換する必要があります。 このバイナリ形式は、UEFI仕様 (現在のバージョン2.5のセクション30.4.1)で説明されおり、そのファイルは連結によって相互に接続できるという点で興味深いものであり、この事実は依然として有用です。

 cert-to-efi-sig-list -g "$(uuidgen)" PK.pem PK.esl
      
      



 cert-to-efi-sig-list -g "$(uuidgen)" KEK.pem KEK.esl
      
      



 cert-to-efi-sig-list -g "$(uuidgen)" ISK.pem ISK.esl
      
      



-gスイッチは、 uuidgenユーティリティを実行し、その出力を使用して取得した生成されたESLファイル(この場合はランダムなもの)にGUIDを追加します。 このユーティリティがない場合は、GUIDを自分で作成するか、デフォルト値のままにしてください。



ESLファイルに署名する
SecureBootが正常に機能するためには、PK自体が署名され、KEKがPKによって署名され、dbおよびdbxリポジトリがKEKによって署名されている必要があります。 同時に、複数のPKが存在しない場合もありますが、複数のKEKが存在する状況は自然に見つかりますが、MicrosoftのプリインストールキーをKEKから削除することをお勧めします。 .e。 MSキーがそこから削除されない場合、MSはdbおよびdbxのコンテンツを管理する機会があります。 トラステッドブートリストに新しいキーまたはハッシュを追加し、そこから既存のものを削除します。 私の意見では、これは少し多すぎるので、キー管理を自分の手に渡せば、最後までこれを行う必要があります。
そうでないと思うなら
さて、 ここ直接道があります 。セクション1.3.4.3の最後に、DER形式のMicrosoft Corporation KEK CA 2011証明書へのリンクがあります。そこから最初にPEMコマンドを取得する必要があります

 openssl x509 -in MicCorKEKCA2011_2011-06-24.crt -inform DER -out MsKEK.pem -outform PEM
      
      



次に、コマンドで結果のPEMをESLに変換します

 cert-to-efi-sig-list -g "$(uuidgen)" MsKEK.pem MsKEK.esl
      
      



次に、コマンドで結果のファイルをKEK.eslファイルに追加します

 cat KEK.esl MsKEK.esl > NewKEK.esl
      
      



 mv -f NewKEK.esl KEK.esl
      
      



これで、Microsoftはあなた自身と同じプラットフォームの承認されたユーザーになりました。
一方、Microsoftキーで署名されたWindowsおよびMicrosoft実行可能コンポーネント(外部ビデオカード用のGOPドライバーや外部ネットワークカード用のPXEドライバーなど)を起動する機能を失いたくない場合は、ISK.eslにいくつかのキーを追加する必要があります-キーMicrosoft Windows Production CA 2011 、MSが独自のブートローダーに署名しMicrosoft UEFIドライバーがサードパーティコンポーネントが署名するCAキーに署名します(ちなみに、Shimブートローダーに署名しました。これにより、すぐにSecureBootをサポートするさまざまなLinuxディストリビューションが開始されます)

シーケンスは、上記のネタバレと同じです。 DERからPEMに変換し、次にPEMからESLに変換してから、db.eslに追加します。最終的に、KEKの任意のキーで署名する必要があります。

 openssl x509 -in MicWinProPCA2011_2011-10-19.crt -inform DER -out MsWin.pem -outform PEM
      
      



 openssl x509 -in MicCorUEFCA2011_2011-06-27.crt -inform DER -out UEFI.pem -outform PEM
      
      



 cert-to-efi-sig-list -g "$(uuidgen)" MsWin.pem MsWin.esl
      
      



 cert-to-efi-sig-list -g "$(uuidgen)" UEFI.pem UEFI.esl
      
      



 cat ISK.esl MsWin.esl UEFI.esl > db.esl
      
      





PKに自分で署名します。

 sign-efi-sig-list -k PK.key -c PK.pem PK PK.esl PK.auth
      
      



PKキーでKEK.eslに署名します。

 sign-efi-sig-list -k PK.key -c PK.pem KEK KEK.esl KEK.auth
      
      



キーKEKを使用してdb.eslに署名します。

 sign-efi-sig-list -k KEK.key -c KEK.pem db db.esl db.auth
      
      





まだ疲れていない場合は、dbに他の何かを追加したり、dbxリポジトリを作成したりできます。必要なコマンドがわかったので、それ以降はすべて自由に判断できます。



ブートローダーに署名する
キーを追加した後、SecureBootの動作を確認するために、ISKキーでいくつかの実行可能ファイルに署名します。 テストについては、 RU.efiユーティリティに署名することをお勧めします。これはグラフィックで明るく、遠くからでも起動したかどうかを確認できます。 実際、このユーティリティは非常に強力であり、あなたはそれに対して多くの良いこととあまり良くないことをすることができますので、テスト後にそれを削除し、将来ダウンローダーのみに署名することが最善です。

いずれにしても、実行可能ファイルは次のコマンドで署名されます。

 sbsign --key ISK.key --cert ISK.pem --output bootx64.efi RU.efi
      
      



ここで、同時に、実行可能ファイルの名前をbootx64.efiに変更しました。このファイルは、FAT32 FSを搭載したテストUSBドライブの/ EFI / BOOTディレクトリに配置する必要があります。 32ビットUEFIの場合(ランダムに作業を行わないようにするため) bootia32.efiおよびRU32.efiを使用します。



このすべての結果として、dv、 KEK 、およびPK NVRAM変数に、その順序で「そのまま」書き込む必要がある3つの.authファイルがあります。 /usr/share/efitools/efi/KeyTool.efi/EFI/BOOT/bootx64.efiとして機能するFAT32 FSを使用して、3つのファイルすべてを別のUSBドライブのルートにコピーします( 念のため、ルートにもコピーします) )と「SecureBoot tamer kit」の準備ができました。



じゃじゃ馬ならし



すべて同じ方法で開始します。キーとKeyToolを備えたUSBフラッシュドライブを空きUSBポートに挿入し、マシンの電源を入れ、BIOSセットアップに進みます。 ここで、SecureBootをセットアップする前に、 CSMを無効にする必要があります。これにより、当社の技術と互換性のないレガシーブートが必要になります。 また、BIOSセットアップログインのパスワードをより確実に設定してください。そうしないと、SecureBootを無効にするだけでバイパスできます。IPMIやAMTを使用する一部のシステムでは、物理的な存在さえ必要ありません。



AMI AptioV
AMIコードに基づくほとんどのファームウェアには、[セキュリティ]タブにSecureBootテクノロジ管理があります。私にとって、この管理は次のようになります。



キー管理メニューに移動し(以前は同じタブにありましたが、現在は別のタブに割り当てられています)、次のように表示されます。



必要な変数を選択した後、最初に新しいキーをインストールするか既存のキーに追加するかを選択するために最初に選択し、最初のキーを選択します。



デフォルト値を設定するか、ファイルから独自の値をロードして、最後の値を選択することが提案されています。



次に、デバイスとその上のファイルが必要です。次に、このファイルの形式を選択します。この場合は、認証済み変数です。



次に、ファイルの更新を確認する必要があります。その前にすべてがうまくいった場合、結果として簡潔なメッセージが表示されます。



KEKとPKについても同じことを繰り返し、出力で次の状態を取得します。



そうです、単一のPK、KEKに1つのキー、dbに3つのキーがあり、Escボタンで前のメニューに戻り、SecureBootをオンにします。



完了、設定を保存し、再起動して終了します。その後、フラッシュドライブから起動して、次の画像を表示します。



さて、署名されていないブートローダーはフォレストを通過しますが、署名されたことを確認するために残ります。 別のUSBフラッシュドライブを挿入して再起動すると、次のように表示されます。



これで、SecureBootが正常に機能すると言うことができます。

AMI UEFIにキーを追加するためのそのようなインターフェイスがない場合は、さらに別の方法が適しています。



Insyde H2O
ここでは、すべてが前のケースよりもいくらか悪化しています。 独自のキーを追加するためのインターフェイスはなく、SecureBootをセットアップするためのオプションは3つだけです。SecureBootをセットアップモードに移行してすべての変数を一度に削除するか、dbにハッシュを追加して起動できる実行可能ファイルを選択しますKEKのAcerとMSのキー、およびdbのAcerとMSの多くのキーによって、まったく署名されていない場合、またはこのマシンのAcerのPKである標準キーに戻る場合

ただし、インターフェースはありません。まあ、それについては、 KeyToolがあります。主なことは、セットアップモードに移動できることです。 興味深いことに、スーパーバイザーパスワードが設定されていない場合、BIOSセットアップはSecureBootを有効にしないため、最初にインストールしてからキーを消去します。



その後、隣接する[ブート]タブで、UEFIブートモードを選択し、SecureBootを有効にします。



なぜなら 真夜中の写真は耐えられないほど嫌なものになり、 KeyToolのスクリーンショットが表示され、以前のシステムでそれを実行します。このシステムではすべてが同じに見えると信じる必要があります。

メディアからKeyToolを起動すると、次のようなものが表示されます。



[キーの編集]を選択し、ストレージ選択メニューに入ります。



そこで、まずdbを選択し、次にキーを交換し、次にUSBデバイス、そしてファイルを選択します。



Enterキーを押すと、成功メッセージは表示されず、ストレージ選択メニューが再び表示されます。 最初にKEKに対して同じことを繰り返し、次にPKに対しても繰り返します。その後、Escをダブルクリックしてメインメニューを終了します。 車の電源を切り、再び電源を入れ、 KeyToolを再度ダウンロードして、そのような画像を確認します(ファームウェアダンプから取り出した、光沢のある画面の写真は以前のものよりもさらに悪夢です)。



さて、SecureBootの一部は動作し、もう一方はRU.efiの起動によってチェックされます。RU.efiは私たちが署名したもので、動作します。 このシステムにWindows 8をUEFIモードでインストールしているため、Microsoftは証明書で失敗しませんでした。



フェニックスSCT
機会はさらに少なく、[セキュリティ]タブの[セキュアブート構成]メニュー全体には2つの項目しかありません。標準モードに戻り、セットアップモードで変換されたシステムですべてのキーを削除します。



次に、[ブート]タブで、UEFIブートタイプを選択し、SecureBootを有効にして、KeyToolのブートレコードを作成する必要があります。そうしないと、このプラットフォームでは機能しません。



[はい、変更を保存して終了し、再起動し、ロード時にF12を押してブートメニューに移動します。そこからKeyToolを選択します。この操作については上記で説明しています。 キーを追加して再起動すると、 KeyToolの再起動はのように終了します。



同時に、同じマシンにインストールされたLinux 署名しRU.efiのように適切にロードし続けるため、 SecureBootは機能していると見なすことができます。



おわりに



その結果、オープンソースユーティリティのおかげで、3つの異なるベンダーのUEFIを搭載したシステムでSecureBootを取得し、独自のキーを生成して、必要な実行可能ファイルに署名することができました。 プラットフォームを完全にロードすることは私たちの手にありますが、BIOSパスワードが強力でクリアテキストで保存されていない場合や、SecureBoot実装では既知の(またはまだ不明な)ホールはありません。 SecureBoot自体はブートキットの万能薬ではありませんが、これを使用すると、セキュアブートを使用する場合よりも、セキュアブートを使用する場合の方がはるかに優れています。

この資料がお役に立てば幸いです。このフットクロスを読んでくれてありがとう。



文学



Linux用EFIブートローダーの管理:SecureBootの制御

AltLinux UEFI SecureBoot mini-HOWTO

自己署名Linuxカーネルの起動

SakakiのEFIインストールガイド:SecureBootの構成

Ubuntuセキュリティチーム:SecureBoot

Windows 8 UEFIプラットフォームの所有

MinnowBoard Max:クイックスタートUEFIセキュアブート

Windows 8.1セキュアブートキーの作成と管理のガイダンス



All Articles