Microsoftから鍵が流出し、セキュアブートがただのブートに
Microsoftのミスにより「golden key」が流出し、セキュアブートがセキュアではなくなったとのことです。
セキュアブートを有効にしているデバイスで、理論的には、ユーザーが起動時のセキュリティーチェックを回避できるようになったとのことです。
これにより多くのデバイスで簡単にLinuxを起動できるようになるが、その一方で、ルートキットの作成にも「golden key」が利用されかねないとのことです。
「golden key」はMicrosoftが提供するデバッギングツールにうっかり含まれており、この鍵を利用すれば誰でもセキュアブートによるセキュリティーチェックを回避できるようになります。
ある特定のセキュアブートポリシーでは、セキュアブートが有効な時に、{bootmgr}を含むすべてのBCDオブジェクトに対し、testsigningが利用可能になる。
セキュアブートはUEFIの仕組みの一部であり、db内の証明書によって署名されているソフトウェアのみ起動する。
Windows RTといったデバイスの中には、ユーザーがセキュアブートを無効化出来ないデバイスが存在する。
しかし開発などいくつかの状況において、セキュアブートの形を少し変更する必要がある。
セキュアブートポリシーは、ASN.1ブロブ内に埋め込まれたバイナリーフォマットのファイルであり、署名されている。
Windows起動時、セキュアブートポリシーはbootmgrにより起動の初期段階で読み込まれる。
セキュアブートポリシーは、db内の証明書により署名されていなければならない。
セキュアブートポリシーは、セキュアブート名前空間内のUEFI変数から読み込まれる。
ポリシーを設定するため、Microsoftによって署名された.efisがいくつかあり、つまり、
.efisの内容をポリシーとしてUEFI変数に設定する。
ポリシーには2種類の異なるルールがある。
BCDルールは、ディスク上のBCDの設定を上書きできる。
レジストリールールは、ポリシー自身の設定を含み、さらに起動サービスなど他のソフトウェアの設定も含んでいる。
例えばWindows 10 version 1607（Redstone）で導入されたあるレジストリー要素を利用すると、モバイルデバイスをUSBストレージモードで動作させることが出来る。
興味深いレジストリールールは、Code Integrityの形を変えるルールである。
つまりある特定のバイナリーを有効なバイナリーとして扱うことが出来る。
しかしバイナリーは、Microsoftが言うには、db内の証明書によって署名されていなければならない。
また、DeviceIDと呼ばれる情報がある。
DeviceIDは、Windows PhoneやWindows RTでポリシーを適用するために使用される情報である。
基本的にbootmgrはポリシーが読み込まれた時にポリシーのチェックを行う。
DeviceIDがデバイスのDeviceIDを一致しない場合、そのポリシーは読み込まれない。
もし有効なポリシーがインストールされていない場合は、bootmgrは自身のリソースに収められているデフォルトのポリシーを使用する。
このポリシーはtestsigningの有効化を拒否し、BCDルールを使用する。
Windows 10 v1607（Redstone）開発時、Micorsoftは新しいセキュアブートポリシーを追加した。
それは「supplemental」ポリシーと呼ばれるもので、EFIESPパーティションに配置される。
Redstoneのbootmgr.efiは、最初にlegacyポリシーを読み込む。
legacyポリシーやEFIESPにあるベースポリシーを読み込んだ後、supplementalポリシーの内容をマージする。
何が問題か？
supplementalポリシーは、マージを行う条件のために新しい要素を含んでいる。
legacyポリシーを読み込んだ時に、これらの条件はbootmgrによってチェックされない。
そしてWindows 10 v1511以前のbootmgrは、新しい要素の存在を知らない。
それらのbootmgrは、完全に有効で、署名されたポリシーとしてポリシーを読み込む。
supplementalポリシーはベースポリシーにマージされるため、DeviceIDを含んでいない。
またBCDルールも含んでいない。
これはtestsigningを有効にできるということを意味する。
つまり、 bootmgrに署名されていない.efiの起動を可能にするということである。
できれば原文を読んでください。
