Microsoft からの最近の「ゴールデン キー」の漏洩と、デバッグ モードの存在により、Windows デバイスでセキュア ブートが無効になることが可能になりました。 読む！
Windows ベースの OS は、もはやモバイル シーンにおけるデフォルトの最上位の選択肢ではありません。 Android のオープン ソースの性質は、OEM に多くのファンを獲得しており、その結果、最近では Windows を使用する携帯電話がますます少なくなっています。
ただし、日常生活で Windows デバイスをまだ使い続けている方には、ちょっとしたニュースがあります。 良いか悪いかは、このニュースのユースケースに対するあなたのスタンスと解釈によって決まります。
報告によると アルス テクニカ そして 登録簿 から発信されたニュースで 頭が痛くなりそうなウェブサイト (冗談ではありません)、数人の開発者 (@never_releases そして @aaaaaaaaaaaaaaaaa) は、Microsoft がデバッグ目的で組み込んだバックドアにより、Windows デバイスのセキュア ブートを無効にする可能性が開かれたことを発見しました。
セキュアブートとは何ですか?
Windows デバイスを初めて起動するとき、起動手順は次の一般的な順序で実行されます。UEFI (BIOS に代わる統合拡張ファームウェア インターフェイス) -> ブート マネージャー -> ブート ローダー -> ウィンドウズ。 UEFI にはセキュア ブート機能が存在します。 名前が示すように、 セキュアブート, デジタル署名を要求することでセキュリティを向上させることを目的としています。 次のステップに進みます。 基本的に、UEFI が予期しているキーでブートローダーが署名されていない場合、デバイスの起動手順は完了しません。
セキュア ブートはオプションの機能ですが、Microsoft は Windows 8 以降、Windows 認定を取得するためにセキュア ブートを有効にすることを必須にしました。 ここでの理由は、セキュア ブートにより、マルウェア作成者がブート手順にコードを挿入することが困難になるということでした。 ただし、セキュア ブートの副作用として、Windows マシンでのデュアル ブートが少し複雑になることが挙げられます。 2 番目の OS とそのすべての前提条件もデジタル署名する必要があるか、セキュア ブートもデジタル署名する必要があります。 無効。 これには他にも多くの問題があり、経験豊富なデュアルブートユーザーなら、私がこの段落で説明できる以上のことを知っているはずです。
現在、ユーザーがセキュア ブートを無効にしたくても無効にできないデバイスがいくつかあります。 これは、すべての Windows デバイス (含む) から主題が大幅に絞り込まれる領域です。 デスクトップ) から、Windows Phone デバイス、Windows RT デバイス、一部の Surface デバイスなどの特定の Windows デバイス、さらには ホロレンズ。 これらのエンド ユーザー デバイスには、 セキュアブートがロックオンされています、つまり、 エンドユーザーはセキュアブートに関連する部分を変更したり無効にしたりすることはできません、ひいては、Microsoft がエンド ユーザーに対して許可していない方法で OS に触れることができません。
しかし、進行中の公式開発を目的として、セキュア ブートを少し緩める必要があります。 セキュア ブートがロックされているデバイスには、セキュア ブートを無効にすることなく承認された開発に役立つセキュア ブート ポリシーが存在します。 研究しているユーザーが述べているように、このセキュア ブート ポリシー ファイルは、Windows のブート プロセスの早い段階でブート マネージャーによってロードされます。 ポリシー ファイルにはレジストリ ルールを含めることもでき、レジストリ ルールには、とりわけポリシー自体の構成を含めることができます。 繰り返しますが、ポリシー ファイルには署名する必要があり、Microsoft のみがこれらの変更をプロビジョニングできることを保証するための他の規定が存在します。
署名要素は、適用時に使用される、いわゆる DeviceID にも依存します。 私にとっては明確ではない部分がいくつかあるため、ここではブログ投稿で説明させていただきます。
また、DeviceID と呼ばれるものがあります。 これは、一部の UEFI PRNG 出力のソルト付き SHA-256 ハッシュの最初の 64 ビットです。 これは、Windows Phone および Windows RT にポリシーを適用するときに使用されます (mobilestartup によって Phone に設定され、RT で初めて起動されるときに SecureBootDebug.efi が設定されます)。 電話機では、ポリシーは EFIESP パーティション上の特定の場所に、DeviceID の 16 進形式を含むファイル名で配置される必要があります。 (Redstone では、これは UnlockID に変更されました。これは bootmgr によって設定され、生の UEFI PRNG 出力にすぎません)。
基本的に、bootmgr はロード時にポリシーをチェックします。bootmgr が実行されているデバイスの DeviceID と一致しない DeviceID がポリシーに含まれている場合、ポリシーはロードに失敗します。 テスト署名を有効にすることを許可するポリシー (MS では、これらの小売デバイスのロック解除/RDU ポリシーと呼びます) それらをインストールするとデバイスのロックが解除されます）、DeviceID（Redstone の UnlockID と その上）。 実際、このようなポリシー (Windows Phone の製品証明書によって署名された) がいくつかありますが、唯一の違いは含まれている DeviceID と署名です。 有効なポリシーがインストールされていない場合、bootmgr はそのリソースにあるデフォルトのポリシーを使用するようにフォールバックします。 このポリシーは、BCD ルールを使用したテスト署名の有効化などをブロックするポリシーです。
ここが興味深い部分です。 Windows 10 v1607 の開発中に、Microsoft は内部テストとデバッグを目的として、新しいタイプのセキュア ブート ポリシー (簡潔にするために、以降 SBP と呼びます) を作成しました。 このポリシーは本質的に「補足的」であり、DeviceID が存在しないため、その設定が既存のブート ポリシーにマージされます。 ブート マネージャーは古いタイプの SBP をロードし、その署名と信頼性を検証してから、これらの補足ブート ポリシーをロードします。 ここで問題となるのは、補足政策自体についてさらなる検証が行われていないことだ。 また、Windows 10 v1511 より前のブート マネージャーは、これらのポリシーの補足的な性質の存在を認識していないため、 完全に有効で署名されたポリシーを読み込んだかのように反応する. 繰り返しますが、この動作は内部開発のためである可能性が高く、開発者はデバイス上で行う必要があるすべての OS バージョンとマイナーな変更に署名する必要はありませんでした。
この SBP は、基本的に署名チェックの目的を無効にするため、「ゴールデン キー」と呼ばれています。 この SBP は、非アクティブ化された状態ではあるものの、意図せず小売店のデバイスに搭載されて出荷されました。 開発者はこの SBP を発見し、その発見を公表しました。 さて、SBP は次のようになります。 インターネット上に浮遊しているのを発見この特定の zip は、Windows RT デバイスに SBP をインストールするために使用されます。
これはどういう意味ですか？
補足の SBP をロードした場合は、Windows のテスト署名を有効にして、未署名のドライバーをロードできるようにすることができます。 さらに、これらのポリシーはブート手順のブート マネージャー段階の前に機能するため、注文全体のセキュリティが侵害され、未承認の (自己署名の読み取り) コードが実行される可能性があります。 これにより、許可を超えて Windows の一部を変更しようとするユーザーやマルウェア作成者にとっても、多くの可能性が開かれます。
この発見の著者らは、大失敗全体の皮肉に焦点を当てている。 Microsoft は、不正な変更を遠ざけるために特定のデバイスでセキュア ブートをロックしましたが、開発とデバッグを続行できるようにバックドアを組み込みました。 しかし、まさにこのバックドアにより、Windows を実行しているすべてのデバイスでセキュア ブートが無効になる道が開かれ、試練全体が無意味になってしまいます。
意欲的なユーザーは、Windows 専用タブレットに Linux ディストリビューション (場合によっては Android) をインストールできるだけでなく、 携帯電話への物理的アクセスを侵害すると、不本意なユーザーも悪意のあるブートキットをインストールされる可能性があります。 デバイス。 前者はすぐに飛び上がることができますが、後者はあまり自信を与えません。 これは双方向であり、セキュリティが諸刃の剣である理由を示しています。 さらに、SBP は本質的に汎用性があり、アーキテクチャに関係なくあらゆるデバイスでの使用を可能にします。 セキュア ブートを簡単にオフにできるデスクトップの場合には特に便利ではありませんが、セキュア ブートをいじることができないデバイスでは非常に有効です。
それで、修正は何ですか？
Microsoft はいくつかのパッチをリリースしましたが、開発者は問題が完全には解決されていないと主張しています。 これらのパッチをチェックアウトできます (MS16-094 そして MS16-100) を読んでから、 ブログ投稿 なぜ問題を解決しないのかについては、それ自体で説明します。 それらが正しい場合、この問題には修正やパッチの予定はありませんが、だからといって Microsoft がさらなる障害を設けようとするのを止めることはできません。
次は何？
世界には可能性があり、その一部は Windows フォーラムで検討されています。 フォーラムをチェックしてください。 Windows Phone 8 の開発とハッキング および私たちのフォーラム Windows 8、Windows RT、Surface の開発とハッキング. 見つけることもできます 一部のデバイスの命令スレッド, 他のユーザーも同じことについて議論しています。
このデバッグ バックドアの存在と SBP の漏洩は、サードパーティにとってだけでなく重要です。 ロックされた Windows デバイスの開発では、意図的に行われた場合に何が起こるかについての厳しい警告も示されています。 バックドアは残っています。 最近のセキュリティへの関心は、法的捜査を支援するためにそのようなバックドアの存在を求める捜査機関に向けられていました。 しかし、遅かれ早かれ、これらの方法は 意思 間違った手に落ちてしまいます。 犯罪と闘い、正義を支援するためのツールとして使用されることを目的としていたものが、いつかは犯罪そのもののツールになってしまうのです。
Debug SBP の漏洩についてどう思いますか? このような「黄金の鍵」は存在すべきだと思いますか? 以下のコメント欄でお知らせください。