ファイル改ざんや実行時アラートに対応する「コードサイニング証明書」を理解する
コードサイニング証明書（コード署名証明書）は、ベリサインなどの認証局（CA）から提供される証明書で、これを利用してソフトウェアなどのファイルに署名することでファイルの配布元を保証するとともに、ファイルの内容が改ざんされていないことを担保できる。この技術は10年以上前から利用されているが、マルウェア/アドウェアを仕込まれたコピー配布サイトの増加やWindowsにおける検証利用範囲の拡大などにより、近年では必要とされる場面が広がってきている。改めてコードサイニング証明書の現状を整理し、正確に把握していこう。
ファイル欠損・改ざんがないことを確認する基本的な方法
ファイルを入手したとき、ファイル欠損や改ざんがないことを確認するために、古くからMD5やSHAなどのハッシュを利用したファイルのチェックが行われてきた。Linuxディストリビューション配布サイトやSourceForge.JPなどのソフトウェア一次配布サイトでは、ファイル公開と同時にMD5やSHAのハッシュを明示している。これらのハッシュ値と、ツールなどを使って生成したダウンロードしたファイルのハッシュ値を比較することで、ファイルのデータに間違いがないかを確認できる。
しかし、この方法ではツールを使ってファイルをチェックするステップが必要である。また、一時配布元以外で再配布されたファイルの場合、配布元を証明する手段がない場合があり、巧妙に改ざんされた場合、MD5などのチェックを潜り抜けるということも不可能ではない。Webサイトから安全にソフトウェアを入手したい場合、最低限でも一次配布元からダウンロードを行うことが必須である。
Windows環境においてはコードサイニングによってファイルの正当性をチェック
Linuxディストリビューションなどのパッケージングシステムでは、これらの課題を解決できるような認証チェックの仕組みが用意されている。いっぽうでWindows向けソフトウェアのみを扱うサイトや紹介サイトでは、チェック手段が提供されていないことが多い。有名紹介サイトでもこのような「配布だけ」という状況は変わらず、このようなサイトからファイルをダウンロードした場合、欠損・改ざんがあってもユーザーには確認を行う手段がない。また、Webブラウズ中にアプリケーションを実行できるActiveXでは、改ざんファイルの配布や実行が即座にできてしまう。そこでOS側の仕組みとしてWindowsに導入されたのが、コードサイニングによるファイルの正当性チェックである。
コードサイニングの一般利用はWindows 2000の時代から始まり、Windows Vistaからは、ユーザーアカウント制御（UAC：User Account Control）によって、コードサイニングされていないファイルを実行した場合に警告が表示されるようになった（図2）。
さらにWindowsのドライバファイルなどカーネルモードのプログラムについては、警告だけではなくコードサイニングが必須となった。そして最新のWindows 8においては、表1のような3段構えの防御壁を築く実装となっている。
| アプリケーション | IE SmartScreen | Windows SmartScreen | UAC | |
|---|---|---|---|---|
| 署名 | レピュテーション | ダウンロード時 IE8から | 実行時1 Windows 8から | 実行時2 Windows Vistaから |
| なし | なし | 警告 | ブロック | 警告 |
| 確立 | なし | なし | 警告 | |
| あり | なし | 警告 | ブロック | なし |
| 確立 | なし | なし | なし | |
IE SmartScreenによる警告
レピュテーションが確立されていないファイルをInternet Explorer（IE）を使ってダウンロードするとき、図3のような警告画面が表示される。
Windows SmartScreenによるブロック
Windows 8からはIE以外のWebブラウザでファイルをダウンロードしたときにもチェックできるように、OS自体にもWindows SmartScreenによるチェック機構が追加されている（図4、5）。
IE SmartScreenおよびWindows SmartScreenはマイクロソフト独自のセキュリティデータベースを利用したチェック機構であり、レピュテーション（評判・評価）が確立されると警告されない仕組みである。レピュテーションの詳細仕様は公開されていないが、使われている証明書や対象ファイルに紐づいてデータが蓄積されている。コードサイニング証明書で署名されたファイルは、対象ファイルのレピュテーションに関わらず、コードサイニング証明書のレピュテーションで評価されるため、レピュテーションを確立するためには、早めにコードサイン証明書を取得して実績を積み上げておいたほうが良い。なお、証明書を更新した場合、更新当初はIE SmartScreenおよびWindows SmartScreenによる警告が表示されるが、更新証明書にも更新前のステータスが引き継がれているため、比較的短期間にレピュテーションが確立されるようだ。よって、更新時の警告によるトラブルを防ぐためには、有効期間が長いコードサイニング証明書を検討する必要がある。このようなWindows SmartScreenフィルタについては、チェックを自動パスするWindows Storeの利用促進という面もあり、まだ利用場面が限られ情報や環境が整っているとはいえず緊急ではないが、近い将来対応が迫られることは確実だ。
PDFやJavaアプレットなどにも実装
コードサイニングはWindows専用の実行ファイルだけでなく、各種WebブラウザによるJavaアプレットのチェックやAdobe ReaderによるPDFの改ざんチェックにも使われるようになっている。改ざんはLinuxやMac OSなどの環境でも無関係ではないのが現状だ。見落とされがちなのはPDF改ざんで、とくに財務情報などが含まれたIR用のPDFが改ざん・流布されてしまった場合、受け取ったユーザーはその内容を丸のみしてしまいやすい。
フリーソフトウェア配布だからこそ求められる場面も
プログラムへの改ざんにおいては、従来からよく蔓延していたスパム送信のためのマルウェアだけでなく、最近は広告や不正サイトへの誘導を埋め込んだアドウェア、オンラインバンキングの偽装画面を表示して不正送金を行う中間者攻撃タイプのマルウェアなどが非常に増えてきている。その際、感染範囲を拡大するためにフリーソフトウェアを感染源として狙う例が多い。フリーソフトウェアが持つ自由な再配布の利便性を突かれてしまっている格好だ。ユーザー側の対策としてはコピー配布サイトやソフトウェア紹介サイトを安易に利用しないということが考えられるが、いっぽうで企業側もユーザーから信頼を得るためにソフトウェアが改ざんされないための対策が必要だ。たとえば企業によってWeb上で公開されているソフトウェアがマルウェアなどの感染源として使われてしまった場合、報道等でその企業名が掲示されることでイメージダウンなどにつながるおそれがある。また、サポートコストなどのリスクも発生してしまう。そういった企業リスクも検討しておくことになる。
警告だけでも効果はあるのか？
では、コードサイニングにはどのくらいの抑止力があるだろうか？ 利用場面によってユーザーの動きは異なるため一概にはいえないものだが、日本ベリサインが調査会社のマクロミルに依頼した国内調査結果（n＝1030）にあるダウンロード時のユーザー行動によると、図6のような結果が得られている。
警告であるため完全な防止とはなっていないものの、コードサイニングは一定の抑止力にはなっていることがわかる。逆にいうと、正当なファイルであってもコードサイニングがされていないファイルは、一定数のユーザーには利用されないのだ。
コードサイニングの仕組み
コードサイニングではどのような仕組みで正当性を確認しているのだろうか？ あるファイルが改変・欠損していないと判断するためには、それを判断するための付加的な情報が必要になる。この情報は、信頼できる状態でファイル自体に埋め込まれ、かつ可搬性がなければならない。コードサイニングには、Webアクセスの暗号化通信（SSL）で用いられている公開鍵基盤と同じような3点間の認証を使った技術が使われており、図7のような仕組みでファイルをチェックしている。
コードサイニングされたファイルをチェックするOSやWebブラウザなどには、それぞれにあらかじめルート証明書が導入されている。このルート証明書とファイルに埋められた署名情報を使ってファイルのチェックを行い、そのファイルの正当性を評価するという仕組みだ。チェックをする環境には同じ認証局から発行されたルート証明書が必要であり、ルート証明書がない認証局のコードサイニングではチェックはできない。
Windowsでのルート証明書の確認
ルート証明書は、OS、Webブラウザ、PDFリーダーごとにそれぞれ異なるものが導入されている。たとえばWindows OSの場合、certmgr.mscというコマンド（Microsoft管理コンソール）で確認できる（図8）。
認証局にはいくつかのベンダーが存在するが、国内最大手は日本ベリサイン（VeriSign）である。ベリサインは公開鍵暗号技術の1つであるRSAを開発したRSAセキュリティの認証サービス部門が独立した会社で、認証サービスの開発とけん引を行ってきただけでなく、業界二番手のジオトラスト（ジオトラストのSSLの解説）も傘下に収めている。コードサイニング証明書においては、Windows用の各種ファイルのほか、Java、PDF、Adobe AIRなどに対応した製品を提供するなど、業界No.1のプラットフォームの多さと実績があるのが特徴だ。また、2012年8月からは3年間の申請・更新が可能となった。これまでは1年間のみだったため、更新作業の手間も含めたコスト削減につながっている。ベリサインのロゴについては図9を参照。セキュリティ関連では紙幣同様にロゴなどの画像イメージが重要な要素ともなるのでチェックしておきたい。
コードサイニング証明書の入手と実装手順
実際にコードサイニング証明書を入手するには、ルート証明書を発行している認証局に申し込み、審査を受け、証明書のファイルが送られてくる、という流れになる。代表的なベリサインでの入手手順を例にすると、法人の場合は第三者データベースもしくは公的書類による存在証明と電話による確認が必要だ。登記事項証明書などの公的な存在証明がない場合には、日本ベリサインにて無償で取得代行を行っている。具体的には、
- Webサイトのストアフロントからの登録申請を行う
- ベリサインにて申請団体の認証（実在性確認）を実施
- 書類送付（必要な場合）、ベリサインからの電話確認対応、費用支払い
- 証明書の取得
- 発行（配布）するファイルを用意する
- 取得した証明書をツールに登録する
- 署名ツールでファイルに署名する（署名付きファイルの生成）
となる。署名ツールはそれぞれの用途ごと標準環境に用意されており、主要なツールならびに関連ドキュメントは表2のようになっている。
| 用途 | ツール | ドキュメント |
|---|---|---|
| Windowsプログラム | signtool.exe（Windows SDK） | http://msdn.microsoft.com/ja-jp/library/8s9b9yaz.aspx |
| Java | jarsigner（Java SE） | http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/jarsigner.html |
| Adobe Acrobat | http://help.adobe.com/ja_JP/acrobat/standard/using/index.html |
署名の際、現在はタイムスタンプも同時に署名するのが一般的で、署名ツール実行の際には、タイムスタンプ用のオプション指定も入れることになる。
以上で、署名付きファイルが完成する。あとの配布などの扱いは通常のファイルと同様である。
最近の動きをチェック
最後に最近のトピックをピックアップしておこう。
まず押さえておきたいのはセキュリティ強化による仕様変更である。アメリカ国立標準技術研究所が2011年以降のセキュリティ強化仕様を示したことにより、たとえばRSAの場合2048ビット以上の鍵を使う運用になってきている。国内携帯電話のSSLなど一部の利用ジャンルでは対応が不完全であるが、Windowsにおいては2012年8月に全バージョンで1024ビット未満の鍵をブロックする修正が加えられている。
Windowsにおけるルート証明書の失効処理も変更があった。これまでWindowsにおけるルート証明書の失効処理は、Windows Updateもしくは手動で実施する形態であったが、2012年6月のアップデートからWindows全バージョンにおいて自動更新プログラムの利用が推奨となった。Windows 8では標準で自動失効処理が行われるようになっている。
このように昨今のインターネット事情を踏まえ、コードサイニングを取り巻く環境にはセキュリティ強化のための変更が積み重なっている。Windows Vista以降、不正なプログラムから積極的にエンドユーザーを守るというマイクロソフトの意向もあり、署名されていないソフトウェアをインターネットからダウンロード、インストールする際には、ユーザーに強烈な警告画面で確認させる仕様になっている。Windows 8以降もさらに強化が行われるという動きもあり、ソフトウェアに対して署名を行うことは機会損失をなくすだけでなく、企業リスク回避やユーザーへの企業責任として必須となりつつある。実際Windows 8のリリースに合わせて、証明書の更新や取得件数は増加しており、導入事例紹介などで確認できる。企業におけるソフトウェア配布を計画する際は、こういった資料を参考に、コードサイニング証明書を真剣に検討してみてはいかがだろうか。
