準備OK？　EVコードサイニング証明書の現状とその実際

渡辺 真次
シェア

Microsoft社が表明したコードサイニング証明書におけるSHA-1のアルゴリズムの利用期限が迫り、またWindows 10において証明書の要件が変更されるなど、証明書に関連するセキュリティ強化に変化が起こっている。本稿では、改めて証明書を取り巻く環境を整理するとともに、必須となりつつあるEVコードサイニング証明書を実際にグローバルサインから取得しながら証明書の利用方法をまとめていこう。

SHA-1からSHA-2への本格移行開始

　SSL証明書やコードサイニング証明書におけるハッシュアルゴリズムとして、これまではSHA-1がデファクトスタンダードとして利用されてきた。しかし、SHA-1に対する攻撃法は10年ほど前に発見されており、コンピュータの演算処理能力も向上してきていることから、SHA-1の強度は十分ではない状況にある。より強力なSHA-2への移行はこれまでも推奨されてきたが、最近になってOSベンダーほか、Webブラウザベンダーが加入しているCAブラウザフォーラム（CA/Browser Forum）やNIST（アメリカ国立標準技術研究所）においてSHA-1対応の打ち切り計画が発表され、WebブラウザではSHA-1への警告が実装されるところまできた。

表1 SHA-1およびSHA-2のハッシュ長（強度）
アルゴリズムハッシュ長
SHA-1160ビット
SHA-2224、256、384、512ビット

ChromeやFirefoxでSHA-1警告表示開始

　WebブラウザのHTTPS（SSL）接続ではURL欄に鍵マークが表示されるが、Google Chromeでは2014年末からSHA-1のSSL証明書の場合に鍵マークを▲と表示して警告をするようになった。

図1 Chromeにおける警告表示の概要
図1　Chromeにおける警告表示（厳密には証明書のステータスによって警告が変わるので、詳しくはSHA-1 SSLサーバ証明書　対応状況などを参照されたい）

　Mozilla FirefoxでもSHA-1のSSL証明書の利用について、Webコンソールで警告されるようになっている。

SHA-1サポートは、SSLが2016年末、コードサインが2015年末まで

　Windowsにおける証明書関連のトピックをピックアップすると、表2のようなスケジュールとなっている。

表2 Windowsに関連した証明書対応のスケジュール
時期概要
2013年11月Microsoft社におけるSHA-1廃止計画発表
2015年3月Windows 7およびWindows Server 2008 R2にてSHA-2対応のアップデート
2015年7月カーネルモードソフトウェアにMicrosoft社の署名が必要となったWindows 10の提供開始
2015年10月Microsoft社の署名を付与する開発サイトにおいて、EVコードサイン証明書の必須化
2015年12月コードサインにおけるSHA-1署名の最終期限
2016年12月SHA-1 SSL証明書利用停止

　以前はWindows 7やWindows Server 2008でSHA-2の取り扱いが完全ではなかったこともあり、SHA-2への移行には本腰を入れ難かったが、2015年3月に行われたアップデートによってWindows 7やWindows Server 2008においてもSHA-2対応し準備は整った（Windows 7 および Windows Server 2008 R2 で SHA-2 コード署名サポートを利用可能）。

　そして、SHA-1のコードサイニング証明書におけるタイムリミットは2015年末である。2016年以降に行ったSHA-1での署名は有効なものと扱われず、署名なしのソフトウェアと同じ扱いになってしまう。また、2015年以前にSHA-1で証明したソフトウェアであっても、署名日時を証明するタイムスタンプ付きの署名でないと（タイムスタンプなしでも署名自体はできる）、その署名は有効ではなくなってしまうことになっている。証明書の切り替え、新規取得時には注意しておきたいポイントである。

Windowsバージョンによるコードサインの違い

　Windowsソフトウェアへの署名は、（EV）コードサイン証明書によるものかWHQL（Windows Hardware Quality Labs、認定プログラムによる署名）によるものが、推奨もしくは必要とされていた。Windows 10からはそのポリシーが変更され、これまでとは異なる方法が追加された。バージョンごとの状況を整理すると以下のようになる。

表3 Windowsバージョンによるコードサインの違い
バージョン ソフトウェア種別 署名方法 EVによる違い
Microsoftが署名 認証局証明書による
自己署名
認定 申請
Windows Vista
Windows 7		 アプリ – – ○
ドライバ ○ – ○
Windows 8 アプリ – – ○ ブロック回避
ドライバ ○ – ○ 一部必須
Windows 10 アプリ – – ○ ブロック回避
ユーザーモードドライバ ○ – ○
カーネルモードドライバ ○ ○ × 必須

　ソフトウェアへの署名はWindows 2000のころから行われているが、Windows Vista以降は署名されていないアプリケーションには警告が表示されるようになった。

図2 UAC（ユーザーアカウント制御）による警告
図2 UAC（ユーザーアカウント制御）による警告

　また、64ビット環境では署名のないドライバのインストールはブロックされる。

図3 Windows 7における署名なしドライバのブロック
図3 Windows 7における署名なしドライバのブロック

　続いてWindows 8からはSmartScreenフィルタが導入され、Microsoft側で管理するレピュテーション（評価）で一定以上の評価が得られないと実行がブロックされるという動作になった。

図4 SmartScreenによるブロック
図4 SmartScreenによるブロック

　実行をブロックされないようにするためには、署名のあるなしにかかわらずソフトウェアの利用実績を積んで一定の評価をクリアするか、EVコードサイン証明書での署名を行うことで最初から高評価を得る必要がある。利用実績を積んでいくというのは難しいので、新規ソフトウェアでブロックされないためには、EVコードサイン証明書を利用することになる。

　またWindows 8になってからは、プリンタドライバなどのユーザーモードドライバであっても署名されていないドライバはインストールがブロックされるように変更されている。

Windows 10における証明書にかかわるポリシー変更

　Windows 10からの大きな違いは、カーネルモードドライバの署名であり、Microsoft社による署名が必須となった（MSDNブログでの解説）。

　以前はマルウェアなどでも、認証局から証明書を入手し自分で署名さえしてしまえば、システムの挙動を変えたりほかのソフトウェアのメモリを覗けるカーネルモードで動作させることができた。Windows 10からはソフトウェアの配布者（配布そのものではなくファイル製作者）をMicrosoft側で管理することで、悪意のあるソフトウェアの排除や追跡が行いやすくなる。また、Microsoftによる署名時にプログラムテストやウイルスチェックを統一的に行うことになるので、Windows 10では品質面での向上も期待できる。

Windows 10カーネルモード用の署名方法は2つ

　ポリシー変更に伴い、Windows 10におけるカーネルモードドライバの署名には、以下の2つの手段が用意されている。

  1. 従来からのハードウェア互換性プログラムによる署名
  2. 新しく用意された、開発者向けサイトでの申請による署名

　新しく用意された、開発者向けサイトにてMicrosoftに署名してもらう方法は、「ハードウェア デベロッパー センター」（Hardware Dev Center）というサイトで作業を行う。

ハードウェア デベロッパー センターのURL
https://msdn.microsoft.com/ja-JP/windows/hardware/

　このサイトでの作業においてEVコードサイン証明書が必要であるが、証明書の位置付けはコードサインとは少々異なる。ドライバへの署名のためではなく、申請者証明のためである。つまり所有者の所在も認証しているEVでなければ意味がない。なお、手続き上アーカイブファイルの送信時に署名作業があるが、ドライバ自体への署名は不要である。

　また、カーネルモードドライバにおけるEVコードサイン証明書の必須化に伴い、Hardware Dev Centerでの対応認証局の拡大も行われている。従来は2つの認証局のみの対応だったが、2015年10月時点では5社の認証局に対応している。

　このように単にソフトウェアへの署名が必要という段階は終了し、より強力な認証機構に移行していく流れは今後も続いていく。

MSDNの価格