はじめに

企業として開発したアプリケーションやデバイスドライバーを信頼できる形でユーザーに配布する場合、 配布物が改ざんされておらず、確かに自社が開発したものであることを証明するする必要があります。 これを実現するのがコードサイニングであり、その仕組みを理解するには公開鍵証明書やデジタル署名についての理解が不可欠です。

この記事では、以下について解説します。

• 公開鍵証明書、デジタル署名について

• コードサイニングのしくみについて

• Windows ドライバの署名ポリシーについて

• マイクロソフト社からの署名を取得する方法について

「信頼できない」ソフトウェアとは？

普段PCを利用していて、次のような表示をみたことがある人は多いのではないでしょうか。

このダイアログは、起動したアプリケーションをWindows OSが信頼できないアプリケーションと認識した場合に、 ユーザーに本当に起動してよいのか確認をとるダイアログです。

信頼されていないというのは、そのアプリケーションがどこの誰が作成したものか不明であり、 改ざんされている可能性もある、とWindowsに判断されているということです。

では、Windowsはどういった条件で"信頼できない"と判断しているのでしょうか。 このように表示されるのは、信頼できる公開鍵証明書によるコードサイニングがされていない アプリケーションです。

信頼できる公開鍵証明書によるコードサイニング とは何なのか、 次項から、デジタル署名、公開鍵証明書、一般的なアプリケーションへのコードサイニングについて説明していきます。

デジタル署名、公開鍵証明書とは

デジタル署名(この記事では以降、単に署名)とは公開鍵暗号を使った電子署名の仕組みで、信頼性を証明したいあるデータに対してハッシュを取得し、これを秘密鍵を用いて暗号化したものです。 データを取得した側は、署名を公開鍵を用いて復号、データのハッシュと照合することで、取得したデータが改ざんされていないことを確認することができます。

公開鍵証明書（この記事では以降、証明書）とは、第三者である証明機関（認証局、CAとも呼ぶ）が発行するもので、データの作成者の身元情報と署名の復号に使う公開鍵が格納されています。 データを取得した人は証明書の公開鍵を用いて署名を復号し、データが改ざんされていないことを確認するとともに、データの作成者の身元情報を確認することができます。

証明書の種類

証明書にはその目的に応じて、次のような種類があります。

• SSLサーバ証明書
  Webサーバの信頼性を証明する。httpsプロトコルで用いられる

• クライアント証明書
  ユーザー、デバイスの信頼性を証明する。SSL-VPNやリモートアクセスで用いられる

• コードサイニング証明書
  配布するアプリケーションが改ざんされていないことと、その作成者の身元を証明する。この記事で解説

証明書にはあらかじめ拡張キー使用法(EKU)というパラメータで使用用途が設定されています。 したがって、たとえばSSL証明書を用いてコードサイニングを行うことはできません。

次項では、どのようにしてコードサイニンでが改ざんが無いことを証明しているのか、しくみを説明します。

コードサイニングのしくみ

コードサイニングの動きについて説明します。

アプリケーションを配布する側は、配布するアプリケーションのハッシュを取得し、 それに対して証明書に紐づいた秘密鍵を用いて暗号化します。 配布アプリケーション、暗号化したハッシュ（署名）、証明書のセットを配布パッケージとして配布します。

データを取得した側は、パッケージを開封すると、証明書の出処の信頼性を確認（後述の証明書チェーン参照）した後、証明書に含まれる公開鍵を用いて署名を復号します。 復号されたハッシュとアプリケーションのハッシュ値を照合し、アプリケーションが改ざんされていないことが確認されます。

証明書の出処、証明書チェーン

前述のしくみを見て気づくことですが、このしくみは証明書自体の出処が不明瞭な場合、まったく意味をなしません。 つまり、誰が発行したかわからない証明書による署名は、信頼できないということです。

Windows OSでは、マイクロソフト社が「ここは信頼できる」と指定した証明機関による証明書があらかじめインストールされています。

Cortanaで「ユーザー証明書の管理」を検索すると、証明書ストアにインストールされた証明書の一覧を確認することができます。

（証明書ストアの例）

「信頼されたルート証明機関」や「中間証明機関」などのストアを確認すると、マイクロソフト社自身やDigiCert社、GlobalSign社などが登録されていることがわかります。 これらの証明書の秘密鍵によって署名されているアプリケーションは、Windowsから信頼されます。

では、新しく発行された証明書は、どのようにしてWindowsから信頼してもらうのでしょうか。

証明書には、ある証明書の出処の信頼性を保障するために別の証明書の秘密鍵で署名する、チェーンの仕組みがあります。 Windowsは既にストアに登録済みの証明書へつながるチェーンが存在するかを確認し、新たな証明書を信頼するか決定しています。 証明機関から証明書を発行してもらった場合、その証明書にはこういったチェーンが設定されているはずです。

（証明書チェーンの例）

証明書を利用する企業の実在性

証明書の出処とは別に、証明書を利用する企業が本当に実在する企業なのか、という観点があります。

企業がコードサイニングする場合、証明機関がその企業の実在性をどれだけ強く証明するかによって、 証明書の区別が大きく分けて3段階あります。 この他にも利用目的によってはDV、IVなどの区別が存在します。

自己証明書

いわゆる「オレオレ署名」。コードの作成者が自分で発行し、証明機関とのチェーンは特にない証明書。 テスト用に用いるが、そもそも証明書のしくみが第三者による証明機関が発行していることを前提とするため、ユーザーに配布する場合は不適当。

OV（実在証明型）証明書

証明機関から購入できる比較的安価な証明書。 法人としての登録、簡単な実在確認をおこなった上で発行される。 信頼度は後述のEVよりは弱く、場合によっては信頼されないため、 アプリケーションをインターネット上で配布した場合、ユーザーが実行するとセキュリティ警告が表示される可能性がある。

EV (実在証明拡張型)証明書

証明機関から購入できる高信頼な証明書。 法人としての登録、OVよりも厳格な実在確認をおこなった上で発行される。 自己証明書による署名やOV証明書による署名よりも信頼される。 Windows SmartScreenなどのセキュリティ警告をスキップできる。

アプリケーションの作成者は必要に応じてこれらの証明書から一つを選択して取得し、署名を行うことになります。

Windows ドライバーの署名ポリシー

ここまで一般的なアプリケーションへのコードサイニングについて述べましたが、 配布したいものがWindowsドライバーの場合、別の署名ポリシーが設定されています。

デバイスドライバー(特にカーネルモードのドライバー)は、一般のアプリケーションでは不可能な Windows OS のシステム領域にアクセスすることができます。 こういったコードが改ざんやなりすましを受けるとシステム全体を乗っ取られたり、破壊されるなどの深刻な攻撃を受けることになります。 そのため、Windows OS ではカーネルモードドライバーに対して厳しいポリシーを設定しています。

具体的にどういった署名が必要か、マイクロソフト社のドライバー署名ポリシー ⧉が公開されています。

ここで重要なのは、Windows10 1607(Anniversary Update) 以降のすべてのバージョンでマイクロソフト社による署名が要件になっていることです。

(マイクロソフト社による署名の例)

実際、現行のWindows10 20H2でマイクロソフト社による署名のないドライバーをインストールしようとした場合、次のように表示され、インストールすることができません。（OSのバージョンによって表記は異なります）

（ドライバーインストール時の警告の例）

また、それ以前のバージョンのWindows OSでは信頼されている証明機関が発行している証明書を用いてAuthenticode署名 ⧉することで、カーネルモードドライバーをインストールし、動作させることができます。

署名によるWindowsバージョン別の動作は以下の通りです。

-	Windows 10 1511以前	Windows10 1607以降セキュアブートなし	Windows10 1607以降(セキュアブートあり)
自己証明書による署名	×	×	×
OV証明書による署名	〇	△	×
EV証明書による署名	〇	△	×
マイクロソフト社による署名	〇	〇	〇

• 〇…インストール・動作可能
• △…証明書ストアにインストール（ユーザー確認あり）後にインストール・動作可能
• ×…インストール・動作不可能

マイクロソフト社の署名を取得するには

前項で説明した通り、現行のWindows10でデバイスドライバーをインストール、動作させるにはマイクロソフト社の署名がほぼ必須になります。 では、どのようにして署名を取得すればよいのでしょうか。

ここでは自作したデバイスドライバーにマイクロソフト社から署名を入れてもらう方法を説明します。 大きく分けて構成証明署名、WHQLリリース署名の2パターンがありますが、どちらも

• マイクロソフト社のパートナーセンターに登録が必要

• 提出するファイルにEV証明書による署名が必要

である点は共通しています。

Windows 10 のみで動作すればよい場合、手順の簡易さから構成証明署名を取得するのがおすすめです。

構成証明署名(Windows 10の場合)

クライアント版のWindows 10でカーネルドライバーを動作させるために署名が必要な場合、 構成証明署名は後述の方法よりも簡単に取得することができます。

手順はこちら ⧉を参照してください。

メリット：

• パートナーセンターへの登録まで済めば、1度の署名にかかる時間は比較的少ない(30分~1時間程度)。

• 後述のHardware Lab Kitテストのような時間のかかるテストをする必要がない。

デメリット：

• Windows 10 でしか使えない

• UEFIファームウェアドライバーなど特殊なドライバーには使えない

WHQLリリース署名(そのほかのOSの場合など)

Windows ServerやWindows 8.1、その他のバージョンのWindows OSについてカーネルドライバーを動作させたい場合、WHQLリリース署名を取得する必要があります。 取得にはWindows Hardware Lab Kit ⧉のテストをパスした上で、 そのログとドライバーファイルをEV証明書による署名後に提出、パートナーセンターで審査 ⧉を受ける必要があります。

メリット：

• 昨今の全てのWindows バージョンで利用可能

• Windows Update等で配布可能

デメリット

• Hardware Lab Kitのテストに時間がかかる（数日単位）

• 署名審査にも時間がかかる(数日単位)

おわりに

コードサイニングについて簡単な紹介と、Windows カーネルモードドライバーへの署名について説明しました。 Windowsドライバー署名のポリシーについては、手順やポリシー自体が変わることがあるため、 この記事の内容が今後古くなることが十分にありえます。 Windowsドライバーの開発、配布などを検討している場合は、ドライバー署名のポリシーやマイクロソフト社の署名取得手段について最新の情報をよく確認することをおすすめします。

参考

• Driver Signing (ドライバーの署名):https://docs.microsoft.com/ja-jp/windows-hardware/drivers/install/driver-signing ⧉
• ドライバー署名ポリシー:https://docs.microsoft.com/ja-jp/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later- ⧉
• 一般リリースのためのカーネル ドライバーへの構成証明署名:https://docs.microsoft.com/ja-jp/windows-hardware/drivers/dashboard/attestation-signing-a-kernel-driver-for-public-release ⧉
• WHQL リリース署名:https://docs.microsoft.com/ja-jp/windows-hardware/drivers/install/whql-release-signature ⧉